gRPC是内网高并发低延迟场景的首选，但需复用ClientConn、启用HTTP/2、正确配置超时与服务发现；HTTP/JSON适用于对外API；消息队列需保障可靠性与幂等性。

gRPC 是内网服务通信的默认选择，但别急着写 grpc.Dial

Go 微服务跑在内网、高并发、低延迟要求下，gRPC 几乎是唯一合理选项：HTTP/2 多路复用避免队头阻塞，P

rotobuf 序列化体积只有 JSON 的约 35%，实测 QPS 提升 3–5 倍，延迟降 40%~60%。但性能优势不会自动生效——grpc.Dial 每次调用都含 DNS 解析、TLS 握手、HTTP/2 协商，开销远超一次 RPC 调用本身。

• 必须复用 *grpc.ClientConn，全局单例或连接池管理，禁止在 handler 里反复 grpc.Dial
• 服务端监听要明确启用 HTTP/2：grpc.NewServer() 后直接 srv.Serve(lis)，不要混用 http.Server 代理
• 若前端 Nginx 反向代理 gRPC，必须配置 http2 和 grpc_pass，否则降级成 HTTP/1.1，多路复用失效
• 客户端超时由 context.WithTimeout 控制，但别在服务端 handler 里重设 deadline——会截断上游剩余时间，引发雪崩式重试

HTTP/JSON 不该被抛弃，而是用在它该在的地方

HTTP 不是“过时协议”，它是对外暴露 API 的事实标准：浏览器、App、第三方系统无法直接消费 gRPC 二进制流；Kong、AWS API Gateway、CDN 等中间件只认 Authorization、Cache-Control 等标准头部；curl -X POST http://localhost:8080/api/user 一行就能验证接口，而 grpcurl 需要额外证书和 proto 文件。

• 内部服务间慎用 net/http 同步调用——默认无超时，http.Client 不设 Timeout 和 Transport 参数，生产环境极易拖垮整条链路
• 务必显式配置：Timeout（建议 ≤ 3s）、MaxIdleConns（≥ 100）、IdleConnTimeout（≤ 30s）
• 错误需分层处理：url.Error 是网络层失败，resp.StatusCode >= 400 是业务层错误，不能只看 err != nil
• 大响应体必须手动调用 resp.Body.Close()，否则连接泄漏，MaxIdleConnsPerHost 很快耗尽

消息队列不是“加个 Kafka 就完事”，可靠性取决于你怎么用

当订单创建后要通知库存、发短信、写日志，这些不需要即时响应的操作，就该交给 Kafka、RabbitMQ 或 NATS。但异步不等于“随便发”，消息可能重复、丢失、乱序——你得主动设计保障机制。

• Kafka 生产者必须设 RequiredAcks: kafka.RequireAllIsr + MaxRetries: 3，否则网络抖动就丢消息
• NATS Streaming 客户端 ClientID 必须全局唯一（比如用 Pod ID），否则旧连接会被踢出，消息中断
• 消费者处理失败时，不能简单 log.Fatal——要重试 + 死信队列（DLQ），把反复失败的消息隔离出来人工介入
• 所有消费者逻辑必须幂等：同一条 OrderCreated 消息被投递两次，库存扣减结果也得和一次一样

别忽略服务发现和连接生命周期，它们决定你能跑多久

硬编码 "127.0.0.1:50051" 在开发期没问题，上线后服务实例动态伸缩，没服务发现就是定时炸弹。gRPC 原生支持自定义解析器，但多数团队卡在“怎么跟 Consul / etcd 对接”这一步。

• gRPC 客户端可传入 grpc.WithResolvers()，自己实现 resolver.Builder 查询注册中心获取实例列表
• HTTP 客户端更简单：封装一个 ServiceClient 结构体，每次请求前调用 GetEndpoints("user-service") 拿可用地址，配合轮询或一致性哈希负载均衡
• 无论 HTTP 还是 gRPC，都要监控连接状态：transport is closing 错误通常不是代码问题，而是空闲连接被防火墙或 LB 中断——必须配 keepalive.EnforcementPolicy 主动心跳保活

真正难的从来不是选协议，而是把连接复用、超时传递、错误分层、幂等设计这些细节嵌进每一行调用里。漏掉任何一个，压测时都可能突然崩掉。