gRPC入门学习之旅（一） - ToB企服应用市场:ToB评测及商务社交产业平台

　　RPC（Remote Procedure Call）远程过程调用，是一种通过网络从远程盘算机步伐上请求服务，而不必要相识底层网络技能的协议，简单的理解是一个节点请求另一个节点提供的服务。RPC只是一套协议，基于这套协议规范来实现的框架都可以称为 RPC 框架，比力典型的有 Dubbo、Thrift 和 gRPC。

　　RPC 机制和实现过程
　　RPC 是远程过程调用的方式之一，涉及调用方和被调用方两个进程的交互。因为 RPC 提供类似于当地方法调用的形式，以是对于调用方来说，调用 RPC 方法和调用当地方法并没有明显区别。

RPC的机制的诞生和底子概念
　　1984 年，Birrell 和 Nelson 在 ACM Transactions on ComputerSystems 期刊上发表了名为“Implementing remote procedure calls”的论文，该文对 RPC 的机制做了经典的解释：
　　RPC 远程过程调用是指盘算机 A 上的进程，调用另外一台盘算机 B 上的进程的方法。其中A 上面的调用进程被挂起，而 B 上面的被调用进程开始执行对应方法，并将效果返回给 A，盘算机 A 接收到返回值后，调用进程继续执行。

　　发起 RPC 的进程通过参数等方式将信息传送给被调用方，然后被调用方处理惩罚结束后，再通过返回值将信息通报给调用方。这一过程对于开发职员来说是透明的，开发职员一般也无须知道双方底层是如何进行消息通信和信息通报的，这样可以让业务开发职员更专注于业务开发，而非底层细节。

　　RPC 让步伐之间的远程过程调用具有与当地调用类似的形式。好比说某个步伐必要读取某个文件的数据，开发职员会在代码中执行 read 系统调用来获取数据。

　　当 read 实际是当地调用时，read 函数由链接器从依赖库中提取出来，接着链接器会将它链接到该步伐中。固然 read 中执行了特别的系统调用，但它自己依然是通过将参数压入堆栈的常规方式调用的，调用方并不知道 read 函数的具体实现和行为。

　　当 read 实际是一个远程过程时（好比调用远程文件服务器提供的方法），调用方步伐中必要引入 read 的接口定义，称为客户端存根（client-stub）。远程过程 read 的客户端存根与当地方法的 read 函数类似，都执行了当地函数调用。不同的是它底层实现上不是进行操作系统调用读取当地文件来提供数据，而是将参数打包成网络消息，并将此网络消息发送到远程服务器，交由远程服务执行对应的方法，在发送完调用请求后，客户端存根随即壅闭，直到收到服务器发回的响应消息为止。

　　当客户端发送请求的网络消息到达服务器时，服务器上的网络服务将其通报给服务器存根（server-stub）。服务器存根与客户端存根一一对应，是远程方法在服务端的体现，用来将网络请求通报来的数据转换为当地过程调用。服务器存根一般处于壅闭状态，等候消息输入。

　　当服务器存根收到网络消息后，服务器将方法参数从网络消息中提取出来，然后以常规方式调用服务器上对应的实现过程。从实现过程角度看，就好像是由客户端直接调用一样，参数和返回地点都位于调用堆栈中，一切都很正常。实现过程执行完相应的操作，随后用得到的效果设置到堆栈中的返回值，并根据返回地点执行方法结束操作。以 read 为例，实现过程读取当地文件数据后，将其填充到 read 函数返回值所指向的缓冲区。

　　read 过程调用完后，实现过程将控制权转移给服务器存根，它将效果（缓冲区的数据）打包为网络消息，最后通过网络响应将效果返回给客户端。网络响应发送结束后，服务器存根会再次进入壅闭状态，等候下一个输入的请求。

　　客户端接收到网络消息后，客户操作系统会将该消息转发给对应的客户端存根，随后解除对客户进程的壅闭。客户端存根从壅闭状态恢复过来，将接收到的网络消息转换为调用效果，并将效果复制到客户端调用堆栈的返回效果中。当调用者在远程方法调用 read 执行完毕后重新获得控制权时，它唯一知道的是 read 返回值已经包含了所需的数据，但并不知道该 read 操作到底是在当地操作系统读取的文件数据，还是通过远程过程调用远端服务读取文件数据。

　　RPC 协议一般分为公有协议和私有协议。比方，HTTP、SMPP、WebService等都是公有协议。如果是某个公司大概构造内部自定义、自己使用的，没有被国际标准化构造接纳和认可的协议，往往划为私有协议，比方 Thrift 协议和蚂蚁金服的 Bolt 协议。

　　分布式架构所必要的企业内部通信模块，往往接纳私有协议来计划和研发。相较公有协议，私有协议固然有很多弊端，好比在通用性上、公网传输的能力上，但是高度定制化的私有协议可以最大限度地低落成本，提升性能，提高灵活性与服从。定制私有协议，可以有用地使用协议里的各个字段，灵活满足各种通信功能需求，好比：CRC 校验、Server Fail-Fast 机制和自定义序列化器。

　　在协议计划上，你还必要考虑以下三个关键题目：

　　1. 协议包括的必要字段与重要业务负载字段。协议里计划的每个字段都应该被使用到，制止无效字段。
　　2. 通信功能特性的支持。好比，CRC 校验、安全校验、数据压缩机制等。
　　3. 协议的升级机制。毕竟是私有协议，没有恒久的验证，字段新增大概修改，是有可能发生的，因此升级机制是必须考虑的。

　　RPC和HTTP区别
　　RPC 和 HTTP都是微服务间通信较为常用的方案之一，其实RPC 和 HTTP 并不完满是同一个层次的概念，它们之间还是有所区别的。
　　1. RPC 是远程过程调用，其调用协议通常包括序列化协议和传输协议。序列化协议有基于纯文本的 XML 和 JSON、二进制编码的Protobuf和Hessian。传输协议是指其底层网络传输所使用的协议，好比 TCP、HTTP。
　　2. 可以看出HTTP是RPC的传输协议的一个可选方案，好比说 gRPC 的网络传输协议就是 HTTP。HTTP 既可以和 RPC 一样作为服务间通信的解决方案，也可以作为 RPC 中通信层的传输协议（此时与之对比的是 TCP 协议）。

　　常见的 RPC 框架
　　目前盛行的开源 RPC 框架还是比力多的，有阿里巴巴的Dubbo、Google 的 gRPC、Facebook 的 Thrift 和Twitter 的 Finagle 等。

　　1. Go RPC：Go 语言原生支持的 RPC 远程调用机制，简单便捷。
　　2. gRPC：Google 发布的开源 RPC 框架，是基于 HTTP 2.0 协议的，并支持众多常见的编程语言，它提供了强盛的流式调用能力，目前已经成为最主流的 RPC 框架之一。
　　3. Thrift：Facebook 的开源 RPC 框架，重要是一个跨语言的服务开发框架，作为老牌开源 RPC 协议，以其高性能和稳定性成为众多开源项目提供数据的方案选项。