详解RPC框架核心原理

RPC概念：

RPC(Remote Procedure Call)：远程过程调用。服务调用者可以像调用本地接口一样调用远程的服务提供者，RPC 框架负责屏蔽底层的传输方式（TCP 或者 UDP）、序列化方式（XML/Json/ 二进制）和通信细节，而不需要关心底层通信细节和调用过程。

RPC 是一种技术思想而非一种规范或协议,目前流行的开源 RPC 框架还是比较多的，有阿里巴巴的 Dubbo、Facebook 的 Thrift、Google 的 gRPC、Twitter 的 Finagle 等。

 

为什么需要RPC？

随着项目的规模和复杂度越来越大，我们需要对项目进行服务化拆分

 

单体应用拆分成多个服务后的优点：

1.降低项目的臃肿程度，按业务维度划分服务后，各个团队专注于所负责的业务线，职责单一化

2.服务间解耦，各个服务可以安排合适的研发人员，独立开发，采用合适的技术栈和独立部署

项目服务化后也会引申出一些问题：

一个业务功能请求需要经过多个服务间调用才能最终完成，各个服务独立部署，无法像单体应用一样本地调用，我们要如何实现服务间的调用呢？

方式一：调用方和被调用方约定一个协议格式，通过Socket通信来传输参数，被调用方监听Socket，根据接收的参数调用本地方法

缺点：调用方和被调用方每次都要关注底层的调用细节

• 入参序列化成字节流，字节流反序列化成参数
• Socket传输协议，socket发送和接收

能不能调用层不关注这个细节？

可以，RPC框架就是解决这个问题的，它能够让调用方“像调用本地函数一样调用远端的函数（服务）”。

 

方式二：通过RPC框架来完成服务间的调用

 

PRC框架的职责是：

• Client端：序列化，连接池管理，负载均衡，路由策略，故障转移，超时处理，异步管理等等
• Server端：网络通信事件处理，反序列化，收发队列，优雅关闭，超时处理

为什么要进行序列化？

在业务程序中，我们通常通过“对象”来操纵数据，但当需要对数据进行存储或者传输时，“对象”就不这么好用了，往往需要把数据转化成连续空间的“二进制字节流”，一些典型的场景是：

• 数据库索引的磁盘存储：数据库的索引在内存里是b+树，但这个格式是不能够直接存储到磁盘上的，所以需要把b+树转化为连续空间的二进制字节流，才能存储到磁盘上
• 缓存的KV存储：redis/memcache是KV类型的缓存，缓存存储的value必须是连续空间的二进制字节流，而不能够是User对象
• 数据的网络传输：socket发送的数据必须是连续空间的二进制字节流，也不能是对象

所谓序列化（Serialization），就是将“对象”形态的数据转化为“连续空间二进制字节流”形态数据的过程。这个过程的逆过程叫做反序列化。

怎么进行序列化？

1. 通过具有自描述特性的标记语言（例如json和xml）来描述对象，规定好转换规则，发送方很容易把一个对象序列化为xml，服务方收到xml二进制流之后，也很容易将其反序列化为对象。
2. 通过自定义一个二进制协议来进行序列化，我们重点来介绍下google的protocol buffer（pb）

 

一个完整的RPC框架：

在一个典型 RPC 的使用场景中，包含了服务发现、负载、容错、网络传输、序列化等组件，其中“RPC 协议”就指明了程序如何进行网络传输和序列化。

 

RPC-Client同步调用架构

 

所谓同步调用，在得到结果之前，一直处于阻塞状态，会一直占用一个工作线程，上图简单的说明了一下组件、交互、流程步骤：

• 左边大框，代表了调用方的一个工作线程
• 左边粉色中框，代表了RPC-client组件
• 右边橙色框，代表了RPC-server
• 蓝色两个小框，代表了同步RPC-client两个核心组件，序列化组件与连接池组件
• 白色的流程小框，以及箭头序号1-10，代表整个工作线程的串行执行步骤：

1）业务代码发起RPC调用：

Result=Add(Obj1,Obj2)

2）序列化组件，将对象调用序列化成二进制字节流，可理解为一个待发送的包packet1；

3）通过连接池组件拿到一个可用的连接connection；

4）通过连接connection将包packet1发送给RPC-server；

5）发送包在网络传输，发给RPC-server；

6）响应包在网络传输，发回给RPC-client；

7）通过连接connection从RPC-server收取响应包packet2；

8）通过连接池组件，将conneciont放回连接池；

9）序列化组件，将packet2范序列化为Result对象返回给调用方；

10）业务代码获取Result结果，工作线程继续往下走；

 

rpc的核心功能：

RPC 的核心功能是指实现一个 RPC 最重要的功能模块，就是上图中的”RPC 协议”部分：

 

一个 RPC 的核心功能主要有 5 个部分组成，分别是：客户端、客户端 Stub、网络传输模块、服务端 Stub、服务端等。

注：

stub 

