一. Dubbo 架构
Dubbo 是阿里服务化治理方案的核心框架，是一种分布式 RPC 框架，它提供了注册中心机制，解耦了消费方与服务方动态发现的问题。
1.1 Dubbo 架构
Dubbo 的架构主要分为四部分：服务提供方、服务消费者、注册中心、统计中心，这四部分也被称为部署逻辑拓扑节点。Dubbo 运作模式如下：
- 注册：服务提供方 (Provider) 启动时，把自己的元数据向注册中心 (Registry) 上面注册；
- 订阅：服务消费者 (Consumer)启动时，从注册中心 (Registry) 订阅服务提供方的元数据；
- 通知：注册中心的数据发生变更，变更的数据会推送给订阅的服务消费者；
- 调用：获取服务提供方的元数据后，消费者可以发起 RPC 调用；
- 监控：RPC 调用发生前后，会向监控中心 (Monitor) 上报统计信息；
![Dubbo架构]()
Dubbo 的架构如上图所示，上图图例说明：
- 图中小方块 Protocol, Cluster, Proxy, Service, Container, Registry, Monitor 代表层或模块，蓝色的表示与业务有交互，绿色的表示只对 Dubbo 内部交互；
- 图中背景方块 Consumer, Provider, Registry, Monitor 代表 Dubbo 架构的四个部分；
- 图中**蓝色虚线**为初始化时调用，红色虚线为运行时异步调用，红色实线为运行时同步调用；
- 注：图中只包含 RPC 的层，不包含 Remoting 的层，Remoting 整体都隐含在 Protocol 中；关于分层见下一节的图示。
1.2 Dubbo 分层
上图为 Dubbo 的分层结构。横向将其分为两部分，左边淡蓝色背景是消费者使用的接口，右边淡绿色背景是提供者使用的接口，位于两者中轴线上的是消费者与提供者共同使用的接口。
纵向可以将 Dubbo 分为十层。如果按照总体功能，可以想左侧的分类一样，将 Dubbo 分为三层：
- 业务层 (Business)：Business
- RPC 层：Config, Proxy, Registry, Cluster, Monitor, Protocol
- 远程调用层 (Remote)：Exchange, Transport, Serialize
如果按照调用方的角度：
- API 层：Service, Config，供用户调用；
- SPI 层：除 API 层其他所有层，这些层全部可扩展的主要提供给扩展者使用，这也是 Dubbo 扩展能力强的原因。
各层及各层的核心组件如下：
| 层次名 | 作用 |
|---|---|
| 业务层 (Service) | 业务代码的接口与实现，即开发者实现的业务代码 |
| 配置层 (Config) | 对外配置接口，以用来暴露服务配置的 ServiceConfig 与引用的服务配置 ReferenceConfig 为中心 |
| 服务代理层 (Proxy) | 无论是服务提供者还是消费者，Dubbo 框架都会生成一个代理类，整个过程对上面是透明的，调用远程接口就像调用本地方法一样。核心为 ServiceProxy |
| 注册层 (Registry) | 负责 Dubbo 框架的服务注册与发现。集群中有服务上下线时，注册中心通知订阅该服务的订阅方相应的动作 |
| 集群容错层 (Cluster) | 又称路由层，负责远程调用失败的容错策略，以及选择调用节点的负载均衡策略 |
| 监控层 (Monitor) | 监控 RPC 调用次数、调用时间 |
| 远程调用层 (Protocol) | 封装 RPC 调用的具体过程。Dubbo 以 Invoker 为核心模型，框架中其他所有模型向它靠拢，可以是一个本地、远程、或者集群的实现 |
| 信息交换层 (Exchange) | 封装请求响应模式 |
| 网络传输层 (Transport) | 把网络传输抽象成统一的接口，以 Mina, Netty 为统一接口，以 Message 为中心 |
| 序列化层 (Serialize) | 负责管理整个框架网络传输时的序列化、反序列化工作 |
1.3 Dubbo 架构关系
首先在 Dubbo 架构图中的服务提供者 (Provider) 与服务消费者 (Consumer) 都是抽象的、相对性的概念，类似于我们平常说的服务器、客户端结构。这样的概念主要是为了让读者更加直观的了解哪些类属于客户端与服务端。
在 RPC 层中，Protocol 是核心层。只要有 Protocol + Invoker + Exporter，就可以完成非透明的 RPC 远程调用。
在远程调用层 Remote 中，基本是 Dubbo 协议的实现。Remote 层内部再划分为传输层 Transport 与信息交换层 Exchange，传输层只负责消息的单向传输，是对不同协议 Mina, Netty, Grizzly 的抽象，同时也可以扩展接口；而Exchange 层在 Transport 层之上封装了请求-响应的模型。