小强源码分析系列-Dubbo-源码分析2---模块整体介绍

模块划分

Dubbo框架整体设计

模块说明：

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

2.dubbo-remoting 远程通讯模块：相当于 Dubbo 协议的实现，如果 RPC 用 RMI协议则不需要使用此包。

3.dubbo-rpc 远程调用模块：抽象各种协议，以及动态代理，只包含一对一的调用，不关心集群的管理。

4.dubbo-cluster 集群模块：将多个服务提供方伪装为一个提供方，包括：负载均衡, 容错，路由等，集群的地址列表可以是静态配置的，也可以是由注册中心下发。

5.dubbo-registry 注册中心模块：基于注册中心下发地址的集群方式，以及对各种注册中心的抽象。

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

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

8.dubbo-container 容器模块：是一个 Standlone 的容器，以简单的 Main 加载 Spring 启动，因为服务通常不需要 Tomcat/JBoss 等 Web 容器的特性，没必要用 Web 容器去加载服务。
整体上按照分层结构进行分包，与分层的不同点在于：

• container 为服务容器，用于部署运行服务，没有在层中画出。

• protocol 层和 proxy 层都放在 rpc 模块中，这两层是 rpc 的核心，在不需要集群也就是只有一个提供者时，可以只使用这两层完成 rpc 调用。

• transport 层和 exchange 层都放在 remoting 模块中，为 rpc 调用的通讯基础。

• serialize 层放在 common 模块中，以便更大程度复用。

领域模型设计

在 Dubbo 的核心领域模型中：

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

基本设计原则

采用 Microkernel + Plugin 模式，Microkernel 只负责组装 Plugin，Dubbo 自身的功能也是通过扩展点实现的，也就是 Dubbo 的所有功能点都可被用户自定义扩展所替换。
采用 URL 作为配置信息的统一格式，所有扩展点都通过传递 URL 携带配置信息。