RPC内核细节(转载)

背景

随着数据量、并发量、业务复杂度的增长，服务化是架构演进必由之路。服务化离不开RPC框架。

RPC服务化的好处

服务化的一个好处就是，不限定服务的提供方使用什么技术选型，能够实现大公司跨团队的技术解耦。
如下图所示：
在这里插入图片描述

服务A：欧洲团队维护，技术背景是Java；
服务B：美洲团队维护，用C++实现；
服务C：中国团队维护，技术栈是go；
服务的上游调用方，按照接口、协议即可完成对远端服务的调用。

但实际上，大部分互联网公司，研发团队规模有限，大都使用同一套技术体系来实现服务:
在这里插入图片描述
这样的话，如果没有统一的服务框架，各个团队的服务提供方就需要各自实现一套序列化、反序列化、网络框架、连接池、收发线程、超时处理、状态机等“业务之外”的重复技术劳动，造成整体的低效。

因此，统一服务框架把上述“业务之外”的工作统一实现，是服务化首要解决的问题。

RPC框架的职责是什么？

RPC框架，要向调用方屏蔽各种复杂性，要向服务提供方也屏蔽各类复杂性：

服务调用方client感觉就像调用本地函数一样，来调用服务；
服务提供方server感觉就像实现一个本地函数一样，来实现服务；

所以整个RPC框架又分为client部分与server部分，实现上面的目标，把复杂性屏蔽，就是RPC框架的职责。

在这里插入图片描述
如上图所示，业务方的职责是：

调用方A，传入参数，执行调用，拿到结果；
服务方B，收到参数，执行逻辑，返回结果；

RPC框架的职责是，中间大蓝框的部分：

client端：序列化、反序列化、连接池管理、负载均衡、故障转移、队列管理，超时管理、异步管理等等；
server端：服务端组件、服务端收发包队列、io线程、工作线程、序列化反序列化等；

序列化协议要考虑什么因素？

不管使用成熟协议xml/json，还是自定义二进制协议来序列化对象，序列化协议设计时都需要考虑以下这些因素：

解析效率：这个应该是序列化协议应该首要考虑的因素，像xml/json解析起来比较耗时，需要解析doom树，二进制自定义协议解析起来效率就很高；
压缩率，传输有效性：同样一个对象，xml/json传输起来有大量的xml标签，信息有效性低，二进制自定义协议占用的空间相对来说就小多了；
扩展性与兼容性：是否能够方便的增加字段，增加字段后旧版客户端是否需要强制升级，都是需要考虑的问题，xml/json和上面的二进制协议都能够方便的扩展；
可读性与可调试性：这个很好理解，xml/json的可读性就比二进制协议好很多；
跨语言：上面的两个协议都是跨语言的，有些序列化协议是与开发语言紧密相关的，例如dubbo的序列化协议就只能支持Java的RPC调用；
通用性：xml/json非常通用，都有很好的第三方解析库，各个语言解析起来都十分方便，上面自定义的二进制协议虽然能够跨语言，但每个语言都要写一个简易的协议客户端；

在这里插入图片描述
RPC-client包含下面部分：

序列化反序列化的部分（上图中的1、4）
发送字节流与接收字节流的部分（上图中的2、3）

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）通过连接池组件，将connection放回连接池；
9）序列化组件，将packet2反序列化为Result对象返回给调用方；
10）业务代码获取Result结果，工作线程继续往下走；

连接池组件有什么作用？
RPC框架锁支持的负载均衡、故障转移、发送超时等特性，都是通过连接池组件去实现的。
在这里插入图片描述
典型连接池组件对外提供的接口为：

int ConnectionPool::init(…);
Connection ConnectionPool::getConnection();
int ConnectionPool::putConnection(Connection t);

init做了些什么？
和下游RPC-server（一般是一个集群），建立N个tcp长连接，即所谓的连接“池”。
getConnection做了些什么？
从连接“池”中拿一个连接，加锁（置一个标志位），返回给调用方。
putConnection做了些什么？
将一个分配出去的连接放回连接“池”中，解锁（也是置一个标志位）。

