Dubbo系列2：源代码结构和整体调用过程

【注】：本文比较清晰的大图都来自Dubbo官网
这里我们先直观浏览一下Dubbo的代码结构和功能划分情况，具体后面逐步展开。Dubbo有效代码大约9.8万，其结构和模块比较复杂，大致结构是：

dubbo-common 公共逻辑模块：包括 Util 类和通用模型。
dubbo-remoting 远程通讯模块：相当于 Dubbo 协议的实现，如果 RPC 用 RMI协议则不需要使用此包。
dubbo-rpc 远程调用模块：抽象各种协议，以及动态代理，只包含一对一的调用，不关心集群的管理。在回过头看上面的图，我们会发现，dubbo-rpc 是整个 Dubbo 的中心。
dubbo-cluster 集群模块：将多个服务提供方伪装为一个提供方，包括：负载均衡, 容错，路由等，集群的地址列表可以是静态配置的，也可以是由注册中心下发。cluster的整体结构如下：

dubbo-registry 注册中心模块：基于注册中心下发地址的集群方式，以及对各种注册中心的抽象。
dubbo-monitor 监控模块：统计服务调用次数，调用时间的，调用链跟踪的服务。
dubbo-config 配置模块：是 Dubbo 对外的 API，用户通过 Config 使用Dubbo，隐藏 Dubbo 所有细节。
dubbo-container 容器模块：是一个 Standlone 的容器，以简单的 Main 加载 Spring 启动，因为服务通常不需要 Tomcat/JBoss 等 Web 容器的特性，没必要用 Web 容器去加载服务。

整体上按照分层结构进行分包，与分层的不同点在于：
container 为服务容器，用于部署运行服务，没有在层中画出。
protocol 层和 proxy 层都放在 rpc 模块中，这两层是 rpc 的核心，在不需要集群也就是只有一个提供者时，可以只使用这两层完成 rpc 调用。
transport 层和 exchange 层都放在 remoting 模块中，为 rpc 调用的通讯基础。
serialize 层放在 common 模块中，以便更大程度复用。

2 Dubbo的完整调用过程

