REST 还是 gRPC：你的服务该如何通信？

当系统壮大并拆分为多个服务时，就会产生它们之间该如何通信的问题。两个选项尤为突出：REST，基于 HTTP 的通用标准；以及 gRPC，由 Google 创建的现代高性能协议。它们并不完全在同一片领域竞争：REST 在公开 API 和与浏览器的通信中大放异彩，而 gRPC 在服务间的内部通信中表现出众。理解何时使用哪一种，能避免会损害性能或兼容性的决策。

在本文中，我们比较 REST 和 gRPC、各自的强项与局限，并说明何时适合哪一种。

什么是 REST

REST 是一种基于 HTTP 的 API 风格，通过标准方法对资源进行操作，通常以 JSON 格式交换数据。它最大的优势是通用性和简单性：任何客户端（包括浏览器）都能理解，对人类可读、易于调试，并拥有庞大的生态。对于公开 API、与第三方的集成，以及任何兼容性和易用性比极致性能更重要的通信，它是默认选择。

什么是 gRPC

gRPC 是一种高性能通信协议，使用 HTTP/2，并以紧凑的二进制格式（Protocol Buffers）而非文本交换数据。它的优势是速度和效率：二进制消息比 JSON 轻得多、快得多，支持双向流式传输，并能根据一份契约自动生成客户端和服务器代码。它在微服务间的内部通信中大放异彩，那里性能和低延迟至关重要，而且通信两端都在你的掌控之下。

关键差异

以下这些因素最能体现 REST 与 gRPC 之间的差异：

• 格式：REST 用文本（JSON）；gRPC 用二进制（Protocol Buffers）。
• 性能：gRPC 更高；REST 足够。
• 兼容性：REST 处处可用；gRPC 在浏览器中有限制。
• 可读性：REST 可读；gRPC 因是二进制而不可读。
• 流式传输：gRPC 中原生且强大；REST 中有限。
• 契约：gRPC 严格且自动生成；REST 更自由。

浏览器这个因素

一个决定性的差异是浏览器兼容性。REST 可以从任何 Web 应用原生地工作，这使它对前端所消费的 API 不可或缺。相反，gRPC 没有一层中间层就无法直接从浏览器工作，因此它的天然领域是服务器到服务器的通信。这个限制与其说是缺陷，不如说它界定了每一种各自的归属：REST 面向外部，gRPC 在系统内部。

契约与维护

另一个实用的差异在于通信如何定义和维护。gRPC 从一份明确的契约（Protocol Buffers 文件）出发，据此自动生成客户端和服务器代码，这减少了错误并让两端保持同步：如果契约改变，双方会一致地更新。REST 由于更自由，提供了更高的灵活性，但把良好地记录和版本化 API 以免客户端崩溃的纪律留给了团队。对于演进迅速、且你掌控两端的内部系统，gRPC 严格的契约是一种维护优势；对于面向许多外部消费者的公开 API，REST 的灵活性和容错性往往更重要。

何时选择哪一种

对于公开 API、与第三方的集成，以及一切必须由浏览器或你无法掌控的客户端消费的通信，就选 REST：它在兼容性和简单性上胜出。对于高性能微服务间的内部通信，那里你掌控两端、速度和效率至关重要，就选 gRPC。许多系统两者并用：面向客户端的边界用 REST，内部服务之间用 gRPC。关键是让每一种各得其所。

在 AxiomTech，我们用合适的协议设计你系统之间的通信，REST 或 gRPC，依据性能和兼容性而定。如果你正在定义你服务的架构，却不知道该如何连接它们，找我们聊聊，我们会根据你的情况为你出谋划策。