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