每个远程对象都包含一个代理对象stub，当运行在本地Java虚拟机上的程序调用运行在远程Java虚拟机上的对象方法时，它首先在本地创建该对象的代理对象stub, 然后调用代理对象上匹配的方法，代理对象会作如下工作： 
与远程对象所在的虚拟机建立连接 
打包(marshal)参数并发送到远程虚拟机 
等待执行结果 
解包(unmarshal)返回值或返回的错误 
返回调用结果给调用程序 
stub 对象负责调用参数和返回值的流化(serialization)、打包解包，以及网络层的通讯过程。 

下面分别介绍核心 RPC 框架的重要组成：

• 客户端(Client)：服务调用方。
• 客户端存根(Client Stub)：存放服务端地址信息，将客户端的请求参数数据信息打包成网络消息，再通过网络传输发送给服务端。
• 服务端存根(Server Stub)：接收客户端发送过来的请求消息并进行解包，然后再调用本地服务进行处理。
• 服务端(Server)：服务的真正提供者。
• Network Service：底层传输，可以是 TCP 或 HTTP。

一次 RPC 调用流程如下：

• 服务消费者(Client 客户端)通过本地调用的方式调用服务。
• 客户端存根(Client Stub)接收到调用请求后负责将方法、入参等信息序列化(组装)成能够进行网络传输的消息体。
• 客户端存根(Client Stub)找到远程的服务地址，并且将消息通过网络发送给服务端。
• 服务端存根(Server Stub)收到消息后进行解码(反序列化操作)。
• 服务端存根(Server Stub)根据解码结果调用本地的服务进行相关处理
• 服务端(Server)本地服务业务处理。
• 处理结果返回给服务端存根(Server Stub)。
• 服务端存根(Server Stub)序列化结果。
• 服务端存根(Server Stub)将结果通过网络发送至消费方。
• 客户端存根(Client Stub)接收到消息，并进行解码(反序列化)。
• 服务消费方得到最终结果。

 

RPC 核心之功能实现(技术点)

RPC 的核心功能主要由 5 个模块组成，如果想要自己实现一个 RPC，最简单的方式要实现三个技术点，分别是：

• 服务寻址(服务的消费放如何找到定位服务的提供者)
• 数据流的序列化和反序列化
• 网络传输

服务寻址

服务寻址可以使用 Call ID 映射。在本地调用中，函数体是直接通过函数指针来指定的，但是在远程调用中，函数指针是不行的，因为两个进程的地址空间是完全不一样的。

所以在 RPC 中，所有的函数都必须有自己的一个 ID。这个 ID 在所有进程中都是唯一确定的。

客户端在做远程过程调用时，必须附上这个 ID。然后我们还需要在客户端和服务端分别维护一个函数和Call ID的对应表。

当客户端需要进行远程调用时，它就查一下这个表，找出相应的 Call ID，然后把它传给服务端，服务端也通过查表，来确定客户端需要调用的函数，然后执行相应函数的代码。

实现方式：服务注册中心。

要调用服务，首先你需要一个服务注册中心去查询对方服务都有哪些实例。Dubbo 的服务注册中心是可以配置的，官方推荐使用 Zookeeper。

实现案例：RMI(Remote Method Invocation，远程方法调用)也就是 RPC 本身的实现方式。

图 9：RMI 架构图

Registry(服务发现)：借助 JNDI 发布并调用了 RMI 服务。实际上，JNDI 就是一个注册表，服务端将服务对象放入到注册表中，客户端从注册表中获取服务对象。

RMI 服务在服务端实现之后需要注册到 RMI Server 上，然后客户端从指定的 RMI 地址上 Lookup 服务，调用该服务对应的方法即可完成远程方法调用。

Registry 是个很重要的功能，当服务端开发完服务之后，要对外暴露，如果没有服务注册，则客户端是无从调用的，即使服务端的服务就在那里。

序列化和反序列化

客户端怎么把参数值传给远程的函数呢?在本地调用中，我们只需要把参数压到栈里，然后让函数自己去栈里读就行。

但是在远程过程调用时，客户端跟服务端是不同的进程，不能通过内存来传递参数。

这时候就需要客户端把参数先转成一个字节流，传给服务端后，再把字节流转成自己能读取的格式。

只有二进制数据才能在网络中传输，序列化和反序列化的定义是：

• 将对象转换成二进制流的过程叫做序列化
• 将二进制流转换成对象的过程叫做反序列化

这个过程叫序列化和反序列化。同理，从服务端返回的值也需要序列化反序列化的过程。

网络传输

网络传输：远程调用往往用在网络上，客户端和服务端是通过网络连接的。

所有的数据都需要通过网络传输，因此就需要有一个网络传输层。网络传输层需要把 Call ID 和序列化后的参数字节流传给服务端，然后再把序列化后的调用结果传回客户端。

只要能完成这两者的，都可以作为传输层使用。因此，它所使用的协议其实是不限的，能完成传输就行。

尽管大部分 RPC 框架都使用 TCP 协议，但其实 UDP 也可以，而 gRPC 干脆就用了 HTTP2。

