系列文章：

RPC 框架 -dubbo：架构及源码分析 - 初篇

一 概述

Apache Dubbo 是一款高性能、轻量级的开源 Java 服务框架，提供了六大核心能力：面向接口代理的高性能 RPC 调用，智能容错和负载均衡，服务自动注册和发现，高度可扩展能力，运行期流量调度，可视化的服务治理与运维。

1.1 微服务框架-dubbo vs SpringCloud

在微服务框架选择上，通常都会讨论 dubbo 和 springcloud。当然，大家应该也知道这两个并不完全是竞争关系，因为严格来说，二者并非同一个层面的东西，dubbo 是 RPC 框架。

1.2 RPC 与 HTTP

RPC 是远端过程调用，其调用协议通常包含传输协议和编码协议。HTTP 严格来说跟 RPC 不是一个层级的概念，HTTP 本身也可以作为 RPC 的传输层协议。

传输协议包含: 如著名的 gRPC 使用的 HTTP 2.0 协议，也有如 Dubbo 一类的自定义报文的 TCP 协议。编码协议包含: 如基于文本编码的 XML Json，也有二进制编码的 ProtoBuf Binpack 等。

所谓的效率优势是针对 HTTP 1.1 协议来讲的，HTTP 2.0 协议已经优化编码效率问题，像 gRPC 这种 RPC 库使用的就是 HTTP 2.0 协议。

在跨语言调用的时候，REST 风格直接把 HTTP 作为应用协议（直接和服务打交道），不同语言之间调用比较方便。

而 RPC 可以把 HTTP 作为一种传输协议（比如 gRPC 使用 HTTP 2.0 协议传输），本身还会封装一层 RPC 框架的应用层协议，不同语言之间调用需要依赖 RPC 协议（需要跨语言 RPC 库实现，比如 Thrift）。

1.3 开篇

本章将开始介绍 dubbo 源码，通过学习源码深入了解 dubbo 的运行机制，也以此深入了解 rpc 框架的组成、应用和潜在问题及解决方案。

二 负载均衡策略

2.1 四种策略

根据官方文档中对负载均衡的描述，在集群负载均衡时，Dubbo 提供了多种均衡策略，缺省为 random 随机调用。另外开发者也可以自行扩展负载均衡策略，参见：负载均衡扩展

默认支持以下四种：

Random LoadBalance：

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

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

RoundRobin LoadBalance：

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

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

LeastActive LoadBalance：

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

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

ConsistentHash LoadBalance：

• 一致性 Hash，相同参数的请求总是发到同一提供者。

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

• 算法参见：http://en.wikipedia.org/wiki/Consistent_hashing

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

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

2.2 源码

在 org.apache.dubbo.rpc.cluster.loadbalance 包下，包内包含了抽象类 AbstractLoadBalance，继承自 LoadBalance 接口。

LoadBalance 接口通过 SPI 机制提供扩展。接口中只有一个方法，就是 select，用于选择一个合适的服务来提供功能：

@SPI(RandomLoadBalance.NAME)public interface LoadBalance {
    /**     * select one invoker in list.     *     * @param invokers   invokers.     * @param url        refer url     * @param invocation invocation.     * @return selected invoker.     */    @Adaptive("loadbalance")    <T> Invoker<T> select(List<Invoker<T>> invokers, URL url, Invocation invocation) throws RpcException;}

ConsistentHashLoadBalance，LeastActiveLoadBalance，RandomLoadBalance，RoundRobinLoadBalance 这四个类就是 2.1 中四种策略的实现。

可见 select 方法的参数有三个：

1、List<Invoker<T>> invokers

2、URL url

3、Invocation invocation

其中 Invoker 就是 dubbo 的核心模型，代表一个可执行体，可向它发起 invoke 调用。在服务提供方，Invoker 用于调用服务提供类。在服务消费方，Invoker 用于执行远程调用。

三 线程模型

3.1 场景

如果事件处理的逻辑能迅速完成，并且不会发起新的 IO 请求，比如只是在内存中记个标识，则直接在 IO 线程上处理更快，因为减少了线程池调度。

但如果事件处理逻辑较慢，或者需要发起新的 IO 请求，比如需要查询数据库，则必须派发到线程池，否则 IO 线程阻塞，将导致不能接收其它请求。

如果用 IO 线程处理事件，又在事件处理过程中发起新的 IO 请求，比如在连接事件中发起登录请求，会报“可能引发死锁”异常，但不会真死锁。

因此，需要通过不同的派发策略和不同的线程池配置的组合来应对不同的场景:

<dubbo:protocol name="dubbo" dispatcher="all" threadpool="fixed" threads="100" />

3.2 Dispatcher

• all 所有消息都派发到线程池，包括请求，响应，连接事件，断开事件，心跳等。

• direct 所有消息都不派发到线程池，全部在 IO 线程上直接执行。

• message 只有请求响应消息派发到线程池，其它连接断开事件，心跳等消息，直接在 IO 线程上执行。

• execution 只有请求消息派发到线程池，不含响应，响应和其它连接断开事件，心跳等消息，直接在 IO 线程上执行。

• connection 在 IO 线程上，将连接断开事件放入队列，有序逐个执行，其它消息派发到线程池。

3.3 ThreadPool

• fixed 固定大小线程池，启动时建立线程，不关闭，一直持有。(缺省)

• cached 缓存线程池，空闲一分钟自动删除，需要时重建。

• limited 可伸缩线程池，但池中的线程数只会增长不会收缩。只增长不收缩的目的是为了避免收缩时突然来了大流量引起的性能问题。

• eager 优先创建Worker线程池。在任务数量大于corePoolSize但是小于maximumPoolSize时，优先创建Worker来处理任务。当任务数量大于maximumPoolSize时，将任务放入阻塞队列中。阻塞队列充满时抛出RejectedExecutionException。(相比于cached:cached在任务数量超过maximumPoolSize时直接抛出异常而不是将任务放入阻塞队列)