摘要

  • RFC 8084 要求断路器在明确的 ingress/egress 量测区段内观察指定流或聚合，并在阈值条件跨越多个量测周期持续存在后才触发。
  • 跳闸记录能证明该范围内执行了停止或显著降速的保护反应；它不能为根因命名、定位网络故障、量化用户影响或证明恢复已经完成。

事故记录最容易被一个简短状态词带偏：“触发”听起来像“查明”。实际上，自动保护机制之所以有价值，正在于它不需要等待完整的事故理论才采取有限行动。它可以在自己的观测范围内发现持续的过量条件，并按已配置的规则收缩流量。不能因为它行动了，就把没有观测到的事实塞进这条记录。

RFC 8084 是 2017 年 3 月发布的 IETF Best Current Practice（BCP 208），署名作者为 G. Fairhurst。它把 network transport circuit breaker 定位为最后的安全保护，而非日常拥塞控制的替身。文档先定义了一个量测区段：流量从一个或多个 ingress 进入，从一个或多个 egress 离开；被观察的对象是该区段内指定的 transport flow 或 aggregate。断路器不是看见一次尖峰就应立即作结论。阈值状态必须经过多个 measurement interval 持续存在，之后才触发。触发后的反应会把流量从这个量测区段移走，方式可以是终止，也可以是显著降低速率。

因此，一条合格的跳闸收据有明确的内容：在已经声明的流量边界、阈值版本和时间窗口里，计量器观察到足以满足持续性条件的状态，并且执行了既定反应。这足以让人复核量测设计和动作本身，却没有授权它替任何其他系统发言。

RFC 8084 对这种克制说得很直接。持续的过度拥塞可能涉及异常流量、被其他用途占用的容量、路由变化、配置错误的服务、网络设备、admission controller 或 policer。它们是可能的来源，不是一行告警可以从中任选的答案。文档还指出，在很多情况下，源头处并看不出原因；应用也可能不知道断路器已经触发，更不知道触发发生在网络的什么位置。

由此可见，跳闸不能证明某条链路就是瓶颈，不能把责任归给某一来源，也不能代表所有共享路径的流都经历同一状态。它不等于可用容量测量，不等于远端体验，更不等于普通拥塞控制已经失败。即便动作之后流量下降，也只说明保护机制改变了它能改变的那一部分。是否恢复，仍需要独立的时序、队列、路径、配置和服务观察。

Heng Lu 的最小初始规范与运行代码优先性提供了一种写作纪律：一个正在运行的机制，只应获得它能局部、确定地验证的含义。断路器可以说明自己的范围、阈值、持续条件和反应；拓扑资料要说明拓扑，配置历史要说明变更，远端服务要说明它的状态，用户侧观察要说明影响。发布更响亮的结论，不能把这些不同的证据层折叠成一层。

这不会削弱断路器，反而使它成为可审计调查的开端。保存完整的 ingress/egress 定义、聚合键、周期序列、阈值和动作，然后让对根因、位置、影响和恢复的每一个更大结论，都回到能够观察它的地方。

来源