标签：队列 服务框架 完整 rgs name 最大 请求报文 如何 重要
上一篇《微服务架构，多“微”才合适？》聊了微服务的粒度。微服务离不开RPC框架，RPC框架的原理、实践及细节，是本篇要分享的内容。服务化的一个好处就是，不限定服务的提供方使用什么技术选型，能够实现大公司跨团队的技术解耦，如下图所示：
但实际上，大部分互联网公司，研发团队规模有限，大都使用同一套技术体系来实现服务：
这样的话，如果没有统一的服务框架，各个团队的服务提供方就需要各自实现一套序列化、反序列化、网络框架、连接池、收发线程、超时处理、状态机等“业务之外”的重复技术劳动，造成整体的低效。
因此，统一服务框架把上述“业务之外”的工作统一实现，是服务化首要解决的问题。
Remote Procedure Call Protocol，远程过程调用。
先来看下什么是“近”，即“本地函数调用”。
当我们写下：
int result = Add(1, 2);
这行代码的时候，到底发生了什么？
传递两个入参
典型的，这个进程部署在另一台服务器上。
最容易想到的，两个进程约定一个协议格式，使用Socket通信，来传输：
假设，设计一个11字节的请求报文：
同理，可以设计一个4字节响应报文：
调用方的代码可能变为：
request = MakePacket(“add”, 1, 2);
SendRequest_ToService_B(request);
response = RecieveRespnse_FromService_B();
int result = unMakePacket(respnse);
这4个步骤是：
（1）将传入参数变为字节流；
（2）将字节流发给服务B；
（3）从服务B接受返回字节流；
（4）将返回字节流变为传出参数；
服务方的代码可能变为：
request = RecieveRequest();
args/function = unMakePacket(request);
result = Add(1, 2);
response = MakePacket(result);
SendResponse(response);
这个5个步骤也很好理解：
（1）服务端收到字节流；
（2）将字节流转为函数名与参数；
（3）本地调用函数得到结果；
（4）将结果转变为字节流；
（5）将字节流发送给调用方；
这个过程用一张图描述如下：
调用方与服务方的处理步骤都是非常清晰。
这个过程存在最大的问题是什么呢？
调用方太麻烦了，每次都要关注很多底层细节：
可以，RPC框架就是解决这个问题的，它能够让调用方“像调用本地函数一样调用远端的函数（服务）”。
讲到这里，是不是对RPC，对序列化范序列化有点感觉了？往下看，有更多的底层细节。
RPC框架，要向调用方屏蔽各种复杂性，要向服务提供方也屏蔽各类复杂性：
RPC框架的职责是，中间大蓝框的部分：
server端的技术大家了解的比较多，接下来重点讲讲client端的技术细节。
先来看看RPC-client部分的“序列化反序列化”部分。
工程师通常使用“对象”来进行数据的操纵：
class User{
std::String user_name;
uint64_t user_id;
uint32_t user_age;
};
User u = new User(“shenjian”);
u.setUid(123);
u.setAge(35);
但当需要对数据进行存储或者传输时，“对象”就不这么好用了，往往需要把数据转化成连续空间的“二进制字节流”，一些典型的场景是：
所谓序列化（Serialization），就是将“对象”形态的数据转化为“连续空间二进制字节流”形态数据的过程。这个过程的逆过程叫做反序列化。
这是一个非常细节的问题，要是让你来把“对象”转化为字节流，你会怎么做？很容易想到的一个方法是xml（或者json）这类具有自描述特性的标记性语言：
<class name=”User”>
<element name=”user_name” type=”std::String” value=”shenjian” />
<element name=”user_id” type=”uint64_t” value=”123” />
<element name=”user_age” type=”uint32_t” value=”35” />
</class>
规定好转换规则，发送方很容易把User类的一个对象序列化为xml，服务方收到xml二进制流之后，也很容易将其范序列化为User对象。
画外音：语言支持反射时，这个工作很容易。
第二个方法是自己实现二进制协议来进行序列化，还是以上面的User对象为例，可以设计一个这样的通用协议：
上面的User对象，用这个协议描述出来可能是这样的：
实际的序列化协议要考虑的细节远比这个多，例如：强类型的语言不仅要还原属性名，属性值，还要还原属性类型；复杂的对象不仅要考虑普通类型，还要考虑对象嵌套类型等。无论如何，序列化的思路都是类似的。
不管使用成熟协议xml/json，还是自定义二进制协议来序列化对象，序列化协议设计时都需要考虑以下这些因素。
RPC-client除了：
同步调用的代码片段为：
Result = Add(Obj1, Obj2);// 得到Result之前处于阻塞状态
异步调用的代码片段为：
Add(Obj1, Obj2, callback);// 调用后直接返回，不等结果
处理结果通过回调为：
callback(Result){// 得到处理结果后会调用这个回调函数
…
}
这两类调用，在RPC-client里，实现方式完全不一样。
所谓同步调用，在得到结果之前，一直处于阻塞状态，会一直占用一个工作线程，上图简单的说明了一下组件、交互、流程步骤：
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结果，工作线程继续往下走；
画外音：请对照架构图中的1-10步骤阅读。
RPC框架锁支持的负载均衡、故障转移、发送超时等特性，都是通过连接池组件去实现的。
典型连接池组件对外提供的接口为：
int ConnectionPool::init(…);
Connection ConnectionPool::getConnection();
int ConnectionPool::putConnection(Connection t);
和下游RPC-server（一般是一个集群），建立N个tcp长连接，即所谓的连接“池”。
从连接“池”中拿一个连接，加锁（置一个标志位），返回给调用方。
将一个分配出去的连接放回连接“池”中，解锁（也是置一个标志位）。
连接池中建立了与一个RPC-server集群的连接，连接池在返回连接的时候，需要具备随机性。
连接池中建立了与一个RPC-server集群的连接，当连接池发现某一个机器的连接异常后，需要将这个机器的连接排除掉，返回正常的连接，在机器恢复后，再将连接加回来。
因为是同步阻塞调用，拿到一个连接后，使用带超时的send/recv即可实现带超时的发送和接收。
总的来说，同步的RPC-client的实现是相对比较容易的，序列化组件、连接池组件配合多工作线程数，就能够实现。
这个问题在《工作线程数究竟要设置为多少最合适？》中讨论过，此处不再深究。
所谓异步回调，在得到结果之前，不会处于阻塞状态，理论上任何时间都没有任何线程处于阻塞状态，因此异步回调的模型，理论上只需要很少的工作线程与服务连接就能够达到很高的吞吐量，如上图所示：
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）下游收发线程，将报文放入“已接受队列”，通过连接池组件，将conneciont放回连接池；
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带回，推动业务的进一步执行；
与同步的连接池思路类似，不同之处在于：
超时收发，与同步阻塞收发的实现就不一样了：
超时管理器，用于实现请求回包超时回调处理。
每一个请求发送给下游RPC-server，会在上下文管理器中保存req-id与上下文的信息，上下文中保存了请求很多相关信息，例如req-id，回包回调，超时回调，发送时间等。
超时管理器启动timer对上下文管理器中的context进行扫描，看上下文中请求发送时间是否过长，如果过长，就不再等待回包，直接超时回调，推动业务流程继续往下走，并将上下文删除掉。
如果超时回调执行后，正常的回包又到达，通过req-id在上下文管理器里找不到上下文，就直接将请求丢弃。
画外音：因为已经超时处理了，无法恢复上下文。
无论如何，异步回调和同步回调相比，除了序列化组件和连接池组件，会多出上下文管理器，超时管理器，下游收发队列，下游收发线程等组件，并且对调用方的调用习惯有影响。
画外音：编程习惯，由同步变为了回调。
异步回调能提高系统整体的吞吐量，具体使用哪种方式实现RPC-client，可以结合业务场景来选取。
像调用本地函数一样，调用一个远端服务。
RPC框架用于屏蔽RPC调用过程中的序列化，网络传输等技术细节。让调用方只专注于调用，服务方只专注于实现调用。
把对象转化为连续二进制流的过程，叫做序列化。磁盘存储，缓存存储，网络传输只能操作于二进制流，所以必须序列化。
同步RPC-client的核心组件是序列化组件、连接池组件。它通过连接池来实现负载均衡与故障转移，通过阻塞的收发来实现超时处理。
异步RPC-client的核心组件是序列化组件、连接池组件、收发队列、收发线程、上下文管理器、超时管理器。它通过“请求id”来关联请求包-响应包-回调函数，用上下文管理器来管理上下文，用超时管理器中的timer触发超时回调，推进业务流程的超时处理。
思路比结论重要。
架构师之路-分享技术思路
推荐阅读：
《“缓存架构，一篇搞定”-年终总结（五）》
《“技术人如何带团队”-年终总结（六）》
《“MySQL必知必会”-年终总结（七）》
《“算法与数据结构”-年终总结（八）》
你读过哪个RPC框架的源码？
标签：队列 服务框架 完整 rgs name 最大 请求报文 如何 重要
原文地址：https://blog.51cto.com/jyjstack/2548843
