第1章 初识gRPC：起源、理念与选型
第 1 章 · 初识 gRPC：起源、理念与选型
章节摘要：本章回答三个问题——gRPC 从哪里来（Stubby 十年内部实践的开源化）、它的设计理念为什么是"契约先行 + 强类型 + 传输效率"（四大技术支柱如何环环相扣）、以及你手里的项目到底该不该用它（与 REST 的逐维度对比和场景边界）。读完本章，你能在技术评审会上有理有据地为一项通信技术选型表态。
阅读收获
阅读完本章，你应当能够：
- 讲清 gRPC 与 Stubby、HTTP/2、Protobuf 三者的历史脉络关系；
- 解释"契约先行"如何从源头减少联调成本与接口漂移；
- 说出 gRPC 四大技术支柱（proto 契约、HTTP/2、代码生成、流式语义）各自的贡献；
- 从序列化体积、传输效率、契约强度、生态兼容等维度对比 gRPC 与 REST；
- 对一个具体项目做出"用 gRPC 还是留在 REST"的判断并给出理由；
- 识别 gRPC 的典型落地场景与明确不适合的场景。
核心概念速览
一句话点题：gRPC 用"把接口变成编译期检查对象"的方式，解决了微服务时代"服务之间靠口头约定说话"的脆弱性。
子章节导航
1.1 从 Stubby 到 gRPC 的演进历程
Google 内部跑了一个十年的 RPC 框架 Stubby，它证明了强契约 RPC 在超大规模下的价值，却也背负了私有协议的历史包袱。gRPC 是把这套经验在标准化协议（HTTP/2）上重写一遍的产物。这一节讲清"为什么要重写而不是直接开源"，以及 2015 年开源至今的关键里程碑。看点有三：Stubby 验证了什么（契约治理的可行性）、它的包袱是什么（私有协议与内部耦合）、HTTP/2 标准化如何恰好补齐了重写的最后一块拼图。历史细节不是闲笔——gRPC 今天"契约至上、性能是入场券、务实兼容"的三个性格，全部能在这段历史里找到出处。
1.2 核心设计理念与四大技术支柱
为什么 gRPC 坚持契约先于实现？为什么选 HTTP/2 而不是再造一层私有传输？代码生成在多语言团队里扮演什么角色？流式语义为什么和四种通信模式绑定？这一节把四个设计决策的因果链串起来，并诚实列出每根支柱的代价（工具链变重、调试间接性、流生命周期管理复杂）。读完你会得到一张"支柱—解决什么—代价—对应章节"的对照表——后续六章本质上都是在展开这四根支柱中的某一根，这张表就是全书的目录缩影。
1.3 对比选型：gRPC 与 REST 的使用边界
同一段业务，用 REST+JSON 和用 gRPC+Protobuf 各会怎样？从序列化体积、连接行为、契约约束、浏览器兼容、调试成本五个维度做量化与定性对比，随后盘点 gRPC 被反复验证的四类落地场景（微服务内部高频调用、实时推送与上报、AI 推理服务、云原生基础设施控制面）与三类该回避的场景（公网开放 API、前端直连、低频简单调用），最后落到混合架构——对外 REST、对内 gRPC、边界转码的共存方案。读完这一节，你可以在技术评审会上把选型的账算给别人听，而不是只说"gRPC 更先进"。
子章节之间的逻辑关系
本章三节是一条"从哪来—为什么这样设计—我该不该用"的递进链：
[1.1 演进历程] [1.2 设计理念] [1.3 对比选型] 历史约束与动机 --> 四大支柱的因果逻辑 --> 落到今天的选型决策 (Stubby的包袱) (契约/传输/生成/流) (gRPC vs REST边界) 铺垫"为什么有" 解释"为什么这样" 回答"为什么用它"
1.1 提供历史语境，1.2 把历史语境翻译成设计原则，1.3 再把设计原则放到你的项目天平上称重。跳过 1.1 直接看 1.3 也能懂结论，但会丢掉"Google 为什么宁可重写也不复用"这个理解 gRPC 性格的关键。
前置知识与后续延伸
- 前置：知道什么是进程间通信、用过至少一种 HTTP 客户端即可，无其他硬性要求。
- 为后续铺垫：1.2 的契约理念会在第 2 章（Protobuf 语法与编码）、第 3 章（HTTP/2 细节）逐层展开；1.3 的选型结论会在第 7 章（gRPC-Web 与协议转码）重新审视——当浏览器兼容问题被转码方案缓解后，边界会往 gRPC 一侧移动。
本章有两个新人最容易混淆的概念组，提前辨析：gRPC 与 Protobuf 不是一回事——Protobuf 是接口定义语言与序列化格式（可以脱离 gRPC 单独用于存储、配置、消息队列载荷），gRPC 是 RPC 框架（契约层恰好选了 Protobuf）；gRPC 与 HTTP/2 也不是绑死关系——当前主流实现跑在 HTTP/2 上，但协议设计留了传输扩展空间，第 7 章的 HTTP/3 支持就是例证。把这三者当成"可独立存在但组合起来最强"的三件东西，后续章节的边界就清晰了。
本章会反复用到几个术语，先在这里统一口径：契约指 proto 文件定义的接口承诺；**存根（Stub）**指按契约生成的客户端代理代码；**通道（Channel）**指客户端管理与服务的连接的组件；一元调用指一问一答的标准请求响应形态。更细的定义在各节首次出现处展开，这里只需混个脸熟，读完全章自然内化。
读完本章，你对 gRPC 的认知就从一个"名词"变成一套"有出处的方案"。接下来进入 1.1，回到故事开始的地方。