dubbo架构与实战

1.dubbo概述

1.1 概念

一款高性能rpc框架，前身是阿里巴巴开源的一个高性能、轻量级的开源框架，可以和spring无缝集成。

1.2 特性

参考官网：https://dubbo.apache.org/zh/docs/quick-start/

1.3 服务治理

服务治理（SOA governance），企业为了确保项目顺利完成而实施的过程，包括最佳实践、架构原则、治理规程、规律以及其他决定性的因素。服务治理指的是用来管理SOA的采用和实现的过程。

2.dubbo处理流程

虚线代表异步调用实线代表同步访问
蓝色虚线是在启动时完成的功能
红色虚线是程序运行中执行的功能

调用流程:
服务提供者在服务容器启动时向注册中心注册自己提供的服务
服务消费者在启动时向注册中心订阅自己所需的服务
注册中心返回服务提供者地址列表给消费者如果有变更注册中心会基于长连接推送变更数据给消费者服务消费者从提供者地址列表中基于软负载均衡算法选一台提供者进行调用如果调用失败则重新选择一台
服务提供者和消费者在内存中的调用次数和调用时间定时每分钟发送给监控中心

3.服务注册中心zookeeper

通过前面的Dubbo架构图可以看到，Registry（服务注册中心）在其中起着至关重要的作用。Dubbo官方推荐使用Zookeeper作为服务注册中心。Zookeeper是ApacheHadoop的子项目，作为Dubbo服务的注册中心，工业强度较高，可用于生产环境，并推荐使用。

Zookeeper的安装及其使用见上一模块，此处不再赘述。

4.dubbo开发实战

4.1 示例代码

https://gitee.com/ixinglan/dubbo-demo.git

4.2 配置方式

示例代码中有相关配置,这里不做过多介绍

注解
基于注解可以快速的将程序配置，无需多余的配置信息，包含提供者和消费者。但是这种方式有一个弊端，有些时候配置信息并不是特别好找，无法快速定位
XML
一般这种方式我们会和Spring做结合，相关的Service和Reference均使用Spring集成后的通过这样的方式可以很方便的通过几个文件进行管理整个集群配置。可以快速定位也可以快速更改。
基于代码方式
基于代码方式的对上述配置进行配置。这个使用的比较少，这种方式更适用于自己公司对其框架与Dubbo做深度集成时才会使用。

5.dubbo管理控制台dubbo-admin

主要包含：服务管理、路由规则、动态配置、服务降级、访问控制、权重调整、负载均衡等管理功能

如我们在开发时，需要知道Zookeeper注册中心都注册了哪些服务，有哪些消费者来消费这些服务。我们可以通过部署一个管理中心来实现。其实管理中心就是一个web应用，原来是war(2.6版本以前)包需要部署到tomcat即可。现在是jar包可以直接通过java命令运行。

1.从git 上下载项目 https://github.com/apache/dubbo-admin 
2.修改项目下的dubbo.properties文件 注意dubbo.registry.address对应的值需要对应当前使用的Zookeeper的ip地址和端口号 
	dubbo.registry.address=zookeeper://zk所在机器ip:zk端口
	dubbo.admin.root.password=root 
	dubbo.admin.guest.password=gues
3.切换到项目所在的路径 使用mvn 打包 mvn clean package -Dmaven.test.skip=true 
4.java 命令运行 java -jar 对应的jar包

6.dubbo配置项说明

6.1 dubbo:application

对应 org.apache.dubbo.confifig.ApplicationConfifig, 代表当前应用的信息

1. name: 当前应用程序的名称，在dubbo-admin中我们也可以看到，这个代表这个应用名称。我们
在真正时是时也会根据这个参数来进行聚合应用请求。
2. owner: 当前应用程序的负责人，可以通过这个负责人找到其相关的应用列表，用于快速定位到责
任人。
3. qosEnable : 是否启动QoS 默认true
4. qosPort : 启动QoS绑定的端口 默认22222
5. qosAcceptForeignIp: 是否允许远程访问 默认是false

