grpc默认keepalive太松致连接频繁重建，需收紧服务端/客户端keepalive参数并启用gzip压缩、修正负载均衡策略、严格管控context传递。
gRPC 默认 KeepAlive 配置太松，连接频繁重建
集群内微服务用 gRPC 通信时，如果没显式调优，KeepAlive 参数会沿用默认值（如 Time=2h、Timeout=20s），在 Kubernetes Pod 重启或网络抖动时，客户端常收到 connection reset by peer 或 UNAVAILABLE 错误，本质是底层 TCP 连接被中间设备（如 kube-proxy、云负载均衡器）静默断开，而 gRPC 没及时探测到。
实操建议：
- 服务端启用并收紧 KeepAlive：
keepalive.EnforcementPolicy{MinTime: 30 * time.Second}和keepalive.ServerParameters{Time: 60 * time.Second, Timeout: 10 * time.Second} - 客户端同步配置：
keepalive.ClientParameters{Time: 60 * time.Second, Timeout: 10 * time.Second, PermitWithoutStream: true}，尤其注意PermitWithoutStream必须设为true，否则空闲连接不发 ping - 避免在
WithBlock()模式下长期阻塞等待连接——它会卡住整个 dial 流程；改用带超时的context.WithTimeout()控制重试节奏
Protobuf 序列化未启用压缩，小包变大包
默认情况下 gRPC 不启用消息压缩，即使业务数据很小（比如只有几十字节的结构体），加上 HTTP/2 header 和 protobuf 编码开销，实际 wire size 可能翻倍。在高 QPS 场景下，这会显著抬高网络吞吐和 CPU 解析负担。
实操建议：
- 服务端注册时明确启用 gzip 压缩：
grpc.UnaryServerInterceptor(grpc_zap.UnaryServerInterceptor(zapLogger))不影响压缩，真正起作用的是grpc.KeepaliveEnforcementPolicy之外的grpc.MaxMsgSize和压缩开关 - 更直接的方式：客户端发起调用时传入
grpc.UseCompressor("gzip")，服务端自动协商解压（无需额外配置） - 注意压缩阈值：小于 ~200B 的消息开启 gzip 反而增加体积，建议只对
len(payload) > 512的请求手动设置grpc.UseCompressor，或用中间件动态判断
Service Mesh 下 gRPC 负载均衡策略失效
在 Istio 或 Linkerd 环境中，若直接使用 dns:///service-name:port 作为 resolver，gRPC 会走默认的 pick_first 策略，只连第一个解析出的 IP，完全绕过 Sidecar 的流量分发能力，导致负载不均甚至单点打满。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
实操建议：
- 强制使用
passthrough:///或unix:///resolver（取决于 sidecar 注入方式），让流量经由 localhost:port 走本地 Envoy - 禁用 gRPC 内置 DNS 解析：初始化 client 时传入
grpc.WithResolvers()并传空 slice，或直接用grpc.Dial("localhost:8080", ...)+ sidecar 映射 - 验证是否生效：抓包看 client 发出的请求目标 IP 是否为
127.0.0.1或localhost，而非集群 Service VIP
Context 传递未截断，跨服务链路拖慢整体响应
每个 gRPC 调用都携带 context.Context，若上游未设 timeout 或 deadline，下游服务可能无限等待；更隐蔽的问题是，Context 中附加的 value（比如 trace ID、auth token）随每次转发不断膨胀，尤其在长链路（A→B→C→D）中，metadata 头部可达数 KB，触发 HTTP/2 frame size 限制或引发中间代理拒绝。
实操建议：
- 所有 outbound 调用必须基于新 context 创建：
ctx, cancel := context.WithTimeout(parentCtx, 800*time.Millisecond)，而不是直接传入 parentCtx - 清理非必要 metadata：用
metadata.Pairs()构造最小集，不要用metadata.FromIncomingContext()全量透传；trace 相关字段保留，auth、debug、custom-header 类字段应由各跳按需注入 - 警惕
context.WithValue()泄漏：避免把 struct、map 等大对象塞进 Context，仅存 string/int 等轻量标识
关键不是堆参数，而是让每条连接知道自己“该活多久”、每条消息知道自己“该不该压”、每次转发知道自己“该信谁”、每个 Context 知道自己“该留什么”。这些细节在单机跑通时全无感知，一上集群就集体暴露。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
