服务网格 15：连接限制与异常实例摘除有什么区别

库存实例变慢，该拒绝请求还是换一台

同一批 orders → inventory 调用中，inventory-v1 响应变慢，而 inventory-v2 仍能处理请求。“连接数满了”与“v1 连续失败”需要两种不同的判断：前者保护某个代理指向上游集群的连接、排队请求或活跃请求等资源；后者依据目标实例的错误信号，暂时从该代理的健康负载均衡集合中摘除异常端点。把两者笼统叫作“熔断”，会让排障时把局部资源耗尽误判为实例不健康。

每个代理局部的资源阈值与集群内某个异常端点的摘除边界

Envoy 的 circuit breaking 是分布式但不集中协调的代理限制：最大连接数、待处理请求、活跃请求、重试等分别计数，边界由各代理所见的 cluster、优先级及配置决定。达到待处理请求上限可能让新请求溢出，但不会据此断言整个服务的全局每秒请求数受到了精确限制。尤其是 HTTP/2 复用下，多请求不必对应多连接；连接阈值也不等于并发请求上限。实际连接数在实现与连接池边界下不宜写成严格永不越过设定值，需核对所用版本文档和代理计数器。

异常实例检测（outlier detection）是被动健康检查：根据代理观测到的连续错误、时间窗口成功率等信号，把某个上游端点从健康集合暂时摘除，并受最大摘除比例、时长及执行开关等配置约束。主动健康检查则定期探测目标，即使没有业务请求也可得到信号；两者可以组合，但不能说“给 v1 开个健康接口就等于已开启被动摘除”。如果只有一个可用实例，策略和门槛可能使错误继续暴露而不是神奇地换到 v2；恢复也应核对重新纳入的条件，不仅看客户端偶然一次 200。

把两个实验分开，才有可比较的结果

先用 examples/service-mesh/ 的无代理调用确认 inventory-v1、inventory-v2 和失败分支确实可区分：

1	`GO_BIN=/tmp/service-mesh-tools/go/bin/go bash scripts/run-00.sh`

基线正常请求由 orders 指向 v1；-quote-delay 可在库存只读报价前引入人工延迟，错误端口则会导致应用无法连接。它们只说明服务处理速度或连接目标错误，没有 Envoy circuit breaker，也没有 outlier ejection；run-00.sh 启动 v2 不意味着代理正向它切换。不能把应用返回的 502/503 改写成代理溢出计数或实例被摘除。

待 Envoy 和隔离环境可用时需做两组正反对照。资源组：固定同一健康上游，先以低并发证明请求可达，再增加并发／排队请求，保存客户端非零结果、代理 upstream_cx_overflow 或相应 pending/request overflow 计数和后端实际请求数；降低负载后确认恢复。实例组：维持足够资源阈值，把 v1 的可控失败与 v2 的正常响应分别记录，核对代理的 ejection 事件／计数、当时可选端点和后续恢复；再关闭摘除做反例。主动健康检查须另存探测请求和状态，不能借用业务请求日志冒充。

本机重跑证据 examples/service-mesh/evidence/00/20261001T151038Z-2717816/：无网格进程正常请求、错误域名、错误端口、应用无上游与账本断言共五项通过；失败请求的 loadgen 退出码为 1。**仍没有 Envoy 或 Kubernetes 代理，两个代理组实验均 NOT_RUN。**要等版本和实际配置固定后才填写代理计数、错误响应来源与恢复时间。即使某个客户端拿到了 200，也仍须检查是否因为重试掩盖了先前失败，不能仅凭最终响应判定限制未触发。

待验收组	正常基线	故障／过载客户端结果	代理计数或摘除事件	后端实际请求
资源溢出与降载	待运行	待运行	待运行	待运行
v1 失败、v2 正常与恢复	待运行	待运行	待运行	待运行
关闭摘除的反例	待运行	待运行	待运行	待运行

练习与参考解答

两个 sidecar 的连接限制各为 10，能断言整个库存服务同时最多 10 条连接吗？参考解答：不能。限制由各代理对目标 cluster 的连接池独立执行；有多个来源代理、连接复用和连接池差异时应分别读取各代理计数，不能把局部阈值当全局配额。
v1 发生连续 503 后，v2 开始收到请求，能否直接认定是主动健康检查摘除了 v1？参考解答：不能。核对负载均衡池中 v1 的状态、outlier 摘除事件、主动探测日志和请求尝试；路由变更或客户端重试也可能改变最终看到的目标。关闭 outlier 后重试相同受控失败，是可证伪的对照。