一个应用拆成几十个服务，怎么还能高效通信？—— 微服务与 gRPC

属于 S4 Go 微服务 · 第二篇 上一篇：单体拆分与边界设计　下一篇：治理与稳定性

单体应用做大了，会出现"改一处要全量部署、一处崩溃全站瘫痪、无法按热点扩缩容"的问题。微服务把这些拆成一个个独立部署的小服务。但拆开之后，服务之间怎么高效通信，成了新问题——gRPC 就是答案之一。

先想清楚：为什么拆，怎么拆

微服务不是"拆得越细越好"。它的收益是独立部署、按需扩缩、故障隔离；代价是分布式事务、网络通信、运维复杂度。拆分要按业务领域边界（用户、订单、商品各自一个服务），做到高内聚低耦合，并且每个服务独立数据库（避免跨服务 join）。

通信分两种：需要立即返回结果的用同步 RPC，能异步化、削峰解耦的用消息队列。核心链路用同步，旁路（如发短信、邮件）用异步。

gRPC 为什么比 HTTP/JSON 快

gRPC 是 Google 的 RPC 框架，它快在三个层面：

1. Protobuf 二进制编码：体积小、序列化快，JSON 是文本且冗余多。
2. HTTP/2：多路复用（一个 TCP 连接承载多个请求，解决 HTTP/1.1 的队头阻塞）、头部压缩。
3. 强类型 + 代码生成：用 .proto 定义契约，自动生成客户端/服务端代码，接口即文档。

用 Protobuf 定义一个服务长这样：

service Greeter {
  rpc SayHello (HelloRequest) returns (HelloReply);
}
message HelloRequest { string name = 1; }

gRPC 支持四种流：一元（一问一答）、服务端流（一问多答，如推送）、客户端流（多问一答，如上传）、双向流（如聊天）。

Go 里的分层

一个 Go 微服务通常分层：api（proto 定义和生成代码）→ server（协议层）→ service（业务逻辑）→ repo（数据访问）。关键是业务逻辑不依赖具体协议——这样换协议（gRPC 换 HTTP）不影响业务。

---

串起来

微服务解决的是"单体太庞大"的问题，拆分要按领域边界、独立数据库；拆开后服务间通信靠 gRPC（Protobuf 二进制 + HTTP/2 多路复用），Go 里用分层隔离协议和业务。

下一篇讲治理与稳定性：几十个服务互相调用，怎么找到彼此、怎么监控、怎么在下游故障时不拖垮整个系统？