Go mod 好菜系列 - 0x13 grpc 这锅服务间通信已经不是小炒了

前面这套系列里有很多模块都像是“项目里的一口菜”，而 grpc 更像是整套通信风格。它不只是一个客户端库，也不只是一个服务器库，而是在告诉你：服务和服务之间，可以按另一种方式说话。

grpc 是什么

它是一套基于 Protocol Buffers 的 RPC 通信框架。粗暴理解就是：

• 你先定义服务和消息结构
• 再生成客户端和服务端代码
• 最后像调用本地方法一样调远程服务

它和普通 REST API 不是互相替代关系，而是两种风格。很多系统会两者并存。

为什么 grpc 在 Go 里特别常见

因为 Go 本来就很适合写后端和微服务，而 grpc 在服务间通信这件事上，又正好很受这类系统欢迎：

• 协议定义清晰
• 代码生成完善
• 类型约束强
• 双向流和流式通信能力成熟

也就是说，它特别适合“后端和后端之间”这种沟通场景。

最核心的感觉：先写 proto

syntax = "proto3";

service UserService {
  rpc GetUser(GetUserRequest) returns (GetUserResponse);
}

message GetUserRequest {
  int64 id = 1;
}

message GetUserResponse {
  int64 id = 1;
  string name = 2;
}

和很多 HTTP 库不一样，grpc 的第一步通常不是直接开写 handler，而是先把接口契约写清楚。

代码生成是它的重要工作流

这也是 grpc 工程味很重的一部分。你不是手搓客户端和服务端结构，而是通过 proto 生成骨架代码，然后在上面实现业务。

这意味着：

• 协议更稳定
• 多语言协作更方便
• 接口变更更可控

它为什么适合服务间通信

因为服务和服务之间往往更关心：

• 协议严格
• 字段明确
• 生成代码降低出错率
• 性能和流式能力更强

而这些恰好就是 grpc 的长项。

但它不是所有项目的默认选项

如果你当前项目只是很普通的前后端接口服务，团队也没有强服务拆分、多语言协作、流式需求，那直接上 grpc 很容易变成“先上了一套更重的通信体系”。

它适合的是那些通信复杂度真的已经上来了的场景，而不是“听说大厂都用，所以我也先摆上”。

小结

grpc 这道菜已经明显不是小炒，而更像一套主食体系：

• 它强调协议先行和代码生成
• 特别适合服务间通信和多语言协作
• 类型约束和流式能力是优势
• 项目还小时，别为了“像微服务”而硬上

到这里，Go mod 好菜系列 又往前扩了一大段：从测试、文档、监控，到权限、热重载，再到 grpc，已经越来越接近“一个真实项目里常见工具全家桶”的形状了。