玩转 gRPC—深入概念与原理

本篇文章属于一篇知识的捡漏和复盘类的文章，主要目的就是为了复盘一下 gRPC 的相关概念，并剖析其原理，相关知识点和使用大家可以参看之前的几篇文章：

• 《玩转gRPC—Go使用gRPC通信实战》
  

• 《玩转gRPC—不同编程语言间通信》
  

• 《一文带你搞懂HTTP和RPC协议的异同》
  

• 《从1开始，扩展Go语言后端业务系统的RPC功能》
  

以上的几篇文章都不同程度的讲述和 RPC 协议相关知识和 Google 开源的 RPC 框架 gRPC 的相关知识，但是可能都比较浅显和不成体系，因此想利用这篇文章系统深入的讲述下 gRPC，下面开始：

1 使用 gRPC 的基本架构

由上图我们可以看出，使用 gRPC 通信的基本架构中基本分为五部分，他们分别是：

• Service：提供的服务

• Client：gRPC 客户端

• gRPC Server：gRPC 服务端接口

• gRPC Stub：gRPC 客户端接口

• Proto Request/Proto Response(s)：中间文件（代码/协议）

2 Protocol Buffers

2.1 什么是 Protocol Buffers？

Protocol Buffers，是 Google 公司开发的一种数据描述语言，简称 protobuf。

特点：

• 支持多种编程语言

• 序列化数据体积小

• 反序列化速度快

• 序列化和反序列化代码自动生成

2.2 Protocol Buffers 和 gRPC 什么关系？

首先要说明的是 gRPC 是 RPC 协议是一种实现，是一个框架；Protocol Buffers，是 Google 公司开发的一种数据描述语言。

gRPC 和 Protocol Buffers 的关系就好比浏览器和 HTML 的关系，不相互依赖，但是需要相互配合使用，才能达到最好的效果。

2.3 Protocol Buffers 基本语法

Protocol Buffers 是一个带有.proto扩展名的普通文本文件。

协议缓冲区数据被构造为消息，其中每条消息都是一个小的信息逻辑记录，包含一系列称为字段的键值对。这是一个简单的例子：

message Person {  string name = 1;  int32 id = 2;  bool has_ponycopter = 3;}

一旦你指定了你的数据结构，你就可以使用协议缓冲区编译器protoc从你的原型定义中以你喜欢的语言生成数据访问类。这些为每个字段提供了简单的访问器，例如name()and set_name()，以及将整个结构序列化/解析到原始字节的方法。

在普通的 proto 文件中定义 gRPC 服务，将 RPC 方法参数和返回类型指定为协议缓冲区消息：

// The greeter service definition.service Greeter {  // Sends a greeting  rpc SayHello (HelloRequest) returns (HelloReply) {}}
// The request message containing the user's name.message HelloRequest {  string name = 1;}
// The response message containing the greetingsmessage HelloReply {  string message = 1;}

gRPC 使用protoc特殊的 gRPC 插件从 proto 文件生成代码：将获得生成的 gRPC 客户端和服务器代码，以及用于填充、序列化和检索消息类型的常规协议缓冲区代码。

3 gRPC 的四种服务提供方法

3.1 Unary RPC

一元 RPC，其中客户端向服务器发送单个请求并获得单个响应，就像正常的函数调用一样。

rpc SayHello(HelloRequest) returns (HelloResponse);

3.2 Server streaming RPC

服务器流式 RPC，其中客户端向服务器发送请求并获取流以读回一系列消息。客户端从返回的流中读取，直到没有更多消息为止。gRPC 保证单个 RPC 调用中的消息顺序。

rpc LotsOfReplies(HelloRequest) returns (stream HelloResponse);

3.3 Client streaming RPC

客户端流式 RPC，其中客户端写入一系列消息并将它们发送到服务器，再次使用提供的流。一旦客户端完成了消息的写入，它就会等待服务器读取它们并返回它的响应。gRPC 再次保证了单个 RPC 调用中的消息顺序。

rpc LotsOfGreetings(stream HelloRequest) returns (HelloResponse);

3.4 Bidirectional streaming RPC

双向流式 RPC，双方使用读写流发送一系列消息。这两个流独立运行，因此客户端和服务器可以按照他们喜欢的任何顺序读取和写入：例如，服务器可以在写入响应之前等待接收所有客户端消息，或者它可以交替读取消息然后写入消息，或其他一些读取和写入的组合。保留每个流中消息的顺序。

rpc BidiHello(stream HelloRequest) returns (stream HelloResponse)

4 gRPC 的生命周期

4.1 服务的提供

RPC 服务的提供主要包括以上四种服务提供方法。

4.2 截止日期/超时

gRPC 允许客户端指定在 RPC 因错误而终止之前，他们愿意等待 RPC 完成多长时间DEADLINE_EXCEEDED。在服务器端，服务器可以查询特定的 RPC 是否已超时，或者还剩多少时间来完成 RPC。

指定期限或超时是特定于语言的：一些语言 API 根据超时工作，而一些语言 API 根据期限工作。

4.3 RPC 终止

在 gRPC 中，客户端和服务器都对调用是否成功做出独立的本地判断，并且它们的结论可能不匹配。这意味着，例如，可能有一个 RPC 在服务器端成功完成但在客户端失败。服务器也可以在客户端发送所有请求之前决定完成。

4.4 取消 RPC

客户端或服务器都可以随时取消 RPC。取消会立即终止 RPC，以便不再进行任何工作。

