今天好好说一说Dubbo的架构原理

工作原理

简单的说，Dubbo 是 基于 Java 的 RPC 框架。Dubbo 工作分为 4 个角色，分别是服务提供者、服务消费者、注册中心、和监控中心。

按照工作阶段又分为部署阶段和运行阶段。

其中部署阶段在图中以蓝色的线来表示，代表服务注册、服务订阅的过程，而运行阶段在图中以红色的线来表示，代表一次 RPC 的完整调用。

部署阶段中服务提供方在启动时在指定的端口上暴露服务，并向注册中心汇报自己的地址。

服务调用方启动时向注册中心订阅自己感兴趣的服务。

运行阶段注册中心先将地址列表推送给服务消费者，服务消费者选取一个地址向对端发起调用。

在这个过程中，服务消费者和服务提供者的运行状态会上报给监控中心。

整体架构

这里是 Dubbo 的整体架构图。首先这张图看起来很复杂、信息量很大。不要被吓到。一点点的来看。

我先介绍一下这张图的解读方式。这张图从左往右看，分为两部分，左半边蓝色背景的部分代表服务消费者，右半边绿色背景的部分代表服务提供者。

从上往下看又分为九层。

左边九层按功能来划分又被分为了三大类，分别是面向用户的 Biz 层、框架核心 RPC 以及负责远程传输的 Remoting，右边按面向人群又划分为了两类，上面两层是面向用户的 API，而下面七层是面向扩展提供者的 SPI。

图中的线代表对象与对象之间不同的关系，紫色代表继承；黑色代表依赖；蓝色虚线代表服务注册、服务订阅的过程，也就是上面讲的部署阶段；红色代表一次完整的 RPC 调用，也就是运行阶段。

我们顺着红色的线，来看下一次完整的 RPC 调用是如何进行的。

首先从图的左边开始，服务消费者从 Proxy 层发起一次 RPC 调用，Dubbo 从 Registry 层拿到服务的地址列表，再通过 Cluster 层选择其中的一个作为目标地址，再流经 Protocol 决定的执行链，最后将服务信息，包括要调用的服务名、方法名、参数等序列化，再经过应用协议编码，通过 Transport 层发送到网络上。

右边的服务提供者从网络上收到数据以后，从下往上，依次通过应用协议解码、反序列化得到要调用的服务信息，再经由执行链，最终通过 Invoker 找到目标服务的目标方法，执行并返回结果。

解读完 Dubbo 的架构图，再来看看架构图中体现的设计原则。

Dubbo 秉承高内聚、低耦合的设计，这一点体现在架构图中九层的清晰划分上，并且也体现在依赖的方向上。黑色的线条的方向永远是从上指向下，没有循环依赖和反向依赖的出现。

Dubbo 还有一个很重要的设计哲学就是平等对待第三方的扩展，即 Dubbo 内建的功能也是通过同样的扩展机制提供出来的，第三方的扩展和内建功能可以相互取代。正是由于 Dubbo 将第三方扩展当成框架的一等公民，为未来基于这个机制建立生态带来了可能性。