上面的只是从水平的角度看这些模块，如果从垂直的角度大致分为十个层次：
config 配置层：对外配置接口，以 ServiceConfig （暴露的服务配置） 和ReferenceConfig （引用的服务配置） 为中心，可以直接初始化配置类，也可以通过 spring 解析配置生成配置类。可以理解为该层管理了整个Dubbo的配置，也是加载用户设置的入口。
proxy 服务代理层：服务接口透明代理，在Dubbo中， 无论生产者还是消费者， 框架都会生成一个代理类， 整个过程对上层是透明的。 当调用一个远程接口时， 看起来就像是调用了一个本地的接口一样，代理层会自动做远程调用并返回结果， 即让业务层对远程调用完全无感。该层会生成服务的客户端 Stub 和服务器端 Skeleton, 以 ServiceProxy为中心，扩展接为 ProxyFactory。
registry 注册中心层：封装服务地址的注册与发现，负责Dubbo框架的服务注册与发现。 当有新的服务加入或旧服务下线时， 注册中心都会感知并通知给所有订阅方。 整个过程不需要人工参。该层以服务 URL 为中心，扩展接口为 RegistryFactory, Registry, RegistryService。
cluster 集群容错层。 该层主要负责： 远程调用失败时的容错策略（如失败重试、 快速失败） 。选择具体调用节点时的负载均衡策略（如随机、 一致性Hash等） ； 特殊调用路径的路由策略（如某个消费者只会调用某个IP的生产者），以 Invoker 为中心，扩展接口为 Cluster, Directory, Router, LoadBalance。
monitor 监控层：RPC 调用次数和调用时间监控，以 Statistics 为中心，扩展接口为 MonitorFactory, Monitor, MonitorService
protocol 远程调用层。 封装RPC调用具体过程， Protocol是Invoker暴露（发布一个服务让别人可以调用） 和引用（引用一个远程服务到本地） 的主功能入口， 它负责管理Invoker的整个生命周期。 Invoker是Dubbo的核心模型， 框架中所有其他模型都向它靠拢， 或者转换成它， 它代表一个可执行体。 允许向它发起invoke调用， 它可能是执行一个本地的接口实现， 也可能是一个远程的实现， 还可能一个集群实现。该层以 Invocation, Result 为中心，扩展接口为 Protocol, Invoker, Exporter。
exchange 信息交换层，建立Request-Response模型， 封装请求响应模式， 如把同步请求转化为异步请求：封装请求响应模式，同步转异以 Request, Response 为中心，扩展接口为 Exchanger, ExchangeChannel, ExchangeClient, ExchangeServer。
transport 网络传输层，把网络传输抽象为统一的接口， 如Mina和Netty虽然接口不一样， 但是Dubbo在它们上面又封装了统一的接口。 用户也可以根据其扩展接口添加更多的网络传输方式：抽象 mina 和 netty 为统一接口，以 Message 为中心，扩展接口为 Channel, Transporter, Client, Server, Codec。
serialize 数据序列化层，如果数据要通过网络进行发送， 则需要先做序列化， 变成二进制流。 序列化层负责管理整个框架网络传输时的序列化/反序列化工作：可复用的一些工具，扩展接口为 Serialization, ObjectInput, ObjectOutput, ThreadPool。
Dubbo总体调用过程：
首先， 服务器端（服务提供者） 在框架启动时， 会初始化服务实例， 通过Proxy组件调用具体协议（Protocol ） ,把服务端要暴露的接口封装成Invoker （真实类型是AbstractProxylnvoker）,然后转换成Exporter,这个时候框架会打开服务端口等并记录服务实例到内存中， 最后通过Registry把服务元数据注册到注册中心。 这就是服务端（服务提供者）整个接口暴露的过程。 读者可能对里面的各种组件还不清楚， 下面就讲解组件的含义：
Proxy组件： 我们知道， Dubbo中只需要引用一个接口就可以调用远程的服务， 并且
只需要像调用本地方法一样调用即可。 其实是Dubbo框架为我们生成了代理类， 调用
的方法其实是Proxy组件生成的代理方法， 会自动发起远程/本地调用， 并返回结果,
整个过程对用户完全透明。
Protocol： 顾名思义， 协议就是对数据格式的一种约定。 它可以把我们对接口的配置,
根据不同的协议转换成不同的Invoker对象。 例如： 用DubboProtocol可以把XML文
件中一个远程接口的配置转换成一个Dubbolnvokero
Exporter： 用于暴露到注册中心的对象， 它的内部属性持有了 Invoker对象， 我们可以
认为它在Invoker上包了 一层。
Registry： 把Exporter注册到注册中心。
以上就是整个服务暴露的过程， 消费方在启动时会通过Registry在注册中心订阅服务端的元数据（包括IP和端口） 。 这样就可以得到刚才暴露的服务了。
下面我们来看一下消费者调用服务提供者的总体流程 ， 我们此处只介绍远程调用， 本地调用是远程调用的子集， 因此不在此展开。 Dubbo组件调用总体流程如下图所示。

首先， 调用过程也是从一个Proxy开始的， Proxy持有了一个Invoker对象。 然后触发invoke调用。 在invoke调用过程中， 需要使用Cluster, Cluster负责容错， 如调用失败的重试。 Cluster在调用之前会通过Directory获取所有可以调用的远程服务Invoker列表（一个接口可能有多个节点提供服务） 。 由于可以调用的远程服务有很多， 此时如果用户配置了路由规则（如指定某些方法只能调用某个节点） ， 那么还会根据路由规则将Invoker列表过滤一遍。
然后， 存活下来的Invoker可能还会有很多， 此时要调用哪一个呢？ 于是会继续通过LoadBalance方法做负载均衡， 最终选出一个可以调用的Invokero这个Invoker在调用之前又会经过一个过滤器链， 这个过滤器链通常是处理上下文、 限流、 计数等。
接着， 会使用Client做数据传输， 如我们常见的Netty Client等。 传输之前肯定要做一些私有协议的构造， 此时就会用到Codec接口。 构造完成后， 就对数据包做序列化（Serialization）,
然后传输到服务提供者端。 服务提供者收到数据包， 也会使用Codec处理协议头及一些半包、粘包等。 处理完成后再对完整的数据报文做反序列化处理。
随后， 这个Request会被分配到线程池（ThreadPool）中进行处理oServer会处理这些Request,根据请求查找对应的Exporter （它内部持有了 Invoker）0 Invoker是被用装饰器模式一层一层套了非常多Filter的， 因此在调用最终的实现类之前， 又会经过一个服务提供者端的过滤器链。
最终， 我们得到了具体接口的真实实现并调用， 再原路把结果返回。
官网上Dubbo的实现是这样一个图：

