Go mod 好菜系列 - 0x13 grpc 这锅服务间通信已经不是小炒了
从协议、代码生成、服务定义、流式通信和适用场景角度详细聊 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，已经越来越接近“一个真实项目里常见工具全家桶”的形状了。