TCP 的连接是最常见的，简要分析基于 TCP 的连接：通常 TCP 连接可以是按需连接(需要调用的时候就先建立连接，调用结束后就立马断掉)，也可以是长连接(客户端和服务器建立起连接之后保持长期持有，不管此时有无数据包的发送，可以配合心跳检测机制定期检测建立的连接是否存活有效)，多个远程过程调用共享同一个连接。

所以，要实现一个 RPC 框架，只需要把以下三点实现了就基本完成了：

• Call ID 映射：可以直接使用函数字符串，也可以使用整数 ID。映射表一般就是一个哈希表。
• 序列化反序列化：可以自己写，也可以使用 Protobuf 或者 FlatBuffers 之类的。
• 网络传输库：可以自己写 Socket，或者用 Asio，ZeroMQ，Netty 之类。

RPC 核心之网络传输协议

在第三节中说明了要实现一个 RPC，需要选择网络传输的方式。

图 10：网络传输

在 RPC 中可选的网络传输方式有多种，可以选择 TCP 协议、UDP 协议、HTTP 协议。

每一种协议对整体的性能和效率都有不同的影响，如何选择一个正确的网络传输协议呢?首先要搞明白各种传输协议在 RPC 中的工作方式。

基于 TCP 协议的 RPC 调用

由服务的调用方与服务的提供方建立 Socket 连接，并由服务的调用方通过 Socket 将需要调用的接口名称、方法名称和参数序列化后传递给服务的提供方，服务的提供方反序列化后再利用反射调用相关的方法。

***将结果返回给服务的调用方，整个基于 TCP 协议的 RPC 调用大致如此。

但是在实例应用中则会进行一系列的封装，如 RMI 便是在 TCP 协议上传递可序列化的 Java 对象。

基于 HTTP 协议的 RPC 调用

该方法更像是访问网页一样，只是它的返回结果更加单一简单。

其大致流程为：由服务的调用者向服务的提供者发送请求，这种请求的方式可能是 GET、POST、PUT、DELETE 等中的一种，服务的提供者可能会根据不同的请求方式做出不同的处理，或者某个方法只允许某种请求方式。

而调用的具体方法则是根据 URL 进行方法调用，而方法所需要的参数可能是对服务调用方传输过去的 XML 数据或者 JSON 数据解析后的结果，***返回 JOSN 或者 XML 的数据结果。

由于目前有很多开源的 Web 服务器，如 Tomcat，所以其实现起来更加容易，就像做 Web 项目一样。

两种方式对比

基于 TCP 的协议实现的 RPC 调用，由于 TCP 协议处于协议栈的下层，能够更加灵活地对协议字段进行定制，减少网络开销，提高性能，实现更大的吞吐量和并发数。

但是需要更多关注底层复杂的细节，实现的代价更高。同时对不同平台，如安卓，iOS 等，需要重新开发出不同的工具包来进行请求发送和相应解析，工作量大，难以快速响应和满足用户需求。

基于 HTTP 协议实现的 RPC 则可以使用 JSON 和 XML 格式的请求或响应数据。

而 JSON 和 XML 作为通用的格式标准(使用 HTTP 协议也需要序列化和反序列化，不过这不是该协议下关心的内容，成熟的 Web 程序已经做好了序列化内容)，开源的解析工具已经相当成熟，在其上进行二次开发会非常便捷和简单。

但是由于 HTTP 协议是上层协议，发送包含同等内容的信息，使用 HTTP 协议传输所占用的字节数会比使用 TCP 协议传输所占用的字节数更高。

因此在同等网络下，通过 HTTP 协议传输相同内容，效率会比基于 TCP 协议的数据效率要低，信息传输所占用的时间也会更长，当然压缩数据，能够缩小这一差距。

 

为什么有了http还要用RPC?

具体使用哪一种要看实际的业务场景，各有优缺点，灵活站位。

HTTP协议，以其中的Restful规范为代表，其优势很大。优点在于：它可读性好，且可以得到防火墙的支持、跨语言的支持。

HTTP协议缺点：①首先是传输数据包有用信息占比少，包含了大量的HTTP头等信息。②效率低，传输相同的内容，时间长，效率低。③使用HTTP协议调用远程方法比较复杂，要封装各种参数名和参数值，在易用性上没rpc强。

1.主要的关注点就在于，基于http协议的resultFul风格的接口调用和rpc的传输协议（比如使用tcp协议）的一个区别。但是所谓的效率优势是针对http1.1协议来讲的，http2.0协议已经优化编码效率问题，像grpc这种rpc库使用的就是http2.0协议。

2.成熟的rpc库相对http容器，更多的是封装了“服务发现”，"负载均衡"，“熔断降级”一类面向服务的高级特性。针对服务的可用性和效率等都做了优化。单纯使用http调用则缺少了这些特性。

 

 

 

https://developer.51cto.com/art/201906/597963.htm

https://zhuanlan.zhihu.com/p/266261432