要让upstream正确支持gRPC需从协议特性、连接管理、健康探测和负载策略四方面协同配置：启用HTTP/2并透传二进制流量，配置长连接保活，采用gRPC Health Checking Protocol做健康探测，选用least_conn等适配流语义的负载策略。
要让 upstream 正确支持 gRPC 协议的微服务集群调度，核心不是“加个参数就行”，而是从协议特性、连接管理、健康探测和负载策略四个层面协同配置。gRPC 基于 HTTP/2，不兼容传统 HTTP/1.x 的 upstream 模式，直接复用 REST 负载均衡配置会导致 502、连接重置或流中断。
必须启用 HTTP/2 并透传二进制流量
gRPC 通信依赖 HTTP/2 的多路复用与头部压缩，Nginx 或 Envoy 等反向代理必须显式开启 HTTP/2，并禁用对请求体的缓冲和重写：
- Nginx 中需在 upstream 块外的 server 块启用
http2，且 location 必须使用grpc_pass（非proxy_pass） - 关闭
proxy_buffering、proxy_http_version 1.1等 HTTP/1.x 特性，避免协议降级 - 确保 TLS 终止点（如 Nginx）支持 ALPN 协议协商，客户端能通过 h2 协商成功建立 HTTP/2 连接
连接复用与长连接保活
gRPC 客户端默认复用单一 TCP 连接发送多个 RPC 请求，upstream 必须维持该连接长期有效：
- 设置
keepalive_timeout≥ 300s（推荐 600s），避免连接被中间设备主动断开 - 配置
keepalive_requests为较大值（如 10000），防止连接因请求数限制而频繁重建 - 后端 gRPC 服务需开启 HTTP/2 keep-alive 参数（如 Java 中
NettyServerBuilder.keepAliveTime）
健康检查必须基于 gRPC Liveness 接口
传统 HTTP GET /health 无法准确反映 gRPC 服务真实可用性，因为 HTTP/2 连接可能存活但 gRPC 方法已卡死：
- 建议后端暴露标准 gRPC Health Checking Protocol（
grpc.health.v1.Health） - Nginx Plus 或 Envoy 可直接调用
/grpc.health.v1.Health/Check进行二进制健康探测 - 开源 Nginx 需配合自定义 Lua 脚本或外部探针，否则只能退而使用 TCP 端口连通性检查（精度较低）
负载均衡策略适配流式语义
gRPC 支持 unary、server-stream、client-stream、bidi 四种调用模式，普通轮询或哈希策略可能破坏流上下文：
- 优先选择 “least_conn” 或 “random with two choices”，避免将大量流集中到单个实例
- 若需会话亲和（如双向流需保持同一后端），可基于
grpc-encoding或自定义 metadata header 做一致性哈希 - Kubernetes Ingress（如 nginx-ingress v1.10+）已原生支持 gRPC 的
grpc-backend标识和健康探针，推荐直接使用
