什么是 gRPC？

远程过程调用 (RPC) 作为一种客户端/服务器交互通信模型，使远程调用具备本地调用的外观与行为。这是一种较老的技术，其概念可以追溯到 20 世纪 70 年代，早期应用见于 ARPANET 和 Xerox PARC 等开创性计算项目中。

在 RPC 调用过程中，客户端与服务器的代理表征进行交互，该代理看似本地对象实为中间层。此中间层通常称为存根，负责处理数据的编组与解编（即将数据转换为适合传输的格式，并将服务器返回结果还原为原始格式）。因其作为客户端/服务器通信的架构风格，常被应用于 API 设计领域。

RPC 框架有许多不同的实现方式，包括 XML-RPC 和 JSON-RPC。这些实现均采用 HTTP 作为传输协议，主要区别在于数据格式类型。这些诞生于 1990 年代至 2000 年代的技术展现了 RPC 的核心优势：简化开发流程、抽象网络通信复杂性、轻量级架构、相对易用且具备人类可读性。

然而，许多现代计算环境——特别是采用微服务架构、多语言技术栈及高数据负载的系统——需要更快速、高性能的框架来连接分布式应用。理想情况下，这一框架能促进在不同环境和数据中心运行的服务之间进行更高效的实时数据传输。

gRPC 的诞生正是为了满足这一需求，它通过数据序列化技术、HTTP/2 协议应用、双向流式传输能力以及代码生成等功能，显著降低通信延迟和提高吞吐量。

gRPC 最初于 2015 年正式发布，与 HTTP/2 协议同年问世。gRPC 主要通过使用 Protocol Buffers（或 Protobuf）及其接口定义语言 (IDL) 解决了旧有 RPC 实现的局限性。Protobuf 将结构化数据序列化并编码为二进制。这种处理使数据更加紧凑，从而实现更快速传输与更高运行性能。

Protobuf 还支持数据字段变更而不会破坏现有代码结构。这有助于减少错误产生，并支持实时数据共享与处理。这些功能使使用 gRPC 构建的 API 成为现代分布式环境、微服务架构、流式传输应用以及连接物联网系统和设备的理想选择。

若认为 gRPC 代表 “Google Remote Procedure Call” 就合情合理。但 grpc.io 的 gRPC 团队俏皮地宣称其代表 “gRPC Remote Process Call”。其 GitHub 指出，“g” 在每个版本中代表不同含义（从“gregarious”到“goose”再到“Guadalupe River Park Conservancy”）。无论如何，gRPC 由 Google 开发并于 2015 年作为开源项目发布。

gRPC 是 RPC 的现代升级版本，支持现代语言，并具有更多的功能和优化。其功能包括：

• 采用名为 Protocol Buffers 的接口设计语言 (IDL)
• 使用 HTTP/2 协议进行数据传输
• 双向流式通信
• 代码生成
• 四种方法类型
• 集成基于 TLS 的安全机制
• 支持拦截器实现日志记录、链路追踪、身份验证等功能

Protocol Buffers（通常称为 Protobuf）是 Google 开发的一种跨平台数据格式，专用于序列化结构化数据。实际上它充当客户端与服务器之间的强大中介，将请求序列化为二进制代码进行传输。

该机制兼具灵活性与高效性，既能实现编程语言无关性，又可减小消息大小，同时提升解析与传输速度。使用 Java 的应用程序可与使用 Python 的应用程序进行通信，因为请求已被转换为二进制通用语言。尽管二进制格式人类不可读，但相比 JSON 等文本格式，计算机传输解码速度更快。

从本质上讲，开发人员通过创建后缀为“.proto”的文本文件来完整记录数据结构的所有相关信息。该信息基于模式，这意味着它定义了参数、方法和可能的输出结果，描述述了数据结构。例如，您可能有一个“用户”条目，其中指出此数据将包括“姓名”、“电子邮件地址”和“最喜欢的披萨配料”等信息。

根据 Protobuf 文档说明，它类似于 XML，“但体积更小、速度更快、结构更简单。您只需定义一次数据的结构化方式，即可通过特制的源代码生成工具，使用各种语言轻松地在各种数据流中写入和读取结构化数据。作为中间层技术，Protobuf 还支持集成多种身份验证与安全防护机制。

