Golang微服务项目实战：构建一个可扩展的电商后端

gRPC客户端无需手动实现连接池，因*grpc.ClientConn本身线程安全、可复用且内置HTTP/2多路复用与连接管理；手动池易致泄漏、误关和并发竞争。

gRPC 客户端连接池必须显式初始化，不能复用 grpc.Dial 每次调用

微服务间高频调用下，反复调用 grpc.Dial 会导致文件描述符耗尽（too many open files），且连接未复用、重试逻辑缺失。这不是性能问题，是稳定性红线。

• grpc.Dial 返回的 *grpc.ClientConn 是长连接通道，应全局复用，而非每次 RPC 都新建
• 必须配 grpc.WithBlock()：否则首次连接失败时 Invoke 直接 panic，报 rpc error: code = Unavailable desc = connection closed
• 生产环境必须设 grpc.WithTransportCredentials；本地开发用 insecure.NewCredentials() 可以，但上线后若漏配 TLS，gRPC 会静默降级为明文，不报错也不连通
• 加 grpc.WithKeepaliveParams：K8s Pod 重启或网络抖动时，空闲连接靠 keepalive 探活，否则出现大量 transport is closing

别用 Gin/Echo 封装服务间 HTTP 调用，用 net/http.Client + 自定义 http.Transport

Web 框架的便利性在服务间通信里全是陷阱：中间件链干扰超时控制、JSON 编解码隐藏错误细节、连接池不可控、可观测性字段无法注入。

• gin.Context 无法直接透传 context.WithTimeout，容易绕过超时导致级联雪崩
• 第三方 REST 接口返回 400 时，Gin 默认 JSON 解码会吞掉具体字段校验失败信息，只剩模糊的 json: cannot unmarshal
• 默认 http.Client 无连接池配置，高频调用下频繁建连，很快触发 net/http: connection refused
• OpenTelemetry 的 trace context 依赖 http.RoundTripper 注入，Gin 中间件会覆盖原始 transport，导致 span 断链

http.Client 超时必须分三层设，不能只设一个 Timeout

单点超时既保不住下游，也救不了自己——3 秒总超时里，DNS 解析、TCP 建连、TLS 握手、首字节响应时间全混在一起，故障定位困难，熔断策略失效。

• Timeout：整个请求生命周期上限，建议 ≤ 3s，防慢下游拖垮本服务
• Transport.DialContext 超时：控制 DNS + TCP + TLS 阶段，建议 ≤ 1s
• Transport.ResponseHeaderTimeout：从建连完成到收到响应头的时间，建议 ≤ 1.5s，避免卡在流式响应开头

订单服务聚合根必须隔离库存扣减，不能跨服务直连 DB

电商系统最常踩的坑：订单服务里直接查库存表、扣减库存字段。这破坏自治性，导致事务边界模糊、数据库锁竞争加剧、扩容受限。

立即学习“go语言免费学习笔记（深入）”；

• 订单服务只管生成订单状态和流水，不碰库存数据
• 库存扣减必须走独立 InventoryService 的 gRPC 接口，哪怕只是同步调用
• 库存变更通过 Kafka 异步广播，订单服务监听事件更新自身缓存，避免强依赖
• 秒杀场景下，库存预扣必须用 Redis 原子操作（DECR + EXPIRE），DB 层仅做最终一致性落库

gRPC 连接生命周期、HTTP 客户端超时分层、服务自治边界——这三个点不抠清楚，系统一上量就出隐蔽故障，日志里找不到根因，监控里看不出瓶颈。