节点角色说明：
- Provider：暴露服务的服务提供方；
- Consumer：调用远程服务的服务消费方；
- Registry：服务注册与发现的注册中心；
- Monitor: 统计服务的调用次数和调用时间；
- Container：服务的运行容器。
调用关系说明:
0. 服务容器负责启动，加载，运行服务提供者。
- 服务提供者在启动时，向注册中心注册自己提供的服务。
- 服务消费者在启动时，向注册中心订阅自己所需的服务。
- 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接
推送变更数据给消费者。 - 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，
如果调用失败，再选另一台调用。 - 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统
计数据到监控中心。
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 关系图，依赖关系线有点乱。整个模块是从上到下传递依赖的。
