使用 gRPC 协议实现微服务通信


在本文中，我们了解了 gRPC 内部结构以及微服务如何使用 gRPC 协议进行通信。然后我们看到了大约 4 种类型的通信模式。我们还了解了 gRPC 的用例以及 gRPC 的优缺点。

gRPC 协议 = HTTP/2 + Protobuf
gRPC被广泛用于内部微服务之间的通信，主要是由于其高性能和多语言特性。 gRPC 使用 HTTP/2 作为其传输协议，因此它继承了 HTTP/2 的二进制帧等优点。正如我在上一篇文章中提到的，与其他基于文本的协议相比，HTTP/2 是健壮的、轻量级的传输和更安全的解码。由于其二进制性质，HTTP/2 与 Protobuf 格式形成了良好的组合。 gRPC 的工作方式与旧的远程过程调用 (RPC) 相同。它是面向 API 的，而不是基于资源的 REST 协议。Protbuf 支持 11 种开箱即用的语言，以及二进制协议超级大国在性能、吞吐量和灵活性方面的所有优势。

用于微服务的 gRPC
微服务的最大优势之一是能够为每个独立的服务（即多语言）使用不同的技术。每个微服务都同意 API 来交换数据、数据格式、错误模式、负载平衡等。由于 gRPC 允许以二进制格式描述合约，它可以有效地用于独立于语言的微服务通信。

​

在上图中，显示了微服务架构。来自客户端（Web 或移动）的请求到达 API 网关，然后转到聚合器服务。 Shopping Aggregator 微服务在内部调用其他微服务并聚合数据以发送到前端。如您所见，聚合器和其他服务之间的通信是通过 gRPC 协议进行的。 在现实世界的场景中，微服务会相互通信以聚合数据并将其发送给客户端。如果我们使用普通的REST API，它会变得更慢，并且客户端会遇到更多的延迟。如果我们在微服务之间使用 gRPC ，它会更快，并且客户端的延迟更低。

gRPC 内部结构
让我们看一下使用 gRPC 在 2 个微服务之间进行通信所需的步骤。提供服务的服务是 gRPC 服务器，而另一个需要来自提供者的数据的服务是 gRPC 消费者。当 gRPC 服务器需要来自另一个微服务的数据时，它也可以是消费者。 在这个例子中，我们假设 gRPC 是用 Go 语言实现的，而消费者是用Java实现的。服务和消费者之间的网络通信使用 gRPC 协议通过 HTTP/2 进行。

​

有以下3个组件

  1. 服务定义
  2. gRPC 服务器
  3. gRPC 客户端

一、服务定义 构建 gRPC 服务的第一步是使用该服务公开的方法以及输入参数和返回类型来创建服务接口定义。 服务定义在ProductInfo.proto文件中指定，服务器端和客户端都使用该文件生成代码，这用作它们之间的 API 契约。 这些 proto 文件在 gRPC 服务器上生成并在客户端代码中使用，与语言无关。

2. gRPC 服务器 通过服务定义文件，可以使用protocol buffer编译器protoc生成源代码。正如我在上一篇文章中提到的，很多语言都支持 protoc。 使用协议缓冲区的 gRPC 插件，您可以生成 gRPC 服务器端以及用于填充、序列化和检索消息类型的常规协议缓冲区代码。 在服务器端，服务器实现该服务定义并运行 gRPC 服务器来处理客户端调用。

3. gRPC 客户端 在客户端，我们使用服务定义生成客户端存根。客户端存根提供与服务器相同的方法，并将它们转换为远程函数调用网络调用，到达服务器端。由于 gRPC 服务定义与语言无关，因此可以从任何语言创建客户端存根。

gRPC 通信模式
gRPC 支持四种通信模式：
简单 RPC、服务器流式 RPC、客户端流式 RPC 和双向 RPC。

1.简单的RPC
这是 gRPC 最简单的通信模式。客户端向服务器发送一条消息并接收一条消息。如下图所示，请求和响应都只有一条二进制消息进入流中。


2. 服务器-流式 RPC
在服务器流式 RPC 中，一旦客户端向服务器发送消息，服务器就会发回一系列响应。此响应消息序列在客户端启动的同一 HTTP 流中发送。 如下图所示，服务器一直等待，直到收到来自客户端的消息，并以帧消息的形式发送多个响应消息。服务器通过发送带有呼叫状态详细信息的尾随元数据来结束流。

​


3. 客户端流式 RPC
这种模式中，客户端向服务器发送多条消息，而服务器只返回一条消息。下图显示了多条消息如何在流中流动。此流可以持续到 RPC 结束。

​

4.双向流式RPC
在双向流式 RPC 中，客户端和服务器都向对方发送消息流。客户端通过发送标头帧来设置 HTTP 流。一旦建立连接，客户端和服务器都可以同时发送消息，而无需等待对方完成。

​


gRPC 用例 gRPC 可用于以下用例

  • 微服务： gRPC专为低延迟和高吞吐量通信而设计。如上所述，它非常适用于效率和延迟至关重要的微服务。
  • 点对点实时通信：gRPC 对双向流有出色的支持。gRPC 服务可以实时推送消息，无需轮询。
  • 多语言环境：gRPC 工具支持所有流行的开发语言，使 gRPC 成为多语言环境的不错选择。
  • 低功耗低带宽网络：gRPC 消息使用轻量级消息格式 Protobuf 进行序列化。gRPC 消息始终小于等效的 JSON 消息。
  • 进程间通信（IPC）：IPC 传输（如 Unix 域套接字和命名管道）可以与 gRPC 一起使用，以便在同一台机器上的应用程序之间进行通信。

gRPC 的好处

  1. 轻量级消息
  2. 高性能
  3. 内置代码生成
  4. 多语言支持
  5. 不同的沟通模式

gRPC 的缺点

  1. 有限的浏览器支持：
  2. 非人类可读格式
  3. 无边缘缓存
  4. 更陡峭的学习曲线

gRPC 与 REST
API 由于 gRPC 大量使用 HTTP/2，因此无法直接从 Web 浏览器调用 gRPC 服务。现代浏览器不提供对 Web 请求所需的控制以支持 gRPC 客户端。因此，需要代理层和 gRPC-web 来执行 HTTP/1.1 和 HTTP/2 之间的转换。 所以REST API仍然非常适合客户端-服务器通信，而 gRPC 现在主要用于微服务之间的服务器到服务器通信

​