1.3 对比选型：gRPC与REST的使用边界

1.3 对比选型：gRPC 与 REST 的使用边界

本节摘要：gRPC 与 REST 不是替代关系，而是分工关系。本节从序列化体积、连接行为、契约强度、浏览器兼容、调试成本五个维度做量化与定性对比，给出典型场景的选型判定表，并列举 gRPC 已被验证的落地场景（微服务内部调用、实时推送、AI 推理服务、云原生基础设施）与明确不适合的场景。

你能学到什么

阅读完本节，你应当能够：

1. 用数据说明 Protobuf 与 JSON 在体积和解析速度上的典型差距；
2. 解释 gRPC 在浏览器端受限的原因与缓解方案；
3. 从契约、性能、生态、人力四个角度评估一个项目的通信选型；
4. 举出 gRPC 的四类典型落地场景与两类不适合场景；
5. 设计"gRPC 与 REST 共存"的混合架构策略。

一、从一个真实场景说起

某电商团队的服务拆到第 12 个时遇到了怪事：压测数据怎么看都不对。订单服务单机 QPS 800，调用链上要串库存、营销、风控三个服务，每次调用都要序列化一个 30 多个字段的 JSON。压到 3000 QPS 时，三台机器的 CPU 全被 JSON 序列化与反序列化吃掉，业务逻辑本身只占两成。

这个案例的解法不止一种，但团队最终选择的路径是：内部高频调用改 gRPC，对外 API 保留 REST。改造后同样的调用链，CPU 占用下降了一半以上，连接数从每服务实例几十条降到个位数。这个决策背后的账，就是本节要算的账。

二、逐维度对比：把账算细

维度一：序列化体积与解析成本

同样一条"用户下单"消息，JSON 文本与 Protobuf 二进制的差距是结构性的。JSON 要为每个字段重复携带字段名字符串、引号、冒号、逗号；Protobuf 只在数据里放一个字段编号（通常一个字节）加值本身。字段名越长、嵌套越深，差距越大。

一个有代表性的量级感受（具体数值随消息结构与运行环境浮动）：

要注意，这个差距在很多业务里"够不着痛处"——如果你的接口本来每秒只有几十次调用，序列化开销无关紧要。它是高频调用场景的问题，不是所有场景的问题。

维度二：连接行为

REST 走 HTTP/1.1 时，一条连接同时只能处理一个请求-响应，并发靠连接池堆连接数；HTTP/2 化的 REST（浏览器与多数服务端已支持）能获得多路复用，但多数 REST 客户端库默认没有充分利用。gRPC 从第一天就按 HTTP/2 的多路复用设计，单连接高并发是默认形态，长连接的心跳、断线重连、优雅关闭都由 Channel 托管。

反映到基础设施上：服务实例之间维持的 TCP 连接数大幅下降，握手、慢启动、TIME_WAIT 状态的压力同步减轻。在服务实例上百、调用关系复杂的拓扑里，这是比序列化更可观的收益。

维度三：契约强度

REST 世界的契约工具是 OpenAPI 规范，成熟且普及，但它的普遍用法是"代码先行、文档后补"，规范与实现之间的同步靠自觉。gRPC 反过来，proto 是源头，代码是产物，同步由构建过程强制保证。

两种模式没有绝对优劣，但适配的协作形态不同：面向外部开发者的开放平台，松散契约反而降低了接入门槛；内部服务网格状的调用关系，强契约才能压住复杂度。

维度四：浏览器与通用客户端

这是 gRPC 最明显的短板。浏览器无法直接发起标准 gRPC 调用——浏览器端的 HTTP/2 编程接口不暴露 gRPC 需要的底层帧控制。缓解方案是 gRPC-Web：浏览器跑受限的 gRPC-Web 协议，由代理层（Envoy 或专用网关）转成标准 gRPC 转发给服务端。能用，但多了一层代理、也损失部分能力（客户端流不可用，双向流退化为服务端流）。第 7 章会专门展开。

同理，curl、wget 这类随手可用的调试工具对 gRPC 不友好——你需要 grpcurl 之类的专用工具，或依赖服务端开启反射服务。

维度五：调试与生态惯性

REST 的调试生态经过二十年积累：浏览器直接看、代理抓包直接读、日志里打出来人眼可辨。gRPC 的二进制帧在抓包工具里是"天书"，排错依赖专门工具链（第 6 章的可观测性一节给方案）。对团队来说，这是一次性的学习成本加上持续的舒适度损失。

选型对比矩阵

三、gRPC 被验证的四类落地场景

对比之后，正面看 gRPC 已经被反复验证的场景，判断时可以直接对号入座。

