第九章：什么时候适合上 gRPC，什么时候不要硬上

#适合场景

• 服务与服务之间高频调用
  • 订单、库存、支付、风控、推荐这类内部链路
• 多语言协作
  • Go、Java、Python、Node、C# 等多团队同时开发
• 对延迟和吞吐比较敏感
  • 中台、网关后链路、实时计算、设备控制
• 天然有流式需求
  • 日志、监控、传感器、推理分段输出、双向控制
• 强调强类型合同
  • 想减少“文档和代码不一致”的组织性问题

#不太适合场景

• 给第三方开放的公网 API
  • 对方可能只想 curl、Postman、浏览器直接调
• 浏览器优先的简单前后端接口
  • 直接 REST/JSON 往往更省心
• 业务很简单、团队规模很小
  • 协议治理成本可能高于收益
• 接口主要用于人工调试和临时集成
  • JSON 文本可读性更有优势
• 团队没有协议演进纪律
  • gRPC 不是救命药，乱改字段照样出事故

一句话总结：

如果你的系统像“多个部门长期高频协作”，gRPC 值得；如果只是“开一个谁都能来办事的公开窗口”，REST 往往更自然。