Closed Loop

解决什么问题：系统如何在运行中持续自我修正—— 没有反馈环 = 系统只有"一次性交付"，无法应对环境变化、 流量波动、组件失效。闭环 = 把"调节动作"接到"测量结果"上， 让偏差自动收敛到目标。

它是什么

闭环反馈（Closed Loop） 是控制论最核心的结构： 测量实际输出 y(t)，与目标值 r(t) 比较产生误差 e(t)， 再用误差驱动控制 u(t)——这个"测量→比较→调节→执行→测量"的 循环自己跑下去，就是闭环。

            ┌─────────────────┐
   r(t) ──→ │  +  求和节点    │
            │  ↑              │
            │  e(t)           ↓ u(t)
            │  控制律 C(s) ──→ [被控对象 G(s)] ──→ y(t)
            │  ↑                              │
            └────────  反馈 H(s)  ────────────┘

钱学森 Ch 4 §4.6： "自动控制系统之所以能够自动地、精确地工作， 关键在于它有反馈环节。没有反馈，就没有自动控制。"

V2 视角（V2.7 B5 段 3）：闭环不是"写下来的设计"，是运行时 持续跑着的机制。判断一个系统"是否真的闭环"的标准 = 你能在 1 分钟内回答出"它的反馈信号从哪儿来、阈值是多少、 谁触发什么动作"。

关键属性

属性	值/含义
测量	必须能持续获得系统输出 y(t)
目标	参考值 r(t) 明确（SLO / 业务目标）
误差	e(t) = y(t) − r(t)，驱动控制律
调节	u(t+1) = f(e)，自动或半自动
滞回	进入/退出阈值不同，避免震荡
延迟	测量到调节的总时间 < 业务容忍的 1/10
覆盖率	关键路径 100% 闭环，非关键可降级
可观测	反馈环路本身必须可监控（延迟/成功率）

怎么用

场景 1：自动限流（最经典的闭环）

目标：QPS ≤ 10000
测量：实际 QPS（每秒采样）
误差：e = 实际 - 目标
控制：调整令牌桶容量

    request → limiter(动态阈值) → pass/drop
         ↑                    ↓
         └── metrics ←─── 实际 QPS

关键设计：进入限流阈值 12000，退出限流阈值 8000—— 滞回避免在阈值附近震荡。

场景 2：K8s HPA 自动扩缩容

目标：CPU 使用率 < 70%
测量：节点 CPU（每 15s）
误差：e = 70% - 实际 CPU
控制：增减 Pod 副本（每 30s 评估一次）

外层闭环（SLO）+ 内层闭环（资源）= 串级控制—— 单层调不够时升级的标准解。

场景 3：事故自愈

测量：可用率 / 错误率 / 健康检查
目标：可用率 > 99.95%
控制：重启 Pod / 切换主备 / 流量重路由

SE@G Ch 23 强调：自愈不是"魔法"，是预先写好的 if-then

• 闭环持续验证——条件变了，调节动作也要变。

场景 4：业务驱动的闭环（A/B 测试 → 决策）

IDDD Ch 8 + EDM Ch 16：把业务事件流当作闭环的"测量信号"—— 用户行为回流 → 触发实验评估 → 自动调整流量分配 = 业务闭环。

事件流：用户下单 / 退款 / 投诉
测量：转化率 / 留存率
控制：灰度比例 / 特性开关

常见误区

1. "闭环 = 监控告警"——错。监控告警只到"通知人"，闭环必须到"自动执行控制"
2. "反馈环越长越好"——错。链路长 = 延迟大 = 失效。延迟 < 业务容忍/10 是硬指标
3. "加了监控就有闭环"——错。有测量无控制律 = 半环，等于没环
4. "反馈环只盯技术指标"——错。技术正常 + 业务受损 = 假象。业务指标必须进环
5. "闭环一次设计好就不变"——错。V2 B7：环境变了，控制律要跟着变——闭环必须可调

关键洞察

闭环 = 让系统"自己在跑"——人只在设计阶段介入，运行阶段靠反馈自驱。

没有闭环，前 3 层（L1-L3）是一次性交付；有了闭环，系统 才能在 L4 这一层"活起来"——并在 L5 阶段持续演化。

相关链接

• 反馈闭环——闭环的核心机制
• 告警——闭环的告警环节
• SLO——闭环的目标值
• A/B 测试——业务闭环
• [V3 涌现作为] · 反馈——闭环的 V2 定位
• [V3 涌现之时] · 演化——闭环必须可演化