二、Dubbo 的架构

1.Dubbo 的架构图解

上述节点简单说明：

• Provider： 暴露服务的服务提供方

• Consumer： 调用远程服务的服务消费方

• Registry： 服务注册与发现的注册中心

• Monitor： 统计服务的调用次数和调用时间的监控中心

• Container： 服务运行容器

调用关系说明：

1. 服务容器负责启动，加载，运行服务提供者。

2. 服务提供者在启动时，向注册中心注册自己提供的服务。

3. 服务消费者在启动时，向注册中心订阅自己所需的服务。

4. 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。

5. 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。

6. 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

重要知识点总结：

• 注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小

• 监控中心负责统计各服务调用次数，调用时间等，统计先在内存汇总后每分钟一次发送到监控中心服务器，并以报表展示

• 注册中心，服务提供者，服务消费者三者之间均为长连接，监控中心除外

• 注册中心通过长连接感知服务提供者的存在，服务提供者宕机，注册中心将立即推送事件通知消费者

• 注册中心和监控中心全部宕机，不影响已运行的提供者和消费者，消费者在本地缓存了提供者列表

• 注册中心和监控中心都是可选的，服务消费者可以直连服务提供者

• 服务提供者无状态，任意一台宕掉后，不影响使用

• 服务提供者全部宕掉后，服务消费者应用将无法使用，并无限次重连等待服务提供者恢复

2.Dubbo 工作原理

图中从下至上分为十层，各层均为单向依赖，右边的黑色箭头代表层之间的依赖关系，每一层都可以剥离上层被复用，其中，Service 和 Config 层为 API，其它各层均为 SPI。

各层说明：

• 第一层：service 层，接口层，给服务提供者和消费者来实现的

• 第二层：config 层，配置层，主要是对 dubbo 进行各种配置的

• 第三层：proxy 层，服务接口透明代理，生成服务的客户端 Stub 和服务器端 Skeleton

• 第四层：registry 层，服务注册层，负责服务的注册与发现

• 第五层：cluster 层，集群层，封装多个服务提供者的路由以及负载均衡，将多个实例组合成一个服务

• 第六层：monitor 层，监控层，对 rpc 接口的调用次数和调用时间进行监控

• 第七层：protocol 层，远程调用层，封装 rpc 调用

• 第八层：exchange 层，信息交换层，封装请求响应模式，同步转异步

• 第九层：transport 层，网络传输层，抽象 mina 和 netty 为统一接口

• 第十层：serialize 层，数据序列化层，网络传输需要

三、Dubbo 的负载均衡策略

1.先来解释一下什么是负载均衡

先来个官方的解释。

维基百科对负载均衡的定义：负载均衡改善了跨多个计算资源（例如计算机，计算机集群，网络链接，中央处理单元或磁盘驱动的的工作负载分布。负载平衡旨在优化资源使用，最大化吞吐量，最小化响应时间，并避免任何单个资源的过载。使用具有负载平衡而不是单个组件的多个组件可以通过冗余提高可靠性和可用性。负载平衡通常涉及专用软件或硬件。

上面讲的大家可能不太好理解，再用通俗的话给大家说一下。

比如我们的系统中的某个服务的访问量特别大，我们将这个服务部署在了多台服务器上，当客户端发起请求的时候，多台服务器都可以处理这个请求。那么，如何正确选择处理该请求的服务器就很关键。假如，你就要一台服务器来处理该服务的请求，那该服务部署在多台服务器的意义就不复存在了。负载均衡就是为了避免单个服务器响应同一请求，容易造成服务器宕机、崩溃等问题，我们从负载均衡的这四个字就能明显感受到它的意义。

2.再来看看 Dubbo 提供的负载均衡策略

在集群负载均衡时，Dubbo 提供了多种均衡策略，默认为 random 随机调用。可以自行扩展负载均衡策略。

1)Random LoadBalance(默认，基于权重的随机负载均衡机制)

• 随机，按权重设置随机概率。

• 在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。

• 

2)RoundRobin LoadBalance(不推荐，基于权重的轮询负载均衡机制)

• 轮循，按公约后的权重设置轮循比率。

• 存在慢的提供者累积请求的问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。

• 

3)LeastActive LoadBalance

• 最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。

• 使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。

4)ConsistentHash LoadBalance

• 一致性 Hash，相同参数的请求总是发到同一提供者。(如果你需要的不是随机负载均衡，是要一类请求都到一个节点，那就走这个一致性 hash 策略。)

• 当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。

• 缺省只对第一个参数 Hash，如果要修改，请配置 `<dubbo:parameter key="hash.arguments" value="0

《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》
浏览器打开：qq.cn.hn/FTe 免费领取

,1" />`

• 缺省用 160 份虚拟节点，如果要修改，请配置 <dubbo:parameter key="hash.nodes" value="320" />
  

3.配置方式

xml 配置方式

服务端服务级别

<dubbo:service interface="..." loadbalance="roundrobin" />

客户端服务级别

<dubbo:reference interface="..." loadbalance="roundrobin" />

服务端方法级别

<dubbo:service interface="..."><dubbo:method name="..." loadbalance="roundrobin"/></dubbo:service>

客户端方法级别

<dubbo:reference interface="..."><dubbo:method name="..." loadbalance="roundrobin"/></dubbo:reference>

注解配置方式：

消费方基于基于注解的服务级别配置方式：

@Reference(loadbalance = "roundrobin")HelloService helloService;

四、zookeeper 宕机与 dubbo 直连的情况

zookeeper 宕机与 dubbo 直连的情况在面试中可能会被经常问到，所以要引起重视。

在实际生产中，假如 zookeeper 注册中心宕掉，一段时间内服务消费方还是能够调用提供方的服务的，实际上它使用的本地缓存进行通讯，这只是 dubbo 健壮性的一种体现。

dubbo 的健壮性表现：

1. 监控中心宕掉不影响使用，只是丢失部分采样数据

2. 数据库宕掉后，注册中心仍能通过缓存提供服务列表查询，但不能注册新服务

3. 注册中心对等集群，任意一台宕掉后，将自动切换到另一台

4. 注册中心全部宕掉后，服务提供者和服务消费者仍能通过本地缓存通讯

5. 服务提供者无状态，任意一台宕掉后，不影响使用

6. 服务提供者全部宕掉后，服务消费者应用将无法使用，并无限次重连等待服务提供者恢复

我们前面提到过：注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小。所以，我们可以完全可以绕过注册中心——采用 dubbo 直连 ，即在服务消费方配置服务提供方的位置信息。

xml 配置方式：

<dubbo:reference id="userService" interface="com.zang.gmall.service.UserService" url="dubbo://localhost:20880" />

注解方式：

@Reference(url = "127.0.0.1:20880")HelloService helloService;

参考资料：《Java 中高级核心知识全面解析》获取方式：私信【资料】免费获取还有更多 Java PDF 学习资料等你来拿！！！