开发人员可以使用名为 Protoc 的编译器，生成包括C#、C++、Dart、Go、Java、Kotlin、Node.js、Objective-C、PHP、Python和Ruby在内的多种编程语言代码。这些生成的代码具备多重功能：通常包含类或模块定义，处理二进制序列化与反序列化流程，并抽象化数据交换的底层复杂性。 开发人员无需关注网络封包、数据编组、兼容性更新及具体实现细节，Protobuf 将自动处理这些底层操作。

Protobuf 基于模式的设计允许开发人员向现有结构添加新的数据字段，而不会破坏整个系统。它还大大减少了更新、维护和处理与 API 相关的繁琐任务所需的工作量，例如在添加新数据字段后调整现有代码。当然，初始配置 .proto 文件仍需投入一定时间与精力。

HTTP/2 作为一种传输层协议——即计算机与服务器间交换信息的标准化方法——采用二进制格式传输消息，减少 TCP 连接数量并使用报头压缩技术，这些特性使其相较于前代协议 (HTTP/1.1) 具有更快的速度与更高的效率。该协议还支持多路复用技术，即通过单一连接同时传输多个并发数据流；gRPC 则利用称为通道的机制在这些多重连接上实现多流传输。消息以 HTTP/2 数据帧形式进行传输，每个数据帧可能包含多个 gRPC 消息单元。

gRPC 提供双向流，客户端和服务器都可以独立通过读/写流发送消息。这种机制赋予系统极大灵活性：服务器与客户端可按序交换响应信息，或等待接收完所有客户端消息后再统一回复。该功能可根据具体应用场景进行适应性调整。

gRPC 采用名为 protoc 的编译工具，根据 .proto 文件中定义的服务规范与消息结构，自动生成各种语言版本的客户端与服务器代码。插件可用于扩展对更多语言的支持。

Protoc 用 proto 定义中指定的语言生成数据访问类。这些类为 [name] 等字段提供了简单的访问器，并提供了将结构串行化和解析为原始字节或从原始字节解析的方法。¹

gRPC 支持四种不同模式的数据传输方法：一元调用、客户端流式传输、服务器端流式传输及双向流式传输。

gRPC 内置 TLS（传输层安全协议）集成支持，可对客户端与服务器间的数据交换进行加密处理，为用户建立安全连接提供保障。

gRPC 支持可插拔身份验证、跟踪、日志记录、指标、负载平衡、健康检查等扩展功能。 

gRPC 有四种不同类型的方法，表示 gRPC 客户端和 gRPC 服务器如何发送和接收消息。这些类型是：

一元调用：最简调用模式，客户端发送单个请求，服务器返回单个响应。

服务器端流式传输：客户端发出单个请求，服务器返回多个响应序列。

客户端流式传输：客户端发送多个请求序列，服务器返回单个响应。服务器可以选择等待整个客户端请求流终止后，然后再进行处理和响应。

双向流式传输：客户端和服务器均同时来回发送多个调用，实现实时通信能力。

gRPC 和 REST 都是 API 设计中常用的架构风格。两者存在诸多共同点：均遵循客户端/服务器架构，依赖基于HTTP的通信机制，保持无状态特性且支持语言无关性。但它们在一些关键方面也存在差异，因此分别适用于不同的应用场景。

数据格式： REST API 使用 JSON 和 XML 等纯文本格式。gRPC 采用 Protobuf 将数据编码为二进制格式。

通信模式：gRPC 支持四种方法：一元调用、服务器流式传输、客户端流式传输和双向流式传输。REST 使用简单的请求-响应一元系统。

代码生成：gRPC 具备内置代码生成功能；REST 则不具备此功能，但有插件可供选择。

设计模式：gRPC 具有面向服务的设计，其中可调用的服务器运营被定义为服务或功能。在 REST 中，设计以资源为导向，其中使用 HTTP 方法通过 URL 定义的端点访问服务器资源。

协议：gRPC 使用 HTTP/2，而 REST 依赖于 HTTP/1.1。

耦合：gRPC 的客户端和服务器紧密耦合，这意味着客户端和服务器都必须访问同一个中间件 proto 文件。其中一个发生改变，另一个也随之改变。REST 是松散耦合的。这种独立性意味着一个组件的更改不会影响其他组件。

