RPC
PRC（Remote Procedure Call）远程过程调用，两台服务器：A 和 B，A 服务器想调用 B 服务器上提供的某个函数/方法，由于它们不在一个内存空间，不能直接调用，需要通过网络来表达调用的语义和交换调用的数据。
那么 RPC 需要解决以下问题：
- 通讯问题，通过在客户端和服务器之间建立 TCP 连接，数据的交换都在这个连接里面传输。可以是按需连接，完成后断开连接。也可以是长连接，众多调用过程共享一个连接。
- 寻址问题，A 服务器怎么告诉底层 RPC 框架，如何连接到 B 服务器的 IP、端口、方法名称。比如，基于 Web Service 协议栈的 RPC，就需要提供一个 Endpoint URI。
- A 服务器发起远程调用时，方法的参数需要通过底层网络协议如 TCP 传递到 B 服务器，由于网络协议是基于二进制的，内存中的参数的值要序列化成二进制形式，也就是序列化，通过寻址和传输将序列化的二进制发送给 B 服务器。
- B 服务器收到请求后，需要对参数进行反序列化，恢复为内存中的表达方式，然后找到对应的方法进行本地调用，然后得到返回值。
- 返回值还要经过序列化发送回 A 服务器上的应用，A 服务器收到数据后，再反序列化，恢复为内存中的表达式，交给 A 服务器上的应用。
gRPC
gRPC 是 Google 开源的基于 HTTP/2 和 ProtoBuf 的通用 RPC 框架，主要面向移动应用开发基于 HTTP/2 协议标准而设计，基于 ProtoBuf（Protocol Buffers）序列化协议开发，且支持众多开发语言。gRPC 提供了一种简单的方法来精确地定义服务和为 iOS、Android 和后台支持服务自动生成可靠性很强的客户端功能库。客户端充分利用高级流和链接功能，从而有助于节省带宽、降低 TCP 连接次数、节省 CPU 使用。
gRPC 现在处于初期阶段，存在一些明显的磨合问题，但未来前景光明。总的来说，我对 gRPC 如何整合到后端体统非常乐观，而且很高兴见证这个框架的发展。
gRPC vs. REST
Protobuf vs. JSON
REST 和 gRPC 之间最大的区别之一是有效负载的格式。 REST 消息系统通常包含 JSON，而 gRPC 接收并返回 Protobuf，从性能角度来看 Protobuf 是一种非常高效的格式，而 JSON 是一种文本格式。
HTTP/2 vs. HTTP 1.1
REST 在很大程度上取决于 HTTP（通常是 HTTP 1.1）和请求-响应模型。而 gRPC 使用较新的 HTTP/2 协议
有几个问题困扰着 HTTP 1.1，而 HTTP/2 修复了这些问题
HTTP 1.1 太大了且过于复杂
HTTP 1.0 RFC 1945 是一个 60 页的 RFC。 HTTP 1.1 最初再 RFC 2616 中描述，它膨胀到 176 页。但是，后来 IETF 将其拆分为六个不同的文档 RFC 7230、7231、7232、7233、7234 和 7235，合并页数更高。
HTTP 1.1 允许许多可选部件，这些部件会增长其大小和复杂性。
页面大小和对象数的增长
网页的趋势是增加页面的总大小（平均1.9MB）以及需要单独请求的页面上对象的数量。由于每个对象都需要单独的 HTTP 请求，因此单独对象的乘法会显著增加 Web 服务器上的负载，并减慢用户的页面加载时间。
延迟问题
HTTP 1.1 对延迟很敏感。每个请求都需要 TCP 握手，而数量较大的请求会显著占用加载页面所需的时间。在大多数情况下，可用带宽的持续改进并不能解决这些延迟问题。
线路阻塞头
对同一域的连接数的限制（过去只有 2 个，现在为 6-8）大大降低了并行发送多个请求的能力。
HTTP/2 如何解决问题
REST 乍看上去非常不错，但是与实际业务结合起来是非常困难的，因此大多实现并不完全遵循 REST 理念，只是用其原则。开发人员还要经常为 REST URL 和参数伤神费力。
gRPC 使用的概念模型是具有具有清晰接口的服务和用于请求和响应的结构化消息。此模型直接从编程语言概念（如接口、函数、方法和数据结构）进行转换。它还允许 gRPC 为您自动生成客户端库。
流式处理 vs. 请求响应
REST 仅支持 HTTP 1.x 中可用的请求-响应模型。但是，gRPC 充分利用了 HTTP/2 的功能，并允许您不断流式传输信息。流式处理有几种类型。
服务器端流式处理
服务器在收到客户端请求消息后发送回响应流。发送回所有响应后，服务器的状态详细信息和可选的尾随元数据将发送回服务器端完成。客户端在具有服务器的所有响应后完成。
客户端流式处理
客户端向服务器发送多个请求的流。服务器发送回单个响应，通常但不一定是在收到客户端的所有请求后发送的，以及其状态详细信息和可选的尾随元数据。
双向流式处理
在这种情况下，客户端和服务器以非常自由的形式相互发送信息（客户端启动序列除外）。最终，客户端将关闭连接。
在微服务领域，gRPC 将很快占据主导地位。性能优势和易于开发实在是太好了，不能放弃。但是，不要搞错，REST 还会在会很长一段时间内存在。为了向后兼容性的原因和公开访问。