关注王有志，分享硬核Java技术的互金摸鱼侠

加入Java人的提桶跑路群：共同富裕的Java人

开个新坑，和大家一起学习Dubbo 3.X。我们按照一个由浅入深顺序来学习，先从使用Dubbo开始，再深入Dubbo的核心原理。

今天我们就从认识Dubbo开始，整体的内容可以分为3个部分：

• Dubbo是什么

• RPC是什么

• Dubbo的架构

正式开始前我先叠个甲，通常网上很多资料将RPC称之为协议，并将RPC与HTTP进行比较，目前来看这已经成为“不太正确”但主流的说法了。而我个人是个原教旨主义者，更倾向使用RPC原初的解释，因此可能和你看到的部分文章有一定的差别。另外，因个人能力有限，若出现错误希望大家不吝赐教。

Tips：RPC的章节主要参考Andrew D. Birrell与Bruce Jay Nelson于1984年发表的论文《Implementing Remote Procedure Calls》，通常认为这篇文章是“现代”RPC的起源（实际上，1976年就有文献开始讨论RPC了）。

我们来看Apache Dubbo社区是怎样描述Dubbo的：

Apache Dubbo是一款RPC服务开发框架，用于解决微服务架构下的服务治理与通信问题，官方提供了Java、Golang等多语言SDK实现。使用Dubbo开发的微服务原生具备相互之间的远程地址发现与通信能力， 利用Dubbo提供的丰富服务治理特性，可以实现诸如服务发现、负载均衡、流量调度等服务治理诉求。Dubbo被设计为高度可扩展，用户可以方便的实现流量拦截、选址的各种定制逻辑。

Dubbo是具有高性能，可拓展等特性的RPC框架，除此之外，Dubbo还提供了服务治理的能力。

Dubbo的“野心”不仅仅在于提供一套完整的RPC调用及服务治理框架，更是将Dubbo与编程语言解绑，提供了大部分主流语言的版本。

Tips：该图截自Apache Dubbo社区在B站上发布的《5分钟快速了解Apache Dubbo》。

既然Dubbo的本质是RPC框架，那么在继续深入学习Dubbo前，我们有必要先来了解下RPC是什么。

RPC（Remote Procedure Call），即远程过程调用。《Implementing Remote Procedure Calls》中是这么解释的：

The idea of remote procedure calls (hereinafter called RPC) is quite simple. It is based on the observation that procedure calls are a well-known and well-understood mechanism for transfer of control and data within a program running on a single computer.Therefore, it is proposed that this same mechanism be

extended to provide for transfer of control and data across a communication network.

RPC的思想是基于对单机程序中的传输和处理数据的过程调用的观察，并建议将相同的机制拓展到远程网络通信上的结果。

是不是有点难理解？没关系，我们换一个简单点的说法，来看Sahn Lam在油管视频《What is RPC? gRPC Introduction》中的解释，视频中他通过本地过程调用与远程过程调用的对比进行解释：

A local procedure call is a function call within a process to execute some code.A remote procedure call enables one machine to invoke some code on another machine as if it is a local fuction call from a user's perspective.

这个解释就非常清晰了，RPC的核心是希望远程调用可以像本地函数调用一样简单。Birrell与Nelson正是基于此目标，给出了RPC服务的设计参考：

Birrell与Nelson的设计是基于存根（stub，即图中的User-stub和Server-stub）这个概念的，系统整体包含5个部分：

• 用户端，服务调用方；

• 用户端存根，保存函数声明，负责请求参数的打包与响应参数的解包；

• RPC Runtime，选择合适的方式（协议）传输数据；

• 服务端存根，保存函数声明，负责请求参数的解包与响应参数的打包；

• 服务端，服务提供方。

用户端和服务端的开发者只需要从存根中获取并调用目标函数，而无需考虑目标函数所在服务器的地址和传输数据的方式，是非常契合“远程调用可以像本地函数调用一样简单”这样的愿景的。

好了，到这里我们已经对“原教旨主义”的RPC有了整体的认知，现在来回答一个不太“正经”的问题：既然有了HTTP为什么还要RPC？

这是个挺常见的初学误区，将RPC与HTTP划上了等号。首先RPC是一种思想（我觉得更像是简化远程服务调用的目标），而HTTP是应用层的传输协议，上图中“两个”RPC Runtime传输数据时可以使用HTTP，也可以是其它能够完成数据传输的方式。其次，“现代”RPC的理论诞生于1984年，而HTTP是1989年发起的，因此这个问题反过来问还显得稍微合理些。最后，HTTP的诞生的目的是接收和发布HTML页面，即在浏览器与服务端之间进行数据的传输，而不是应用在两个服务端之间的数据传输。

Tips：

• Sahn Lam和Alex Xu是油管频道ByteByteGo的管理者，拥有有43万粉丝，另外他们也是《System Design Interview》的作者；

