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

在构建现代应用，尤其是微服务架构时，我们经常讨论一个问题：已经有了无处不在的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细节，同时也确保了前后端的接口定义严格一致。

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，以获得最佳性能和可靠性。

希望对你有帮助，如果有帮助期待你的点赞、关注、分享，更多精彩文章在我的公众号：IT周瑜，欢迎关注。