如何实现负载均衡？
连接池中建立了与一个RPC-server集群的连接，连接池在返回连接的时候，需要具备随机性。

如何实现故障转移？
连接池中建立了与一个RPC-server集群的连接，当连接池发现某一个机器的连接异常后，需要将这个机器的连接排除掉，返回正常的连接，在机器恢复后，再将连接加回来。

如何实现发送超时？
因为是同步阻塞调用，拿到一个连接后，使用带超时的send/recv即可实现带超时的发送和接收。

总的来说，同步的RPC-client的实现是相对比较容易的，序列化组件、连接池组件配合多工作线程数，就能够实现。

RPC-client异步调用架构如何？

在这里插入图片描述
所谓异步回调，在得到结果之前，不会处于阻塞状态，理论上任何时间都没有任何线程处于阻塞状态，因此异步回调的模型，理论上只需要很少的工作线程与服务连接就能够达到很高的吞吐量，如上图所示：
左边的框框，是少量工作线程（少数几个就行了）进行调用与回调

中间粉色的框框，代表了RPC-client组件
右边橙色框，代表了RPC-server
蓝色六个小框，代表了异步RPC-client六个核心组件：上下文管理器，超时管理器，序列化组件，下游收发队列，下游收发线程，连接池组件
白色的流程小框，以及箭头序号1-17，代表整个工作线程的串行执行步骤：

1）业务代码发起异步RPC调用；

Add(Obj1,Obj2, callback)

2）上下文管理器，将请求，回调，上下文存储起来；
3）序列化组件，将对象调用序列化成二进制字节流，可理解为一个待发送的包packet1；
4）下游收发队列，将报文放入“待发送队列”，此时调用返回，不会阻塞工作线程；
5）下游收发线程，将报文从“待发送队列”中取出，通过连接池组件拿到一个可用的连接connection；
6）通过连接connection将包packet1发送给RPC-server；
7）发送包在网络传输，发给RPC-server；
8）响应包在网络传输，发回给RPC-client；
9）通过连接connection从RPC-server收取响应包packet2；
10）下游收发线程，将报文放入“已接受队列”，通过连接池组件，将connection放回连接池；
11）下游收发队列里，报文被取出，此时回调将要开始，不会阻塞工作线程；
12）序列化组件，将packet2反序列化为Result对象；
13）上下文管理器，将结果，回调，上下文取出；
14）通过callback回调业务代码，返回Result结果，工作线程继续往下走；

如果请求长时间不返回，处理流程是：
15）上下文管理器，请求长时间没有返回；
16）超时管理器拿到超时的上下文；
17）通过timeout_cb回调业务代码，工作线程继续往下走；

序列化组件和连接池组件上文已经介绍过，收发队列与收发线程比较容易理解。下面重点介绍上下文管理器与超时管理器这两个总的组件。

为什么需要上下文管理器？
由于请求包的发送，响应包的回调都是异步的，甚至不在同一个工作线程中完成，需要一个组件来记录一个请求的上下文，把请求-响应-回调等一些信息匹配起来。

如何将请求-响应-回调这些信息匹配起来？
这是一个很有意思的问题，通过一条连接往下游服务发送了a，b，c三个请求包，异步的收到了x，y，z三个响应包：
在这里插入图片描述
怎么知道哪个请求包与哪个响应包对应？
怎么知道哪个响应包与哪个回调函数对应？
可以通过“请求id”来实现请求-响应-回调的串联。

整个处理流程如上，通过请求id，上下文管理器来对应请求-响应-callback之间的映射关系：
1）生成请求id；
2）生成请求上下文context，上下文中包含发送时间time，回调函数callback等信息；
3）上下文管理器记录req-id与上下文context的映射关系；
4）将req-id打在请求包里发给RPC-server；
5）RPC-server将req-id打在响应包里返回；
6）由响应包中的req-id，通过上下文管理器找到原来的上下文context；
7）从上下文context中拿到回调函数callback；
8）callback将Result带回，推动业务的进一步执行；