服务网格对gRPC长连接调用的支持度已经相当成熟，在大多数生产环境下，istio、linkerd 等主流网格都能稳定代理 gRPC 流量，但支持度取决于你如何配置，默认配置往往不是最优解。
gRPC 基于 HTTP/2，天然就是长连接，服务网格引入 sidecar 后，调用链变成 app → sidecar → sidecar → app，这里面的连接管理、负载均衡、健康检查都和普通短连接请求完全不同，接下来我结合自己调优的经验，把服务网格对 gRPC 长连接调用的支持度拆开讲清楚。
服务网格 gRPC 长连接支持度：核心机制与踩坑点
长连接在 sidecar 模型下怎么走
当服务网格注入 sidecar 后，sidecar 之间维持的是长连接，而且是复用字节流里的多个 stream，istio 的 Envoy 默认保持上游连接，除非空闲超时或健康检查失败，linkerd 则用 tcp 隧道方式，同样维持长连接。
这带来一个实际影响：连接数很少，但每个连接上的 stream 很多，多数情况下，service mesh 的 CPU 开销集中在 HTTP/2 帧的处理上，而不是连接建立，所以如果你发现网格性能下降，先看 CPU，而不是连接数。
连接池与并发流限制：为什么 gRPC 会卡住
服务网格内部有连接池机制,Envoy 针对每个 upstream cluster 维护连接池，HTTP/2 连接默认最大并发流数受协议设置影响，Envoy 默认 100，可以通过 http2ProtocolOptions 修改，连接池最大连接数默认是 1，也就是说所有 stream 都挤在一条连接上，一旦这条连接出问题，全挂。
行业共识认为,生产环境需要显式调整 http2ProtocolOptions 的 maxConcurrentStreams 和 circuitBreakers 的 max_connection，istio 默认并没有帮你在 DestinationRule 里把这些调优，需要自己动手。
给你一个 istio DestinationRule 片段，能有效提高并发流上限：
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: grpc-adjust
spec:
host: my-grpc-service
trafficPolicy:
connectionPool:
http:
h2UpgradePolicy: UPGRADE
maxRequestsPerConnection: 0
http2MaxRequests: 10000
maxConcurrentStreams: 100
http2MaxRequests 默认是 0，表示不限制。maxConcurrentStreams 默认 100，可以调高到 1000，但别太夸张，不然内存会涨。
istio 对 gRPC 长连接支持怎么样？对比 linkerd 的差异
istio 的 xDS 与长连接维护
istio 通过 Envoy 实现 gRPC 代理，支持 h2c 升级、TLS 透传、超时重试、熔断，istio 对长连接的感知比较强，因为 Envoy 在连接断开时能快速感知并重新建立，配合故障注入和灰度发布，控制力很足。
但 istio 也有一个典型短板：长连接下，某些配置变更不会立即生效，比如改了重试策略，已建立的连接可能还要等空闲超时后才应用新配置，业内专家指出，istio 的 xDS 推送是异步的，对长连接 stream 的已有请求不会中断，但新请求会慢慢迁移到新配置上。
linkerd 的跳过协议处理对 gRPC 意味着什么
linkerd 走的是“绕过 HTTP/2 头部解析”的路子，它不解析 gRPC 方法，只做 TCP 层转发，这么说吧，istio 看得懂你 gRPC 里的每个方法，linkerd 只知道这是一堆字节流，所以对于 gRPC 长连接，linkerd 的代理开销更低，但它也做不了按方法级别的路由、重试或熔断，如果你只用长连接做简单的负载均衡，linkerd 足够；如果你想做 gRPC 细粒度治理，istio 更合适。
两个主流网格支持度对比
| 维度 | istio | linkerd |
|---|---|---|
| 长连接穿透 | 支持，HTTP/2 代理 | 支持，TCP 透传 |
| gRPC 方法级路由 | 支持 | 不支持 |
| 重试/超时 | 支持，需配置 | 基础支持有限 |
| 连接池调优 | 灵活但复杂 | 较少需要 |
| 性能开销 | 较高 | 较低 |
两者对长连接本身的稳定性都有保障,区别在治理能力，如果你的服务只是内部调用，没有太多灰度场景，linkerd 省心；如果需要按 header 分流、多版本路由，istio 是更成熟的答案。
服务网格 gRPC 长连接调用的常见坑与排查路径
坑一：连接被 sidecar 的空闲超时断开
Envoy 默认 idle timeout 是 1 小时，gRPC 长连接如果一小时没数据，会被断开，客户端如果没做自动重连，服务就中断，解决办法：
- 在 DestinationRule 里设置
idleTimeout: 3600s甚至更长。 - 客户端 gRPC 启用 keepalive 参数，ping 间隔 1 分钟。
坑二：负载均衡失效，流量偏到一台机器
即便有服务网格,gRPC 长连接依然可能负载不均匀，因为 Envoy 默认使用 LEAST_REQUEST 算法，但长连接下请求分布和连接分布不是一回事，最关键的是，如果客户端只有一个连接，那么所有请求都走同一个后端连接，加几个副本也没用，需要：
- 让客户端创建多个连接,比如连接池大小设为 4。
- 用较细粒度的路由规则,比如按 header 拆分到不同 subset。
坑三：健康检查把长连接踢掉
有的网格健康检查是主动探测,探活请求如果走的是同一个长连接，可能导致“死连接复活”或者误杀，建议用带 session affinity 的被动健康检查，或者调整 unhealthyThreshold 阈值。
排查命令实操
一旦出现 gRPC 卡顿，先看 sidecar 日志和指标。
istioctl proxy-config cluster <pod-name> -n <namespace> --port 50051
这个命令能列出上游集群的状态,可以检查 connect_timeout、idle_timeout 等配置，想看端点是否健康：
istioctl proxy-config endpoints <pod-name> -n <namespace>
如果输出里某些 endpoint 的 healthy_status 变成 unhealthy，基本就是健康检查误杀，用 kubectl exec 进 pod 跑一下：
curl -v -X POST http://localhost:15000/stats | grep grpc
Envoy 的 stats 接口会暴露 grpc 相关的计数，cluster.upstream_rq_timeout 是否在涨。
服务网格 gRPC 长连接支持度：生产环境选型建议
看你的核心诉求是什么。
- 如果只用 gRPC 做内部服务间调用，没有太复杂的灰度需求，linkerd 的简单和低开销更省心。
- 如果需要 gRPC 的多版本路由、故障注入、按 header 分流、精确的限流熔断，istio 是更成熟的答案。
- 如果团队已经在用 spring cloud，那 service mesh 与 gRPC 的整合还要考虑存量系统改造成本，这部分往往比网格选型更费时间。
成本也不必回避：istio 对资源占用更高，生产环境至少给 sidecar 预留内存 128Mi 以上，linkerd 的单 pod 内存占用通常低许多，但这是控制面与数据面的整体成本，往往还要算上团队的学习成本。
关于服务网格 gRPC 长连接支持的 Q&A
问：服务网格对 gRPC 长连接调用的支持度足够用于生产吗？
答：足够，istio 和 linkerd 都经历过大规模生产验证，但必须做好连接池调优、健康检查、负载均衡策略三项配置，否则很容易出现超时、连接断开、流量倾斜等问题。
问：gRPC 长连接在服务网格里为什么会遇到 100 并发流限制？
答：这源自 Envoy 的 HTTP/2 配置默认值，Envoy 为了控制内存和并发，默认 max_concurrent_streams 为 100，单个长连接内的活跃 stream 超过 100 个时，新的请求会排队，可以通过 DestinationRule 调整该值，或者用多连接池分散压力。
问：istio 和 linkerd 对于 gRPC 长连接的性能哪个更好？
答：不涉及方法级治理时，linkerd 的代理开销更低，长连接场景下吞吐表现更接近裸调，istio 因为解析帧和 L7 路由，CPU 消耗更高，但能换来更灵活的治理能力，性能差异在低流量下不明显，高并发时需要压测对比。