6.2 dubbo:registry

org.apache.dubbo.confifig.RegistryConfifig, 代表该模块所使用的注册中心。一个模块中的服务可以将其注册到多个注册中心上，也可以注册到一个上。后面再service和reference也会引入这个注册中心。

1. id : 当当前服务中provider或者consumer中存在多个注册中心时，则使用需要增加该配置。在一些公司，会通过业务线的不同选择不同的注册中心，所以一般都会配置该值。
2. address : 当前注册中心的访问地址。
3. protocol : 当前注册中心所使用的协议是什么。也可以直接在 address 中写入，比如使用zookeeper，就可以写zookeeper://xx.xx.xx.xx:2181 
4. timeout : 当与注册中心不再同一个机房时，大多会把该参数延长。

6.3 dubbo:protocol

org.apache.dubbo.confifig.ProtocolConfifig, 指定服务在进行数据传输所使用的协议。

1. id : 在大公司，可能因为各个部门技术栈不同，所以可能会选择使用不同的协议进行交互。这里在多个协议使用时，需要指定。
2. name : 指定协议名称。默认使用 dubbo 。

6.4 dubbo:service

org.apache.dubbo.confifig.ServiceConfifig, 用于指定当前需要对外暴露的服务信息，后面也会具体讲解。和 dubbo:reference 大致相同。

1. interface : 指定当前需要进行对外暴露的接口是什么。
2. ref : 具体实现对象的引用，一般我们在生产级别都是使用Spring去进行Bean托管的，所以这里面一般也指的是Spring中的BeanId。 
3. version : 对外暴露的版本号。不同的版本号，消费者在消费的时候只会根据固定的版本号进行消费。

6.5 dubbo:reference

org.apache.dubbo.confifig.ReferenceConfifig, 消费者的配置

1. id : 指定该Bean在注册到Spring中的id。 2. interface: 服务接口名
3. version : 指定当前服务版本，与服务提供者的版本一致。
4. registry : 指定所具体使用的注册中心地址。这里面也就是使用上面在 dubbo:registry 中所声
明的id。

6.6 dubbo:method

org.apache.dubbo.confifig.MethodConfifig, 用于在制定的 dubbo:service 或者 dubbo:reference 中的更具体一个层级，指定具体方法级别在进行RPC操作时候的配置，可以理解为对这上面层级中的配置针对于具体方法的特殊处理。

1. name : 指定方法名称，用于对这个方法名称的RPC调用进行特殊配置。
2. async: 是否异步 默认false

6.7 dubbo:service和dubbo:reference详解

这两个在dubbo中是我们最为常用的部分，其中有一些我们必然会接触到的属性。并且这里会讲到一些设置上的使用方案。

1. mock: 用于在方法调用出现错误时，当做服务降级来统一对外返回结果，后面我们也会对这个方法做更多的介绍。
2. timeout: 用于指定当前方法或者接口中所有方法的超时时间。我们一般都会根据提供者的时长来具体规定。比如我们在进行第三方服务依赖时可能会对接口的时长做放宽，防止第三方服务不稳定导致服务受损。
3. check: 用于在启动时，检查生产者是否有该服务。我们一般都会将这个值设置为false，不让其进行检查。因为如果出现模块之间循环引用的话，那么则可能会出现相互依赖，都进行check的话，那么这两个服务永远也启动不起来。
4. retries: 用于指定当前服务在执行时出现错误或者超时时的重试机制。
    1. 注意提供者是否有幂等，否则可能出现数据一致性问题
    2. 注意提供者是否有类似缓存机制，如出现大面积错误时，可能因为不停重试导致雪崩
5. executes: 用于在提供者做配置，来确保最大的并行度。
    1. 可能导致集群功能无法充分利用或者堵塞
    2. 但是也可以启动部分对应用的保护功能
    3. 可以不做配置，结合后面的熔断限流使用

其他配置见官网https://dubbo.apache.org/zh/