Cluster 是外围概念，目的是将多个 Invoker 伪装为一个 Invoker，这样其它人只要关注 Protocol 层 Invoker 即可。只有一个 provider 时，是不需要 Cluster 的
Proxy 层封装了所有接口的透明化代理，而在其它层都以 Invoker 为中心，只有到了暴露给用户使用时，才用 Proxy 将 Invoker 转成接口，或将接口实现转成 Invoker，看起来像调本地服务一样调远程服务
Remoting 内部再划为 Transport 传输层和 Exchange 信息交换层：Transport 层只负责单向消息传输，是对 Mina, Netty, Grizzly 的抽象；而 Exchange 层是在传输层之上封装了 Request-Response 语义
Dubbo核心领域模型：
Protocol 是服务域，它是 Invoker 暴露和引用的主功能入口，它负责 Invoker 的生命周期管理
Invoker 是实体域，它是 Dubbo 的核心模型，其它模型都向它靠扰，或转换成它。它代表一个可执行体，可向它发起 invoke 调用，它有可能是一个本地的实现，也可能是一个远程的实现，也可能一个集群实现
Invocation 是会话域，它持有调用过程中的变量，比如方法名，参数等
Dubbo主要包括以下几个节点：
Provider：暴露服务的服务提供方
Consumer：调用远程服务的服务消费方
Registry：服务注册和发现的注册中心
Monitor：统计服务的调用次数和调用时间的监控中心
Container：服务运行容器
Consumer, Provider, Registry, Monitor代表逻辑部署节点。图中只包含 RPC 层，不包含 Remoting层，Remoting整体隐藏在 Protocol 中。
蓝色方框代表业务有交互，绿色方框代表只对Dubbo内部交互。蓝色虚线为初始化时调用，红色虚线为运行时异步调用，红色实线为运行时同步调用
0、服务在容器中启动，加载，运行Provider
1、Provider在启动时，向Registry注册自己提供的服务
2、Consumer在启动时，想Registry订阅自己所需的服务
3、Registry给Consumer返回Provider的地址列表，如果Provider地址有变更（上线/下线机器），Registry将基于长连接推动变更数据给Consumer
4、Consumer从Provider地址列表中，基于软负载均衡算法，选一台进行调用，如果失败，重试另一台调用
5、Consumer和Provider，在内存中累计调用次数和时间，定时每分钟一次将统计数据发送到Monitor
将上面的服务调用流程展开，如下图所示：
蓝色虚线为初始化过程，即启动时组装链；红色实线为方法调用过程，即运行时调用链；紫色实线为继承
三、实现细节
Invoker 是 Dubbo 领域模型中非常重要的一个概念，很多设计思路都是向它靠拢，这就使得 Invoker 渗透在整个实现代码里。下面用一个精简的图来说明最重要的两种 Invoker：服务提供 Invoker 和服务消费 Invoker：
① 定义服务接口：
public interface DemoService { String sayHello(String name); }