必须知道的RPC内核细节（值得收藏）！！！

微服务分层架构，之前聊得很多了，微服务离不开RPC框架，RPC框架的原理、实践及细节，今天和大家聊一聊。

文章较长，1万字左右，建议提前收藏。

这样的话，如果没有统一的服务框架，各个团队的服务提供方就需要各自实现一套序列化、反序列化、网络框架、连接池、收发线程、超时处理、状态机等“业务之外”的重复技术劳动，造成整体的低效。

int result = Add(1, 2);

最容易想到的，两个进程约定一个协议格式，使用Socket通信，来传输：

request = MakePacket(“add”, 1, 2);

SendRequest_ToService_B(request);

response = RecieveRespnse_FromService_B();

int result = unMakePacket(respnse);

request = RecieveRequest();

args/function = unMakePacket(request);

result = Add(1, 2);

response = MakePacket(result);

SendResponse(response);

调用方与服务方的处理步骤都是非常清晰。

RPC框架的职责是什么？

如上图所示，业务方的职责是：

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);

<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>

RPC-client除了：

Result = Add(Obj1, Obj2);// 得到Result之前处于阻塞状态

Add(Obj1, Obj2, callback);// 调用后直接返回，不等结果

callback(Result){// 得到处理结果后会调用这个回调函数

         …

}

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

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

Result=Add(Obj1,Obj2)

典型连接池组件对外提供的接口为：

int ConnectionPool::init(…);

Connection ConnectionPool::getConnection();

int ConnectionPool::putConnection(Connection t);

所谓异步回调，在得到结果之前，不会处于阻塞状态，理论上任何时间都没有任何线程处于阻塞状态，因此异步回调的模型，理论上只需要很少的工作线程与服务连接就能够达到很高的吞吐量，如上图所示：

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

Add(Obj1,Obj2, callback)

怎么知道哪个请求包与哪个响应包对应？

整个处理流程如上，通过请求id，上下文管理器来对应请求-响应-callback之间的映射关系：

超时管理器，用于实现请求回包超时回调处理。

架构师之路-分享技术思路