RPC理解

一、什么是RPC？

RPC（Remote Procedure Call）中文名「远程过程调用」，又是一个很蹩脚的翻译。咱们拆开理解下，「过程」也叫方法或函数，「远程」就是说方法不在当前进程里，而是在其余进程或机器上面，合起来 RPC 就是调用其余进程或机器上面的函数。

在没有网络的时代，程序都是单机版的，全部逻辑都必须在同一个进程里。进程之间就像高楼大厦里面陌生的邻居，你们没法共享，遇到一样的功能只能重复实现一次。显然进程的障碍是逆天的，不符合先进生产力的发展方向，这个时候「进程间通讯」的需求出现了，你们要求进程之间可以相互交流，相互共享和调用。这样再写程序，就能够利用进程间通讯机制来调用和共享已经存在的功能了。随着网络的出现，进程的隔阂进一步消除，不光同一栋楼里的邻居能够共享资源，其余小区、甚至其余城市的居民均可以经过互联网互相调用，这就是RPC。概念很容易理解，可是远程和本地的实现原理有很大区别，架构设计者的职责就是设计一个机制让远程调用服务就像调本地服务同样简单，这就是RPC框架。

二、基本原理

RPC 首要解决的是通信的问题，主流的 RPC 框架分为基于 HTTP 和基于 TCP 的两种。基于 HTTP 的 RPC 调用很简单，就和咱们访问网页同样，只是它的返回结果更单一（JSON 或 XML）。它的优势在于实现简单，标准化和跨语言，比较适合对外提供 OpenAPI 的场景，而它的缺点是 HTTP 协议传输效率较低、短链接开销较大（HTTP 2.0 后有很大改进）。而基于 TCP 的 RPC 调用，因为 TCP 协议处于协议栈的下层，可以更加灵活地对协议字段进行定制，减小网络开销，提升性能，实现更大的吞吐量和并发数。可是须要更多地关注底层复杂的细节，跨语言和跨平台难度大，实现的代价更高，它比较适合内部系统之间追求极致性能的场景。

接下我讲的 RPC 都是基于 TCP 的，由于它是目前业界主流 RPC 框架支持的方式，也是阿里的 HSF，蚂蚁的 Bolt 采用的方式。首先来看看一个 RPC 调用的基本流程，以便你们对它有宏观的认识，后面再逐一讨论其中的细节

1. 调用方（Client）经过本地的 RPC 代理（Proxy）调用相应的接口
2. 本地代理将 RPC 的服务名，方法名和参数等等信息转换成一个标准的 RPC Request 对象交给 RPC 框架
3. RPC 框架采用 RPC 协议（RPC Protocol）将 RPC Request 对象序列化成二进制形式，而后经过 TCP 通道传递给服务提供方 （Server）
4. 服务端（Server）收到二进制数据后，将它反序列化成 RPC Request 对象
5. 服务端（Server）根据 RPC Request 中的信息找到本地对应的方法，传入参数执行，获得结果，并将结果封装成 RPC Response 交给 RPC 框架
6. RPC 框架经过 RPC 协议（RPC Protocol）将 RPC Response 对象序列化成二进制形式，而后经过 TCP 通道传递给服务调用方（Client）
7. 调用方（Client）收到二进制数据后，将它反序列化成 RPC Response 对象，而且将结果经过本地代理（Proxy）返回给业务代码

参考连接：
https://juejin.im/entry/5b2089def265da6e2f3e39fd

https://www.yuque.com/egg/nodejs/dklip5