微服务RPC原理【深度好文】

转自：https://mp.weixin.qq.com/s/y3l9VuIeXxSI0tLG784lqA

上一篇《微服务架构，多“微”才合适？》聊了微服务的粒度。微服务离不开RPC框架，RPC框架的原理、实践及细节，是本篇要分享的内容。

服务化有什么好处？

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

 

• 服务A：欧洲团队维护，技术背景是Java

• 服务B：美洲团队维护，用C++实现

• 服务C：中国团队维护，技术栈是go

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

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

 

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

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

什么是RPC？

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

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

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

当我们写下：

int result = Add(1, 2);

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

• 传递两个入参

• 调用了本地代码段中的函数，执行运算逻辑

• 返回一个出参

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

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

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

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

• 入参

• 调用哪个函数

• 出参

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

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

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

• 前3个字节填入函数名“add”

• 中间4个字节填入第一个参数“1”

• 末尾4个字节填入第二个参数“2”

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

• 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）本地调用函数得到结果；