自镇定与自适应 = 无模型的稳定
解决什么问题：当系统的精确模型不可得时，如何保证系统稳定—— 不依赖精确模型，而是依靠系统的自组织能力。
业务问题
真实场景
场景 1：模型不可得的复杂系统
业务：复杂的微服务系统
问题：
- 系统太复杂，无法建立精确模型
- 模型不准确 = 控制律失效
- 需要一种不依赖模型的方法
→ 自镇定：不依赖模型就能稳定场景 2：环境变化快的系统
业务：业务环境变化快
问题：
- 业务规则每周变
- 控制律很快过时
- 需要持续调整
→ 自适应：根据环境自动调整场景 3：故障自愈
业务：服务故障需要自动恢复
问题：
- 故障模式太多
- 不能为每种故障写规则
- 需要通用恢复机制
→ 自镇定：自动恢复到稳定状态失败的典型做法
做法 1：依赖精确模型
✗ 必须有精确模型才能控制
✗ 模型不准确 = 系统失稳
后果：模型过时 = 系统失效做法 2：手动调整
✗ 工程师手动调整参数
✗ 滞后于环境变化
后果：响应慢做法 3：硬编码恢复
✗ 为每种故障写恢复逻辑
✗ 故障模式太多
后果：代码爆炸控制论视角
数学原型
钱学森《工程控制论》Ch 18 §18 引言：
"自镇定系统是这样一个系统——它不需要知道自己的精确数学模型，但仍然能保证在扰动后恢复到稳定状态。这种系统的核心是Lyapunov 稳定性——只要系统的能量函数在扰动后单调递减，系统就会回到稳定。"
自适应系统更进一步——它能识别环境的变化并自动调整控制律。
控制论解法
自镇定 vs 自适应：
自镇定：
- 不依赖精确模型
- 依靠 Lyapunov 稳定性
- 系统的能量函数 = 单调递减
- 扰动后自动恢复
自适应：
- 识别环境变化
- 自动调整控制律
- 跟踪环境变化
- 持续最优
两者结合 = 自镇定 + 自适应 = 持续稳定的系统与业务的对应
| 控制论概念 | 软件工程 |
|---|---|
| 自镇定 | 服务降级 / 自愈系统 |
| Lyapunov 稳定性 | 系统能量 / 资源消耗 |
| 自适应 | 弹性扩缩容 / 自动调参 |
| 环境变化 | 业务变化 / 流量变化 |
| 跟踪最优 | 持续优化 |
核心概念
定义
自镇定：不依赖精确模型，通过系统本身的特性保证扰动后恢复到稳定状态。
自适应：根据环境变化自动调整控制律，使系统持续稳定。
软件工程对位：故障自愈、弹性扩缩容、自动调参。
自镇定 vs 自适应
| 维度 | 自镇定 | 自适应 |
|---|---|---|
| 目标 | 稳定 | 持续最优 |
| 依赖 | 不依赖模型 | 依赖模型识别 |
| 响应 | 扰动后恢复 | 持续跟踪 |
| 实现 | 简单 | 复杂 |
关键属性
| 属性 | 含义 |
|---|---|
| 无模型 | 不需要精确模型 |
| 自动恢复 | 扰动后自动稳定 |
| 跟踪变化 | 适应环境变化 |
| 鲁棒 | 抗干扰 |
| 可持续 | 长期稳定 |
Lyapunov 稳定性的工程对位
Lyapunov 稳定性：
- 能量函数 V(x) 单调递减
- 扰动后 V 减小 → 系统回到稳定
软件工程对位：
- 资源使用率（CPU、内存）
- 错误率
- 队列长度
扰动 → 这些指标上升
系统稳定 → 这些指标下降
例（队列）：
- V = 队列长度
- 正常处理 → 队列缩短 → V 减小
- 故障 → 队列变长 → V 增大
- 自愈 → 队列缩短 → V 减小 → 回到稳定工程实践
步骤 1：识别系统的"能量函数"
能量函数识别：
候选：
- 资源使用率（CPU、内存）
- 队列长度
- 错误率
- 响应延迟
选择标准：
- 单调性（扰动后上升 / 恢复后下降）
- 可测量（实时监控）
- 可控制（能调节）步骤 2：设计自镇定机制
自镇定机制：
1. 检测扰动：
- 能量函数超过阈值
- 触发响应
2. 自动响应：
- 重启服务
- 切换主备
- 流量切换
3. 等待恢复：
- 能量函数下降
- 系统回到稳定
4. 验证：
- 持续监控
- 确认稳定步骤 3：设计自适应机制
自适应机制：
1. 环境识别：
- 业务量变化
- 用户行为变化
- 故障模式变化
2. 参数调整：
- 自动调参
- 弹性扩缩容
- 限流阈值调整
3. 持续优化：
- 跟踪业务目标
- 持续调整步骤 4：建立反馈闭环
反馈闭环：
1. 测量：实时监控
2. 比较：与目标对比
3. 调节：自动响应
4. 验证：确认效果常见反模式
反模式 1：依赖精确模型
症状：
- 必须有模型才能控制
- 模型过时 = 系统失效
后果：脆弱
正解：自镇定反模式 2：手动调整
症状：
- 工程师手动调整
- 滞后
后果：响应慢
正解：自适应反模式 3：硬编码恢复
症状：
- 为每种故障写恢复逻辑
- 故障模式太多
后果：代码爆炸
正解：通用自愈机制工程实例
实例 1：服务自愈系统
业务：服务故障自愈
自镇定机制：
1. 健康检查（每 10 秒）
2. 连续失败 3 次 → 判定故障
3. 自动重启 Pod
4. 等待 30 秒
5. 重新健康检查
6. 成功 → 回到正常
7. 失败 → 升级告警
Lyapunov 函数：
- V = 服务不健康程度
- 正常时 V = 0
- 故障时 V > 0
- 自愈后 V → 0
效果：
- 故障恢复时间 < 1 分钟
- 人工介入 < 5%实例 2：弹性扩缩容
业务：流量变化时自动扩缩容
自适应机制：
1. 监控 QPS（每 30 秒）
2. 当前 QPS vs 目标 QPS
3. 偏差 > 30% → 调整
4. 自动扩缩容
5. 等待稳定
6. 持续监控
自适应算法：
- QPS 增加 30% → 扩容 50%
- QPS 减少 30% → 缩容 30%
- 滞回：避免频繁调整
效果：
- 自动应对流量高峰
- 资源利用率提升实例 3：数据库连接池自适应
业务：数据库连接池
自适应机制：
1. 监控连接使用率
2. 连接使用率 > 80% → 扩容
3. 连接使用率 < 30% → 缩容
4. 根据历史峰值动态调整
Lyapunov 函数：
- V = 连接池使用率偏离度
- 正常时 V 接近 0
- 异常时 V 增大
- 调整后 V 减小
效果：
- 自动应对流量变化
- 避免连接耗尽实例 4：限流阈值的自适应
业务：限流阈值
自适应机制：
1. 当前 QPS vs 阈值
2. 拒绝率 < 1% → 阈值可以提高
3. 拒绝率 > 5% → 阈值需要降低
4. 自动调整
自适应算法：
- 拒绝率 < 1% → 阈值 × 1.1
- 拒绝率 > 5% → 阈值 × 0.9
- 收敛到合适阈值
效果：
- 自动找到合适阈值
- 适应业务变化性能指标
自镇定/自适应健康指标
| 指标 | 设计目标 | 衡量方法 |
|---|---|---|
| 故障恢复时间 | < 1 分钟 | MTTR |
| 人工介入率 | < 5% | 人工介入 / 总故障 |
| 资源利用率 | > 70% | 实际使用 / 容量 |
| 自适应稳定性 | 不震荡 | 参数变化频率 |
| 业务连续性 | > 99.95% | 可用率 |
监控设计
关键监控：
- 故障恢复时间（MTTR）
- 人工介入次数
- 资源利用率
- 自适应参数变化
- 业务可用性
告警分级：
- P2：自适应参数震荡
- P1：故障恢复 > 5 分钟 / 人工介入 > 20%
- P0：自镇定失效 / 业务可用性 < 99%边界判断
何时不用
场景 1：业务完全可控
- 有精确模型
- 不需要自镇定
→ 不需要自镇定场景 2：业务稳定
- 环境不变
- 不需要自适应
→ 不需要自适应场景 3：系统简单
- 复杂度低
- 不需要无模型方法
→ 不需要自镇定/自适应与其他方法论的边界
| 相邻概念 | 区别 |
|---|---|
| 大系统理论 | 大系统关注"多级协调"；本方法论关注"无模型稳定" |
| 冗余与容错 | 冗余容错关注"可靠性"；本方法论关注"自适应" |
| 自动扩缩容 | 自动扩缩容是具体实现；本方法论是设计原则 |
何时升级（更复杂的自适应）
当以下情况出现时，考虑升级：
1. 环境变化快 → 强化学习
2. 多目标优化 → 多目标自适应
3. 跨服务协调 → 协同自适应
4. 业务关键 → 多重自适应（容错）关键洞察
钱学森 Ch 18：自镇定与自适应是不依赖精确模型的稳定方法。
软件工程的自镇定智慧：
不是所有系统都需要精确模型——很多系统可以通过自组织达到稳定。
应用场景：
- 服务自愈 → 自动重启、自动切换
- 弹性扩缩容 → 跟踪流量变化
- 限流阈值 → 动态调整
- 连接池 → 自适应调整
好的自镇定/自适应 = 简单的机制 + 持续的反馈 + 自动的调节
相关链接
IDDD 对位
- 自镇定 = 自修复 → 事件分发与一致性（Ch 8）：事件驱动自修复
- 自适应 = BC 自演进 → BC（Ch 2）：BC 必须能独立演进
- 演化 = Context Map 调整 → 9 种 BC 关系（Ch 3）
核心：自镇定 = 系统无需外部干预能保持稳定——IDDD 自演化 BC 和 cybernetics 自镇定控制同构。