• RPC的系统设计图截自《Implementing Remote Procedure Calls》；

• 实际的项目中，没有严格的用户端与服务端的区分，服务都可以提供对外的接口，也可以使用外部服务的接口。

Dubbo 3.0开始，Dubbo的官方文档使用了新的抽象架构：

将Dubbo从整体划分了两层：

• Dubbo数据面：提供RPC功能的核心部分，通过RPC协议进行通信，定义了调用规范，完成了数据交互的编码和解码功能做；

• 服务治理控制面：服务治理的抽象，包含了注册中心，流量管控策略，Dubbo Admin控制台等。

Dubbo 3.0之前，官方给出过一张非常复杂的Dubbo 2.X的设计图（以下的部分是官方原文）：

图例说明

• 图中左边淡蓝背景的为服务消费方使用的接口，右边淡绿色背景的为服务提供方使用的接口，位于中轴线上的为双方都用到的接口；

• 图中从下至上分为十层，各层均为单向依赖，右边的黑色箭头代表层之间的依赖关系，每一层都可以剥离上层被复用，其中，Service和Config层为API，其它各层均为SPI；

• 图中绿色小块的为扩展接口，蓝色小块为实现类，图中只显示用于关联各层的实现类；

• 图中蓝色虚线为初始化过程，即启动时组装链，红色实线为方法调用过程，即运行时调时链，紫色三角箭头为继承，可以把子类看作父类的同一个节点，线上的文字为调用的方法。

Dubbo提供了非常丰富的接口，这些都是Dubbo的可被用户自定义的拓展点。Dubbo自身也采用了Microkernel+Plugin（微内核+拓展）的模式，Microkernel只负责组装Dubbo对Plugin的默认实现。

各层说明

• config配置层：对外配置接口，以ServiceConfig，ReferenceConfig为中心，可以直接初始化配置类，也可以通过Spring解析配置生成配置类

• proxy服务代理层：服务接口透明代理，生成服务的客户端Stub和服务器端Skeleton, 以ServiceProxy为中心，扩展接口为ProxyFactory

• registry注册中心层：封装服务地址的注册与发现，以服务URL为中心，扩展接口为RegistryFactory，Registry，RegistryService

• cluster路由层：封装多个提供者的路由及负载均衡，并桥接注册中心，以Invoker为中心，扩展接口为Cluster，Directory，Router，LoadBalance

• monitor监控层：RPC调用次数和调用时间监控，以Statistics为中心，扩展接口为MonitorFactory，Monitor，MonitorService

• protocol远程调用层：封装RPC调用，以Invocation，Result为中心，扩展接口为Protocol，Invoker，Exporter

• exchange信息交换层：封装请求响应模式，同步转异步，以Request，Response为中心，扩展接口为Exchanger，ExchangeChannel，ExchangeClient。ExchangeServer

• transport网络传输层：抽象Mina和Netty为统一接口，以Message为中心，扩展接口为Channel，Transporter，Client，Server，Codec

• serialize数据序列化层：可复用的一些工具，扩展接口为Serialization，ObjectInput，ObjectOutput，ThreadPool

有些文章会将Service纳入Dubbo的层级结构中，但实际上Service是用户业务逻辑的部分，严格意义上并不是Dubbo自身的组成。

支持协议

协议是RPC框架的核心功能，定义了数据的传输格式，除了数据本身外，还应包含控制信息，如：序列化方式，超时时间等。

Dubbo支持了非常多的协议，在这里我将它们分成5类：

不要看到Dubbo支持了这么多协议就害怕，它虽然支持的多，但我们不必每个协议都深入。未来我们在学习到协议的部分是，会重点的学习Dubbo协议，Dubbo 3.X主推的Triple协议以及支持HTTP/2的gRPC，其余协议我们大致了解其特性即可。

Tips：实际上Dubbo 2.X的官方文档中有非常详细的设计文档，不知道为什么Dubbo 3.0中删除了这部分内容。

好了，到目前为止希望你能够建立起一个对Dubbo设计的整体认知。设计虽然复杂，支持的协议虽然很多，但我们今天的目的不是“一文弄懂”。我们以理解RPC和Birrell与Nelson给出的设计为主，其次我们需要建立对Dubbo的设计的整体认知，看看它Dubbo在Birrell与Nelson的基础上做出了哪些拓展。如果有兴趣的话，可以参考Birrell与Nelson给出的架构来设计自己的RPC服务，需要考虑如何将服务保存到存根中？使用哪种方式进行交互？交互的数据结构该如何设计？

下一篇，我们一起来使用Duubbo，掌握Dubbo的应用。如果本文对你有帮助的话，请多多点赞支持。最后欢迎大家关注分享硬核技术的金融摸鱼侠王有志，我们下次再见！