【GRPC 和 HTTP】设计目标和底层构建

文章目录

• • • 一、核心维度对比表
    • 二、关键差异拆解
    • • 1. 序列化：JSON vs Protobuf（性能核心差距）
      • 2. 传输协议：HTTP/1.1 vs HTTP/2（并发能力差距）
      • 3. 通信模式：单向请求 vs 多模式流式
      • 4. 接口契约：松散 vs 强约束（开发效率差距）
    • 三、选型建议
    • 总结

若对您有帮助的话，请点赞收藏加关注哦，您的关注是我持续创作的动力！有问题请私信或联系邮箱：funian.gm@gmail.com

GRPC 和 HTTP（通常指 HTTP/1.1 及 RESTful 风格）的核心差异源于设计目标和底层完成：HTTP 是通用的应用层协议，而 GRPC 是基于 HTTP/2 的高性能 RPC 框架（本质是“协议+工具链”的组合）。

一、核心维度对比表

对比维度	HTTP（RESTful 为主，基于 HTTP/1.1）	GRPC（基于 HTTP/2 + Protobuf）
本质定位	通用应用层协议（无绑定框架）	高性能 RPC 框架（协议+代码生成+工具链）
传输协议依赖	支持 HTTP/1.1、HTTP/2、HTTP/3	强制依赖 HTTP/2
序列化方式	主流 JSON（文本格式），支持 XML/FormData	强制 Protobuf（二进制格式）
通信模式	以“请求-响应”为主（单向），支持 WebSocket 流式	支持 4 种模式：Unary（请求-响应）、服务端流式、客户端流式、双向流式
接口契约	松散约定（靠文档/Swagger 维护）	强契约（通过 .proto 文件定义接口、参数、返回值）
代码生成	无原生支持（需第三方应用如 OpenAPI Generator）	原生支持跨语言代码生成（客户端/服务端 stub）
性能表现	中等（JSON 解析慢、HTTP/1.1 队头阻塞）	高性能（二进制序列化+HTTP/2 多路复用，低延迟、高吞吐量）
跨语言支持	天然支持（基于 HTTP 协议），但接口一致性需手动保障	原生跨语言（.proto 文件统一约束，生成对应语言代码）
可读性&调试	高（JSON 文本可直接阅读，curl/Postman 调试便捷）	低（二进制数据需解码，需专用工具如 grpcurl）
适用场景	对外 API（浏览器/第三方集成）、简单 CRUD、需可读性的场景	内部微服务通信、跨语言调用、实时流式传输（如聊天/监控）、高性能需求场景

二、关键差异拆解

1. 序列化：JSON vs Protobuf（性能核心差距）

• HTTP（JSON）：文本格式，人类可读，调试方便，但解析慢、数据体积大（比如一个对象的 JSON 表示比 Protobuf 大 30%-50%），不适合高并发场景。
• GRPC（Protobuf）：二进制格式，需通过 .proto 文件定义数据结构（如 message User { int32 id = 1; string name = 2; }），序列化/反序列化速度是 JSON 的 5-10 倍，数据体积小，带宽占用低。
• 核心优势：Protobuf 是“强类型”的，编译时会校验字段类型，避免 JSON 中“字段类型不匹配”“缺字段”等运行时错误。

2. 传输协议：HTTP/1.1 vs HTTP/2（并发能力差距）

• HTTP/1.1 痛点：
  • 单连接下同一时间只能处理一个请求（队头阻塞），高并发需建立多个 TCP 连接，开销大；
  • 头部信息重复传输（无压缩），浪费带宽。
• HTTP/2 赋能 GRPC：
  • 多路复用：单 TCP 连接可同时处理多个请求/响应（借助帧标识归属），消除队头阻塞；
  • 头部压缩（HPACK）：减少重复头部的传输开销；
  • 服务器推送：协助服务端主动向客户端推送资料（配合流式通信）。
• 注意：HTTP 也可基于 HTTP/2，但 GRPC 是“强制依赖”，并充分利用了 HTTP/2 的流式能力。

3. 通信模式：单向请求 vs 多模式流式

• HTTP（REST）：核心是“请求-响应”（比如 GET /user/1 → 返回用户数据），仅能通过 WebSocket 达成有限流式（需额外适配），不支持双向同时传输。
• GRPC：原生支持 4 种通信模式，覆盖更多场景：
  • Unary：和 HTTP 一致（请求→响应）；
  • 服务端流式：客户端发 1 个请求，服务端返回多个连续响应（如实时日志推送）；
  • 客户端流式：客户端发多个连续请求，服务端统一返回响应（如批量上传文件）；
  • 双向流式：客户端和服务端同时双向传输（如即时聊天、视频通话信令）。

4. 接口契约：松散 vs 强约束（创建效率差距）

• HTTP（REST）：接口靠“约定”（比如 URL 路径、请求途径、参数格式），需依据文档（如 Swagger）同步给前端/客户端，容易出现“文档和实现不一致”（比如后端改了字段，文档没更）。
• GRPC：接口通过 .proto 文件“强定义”，比如：

  service UserService {// Unary 接口rpc GetUser(GetUserRequest) returns (GetUserResponse);// 服务端流式接口rpc ListUsers(ListUsersRequest) returns (stream User);
  }

  编译后自动生成客户端（如 Java、Go、Python）和服务端代码，开发者无需手动写 HTTP 请求/响应逻辑，且接口变更会直接在编译时报错，避免“契约不一致”问题。

三、选型建议

场景	优先选 HTTP（REST）	优先选 GRPC
对外提供 API（浏览器/第三方调用）	✅ （可读性强、调试方便、生态成熟）	❌ （二进制不可读，第三方适配成本高）
内部微服务通信	❌ （性能不足，契约易乱）	✅ （高性能、强契约、跨语言友好）
实时流式传输（日志/聊天/监控）	❌ （需额外适配 WebSocket，作用有限）	✅ （原生协助多模式流式，低延迟）
跨语言调用（如 Go→Java→Python）	❌ （需手动保障接口一致性）	✅ （.proto 统一约束，自动生成代码）
简单 CRUD 接口（如管理后台）	✅ （开发快，curl/Postman 调试便捷）	❌ （配置成本高，没必要）

总结

• HTTP 是“通用协议”，主打兼容性、可读性，适合对外场景；
• GRPC 是“高性能 RPC 框架”，主打性能、强契约、流式通信，适合内部服务场景。

两者并非对立：很多系统会“对外用 HTTP REST，对内用 GRPC”，兼顾易用性和性能。