gRPC比HTTP/JSON更适合Go微服务内部通信，因其HTTP/2多路复用避免队头阻塞、Protobuf序列化体积小60%+且解码快2–3倍、强类型.proto定义支持编译期校验、Go官方生态成熟稳定，实测吞吐量提升3–5倍、延迟降低40%以上。
直接用 gRPC，别绕弯子。Go 微服务内部通信，gRPC 是目前最成熟、性能最稳、生态最齐的选择，HTTP/REST 在内部调用里纯属自降性能。
为什么 gRPC 比 HTTP/JSON 更适合 Go 内部通信
不是“更推荐”，而是实际压测和线上观察得出的硬结论：同等硬件下，gRPC 的吞吐量通常是 REST 的 3–5 倍，延迟降低 40% 以上。原因很实在：
-
HTTP/2多路复用：单连接并发处理多个 RPC，避免 HTTP/1.1 的队头阻塞和连接爆炸 -
Protocol Buffers二进制序列化：比 JSON 小 60%+，解码快 2–3 倍，GC 压力明显更低 - 强类型
.proto定义：编译期就能发现字段缺失、类型错配，不用靠运行时 panic 或日志 debug - Go 原生支持极好：
google.golang.org/grpc是官方维护，无兼容性黑盒，升级路径清晰
生成代码时最容易漏掉的两个插件参数
很多人跑 protoc 只加 --go_out，结果跑不起来——缺了 gRPC 运行时绑定。必须同时指定：
-
--go-grpc_out=.：生成服务接口和客户端 stub（比如UserServiceClient） -
--go_opt=paths=source_relative和--go-grpc_opt=paths=source_relative：保证生成的import路径跟 proto 文件位置一致，否则go build直接报 “no such file”
完整命令示例：
protoc --go_out=. --go_opt=paths=source_relative \
--go-grpc_out=. --go-grpc_opt=paths=source_relative \
user.proto
流式 RPC 不是炫技，而是解决真实瓶颈的刚需
当你要传几百条用户数据、实时推送监控指标、或做长周期任务状态更新时，stream 不是可选项，是必选项。常见误用：
- 用一元 RPC
rpc ListUsers(ListUsersRequest) returns (ListUsersResponse)返回大数组 → 内存峰值高、超时风险大、无法中途 cancel - 正确做法是服务端流：
rpc ListUsers(ListUsersRequest) returns (stream ListUsersResponse)，每次只发一条User，客户端用Recv()持续收 - 注意：服务端流要求 client 必须主动调用
CloseSend()（哪怕没发请求体），否则服务端Send()会永久阻塞
并发调用 gRPC 客户端时，别自己 new conn
每个 grpc.Dial() 创建一个连接，但 Go 的 grpc.ClientConn 本身是线程安全且支持复用的。错误写法：
- 每次 RPC 都
conn, _ := grpc.Dial(...)→ 连接数爆炸、DNS 解析频繁、TLS 握手开销翻倍 - 正确做法：全局复用一个
*grpc.ClientConn，用完不关；或者按服务粒度（如userClient、orderClient）各持一个 - 如果需要控制连接行为（比如超时、重试、负载均衡），通过
grpc.WithTransportCredentials、grpc.WithDefaultCallOptions等选项配置，而不是反复 dial
真正容易被忽略的是：gRPC 连接默认启用 keepalive，但在容器环境或 Kubernetes Service 下，中间 LB（如 nginx、istio sidecar）可能静默断连。建议显式配置：
grpc.WithKeepaliveParams(keepalive.PeriodicKeepaliveTime(30*time.Second))
最后提醒一句：gRPC 的优势全建立在“内部可信网络”前提下。别把它暴露给前端浏览器——没有原生支持，调试也极其痛苦。对外 API 该用 HTTP 还得用 HTTP，别为了统一强行套 gRPC。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
