微服务调用延迟高的核心在于网络、序列化、连接管理等配置未对齐业务实际。1. 复用 HTTP 连接池，显式设置 MaxIdleConns 和 IdleConnTimeout，避免频繁建连与空闲断连；2. 禁用 http.DefaultClient，为客户端单独配置 Transport 以隔离影响；3. 内部通信优先采用 Protocol Buffers 或 MsgPack 替代 JSON，降低序列化开销；4. 显式设置分级超时（连接、读写、总超时），并通过 context 透传截止时间与追踪信息；5. 异步化非关键操作如日志上报，使用 errgroup 并发调用，减少串行阻塞；6. 上线前结合 go tool trace 与 pprof 分析慢请求，精准定位瓶颈。多数问题源于连接池未配、JSON 解析过重、context 缺失或超时不合理。
微服务调用延迟高，核心不在代码写得慢，而在网络、序列化、连接管理、超时与重试策略这些环节没对齐业务实际。Golang本身轻量高效，但默认配置往往不适合高并发低延迟场景。
复用 HTTP 连接池，避免频繁建连
每次 HTTP 调用都新建 TCP 连接，会带来显著的 SYN/ACK 延迟（尤其跨机房）。Go 的 http.Client 默认复用连接，但需显式配置连接池参数：
-
设置
MaxIdleConns和MaxIdleConnsPerHost：建议设为 100~500（根据下游 QPS 调整），避免连接数不足导致排队等待 -
缩短
IdleConnTimeout（如 30s）：防止空闲连接被中间设备（NAT、LB）静默断开，引发下次请求时重连 -
禁用
http.DefaultClient：它共享全局连接池，易被其他模块干扰；应为每个服务客户端单独初始化带定制 Transport 的 Client
选用更轻量的序列化协议
JSON 虽通用但解析慢、体积大。在内部服务通信中，优先考虑：
- Protocol Buffers（gRPC）：二进制编码、强 Schema、自动生成 Go 代码，序列化/反序列化耗时通常比 JSON 低 3~5 倍
-
MsgPack：兼容 JSON 结构，但无字段名冗余，Go 生态有成熟库（
go-codec/codec），适合 REST API 升级过渡 - 避免在高频接口中混用 XML 或嵌套过深的 JSON 结构——解析开销会线性增长
合理设置超时与上下文传播
不设超时或超时过长，会导致请求堆积、级联失败；不传 context，则无法主动取消、埋点追踪也失效：
立即学习“go语言免费学习笔记（深入）”；
-
对每个 outbound 调用显式传入带 Deadline 的 context：例如
ctx, cancel := context.WithTimeout(parentCtx, 200*time.Millisecond) -
区分“连接超时”、“读写超时”、“总超时”：用
http.Transport设置DialContext+ResponseHeaderTimeout，避免卡死在 DNS 或 TLS 握手阶段 - 在 gRPC 客户端透传 context：确保 deadline、traceID、auth token 等元数据自动注入到请求头
异步化非关键路径，减少串行阻塞
不是所有调用都需要同步等待结果。识别可降级、可延后、只读上报类操作：
- 将日志上报、指标打点、缓存更新等改为 goroutine 异步执行（注意加简单限流，防 goroutine 泄漏）
-
使用
errgroup.Group并发调用多个非依赖服务，而非顺序等待；配合WithContext实现整体超时控制 - 对最终一致性要求不高的场景，考虑写本地队列（如 channel 或 ring buffer）再由后台协程批量提交
基本上就这些。不复杂但容易忽略——很多延迟问题其实出在连接复用没配、JSON 解析太深、context 忘传、超时拍脑袋定。上线前用 go tool trace 和 pprof 抓几个慢请求，90% 的瓶颈都能定位到具体环节。