gRPC 通常用于在分布式环境中连接多个服务的复杂 API。gRPC 的实时流媒体能力和高性能使其非常适合多种用例，包括微服务、流式传输和物联网客户端连接。

凭借其高性能、低延迟、大数据量处理能力及实时双向流传输特性，gRPC 常被用于构建微服务架构的 API 接口。

由于 gRPC 具有语言无关性，它能有效促进不同编程语言编写的服务之间的通信。此外，Protobuf 定义提供了强类型模式机制，为微服务数据完整性提供了重要保障。

gRPC 的双向流式传输功能意味着它可以在单一网络连接上实现客户端与服务器之间的双向并发数据流传输。此能力使 gRPC 特别适用于视频会议等持续进程场景，或当用户需要在传输部分数据集时同时使用其他数据的应用情境。

物联网指由互联设备或客户端构成的网络体系。物联网 (IoT) 设备（也称为“智能对象”）可能包括简单的“智能家居”设备（例如智能恒温器），可穿戴设备（例如智能手表和支持 RFID 的服装），以及复杂的工业机械和运输系统。²gRPC API 常被用于确保这些设备间数据交换的一致性。

凭借其双向流支持和微服务友好功能（以及作为 CNCF 项目的地位），gRPC 越来越多地用于云原生 API。

gRPC 可用于生成多种编程语言的客户端库。这些库基于 .proto 文件中定义的服务接口生成；一旦完成服务定义，gRPC 即可自动生成指定编程语言的客户端代码。

该功能显著简化了开发工作，使开发人员能专注于应用逻辑而非底层通信代码的实现。

对于需要构建高性能 API 的组织与开发人员，gRPC 提供诸多优点：这些优点包括：

更快速、更高效的传输：多重因素有助于提升 gRPC 的性能。首先，Protobuf 序列化可减少消息大小，使数据包更快速传输。其次，二进制格式比 JSON 或 XML 等纯文本格式的解析效率更高。

此外， gRPC 采用 HTTP/2 协议， 相比 HTTP/1.1 具有更高速度与效率，进一步降低延迟与带宽消耗。

更高的可移植性：由于使用 Protocol Buffers（一种与语言和平台无关的序列化机制）来描述数据结构和 RPC 接口，gRPC 可用于实现跨平台、以各种语言编写的服务之间的通信。

减少运行时错误： Protobuf 提供强类型，这意味着它强制使用可靠、明确定义的数据结构。强类型有助于提高一致性并支持早期错误检测，从而降低运行时错误概率。

灵活定制：内置中间件支持允许进行功能定制与扩展，例如安全和身份验证措施或分析工具。

虽然 gRPC 具有众多优点，但也并非没有挑战。在某些场景下，例如面向公共 API 且数据源简单、易用性为首要考量时，gRPC 带来的复杂性可能是不必要的。 gRPC 的挑战包括：

复杂性： 按照 gRPC 要求在 .proto 文件中定义消息结构与服务，比处理 XML/JSON 等文本格式更具挑战性。

易用性： 对于习惯于使用 REST 的开发人员来说，gRPC、协议缓冲区和 HTTP/2 可能会带来陡峭的学习曲线。

调试： 由于二进制格式不适合人类阅读，因此检查、调试和记录 gRPC 应用可能比较困难。虽然有一些工具可以转换二进制文件，但与 XML 或 JSON 相比，它们需要额外的步骤。

最近性和支持： gRPC 并不像 REST 等其他流行架构那样历史悠久，也没有那么大的社区或插件和文档支持。作为较新的框架，与一些更成熟的框架相比，gRPC 的可用工具（例如安全扫描程序工具）较少。

浏览器限制： 由于 Web 浏览器本身并不支持 gRPC 协议，因此无法从基于浏览器的应用程序直接调用 gRPC 服务。解决这一问题的方法之一是采用代理，如 gRPC-Web。gRPC-Web 本质上可充当浏览器 HTTP 和 gRPC 协议之间的转换层。

Web 应用通过 gRPC-Web JavaScript 客户端库发起调用，发送经浏览器兼容适配的 gRPC 请求。该请求被发送至代理服务器转换为标准 gRPC 请求后，转发至 gRPC 后端服务器。服务端处理请求后返回响应至代理服务器，代理再次将响应转换为 gRPC-Web 格式传回客户端。