5 gRPC 通信原理

众所周知，gRPC 是基于 HTTP2 的，而 HTTP2 又是一个相对 HTTP1.1 比较新的概念，因此在探究 gRPC 原理之前有必要先了解下 HTTP2 是怎样的。

5.1 HTTP2

• HTTP/2 的规范于 2015 年 5 月发布，旨在解决其前身的一些可扩展性问题，在许多方面改进了 HTTP/1.1 的设计，最重要的是提供了连接上的语义映射。

• 创建 HTTP 连接的开销很大。您必须建立 TCP 连接、使用 TLS 保护该连接、交换标头和设置等。HTTP/1.1 通过将连接视为长期存在的、可重用的对象来简化此过程。HTTP/1.1 连接保持空闲，以便可以通过现有的空闲连接发送到同一目的地的新请求。虽然连接重用缓解了这个问题，但一个连接一次只能处理一个请求——它们是 1:1 耦合的。如果要发送一条大消息，新请求必须要么等待它完成（导致 队列阻塞），要么更频繁地为启动另一个连接付出代价。

• HTTP/2 通过在连接之上提供一个语义层： 流，从而进一步扩展了持久连接的概念。流可以被认为是一系列语义连接的消息，称为 帧。流可能是短暂的，例如请求用户状态的一元流（在 HTTP/1.1 中，这可能等同于 GET /users/1234/status）。随着频率的增加，它的寿命很长。接收者可能会建立一个长期存在的流，从而实时连续接收用户状态消息，而不是向 /users/1234/status 端点发出单独的请求。流的主要优点是连接并发，即在单个连接上交错消息的能力。

• 流量控制

• 然而，并发流包含一些微妙的陷阱。考虑以下情况：同一连接上的两个流 A 和 B。流 A 接收大量数据，远远超过它在短时间内可以处理的数据。最终，接收者的缓冲区被填满，TCP 接收窗口限制了发送者。这对于 TCP 来说都是相当标准的行为，但这种情况对于流来说是不利的，因为两个流都不会接收更多数据。理想情况下，流 B 应该不受流 A 的缓慢处理的影响。

• HTTP/2 通过提供 流控制 机制作为流规范的一部分来解决这个问题。流控制用于限制每个流（和每个连接）的未完成数据量。它作为一个信用系统运行，其中接收方分配一定的“预算”，发送方“花费”该预算。更具体地说，接收方分配一些缓冲区大小（“预算”），发送方通过发送数据填充（“花费”）缓冲区。接收方使用特殊用途的 WINDOW_UPDATE 帧向发送方通告可用的额外缓冲区 . 当接收方停止广播额外的缓冲区时，发送方必须在缓冲区（其“预算”）耗尽时停止发送消息。

• 使用流控制，并发流可以保证独立的缓冲区分配。再加上轮询请求发送，所有大小、处理速度和持续时间的流都可以在单个连接上进行多路复用，而无需关心跨流问题。

• 更智能的代理

• HTTP/2 的并发属性允许代理具有更高的性能。例如，考虑一个接受和转发尖峰流量的 HTTP/1.1 负载平衡器：当出现尖峰时，代理会启动更多连接来处理负载或将请求排队。前者——新连接——通常是首选（在某种程度上）；这些新连接的缺点不仅在于等待系统调用和套接字的时间，还在于在 发生 TCP 慢启动时未充分利用连接所花费的时间。

• 相比之下，考虑一个配置为每个连接多路复用 100 个流的 HTTP/2 代理。一些请求的峰值仍然会导致新的连接被启动，但与 HTTP/1.1 对应的连接数相比只有 1/100 个连接。更笼统地说：如果 n 个 HTTP/1.1 请求发送到一个代理，则 n 个 HTTP/1.1 请求必须出去；每个请求都是一个有意义的数据请求/有效负载，请求是 1:1 的连接。相反，使用 HTTP/2 发送到代理的 n 请求需要 n 个 流，但 不需要 n 个 连接！

5.2 gRPC 与 HTTP2

gRPC 引入了三个新概念：通道、远程过程调用 (RPC) 和消息。三者之间的关系很简单：每个通道可能有很多 RPC，而每个 RPC 可能有很多消息。

通道是 gRPC 中的一个关键概念。HTTP/2 中的流支持在单个连接上进行多个并发会话；**通道通过在多个并发连接上启用多个流来扩展这个概念。**从表面上看，频道为用户发送消息提供了一个简单的界面；然而，在引擎盖下，大量的工程投入到保持这些连接的活力、健康和利用上。

通道代表到端点的虚拟连接，实际上可能由许多 HTTP/2 连接支持。RPC 与连接相关联（此关联将在后面进一步描述）。RPC 实际上是普通的 HTTP/2 流。消息与 RPC 相关联并作为 HTTP/2 数据帧发送。更具体地说，消息是在数据帧之上*分层的。*一个数据帧可能有很多 gRPC 消息，或者如果一个 gRPC 消息非常大它可能跨越多个数据帧。

6 总结

好了，到这里关于 gRPC 的讲解就差不多了，归根结底，gRPC 是一个网络协议，既然是网络协议就难逃网络 I/O，因此也正是 I/O 多路复用成就了 HTTP2，进而成就了 gRPC，下一篇文章，让我们深入浅出网络 I/O 模型！

参考文章：

https://www.cncf.io/blog/2018/07/03/http-2-smarter-at-scale/

https://grpc.io/blog/grpc-on-http2/