前言

本文中部分知识涉及Dubbo，需要对Dubbo有一定的理解，且对源码有一定了解

如果不了解，可以参考学习我之前的文章：

1. 浅谈Spring整合Dubbo源码（@Service和@Reference注解部分）

2. 浅谈Dubbo服务导出到注册中心源码

3. 浅谈Dubbo服务引入源码（@ReferenceBean依赖注入）

4. 浅谈Dubbo核心概念及架构流程

---

RPC体系

RPC与HTTP协议都属于网络协议中的应用层，HTTP协议侧重描述通信层面的约定，而RPC更加侧重于远程过程调用的目的（可以使程序能在网络上请求远程计算机上的服务，而无须关心底层网络技术细节），即两者并不冲突，比如RPC框架的实现之一Feign，其底层通信就是使用的HttpClient。

基于RPC需要具备的各项能力，可以对整个RPC的调用过程进行分层，将各项能力分布在各层中，最终达成我们的目的。下图为RPC各层的梳理，同时将开源的Dubbo框架架构图中的各层与RPC的各层进行了映射：

整体执行流程如下：

1. 客户端调用：客户端通过本地调用远程过程的方式，就像调用本地方法一样；
2. 数据序列化：客户端将调用的参数序列化为可以在网络上传输的格式，如二进制流或 JSON；
3. 网络传输：序列化后的数据通过网络传输到远程服务器；
4. 数据反序列化：服务器接收到数据后，将其反序列化为原始参数；
5. 服务端执行：服务器执行相应的过程，并将结果返回；
6. 结果序列化：服务器将执行结果序列化为可以在网络上传输的格式；
7. 网络传输：序列化后的结果通过网络传输到客户端；
8. 结果反序列化：客户端接收到结果后，将其反序列化为最终的返回值；
9. 客户端接收结果：客户端获得最终的执行结果，完成整个过程。

---

Dubbo架构

在了解了RPC体系以后，再看Dubbo的架构图，尽管图中节点很多，但是我们可以很方便的抓住核心点（起码我很有感觉），即明白这是哪一层，这一层要干嘛，相关节点的大致作用。

---

最后

我们可以明确，类比于其他RPC框架，它们面对的问题、以及要解决的问题都是相同的，只不过不同的框架相关的实现有差异，仅此而已。

同时我们不难发现，不同RPC框架经常说的性能问题，其本质也就是①Message Protocol（消息管理层）、②Transfer/Network Protocol（传输管理层）、③描述后的URL（描述服务的协议方式）、④Registration Center（注册中心）之间的差异。