复合控制 = 业务规则 + 实时反馈

解决什么问题：如何让系统既遵循业务规则，又能根据实时反馈自动调节—— 既不是纯业务规则（不灵活），也不是纯反馈控制（不可预测）。

业务问题

真实场景

场景 1：限流系统的设计

需求：
- 业务方要求"早 9 晚 9 高峰期限流 1w QPS，其他时间不限流"
- SRE 要求"系统过载时自动限流保护"

设计 A：纯业务规则
- 按时段硬编码限流阈值
- 优点：可预测
- 缺点：业务时段变化时要改代码 / 配置

设计 B：纯实时反馈
- 系统过载时自动限流
- 优点：自适应
- 缺点：不可预测，业务方无法承诺 SLA

设计 C：复合控制（业务规则 + 实时反馈）
- 业务规则给"基线限流值"（如高峰期 1w）
- 实时反馈根据系统负载动态调整（如实际负载 80% 时降到 8000）
- 优点：既有规则，又有自适应

场景 2：推荐系统的排序

需求：
- 业务方要求"新书优先展示"
- 算法要求"按用户兴趣排序"

设计 A：纯业务规则（强制新书置顶）
- 违反用户兴趣

设计 B：纯实时反馈（按 CTR 排序）
- 新书永远没机会展示

设计 C：复合控制
- 业务规则给"基线权重"（新书 ×1.5）
- 实时反馈根据 CTR 微调
- 新书 + 用户兴趣 = 综合得分

场景 3：风控系统

需求：
- 业务规则要求"高风险交易必须人工审核"
- 风控模型要求"自动识别可疑交易"

设计 C：复合控制
- 业务规则给"高风险规则清单"（大额、异常时段、异常地区）
- 实时反馈给"动态阈值"（根据近期风险事件调整）
- 命中规则的 + 模型得分高 → 人工审核

失败的典型做法

做法 1：纯业务规则

✗ 所有逻辑都写在代码里
✗ 修改业务规则 = 修改代码 + 重新部署

后果：
- 业务响应慢
- 系统不灵活

做法 2：纯反馈控制

✗ 所有逻辑都靠自动调节
✗ 没有业务规则的约束

后果：
- 系统行为不可预测
- 业务方无法承诺 SLA

做法 3：业务规则和反馈割裂

✗ 业务规则在 A 系统，反馈在 B 系统
✗ 两套规则互相冲突

后果：
- 系统行为不确定
- 出问题时难以定位

控制论视角

数学原型

钱学森《工程控制论》Ch 5 §5.3：
"这种系统常称为复合控制系统。在这种控制系统内控制量 u 不仅是误差的函数，也是输入作用和外扰作用的函数。"
u = u_前馈(x_ref, d) + u_反馈(e)

控制论解法

复合控制 = 开环前馈 + 闭环反馈

u = u_前馈(x_ref, d) + u_反馈(e)
    │                    │
    ├─ 前馈（开环）：      ├─ 反馈（闭环）：
    │  基于业务规则        │  基于实时反馈
    │  基于外部输入        │  基于误差信号
    │  可预测              │  自适应
    └─ 保证业务承诺        └─ 保证系统稳定

与业务的对应

控制论概念	软件工程
前馈（开环）	业务规则 / 配置 / 静态策略
反馈（闭环）	实时监控 / 自动调节 / SLO 控制器
控制量 u = 前馈 + 反馈	系统的最终行为 = 业务规则 + 实时调节
输入作用 x_ref	业务输入 / 用户请求
外扰 d	外部干扰（流量峰值、依赖故障）
误差 e	实际值 vs 目标值

核心概念

定义

复合控制：系统的最终行为由两部分组成——业务规则（前馈） 和 实时反馈（反馈）。

关键属性

属性	含义
规则保证	业务规则定义系统必须遵守的硬约束
反馈调节	实时反馈根据系统状态动态微调
可预测	业务规则部分 = 可预测（业务方能承诺）
自适应	反馈部分 = 自适应（系统能应对变化）
可解释	两部分分离 = 出问题可定位

