今日主题

理解 gRPC 是什么，读 Introduction to gRPC 和 gRPC Documentation

今天为什么学这个

这一天的主题不是孤立知识点，而是这条学习线里的一个关键节点。真正目标不是把术语记住，而是把它接到后面几天的实操和排障链路里。

今天至少要搞懂

  • 理解 gRPC、REST、消息队列三者的模型差异
  • 搞清 RPC、HTTP/2、Protobuf 在 gRPC 里的定位
  • 明确 gRPC 为什么更适合内部服务间通信

建议实践

写下 gRPC、REST、消息队列三者的区别

推荐操作步骤

  1. 先把今天要读的资料快速过一遍，圈出不懂的术语和命令。
  2. 按今天的实践要求做一个最小可运行 demo，不要先追求完整项目。
  3. 把执行过程中看到的输入、输出、日志或截图整理到当天目录的笔记里。
  4. 对照完成标准做一次自测，确认不是“看懂了”，而是真的“跑通了”。

完成标准

你能解释为什么 gRPC 适合服务间通信

补充笔记

三者的核心区别在于：gRPC 和 REST 都主要是“服务直接调用”，而“消息队列”是“通过中间队列异步传递消息”。

项目 gRPC REST 消息队列
本质 RPC 调用 资源式 HTTP API 异步消息传递
通信方式 同步为主，也支持流式 同步请求-响应 异步为主
协议 HTTP/2 通常 HTTP/1.1 或 HTTP/2 依赖 MQ 协议和中间件
数据格式 Protobuf 通常 JSON 任意消息体
性能 高，适合内部服务 一般，易调试易兼容 吞吐高，解耦强
可读性 较低，不适合直接人工查看 高，浏览器/Postman 友好 取决于消息内容
耦合方式 调用方依赖服务方接口 调用方依赖 HTTP API 生产者和消费者解耦
典型场景 微服务内部通信 对外开放 API、前后端交互 异步任务、削峰填谷、事件驱动
可以这样理解：
  • gRPC：像“函数调用远程服务”，强调高性能、强类型、低延迟。
  • REST：像“通过 URL 操作资源”，强调通用性、易理解、生态成熟。
  • 消息队列：像“发消息到邮箱，别人稍后处理”，强调异步、解耦、可靠传递。 常见使用场景：
  • 内部微服务通信：优先 gRPC
  • 对外提供开放接口：优先 REST
  • 下单后发短信、发邮件、生成报表：优先 消息队列 一句话总结：
  • 要“立刻拿结果”用 gRPC 或 REST
  • 要“先发出去，稍后处理”用 消息队列 gRPC 适合服务间通信，核心原因是它更符合“机器调用机器”的场景，而不是“人调用接口”的场景。 主要有这几个点：
  1. 性能高 gRPC 默认用 HTTP/2 + Protobuf。 Protobuf 是二进制格式，比 JSON 更小、更快；HTTP/2 支持多路复用，减少连接开销，所以很适合高并发、低延迟的内部调用。
  2. 接口约束强 gRPC 先用 .proto 定义服务和消息结构，再生成客户端和服务端代码。 这意味着接口是强类型、明确的，字段、方法、返回值都提前约定好，能减少“文档写的是一套，实际接口又是一套”的问题。
  3. 多语言协作方便 微服务体系里常常不同服务用不同语言实现。 gRPC 可以从同一份 .proto 生成 Go、Java、Python、Node.js 等多种语言代码，跨语言通信成本低。
  4. 更像本地调用 调用方式接近“调用一个远程函数”，比 REST 里手动拼 URL、处理 HTTP 方法、解析 JSON 更直接。 对内部服务开发来说，心智负担更低，开发效率更高。
  5. 天然支持流式通信 gRPC 不只是普通请求-响应，还支持：
  • 服务端流
  • 客户端流
  • 双向流 这对日志流、实时推送、长连接数据同步这类服务间场景很有价值，REST 做起来通常更绕。
  1. 更适合可控的内部环境 gRPC 对浏览器、人工调试、开放生态不如 REST 友好，但服务间通信通常发生在内部网络中，调用双方都由团队控制。 这时“高性能、强约束、自动生成代码”的收益，比“人类可读、通用易调试”更重要。 一句话说就是： gRPC 适合服务间通信，因为内部服务更看重性能、类型安全、接口一致性和跨语言协作，而这些正是 gRPC 的强项。

建议产出物

  • 一个可以反复运行的最小 demo
  • 一页记录输入、输出和失败路径的 README 或笔记
  • 一段“如果这是生产环境，我还缺什么”的复盘

今日复盘

  • 今天真正搞懂了什么
  • 哪一步最容易卡住
  • 如果明天继续推进，下一步最该补什么