开个新坑，和大家一起学习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了）。
Dubbo是什么？
我们来看Apache Dubbo社区是怎样描述Dubbo的：
Dubbo是具有高性能，可拓展等特性的RPC框架，除此之外，Dubbo还提供了服务治理的能力。
Dubbo的“野心”不仅仅在于提供一套完整的RPC调用及服务治理框架，更是将Dubbo与编程语言解绑，提供了大部分主流语言的版本。
Tips：该图截自Apache Dubbo社区在B站上发布的《5分钟快速了解Apache Dubbo》。
RPC是什么？
既然Dubbo的本质是RPC框架，那么在继续深入学习Dubbo前，我们有必要先来了解下RPC是什么。
RPC（Remote Procedure Call），即远程过程调用。《Implementing Remote Procedure Calls》中是这么解释的：
RPC的思想是基于对单机程序中的传输和处理数据的过程调用的观察，并建议将相同的机制拓展到远程网络通信上的结果。
是不是有点难理解？没关系，我们换一个简单点的说法，来看Sahn Lam在油管视频《What is RPC? gRPC Introduction》中的解释，视频中他通过本地过程调用与远程过程调用的对比进行解释：
这个解释就非常清晰了，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的架构
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为中心，扩展接口为ProxyFactoryregistry注册中心层：封装服务地址的注册与发现，以服务URL为中心，扩展接口为
RegistryFactory，Registry，RegistryServicecluster路由层：封装多个提供者的路由及负载均衡，并桥接注册中心，以
Invoker为中心，扩展接口为Cluster，Directory，Router，LoadBalancemonitor监控层：RPC调用次数和调用时间监控，以
Statistics为中心，扩展接口为MonitorFactory，Monitor，MonitorServiceprotocol远程调用层：封装RPC调用，以
Invocation，Result为中心，扩展接口为Protocol，Invoker，Exporterexchange信息交换层：封装请求响应模式，同步转异步，以
Request，Response为中心，扩展接口为Exchanger，ExchangeChannel，ExchangeClient。ExchangeServertransport网络传输层：抽象Mina和Netty为统一接口，以
Message为中心，扩展接口为Channel，Transporter，Client，Server，Codecserialize数据序列化层：可复用的一些工具，扩展接口为
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的应用。如果本文对你有帮助的话，请多多点赞支持。最后欢迎大家关注分享硬核技术的金融摸鱼侠王有志，我们下次再见！