复合控制的三种形式

形式 1：前馈主导 + 反馈微调
  u = u_前馈 × (1 + δ_反馈)
  适用：业务规则为主，反馈只调整幅度
  例：新书 ×1.5 × (1 + 用户兴趣修正)

形式 2：反馈主导 + 前馈约束
  u = u_反馈 × 业务约束
  适用：自适应为主，业务规则约束范围
  例：CTR 排序 × (新书下限 0.1)

形式 3：前馈 + 反馈并联
  u = u_前馈 + u_反馈
  适用：业务规则和反馈独立工作
  例：限流基线 + 过载保护

工程实践

步骤 1：识别业务规则

问业务方：
- 哪些业务规则是必须遵守的（硬约束）？
- 哪些规则可以微调（软约束）？
- 哪些规则可以违反（业务底线）？

例（限流）：
- 硬约束：高峰期 1w QPS 上限
- 软约束：实际阈值可上下浮动 10%
- 业务底线：用户至少 80% 请求成功

步骤 2：设计反馈机制

问 SRE：
- 系统过载的指标是什么？（CPU / 延迟 / 错误率）
- 反馈的输入信号是什么？（实际负载 / 实际延迟）
- 反馈的输出动作是什么？（降级 / 限流 / 扩容）

例（限流）：
- 过载指标：CPU > 80% / 延迟 > SLO
- 输入信号：CPU 使用率 / P99 延迟
- 输出动作：动态调整限流阈值

步骤 3：组合规则 + 反馈

公式：u = u_前馈 × f(反馈)

例（限流）：
- u_前馈 = 业务规则的基线阈值
- f(反馈) = 基于 CPU 和延迟的动态调整系数
- f(反馈) = max(0.5, min(1.5, 1 - (CPU - 60%) / 40%))
  → CPU 60% → f = 1.0（无调整）
  → CPU 80% → f = 0.5（降到 50%）
  → CPU 40% → f = 1.5（升到 150%）

步骤 4：实现 + 监控

实现：
- 业务规则：配置中心 / 数据库
- 反馈机制：监控 + 控制器
- 组合逻辑：单独的"复合控制器"组件

监控：
- u_前馈（业务规则）→ 配置变更日志
- u_反馈（反馈信号）→ 实时指标
- u（最终输出）→ 系统行为
- 业务方满意度

常见反模式

反模式 1：业务规则和反馈混淆

症状：
- 一个函数里既写业务规则，又写反馈逻辑
- 难以区分哪个是规则，哪个是反馈

后果：出问题时无法定位
正解：分离规则和反馈 = 复合控制器组件

反模式 2：业务规则优先级低

症状：
- 反馈信号覆盖业务规则
- 业务规则失效

后果：业务方投诉
正解：业务规则有最高优先级，反馈只在规则内微调

反模式 3：反馈信号单一

症状：
- 只看 CPU
- 不看延迟 / 错误率

后果：CPU 低但延迟高时，反馈失效
正解：多信号综合（CPU + 延迟 + 错误率）

工程实例

实例 1：电商限流系统

业务规则（前馈）：
- 高峰期（9:00-21:00）基线阈值 = 1w QPS
- 低峰期（21:00-9:00）基线阈值 = 5k QPS
- 大促期间基线阈值 = 5w QPS

反馈机制（反馈）：
- 实时 CPU 使用率
- 实时 P99 延迟
- 实时错误率
- 综合调整系数 f(反馈)

组合（复合控制器）：
- u = u_前馈 × f(反馈)
- f(反馈) = max(0.5, min(2.0, 1 - 偏差))
- 偏差 = (实际 CPU - 目标 CPU) × 0.5 + (实际延迟 - 目标延迟) × 0.3 + (错误率 - 目标) × 0.2

效果：
- 业务方知道高峰期至少 1w QPS
- 系统过载时自动降到 5k（业务底线）
- 系统空闲时可升到 1.5w（弹性）

实例 2：推荐系统排序