图例说明：

• 图中左边淡蓝背景的为服务消费方使用的接口，右边淡绿色背景的为服务提供方使用的接口，位于中轴线上的为双方都用到的接口。

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

• 图中绿色小块的为扩展接口，蓝色小块为实现类，图中只显示用于关联各层的实现类。

• 图中蓝色虚线为初始化过程，即启动时组装链，红色实线为方法调用过程，即运行时调时链，紫色三角箭头为继承，可以把子类看作父类的同一个节点，线上的文字为调用的方法。

• 在 RPC 中，Protocol 是核心层，也就是只要有 Protocol + Invoker + Exporter 就可以完成非透明的 RPC 调用，然后在 Invoker 的主过程上 Filter 拦截点。

• 图中的 Consumer 和 Provider 是抽象概念，只是想让看图者更直观的了解哪些类分属于客户端与服务器端，不用 Client 和 Server 的原因是 Dubbo 在很多场景下都使用 Provider, Consumer, Registry, Monitor 划分逻辑拓普节点，保持统一概念。

• 而 Cluster 是外围概念，所以 Cluster 的目的是将多个 Invoker 伪装成一个 Invoker，这样其它人只要关注 Protocol 层 Invoker 即可，加上或者去掉 Cluster 对其它层都不会造成影响，因为只有一个提供者时，是不需要 Cluster 的。

• Proxy 层封装了所有接口的透明化代理，而在其它层都以 Invoker 为中心，只有到了暴露给用户使用时，才用 Proxy 将 Invoker 转成接口，或将接口实现转成 Invoker，也就是去掉 Proxy 层 RPC 是可以 Run 的，只是不那么透明，不那么看起来像调本地服务一样调远程服务。

• Remoting是Dubbo协议的实现，如果你选择 RMI 协议，整个 Remoting 都不会用上，Remoting 内部再划为 Transport 传输层和 Exchange 信息交换层，Transport 层只负责单向消息传输，是对 Mina, Netty, Grizzly 的抽象，它也可以扩展 UDP 传输，而 Exchange 层是在传输层之上封装了 Request-Response 语义。

• Registry 和 Monitor 实际上不算一层，而是一个独立的节点，只是为了全局概览，用层的方式画在一起。

3.调用链

展开总设计图的红色调用链，如下：

3.从功能角度看dubbo配置的类型

配置的实现在dubbo-common下的common下的config里，而不是dubbo-config包，注意是那一堆后缀为**Config的文件。这些文件的关系是：

不过该图与实际代码有点出入，我们看看类关系图：

图中比较重要配置可以分为四类：

1. 蓝钩部分，application-shared应用共享的配置
   2.黄框 provider-side 提供方的配置
   3.红框consumer-side 服务消费者配置
   更具体的有：
   
   其中：dubbo:reference/引用缺省是延迟初始化的，只有引用被注入到其它 Bean，或被 getBean() 获取（Spring的DI节点入口就是getBean()），才会初始化。如果需要饥饿加载，即没有人引用也立即生成动态代理，可以配置：<dubbo:reference … init=“true” /> ↩︎

如果多个标签都配置了一个属性，例如都有超时timeout属性，那该以哪个为标准呢？
优先顺序是：

• 方法级优先，接口级次之，全局配置再次之。
• 如果级别一样，则消费方优先，提供方次之。
  注意这个优先级和上一节的不一样，上一节是配置文件来源的优先级，而这部分是获取配置文件之后，类，方法，接口等面对同一个参数的不同设置该怎么处理的问题。