用通俗的语言介绍 RPC 框架的架构原理
2022 年认真干点事！
动手实现一个简易的 RPC 轮子真的很难吗？no no no，很简单的，不信你把文章看完（doge）。
RPC 框架典型的架构
典型的 RPC 架构大致可以分为三个部分：
（1）服务提供者（RPC Server）：运行在服务器端，提供服务接口定义与服务实现类。
（2）注册中心（Registry）：运行在服务器端，负责将本地服务发布成远程服务，管理远程服务，提供给服务消费者使用。
（3）服务消费者（RPC Client）：运行在客户端，通过远程代理对象调用远程服务。
通过上面的图可以看出，一次简单的 RPC 调用可以分为以下几个步骤：
（1）服务提供者启动后主动向服务注册中心注册机器ip、端口以及提供的服务列表；
（2）服务消费者启动时向服务注册中心获取服务提供方地址列表，在本地缓存一份；
（3）服务消费者通过本地调用的方式调用服务，调用模块收到请求后通过负载均衡策略选取合适的远程服务地址；
（4）协议模块负责将方法、入参等信息序列化(编码)成能够进行网络传输的消息体，并将消息通过网络发送给服务端；
（5）服务端收到消息后进行解码(反序列化操作)。
（6）根据解码结果调用本地的服务进行相关处理；
（7）服务端将处理返回的结果进行序列化（编码），并将结果通过网络发送至服务消费者；
（8）服务消费者收到消息后进行解码最终得到结果；
敲黑板：在不同的 RPC 框架实现中步骤 1、2、3的顺序可能有些不同。
RPC 核心功能
一个完整的商用 RPC 框架有很多功能，最最核心的基本就是三个：服务寻址、数据编解码、网络传输。
服务寻址
如果是本地调用，被调用的方法在同一个进程内，操作系统或虚拟机可以地址空间找到；但是在远程调用中，这是行不通的，因为两个进程的地址空间是完全不一样的，并且也无法知道远端的进程在何处。
要想实现远程调用，我们需要对服务消费者和服务提供者进行约束：
在远程过程调用中所有的函数都必须有一个ID，这个 ID 在整套系统中是唯一确定的。
服务消费者在做远程过程调用时，发送的消息体中必须携带这个 ID。
服务消费者和服务提供者分别维护一个函数和 ID 的对应表。
当服务消费者需要进行远程调用时，它就查一下这个表，找出对应的 ID，然后把它传给服务端，服务端也通过查表，来确定客户端需要调用的函数，然后执行相应函数的代码。
上面说的可能比较抽象，通俗一点就是服务消费者如何寻找服务提供者，这就是服务寻址。
服务寻址的实现方式有很多种，比较常见的是：服务注册中心。要调用服务，首先你需要一个服务注册中心去查询对方服务都有哪些实例，然后根据负载均衡策略择优选一。
像 Dubbo 框架的服务注册中心是可以配置的，官方推荐使用 Zookeeper。
数据编解码（序列化和反序列化）
对计算机网络稍微有一点了解的同学都知道，数据在网络中传输是二进制的：01010101010101010，类似这种，只有二进制数据才能在网络中传输。
那一个客户端调用远程服务的一个方法，像方法入参这些必然需要转换成二进制才能进行传输，这种将对象转换成二进制流的过程就叫做序列化编码。
服务端接收到二进制流不能识别，势必要将二进制流转换成对象，这个逆过程就叫做反序列化解码。
一般场景下是可以将序列化编码简称为序列化。
敲黑板：
如果非要较真，严格来说序列化和编码是两个不同的概念，我画一张图大家都明白了。
序列化+编码的逆过程就是：解码+反序列化。
网络传输
提起网络传输大家脑海里肯定马上就能想到 TCP/IP四层模型、OSI 七层模型，那通常 RPC 会选择那一层作为传输协议呢？
在回答这个问题前我们先看下 RPC 需要网络传输实现什么功能。
客户端的数据经过序列化+编码后，就需要通过网络传输到服务端。网络传输层需要把前面说的函数 ID 和序列化后的参数字节流传给服务端，服务端处理完然后再把序列化后的调用结果传回客户端。
原则上只要能实现上面这个功能的都可以作为传输层来使用，具体协议没有限制。
我们先来看下 TCP 协议，TCP 连接可以是按需连接，需要调用的时候就先建立连接，调用结束后就立马断掉，也可以是长连接，客户端和服务器建立起连接之后保持长期持有，不管此时有无数据包的发送，可以配合心跳检测机制定期检测建立的连接是否存活有效。
由此可见 TCP 的性能确实很好，因此市面上大部分 RPC 框架都使用 TCP 协议，但也有少部分框架使用其他协议，比如 gRPC 就基于 HTTP2 来实现的。
敲黑板：
数据编解码和网络传输可以有多种组合方式，比如常见的有：HTTP+JSON, Dubbo 协议+TCP 等。
常见的 RPC 框架
说了这么多 RPC 相关的技术，我们盘点一下市面上常用的 RPC 框架。
RMI（Sun/Oracle） Thrift（Facebook/Apache） gRPC（Google） Finagle（Twitter） Dubbo（阿里巴巴/Apache） Motan（新浪微博） brpc（百度/Apache） ……欢迎大家补充其他的。
总结
（1）服务提供者需要以某种形式提供服务调用相关的信息，包括但不限于服务接口定义、数据结构、或者中间态的服务定义文件。例如Facebook的 Thrift 框架的IDL文件，Web service的 WSDL 文件；服务的消费者需要通过一定的场景获取远程服务调用相关的信息。
（2）远程代理对象：服务消费者用的服务实际是远程服务的本地代理，说白了就是通过动态代理来实现的。
（3）序列化：毕竟是远程通信，需要将对象转化成二进制流进行传输。不同的RPC框架应用的场景不同，在序列化上也会采取不同的技术。
（4）通信：RPC框架与具体的协议无关。Netty 是一个高性能的网络通信框架。
因此要实现一个 RPC 框架，只需要把上面四点实现了就基本完成了。大家学会了吗？
-- END --
前段时间我动手撸了一个 RPC 框架demo，欢迎大家去下载源码试用。
如果你对这个项目还不是很熟悉，建议你先看一下下面的入门文章。
「从零开始造 RPC 轮子系列」01 我为什么要去造一个轮子？
「从零开始造 RPC 轮子系列」02 演示轮子，是驴是马拉出来遛遛
「从零开始造 RPC 轮子系列」03 完事具备，只差一个环境搭建
「从零开始造 RPC 轮子系列」04 手绘4 张图带你入门 RPC 服务框架
我是雷小帅，记得三连，下期见~