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

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

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

服务化有什么好处？

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

（1）服务A：欧洲团队维护，技术背景是Java；

（2）服务B：美洲团队维护，用C++实现；

（3）服务C：中国团队维护，技术栈是go；

服务的上游调用方，按照接口、协议即可完成对远端服务的调用。

但实际上，大部分互联网公司，研发团队规模有限，大都使用同一套技术体系来实现服务：

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

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

什么是RPC？

Remote Procedure Call Protocol，远程过程调用。

什么是“远程”，为什么“远”？

先来看下什么是“近”，即“本地函数调用”。

当我们写下：

int result = Add(1, 2);

这行代码的时候，到底发生了什么？

（1）传递两个入参；

（2）调用了本地代码段中的函数，执行运算逻辑；

（3）返回一个出参；

这三个动作，都发生在同一个进程空间里，这是本地函数调用。

那有没有办法，调用一个跨进程的函数呢？

典型的，这个进程部署在另一台服务器上。

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

（1）入参；

（2）调用哪个函数；

（3）出参；

如果能够实现，那这就是“远程”过程调用。

Socket通信只能传递连续的字节流，如何将入参、函数都放到连续的字节流里呢？

假设，设计一个11字节的请求报文：

（1）前3个字节填入函数名“add”；

（2）中间4个字节填入第一个参数“1”；

（3）末尾4个字节填入第二个参数“2”；

同理，可以设计一个4字节响应报文：

（1）4个字节填入处理结果“3”；

调用方的代码可能变为：

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）将字节流发送给调用方；

这个过程用一张图描述如下：