业务规则（前馈）：
- 新书 ×1.5 权重
- 库存 ≥ 10 的商品 ×1.2 权重
- 黑名单商品权重 = 0

反馈机制（反馈）：
- 实时 CTR
- 实时转化率
- 用户行为反馈

组合：
- 综合得分 = CTR × 业务规则权重
- 反馈调整 CTR（贝叶斯平滑）
- 业务规则和反馈的乘积

效果：
- 新书有保底展示
- 用户兴趣强的内容排在前面

性能指标

复合控制健康指标

指标	设计目标	衡量方法
业务规则覆盖率	100% 业务规则都有显式表达	已编码规则 / 业务规则总数
反馈信号有效率	> 80% 反馈触发能改善系统	触发后系统改善次数 / 总触发次数
业务承诺达成率	业务方承诺的 SLA 都达成	实际达成次数 / 承诺次数
业务方满意度	> 80%	业务方评分

监控设计

关键监控：
- u_前馈（业务规则）：配置变更频率、规则命中率
- u_反馈（反馈信号）：触发频率、调整幅度
- u（最终输出）：实际系统行为
- 业务方满意度

告警分级：
- P2：业务规则覆盖率 < 100%
- P1：反馈信号有效率 < 50%
- P0：业务方承诺的 SLA 持续未达成

边界判断

何时不用

场景 1：业务极简

- 没有明显的业务规则
- 没有反馈需求

→ 直接写代码，不需要复合控制

场景 2：业务规则完全主导

- 所有逻辑都是业务规则
- 不需要自适应

→ 不需要复合控制，直接业务规则即可

场景 3：反馈完全主导

- 所有逻辑都是自适应
- 业务方不需要承诺 SLA

→ 不需要业务规则，直接反馈控制

与其他方法论的边界

相邻概念	区别
业务规则引擎	业务规则引擎只做规则；复合控制 = 规则 + 反馈
自适应控制	自适应控制是纯反馈；复合控制 = 规则 + 反馈
CQRS	CQRS 是读写分离；复合控制是控制律组合

何时升级（更复杂的控制）

当以下情况出现时，考虑更复杂的控制：

1. 业务规则频繁变化 → 引入规则引擎
2. 反馈信号太多 → 引入机器学习
3. 多业务方冲突 → 协商机制
4. 实时性要求高 → 流式处理

关键洞察

钱学森 §5.3 复合控制 = 业务规则 + 实时反馈——
这不是控制论的"高级技术"，而是控制论最基础的工程智慧：
"控制量 u 不仅是误差的函数，也是输入作用和外扰作用的函数。"
软件工程的等价表述： "系统的行为不仅由反馈决定，也由业务规则决定。"
纯业务规则 = 死板纯反馈控制 = 不可预测 复合控制 = 既可预测又自适应

IDDD 对位

复合控制 = 多控制器 → 9 种 BC 关系：Partnership / Customer-Supplier
主从结构 = Orchestration → 用例编排（Ch 14）
解耦 → 集成成熟度模型

核心：复合控制 = 多 BC 协同编排——和 IDDD 用例编排同构。

复合控制 = 业务规则 + 实时反馈 ​

业务问题 ​

真实场景 ​

失败的典型做法 ​

控制论视角 ​

数学原型 ​

控制论解法 ​

与业务的对应 ​

核心概念 ​

定义 ​

关键属性 ​

复合控制的三种形式 ​

工程实践 ​

步骤 1：识别业务规则 ​

步骤 2：设计反馈机制 ​

步骤 3：组合规则 + 反馈 ​

步骤 4：实现 + 监控 ​

常见反模式 ​

反模式 1：业务规则和反馈混淆 ​

反模式 2：业务规则优先级低 ​

反模式 3：反馈信号单一 ​

工程实例 ​

实例 1：电商限流系统 ​

实例 2：推荐系统排序 ​

性能指标 ​

复合控制健康指标 ​

监控设计 ​

边界判断 ​

何时不用 ​

与其他方法论的边界 ​

何时升级（更复杂的控制） ​

关键洞察 ​

相关链接 ​

IDDD 对位 ​