转载

Dubbo 源码分析系列之三 —— 架构原理

1 核心功能

首先要了解Dubbo提供的三大核心功能：

Remoting:远程通讯
- 提供对多种NIO框架抽象封装，包括“同步转异步”和“请求-响应”模式的信息交换方式。
Cluster: 服务框架
- 提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。
Registry: 服务注册中心
- 基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。

2 Dubbo各个组件之间的关系结构

2.1 调用关系

Dubbo 源码分析系列之三 —— 架构原理

节点角色说明

节点	角色说明
`Provider`	暴露服务的服务提供方
`Consumer`	调用远程服务的服务消费方
`Registry`	服务注册与发现的注册中心
`Monitor`	统计服务的调用次数和调用时间的监控中心
`Container`	服务运行容器

2.2 依赖关系

Dubbo 源码分析系列之三 —— 架构原理

图例说明：

图中小方块 Protocol, Cluster, Proxy, Service, Container, Registry, Monitor 代表层或模块，蓝色的表示与业务有交互，绿色的表示只对 Dubbo 内部交互。
图中背景方块 Consumer, Provider, Registry, Monitor 代表部署逻辑拓扑节点。
图中蓝色虚线为初始化时调用，红色虚线为运行时异步调用，红色实线为运行时同步调用。
图中只包含 RPC 的层，不包含 Remoting 的层，Remoting 整体都隐含在 Protocol 中。

调用链

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

Dubbo 源码分析系列之三 —— 架构原理

暴露服务时序

展开总设计图左边服务提供方暴露服务的蓝色初始化链，时序图如下：

Dubbo 源码分析系列之三 —— 架构原理

引用服务时序

展开总设计图右边服务消费方引用服务的蓝色初始化链，时序图如下：

Dubbo 源码分析系列之三 —— 架构原理

3 Dubbo 的水平分层结构

Dubbo最大的特点是 按照分层的方式来架构 ，使用这种方式可以使各个层之间解耦合（或者最大限度地松耦合）。所以，我们 横向以分层的方式来看下Dubbo的架构

整体设计

Dubbo 源码分析系列之三 —— 架构原理

图例说明：

图中左边淡蓝背景的为服务消费方使用的接口，右边淡绿色背景的为服务提供方使用的接口，位于中轴线上的为双方都用到的接口。
图中从下至上分为十层，各层均为单向依赖，右边的黑色箭头代表层之间的依赖关系，每一层都可以剥离上层被复用，其中，Service 和 Config 层为 API，其它各层均为 SPI。
图中绿色小块的为扩展接口，蓝色小块为实现类，图中只显示用于关联各层的实现类。
图中蓝色虚线为初始化过程，即启动时组装链，红色实线为方法调用过程，即运行时调时链，紫色三角箭头为继承，可以把子类看作父类的同一个节点，线上的文字为调用的方法。

各层说明

config 配置层 ：对外配置接口，以 ServiceConfig , ReferenceConfig 为中心，可以直接初始化配置类，也可以通过 spring 解析配置生成配置类
proxy 服务代理层 ：服务接口透明代理，生成服务的客户端 Stub 和服务器端 Skeleton, 以 ServiceProxy 为中心，扩展接口为 ProxyFactory
registry 注册中心层 ：封装服务地址的注册与发现，以服务 URL 为中心，扩展接口为 RegistryFactory , Registry , RegistryService
cluster 路由层 ：封装多个提供者的路由及负载均衡，并桥接注册中心，以 Invoker 为中心，扩展接口为 Cluster , Directory , Router , LoadBalance
monitor 监控层 ：RPC 调用次数和调用时间监控，以 Statistics 为中心，扩展接口为 MonitorFactory , Monitor , MonitorService
protocol 远程调用层 ：封装 RPC 调用，以 Invocation , Result 为中心，扩展接口为 Protocol , Invoker , Exporter
exchange 信息交换层 ：封装请求响应模式，同步转异步，以 Request , Response 为中心，扩展接口为 Exchanger , ExchangeChannel , ExchangeClient , ExchangeServer
transport 网络传输层 ：抽象 mina 和 netty 为统一接口，以 Message 为中心，扩展接口为 Channel , Transporter , Client , Server , Codec
serialize 数据序列化层 ：可复用的一些工具，扩展接口为 Serialization , ObjectInput , ObjectOutput , ThreadPool

关系说明

在 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 对其它层都不会造成影响，因为只有一个提供者时，是不需要 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 实际上不算一层，而是一个独立的节点，只是为了全局概览，用层的方式画在一起。

参考文章

https://dubbo.incubator.apache.org/zh-cn/docs/dev/design.html

http://svip.iocoder.cn/Dubbo/implementation-intro/

https://juejin.im/post/5b0426b5f265da0b7770087b

https://juejin.im/post/5ab09943f265da238f125ee8

https://my.oschina.net/ywbrj042/blog/702521