为什么有了HTTP，还需要gRPC？

在构建现代应用，尤其是微服务架构时，我们经常讨论一个问题：已经有了无处不在的 HTTP，为什么还需要 gRPC？答案很简单：HTTP 在某些场景下不够高效，而 gRPC 正是为了解决这些痛点而生的。

HTTP 的缺点

HTTP/1.1 是目前最广泛的应用层协议，但它存在一些固有的问题，尤其是在大规模分布式系统中：

• 文本协议，效率低下： HTTP/1.1 是基于文本的协议，使用 JSON 或 XML 作为数据格式。这些格式可读性好，但体积大、解析慢，在需要高性能、低延迟的场景下成为瓶颈。
• 队头阻塞： 每个 HTTP/1.1 请求都需要建立一个新的 TCP 连接，或者复用有限的几个连接。在一个连接上，请求和响应是串行的，如果前一个请求耗时很长，后面的请求就会被阻塞，这就是“队头阻塞”。
• 单向通信： 传统的 HTTP 是客户端-服务器模式，客户端发起请求，服务器响应。服务器无法主动向客户端推送消息。虽然有 WebSocket、长轮询等技术作为补充，但它们并非 HTTP 的核心能力。

gRPC 是什么？

gRPC (Google Remote Procedure Call) 是一个由 Google 开发的高性能、开源的通用 RPC（远程过程调用）框架。它有几个核心特点：

• 基于 HTTP/2： gRPC 直接构建在 HTTP/2 之上，继承了其所有优点。
• Protobuf： 这是 gRPC 默认的数据序列化格式。它是一种与语言无关、与平台无关的二进制格式，比 JSON/XML 更小、更快、更高效。
• 面向服务： 使用.proto文件来定义服务、消息和方法。这个文件就像一份具有强类型约束的“契约”，服务端和客户端的代码都可以据此自动生成，保证了一致性。

gRPC 如何解决 HTTP 的缺点？

gRPC 的设计精准地弥补了 HTTP/1.1 的不足：

• 二进制协议，高性能： gRPC 使用 Protobuf 将数据序列化为二进制格式进行传输。相比于 JSON，二进制格式体积更小，解析速度更快，大大降低了网络带宽消耗和 CPU 使用率。
• HTTP/2 的多路复用： gRPC 运行在 HTTP/2 上，它允许在单个 TCP 连接上同时发送和接收多个请求和响应，彻底解决了 HTTP/1.1 的队头阻塞问题。连接的复用也减少了 TCP 握手带来的开销。
• 支持流式通信： HTTP/2 的原生支持使得 gRPC 可以轻松实现四种通信模式：
  • 一元 RPC (Unary RPC)： 客户端发一个请求，服务端回一个响应（类似传统 HTTP）。
  • 服务端流式 RPC (Server streaming RPC)： 客户端发一个请求，服务端返回一个数据流。
  • 客户端流式 RPC (Client streaming RPC)： 客户端发送一个数据流，服务端返回一个响应。
  • 双向流式 RPC (Bidirectional streaming RPC)： 客户端和服务端可以同时向对方发送数据流。
• 强类型的服务契约： 通过.proto文件定义服务接口，gRPC 的工具链可以为多种语言（Java, C++, Python, Go, Dart 等）自动生成类型安全的客户端存根和服务端骨架代码。这使得开发者可以专注于业务逻辑，而不用处理底层的 RPC 细节，同时也确保了前后端的接口定义严格一致。/li>

gRPC 能完全替代 HTTP 吗？

不能。 gRPC 和 HTTP（特别是 RESTful API）是解决不同问题的工具，它们是互补关系，而非替代关系。

gRPC 的主要优势在于后台服务间的通信，但在面向外部用户（如 Web 浏览器）时存在一些天然的障碍。浏览器本身不支持直接调用 gRPC，需要通过代理（如 gRPC-Web）进行转换，这增加了架构的复杂性。

HTTP 的应用场景

HTTP/RESTful API 依然是许多场景下的最佳选择：

• 面向公众的 API： 当你需要构建开放 API 供第三方开发者或 Web 浏览器直接使用时，RESTful API 基于 JSON 和 HTTP，拥有最好的兼容性和通用性。
• 简单的请求-响应通信： 对于管理后台、简单的 CRUD 操作等不需要极致性能的场景，RESTful API 开发简单、调试方便（可以直接用 curl 或浏览器测试）。
• Web 浏览器应用： 所有面向浏览器的前端应用，其后端接口几乎都会选择 HTTP API。

gRPC 的应用场景

gRPC 在以下场景中表现出色：

• 内部微服务通信： 这是 gRPC 最经典的应用场景。在数据中心内部，服务间的通信对性能、延迟和网络带宽要求极高，gRPC 的二进制协议和 HTTP/2 多路复用优势尽显。
• 需要流式通信的场景： 例如实时数据推送、物联网设备数据上报、实时音视频传输等，gRPC 原生的流式处理能力非常适合。
• 多语言环境： 当你的系统由多种不同语言编写的服务组成时，gRPC 通过.proto文件提供了一个统一的、与语言无关的接口定义，简化了跨语言调用的复杂性。
• 移动端应用： 移动设备网络环境不稳定且带宽有限，gRPC 的高效性可以节省流量和电量，并提升响应速度。

如何进行技术选型？

选择 HTTP 还是 gRPC，可以遵循以下原则：

总结： 没有银弹。将你的系统看作一个整体，对外暴露的“北-南”流量（用户到系统）通常更适合使用 HTTP/RESTful API，而系统内部服务间的“东-西”流量则应该优先考虑 gRPC，以获得最佳性能和可靠性。

以上关于为什么有了HTTP，还需要gRPC？的文章就介绍到这了，更多相关内容请搜索码云笔记以前的文章或继续浏览下面的相关文章，希望大家以后多多支持码云笔记。