**场景一：微服务内部高频调用。**这是 gRPC 的主场。服务实例之间调用频繁、消息结构复杂、调用链长，序列化与连接开销被放大到肉眼可见；同时内部环境统一，不受浏览器约束，代理与网关由平台团队统一建设。前文电商案例就是典型。

**场景二：实时数据推送与上报。**行情推送、位置追踪、日志上报、IoT 设备遥测——这些"一边持续产生、一边持续消费"的场景，天然需要流式语义。服务端流做推送，客户端流做批量上报，双向流做实时对话。用 REST 轮询模拟这些交互，延迟与空转请求都是持续的成本。

**场景三：AI 与数据服务的推理接口。**模型推理服务（以 TensorFlow Serving 为代表）用 gRPC 承载请求与响应，批量张量数据的传输效率直接影响吞吐。多模态场景里音频、视频帧的持续输入输出，也依赖流式接口。数据中心内部的服务间调用环境恰好绕开了 gRPC 的所有短板。

**场景四：云原生基础设施的控制面。**etcd 对外的键值接口、Envoy 的 xDS 配置下发、各类调度与编排系统的组件通信——基础设施组件对延迟与可靠性敏感，且部署在受控环境，是 gRPC 早期的种子场景。理解这一点有个实用推论：即便你的业务全用 REST，运维云原生基础设施也绕不开 gRPC 的概念（健康检查协议、反射服务、xDS）。

四、不适合与需要犹豫的场景

反面同样清晰：

**公网开放 API 慎用。**面向第三方开发者的接口，可读性、可试用性、生态惯性都站在 REST 一边。第三方开发者打开浏览器就能试 REST 接口，gRPC 要装工具链。开放平台的正确姿势是内部 gRPC、边缘转码成 REST（第 7 章的转码方案）。

**前端直连场景慎用。**浏览器直连 gRPC 的受限前面说过。如果整个产品就是"网页调后端"，为通信协议引入一层转码代理，多数情况下不划算。

**低频简单调用不必用。**一天几百次的告警通知接口，用什么协议都行，引入 gRPC 纯属给团队增加心智负担。协议选型的收益与调用频次、消息复杂度、服务规模成正比，与"技术先进性"无关。

⚠️ 常见坑：把"gRPC 更快"当成选型理由。如果你的瓶颈在数据库慢查询、在算法复杂度、在三方依赖，换协议是缘木求鱼。先做性能剖析，确认通信层确实是瓶颈，再动协议。

五、混合架构：现实中的常态

成熟的系统很少"全 gRPC"或"全 REST"，常态是分层混合：

对外一个面孔（REST），对内一种语言（gRPC），边界处由网关完成转码。这样既保住外部生态的兼容性，又吃到内部通信的效率与治理红利。第 7 章讲 gRPC-Web 与转码网关的实现细节时，会给出这个边界的具体建设方案。

常见问题

问：团队没有 gRPC 经验，第一个项目怎么起步风险最小？
挑一个纯内部、调用方少、没有外部依赖的服务做试点，先用一元模式跑通"契约定义—代码生成—服务上线—可观测接入"的完整闭环，再考虑流式与治理高级特性。避免一上来就改造核心链路。

问：迁移期间两套协议并存，运维上要注意什么？
并存期最大的风险是"两套体系各建各的观测与告警，故障定位要跨两套工具"。提前把指标与日志的口径统一（同一个监控面板看两套协议的错误率与延迟），网关层的转码流量单独打标——不然出了问题连"哪套协议的锅"都要查半天。

问：已经有一整套 REST 服务，值得迁移吗？
按调用热度排优先级，只迁移热点路径。内部调用 QPS 前百分之十的接口贡献了绝大部分通信开销，这些先换；长尾接口留在 REST，不值得动。混合状态会持续很久，这正常。

核心回顾

• 序列化差距是结构性的：Protobuf 按字段编号编码，JSON 重复携带字段名文本；但差距只在高频调用时构成痛点。
• 连接行为差异在大规模时显现：gRPC 单连接多路复用显著降低连接数与握手开销。
• 契约强度适配协作形态：内部网状调用要强契约，开放平台要低门槛，方向相反。
• 浏览器与调试生态是 gRPC 的主要短板：gRPC-Web 加代理可解，但有代价。
• 四类场景直接对号入座：微服务内部高频调用、实时推送上报、AI 推理服务、云原生基础设施控制面。
• 三类场景明确回避：公网开放 API、前端直连、低频简单调用。
• 混合架构是常态：对外 REST、对内 gRPC、边界转码，不必追求单一协议。

至此第 1 章结束，你已经能判断 gRPC 在自己体系里的位置。第 2 章进入第一根支柱的内部：proto3 语法全解，以及那些"改一个字段编号就出事故"的兼容性规则。