Dubbo源码分析(一)-----包结构的分析

Dubbo总体架构图(来源于http://dubbo.apache.org/books/dubbo-dev-book/design.html)以下：

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

• 图中从下至上分为十层，各层均为单向依赖，右边的黑色箭头表明层之间的依赖关系，每一层均可以剥离上层被复用，其中，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、Export,。

• Exchanger 信息交换层，封装请求响应模式，以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的, 而后在 Invoker 的主过程上 Filter 拦截点

• 图中的Provider和Consumer是抽象的概念，只是想让看图者更直观的了解哪些分类是分属于客户端于服务端，不用Client和Server的缘由是Dubbo在不少场景下都使用Provider,Register,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语义。

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

模块分包 WX20190613-184631@2x.png

模块说明：

dubbo-common 公共逻辑模块：包括 Util 类和通用模型。 dubbo-remoting 远程通信模块：至关于 Dubbo 协议的实现，若是 RPC 用 RMI协议则不须要使用此包 dubbo-rpc 远程调用模块：抽象各类协议，以及动态代理，只包含一对一的调用，不关心集群的管理。 dubbo-cluster 集群模块：将多个服务提供方假装为一个提供方，包括：负载均衡, 容错，路由等，集群的地址列表能够是静态配置的，也能够是由注册中心 dubbo-registry 注册中心模块：基于注册中心下发地址的集群方式，以及对各类注册中心的抽象。 dubbo-monitor 监控模块：统计服务调用次数，调用时间的，调用链跟踪的服务。 dubbo-config 配置模块: 是 Dubbo 对外的 API，用户经过 Config 使用D ubbo，隐藏 Dubbo 全部细节。 dubbo-container 容器模块：是一个 Standlone 的容器，以简单的 Main 加载 Spring 启动，由于服务一般不须要 Tomcat/JBoss 等 Web 容器的特性，不必用Web 容器去加载服务。总体上按照分层结构进行分包，与分层的不一样点在于： container 为服务容器，用于部署运行服务，没有在层中画出。 protocol 层和 proxy 层都放在 rpc 模块中，这两层是 rpc 的核心，在不须要集群也就是只有一个提供者时，能够只使用这两层完成 rpc 调用。 transport 层和 exchange 层都放在 remoting 模块中，为 rpc 调用的通信基础。 serialize 层放在 common 模块中，以便更大程度复用。 依赖关系

图例说明：

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

暴露服务时序

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

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

领域模型

在 Dubbo 的核心领域模型中

Protocol 是服务域，它是 Invoker 暴露和引用的主功能入口，它负责 Invoker 的生命周期管理。 Invoker 是实体域，它是 Dubbo 的核心模型，其它模型都向它靠扰，或转换成它，它表明一个可执行体，可向它发起 invoke 调用，它有多是一个本地的实现，也多是一个远程的实现，也可能一个集群实现。 Invocation 是会话域，它持有调用过程当中的变量，好比方法名，参数等。

基本设计原则 采用 Microkernel + Plugin 模式，Microkernel 只负责组装 Plugin，Dubbo 自身的功能也是经过扩展点实现的，也就是 Dubbo 的全部功能点均可被用户自定义扩展所替换。 采用 URL 做为配置信息的统一格式，全部扩展点都经过传递 URL