《一》Dubbo之总体架构剖析

Posted 2021-04-05 码农霓风

一、架构剖析

Dubbo 总体采用微内核+插件体系，使得设计优雅，扩展性强 ，下面是各个层面的设计。

1. Privoder服务提供者启动时，会向注册中心（默认zk）写入自己的元数据信息 。
2. consumer服务消费者启动时，也会向注册中心（默认zk）写入自己的元数据信息，同时并订阅服务提供者、路由和配置元信息数据。pull 拉取模式获取全量的数据，并向zk注册一个watcher,同时zk客户端与zk注册中心保持TCP长连接方式。
3. 消费者拉取到了注册中心的注册信息后会缓存起来（内存有一份。磁盘也会持久化一份），后面调用时候不用再经过注册中心（空间换时间）。
4. Register注册中心当有服务新增或者离开时，会异步通知服务消费者。zk采用“事件通知”+“客户端拉取”的方式实现
5. zk注册中心客户端：Apache Curator、zkClient
6. 整个注册中心的逻辑部分使用了模板模式，AbstractRegistry实现了Registry接口中的注册、订阅、查询、通知等方法。FailbackRegistry又继承了AbstractRegistry添加了重试机制。

二、分层结构

1. config 即配置层：对外配置接口，主要有 ServiceConfig, ReferenceConfig ，dubbo启动时会直接初始化相关配置类，当然也可以通过 spring 解析配置从而生成相应的配置类。

2. proxy 即代理层：服务接口代理层，例如ServiceProxy 扩展接口为 ProxyFactory。

4. cluster 即路由层：会封装多个provider的路由负载均衡，并桥接注册中心，例如Invoker ，扩展接口为 Cluster, Directory, Router, LoadBalance等。

5. monitor 即监控层：会统计和RPC 调用次数和调用时间监控等。

6. protocol 即远程调用层：封装 RPC 的调用，以 Invocation为中心。

7. exchange 即信息交换层：封装请求响应模式，同步转异步。

8. transport 即网络传输层：主要抽象 mina 和 netty 为统一接口，以 Message 为中心，扩展接口为 Channel, Transporter, Client, Server, Codec

9. serialize  即序列化层：主要扩展接口为 Serialization, ObjectInput, ObjectOutput, ThreadPool

三、关系说明

1.  Protocol 是核心层，通过 Protocol + Invoker + Exporter 就可以完成非透明的 RPC 调用。

2. 其中 Consumer 和 Provider 是抽象概念，不采用C/S架构的原因是 Dubbo 在很多场景下都使用 Provider, Consumer, Registry, Monitor 划分逻辑拓普节点，保持统一概念。

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

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

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

6. 注册中心和监控Registry 和 Monitor 实际上不算一层，而是一个独立的节点。

四、模块分包

模块说明：

1. dubbo-common 公共逻辑模块：包括 工具类和通用模型

3. dubbo-monitor 监控模块：统计服务调用次数，调用时间的，调用链跟踪的服务。

4. dubbo-config 配置模块：是 Dubbo 对外的 API，用户通过 Config 使用Dubbo，隐藏 Dubbo 所有细节。

5. dubbo-container 为服务容器，用于部署运行服务。spring、logback等
   

6. dubbo-rpc 为rpc通讯的核心里面包括很多扩展点实现包含dubbo、hession、thrift、webservice、xml等实现

7. dubbo-remoting 主要是 rpc 调用的通讯基础包含netty、http、相关实现

8. dubbo-serialize 序列化相关包括avro、fst、hessian2、protostuff等

六、Dubbo主要的调用链路

七、服务export时序图

八、服务refer时序图

九、领域模型

1. 在 Dubbo 的核心DDD中：

2. Protocol 是服务域，它是 Invoker 暴露和引用的主功能入口，它负责 Invoker 的生命周期管理。

3. Invoker 是实体域，它是 Dubbo 的核心模型，其它模型都向它靠扰，或转换成它，它代表一个可执行体，可向它发起 invoke 调用，它有可能是一个本地的实现，也可能是一个远程的实现，也可能一个集群实现。

4. Invocation 是会话域，它持有调用过程中的变量，比如方法名，参数等。

十、基本设计原则

1. 采用 Microkernel + Plugin 模式，Microkernel 只负责组装 Plugin，Dubbo 自身的功能也是通过扩展点实现的，也就是 Dubbo 的所有功能点都可被用户自定义扩展所替换。

2. 采用 URL 作为配置信息的统一格式，所有扩展点都通过传递 URL 携带配置信息。