Dubbo学习摘录（零）

节点角色说明：

• Provider：暴露服务的服务提供方；
• Consumer：调用远程服务的服务消费方；
• Registry：服务注册与发现的注册中心；
• Monitor: 统计服务的调用次数和调用时间；
• Container：服务的运行容器。

调用关系说明:

1. 服务容器负责启动，加载，运行服务提供者。
2. 服务提供者在启动时，向注册中心注册自己提供的服务。
3. 服务消费者在启动时，向注册中心订阅自己所需的服务。
4. 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接
   推送变更数据给消费者。
5. 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，
   如果调用失败，再选另一台调用。
6. 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统
   计数据到监控中心。

Dubbo 源文件主要包含以上这么多包，其中:

• dubbo-common 公共逻辑模块，包括 Util 类和通用模型。
• dubbo-remoting 远程通讯模块，相当于 Dubbo 协议的实现，如果 RPC 用 RMI 协议
  则不需要使用此包。
• dubbo-rpc 远程调用模块，抽象各种协议，以及动态代理，只包含一对一的调用，不关心集群的管理。
• dubbo-cluster 集群模块，将多个服务 供方伪装为一个 供方，包括:负载均衡, 容错，路由等，集群的地址列表可以是静态配置的，也可以是由注册中心下发。 dubbo-registry 注册中心模块，基于注册中心下发地址的集群方式，以及对各种注册中心的抽象。
• dubbo-monitor 监控模块，统计服务调用次数，调用时间的，调用链跟踪的服务。 dubbo-config 配置模块，是 Dubbo 对外的 API，用户通过 Config 使用 Dubbo，隐藏
  Dubbo 所有细节。

• dubbo-container 容器模块，是一个 Standlone 的容器，以简单的 Main 加载 Spring启动，因为服务通常不需要 Tomcat/JBoss 等 Web 容器的特性，没必要用 Web 容器去加载服务。

  整体上按照分层结构进行分包，与分层的不同点在于:
  container 为服务容器，用于部署运行服务，没有在层中画出。
  protocol 层和 proxy 层都放在 rpc 模块中，这两层是 rpc 的核心，在不需要集群时(只 有一个 供者)，可以只使用这两层完成 rpc 调用。
  transport 层和 exchange 层都放在 remoting 模块中，为 rpc 调用的通讯基础。
  serialize 层放在 common 模块中，以便更大程度复用。

下面是更详细的 Project 关系图，依赖关系线有点乱。整个模块是从上到下传递依赖的。