dubbo从入门到深入——设计原理分析

本文基于dubbo文档，并结合自己的分析\理解。

整体设计

这里写图片描述

Dubbo 的核心领域模型

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

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

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

Business层

指Service层,主要是Provider(服务提供者)定义的服务接口Interface，以及具体的接口实现Implement。

服务接口也是服务消费者必须依赖的,通常以jar包形式引入消费者中。

RPC层

config 配置层

以 ServiceConfig, ReferenceConfig 为中心。
ServiceConfig对应服务端的暴露服务配置< dubbo:service >。
//服务端示例xml配置：

<!-- 和本地服务一样实现远程服务 -->
<bean id=“xxxService” class=“com.xxx.XxxServiceImpl” /> 
<!-- 增加暴露远程服务配置 -->
<dubbo:service interface=“com.xxx.XxxService” ref=“xxxService” />

ReferenceConfig对应服务消费端的引用服务配置< dubbo:reference >。

//消费端示例xml配置：

<!-- 增加引用远程服务配置 -->
<dubbo:reference id=“xxxService” interface=“com.xxx.XxxService” />
<!-- 和本地服务一样使用远程服务 -->
<bean id=“xxxAction” class=“com.xxx.XxxAction”> 
    <property name=“xxxService” ref=“xxxService” />
</bean>

proxy 服务代理层

服务接口透明代理，生成服务的客户端proxy或称客户端Stub） 和服务器端 invoker（或称服务端Skeleton）。
这一层主要是屏蔽rpc通信具体调用细节，提供给上层一个透明的代理。

registry 注册中心层

封装服务地址的注册与发现，以服务 URL 为中心，扩展接口为 RegistryFactory, Registry, RegistryService
这层其实是个独立的节点的客户端，比如使用Zookeeper服务作为注册中心，应用中的这一层作为ZK的客户端向ZK注册获取相关服务信息。

cluster 路由层

封装多个提供者的路由及负载均衡，并桥接注册中心，以 Invoker 为中心，扩展接口为 Cluster, Directory, Router, LoadBalance。
将多个服务提供方伪装为一个提供方，包括：负载均衡, 容错，路由等

monitor 监控层

RPC 调用次数和调用时间监控，以 Statistics 为中心，扩展接口为 MonitorFactory, Monitor, MonitorService。

监控层，也是一个独立的监控节点，dubbo的服务端消费端通过filter机制（MonitorFilter），增加数据统计功能，并定时将数据异步上报给某个独立监控节点。

protocol 远程调用层

封装 RPC 调用，以 Invocation, Result 为中心，扩展接口为 Protocol, Invoker, Exporter。RPC调用的通信基础，是RPC这一层的核心（Invoker+Protocol+Exporter）。

Remoting层

Dubbo 协议的实现，主要包含 通信模块与序列化(反序列化）模块。

exchange 信息交换层

封装request\response，同步转异步。

transport 网络传输层

socket网络编程模型。
抽象netty 为统一接口，以 Message 为中心，扩展接口为 Channel, Transporter, Client, Server, Codec。

serialize 数据序列化层

可复用的一些工具，扩展接口为 Serialization, ObjectInput, ObjectOutput, ThreadPool

各层交互\依赖关系

这里写图片描述

图例说明：

图中小方块 Protocol, Cluster, Proxy, Service, Container, Registry, Monitor
代表层或模块，蓝色的表示与业务有交互，绿色的表示只对 Dubbo 内部交互。 图中背景方块 Consumer, Provider,
Registry, Monitor 代表部署逻辑拓扑节点。

图中蓝色虚线为初始化时调用，红色虚线为运行时异步调用，红色实线为运行时同步调用。

图中只包含 RPC 的层，不包含 Remoting 的层，Remoting 整体都隐含在 Protocol 中。
container模块 简单的启动容器，通常以main方式运行启动spring容器，暴露提供服务。

调用流程

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

这里写图片描述

暴露服务时序

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

这里写图片描述

引用服务时序

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

这里写图片描述

基本设计原则

采用 Microkernel + Plugin 模式，Microkernel 只负责组装 Plugin，Dubbo 自身的功能也是通过扩展点实现的，也就是 Dubbo 的所有功能点都可被用户自定义扩展所替换。
采用 URL 作为配置信息的统一格式，所有扩展点都通过传递 URL 携带配置信息。
详细设计原则：
http://dubbo.apache.org/books/dubbo-dev-book/principals/code-detail.html

参考及摘抄：

http://dubbo.io/books/dubbo-dev-book/

转载：https://blog.csdn.net/lemon89/article/details/54709618