第3章 指标冲突处理的架构总览：分层决策模型、组件划分、数据流与决策流

指标冲突处理绝非单一算法能解决的问题，它需要从业务目标到算法调参的完整链路协同。本章从架构高度拆解冲突处理的边界、分层决策模型、组件职责、数据流与决策流，并给出选型权衡、风险点、落地步骤与验收标准，为后续各章的深度设计奠定总图。

3.1 边界定义：什么纳入架构，什么不纳入

3.2 分层决策模型详解

分层决策模型将冲突处理拆解为三个自治层，层间通过标准化接口通信，降低整体复杂度。

• 业务目标层：负责定义指标优先级、硬约束阈值、业务容忍区间。输出 ConflictReport 与 PriorityMatrix。
• 策略权衡层：根据业务层输入的优先级矩阵，选择权衡策略（加权和、ε‑约束、Pareto 排序）。输出 TradeoffPlan。
• 算法优化层：执行具体的多目标搜索或调参，将权衡计划转化为可执行的配置变更。输出 ActionSet。

3.3 组件划分与职责

3.4 数据流与决策流

架构采用双流分离设计，数据流与决策流异步解耦，避免循环依赖。

• 数据流（Data Flow）：从底层指标采集器 → 冲突检测 → 冲突分析，逐层向上聚合，形成全局冲突视图。方向：自下而上。
• 决策流（Decision Flow）：从业务目标层 → 策略权衡层 → 算法优化层，逐层向下传递裁决指令。方向：自上而下。

双流通过共享状态层（Redis / etcd / 内存 Grid）交换中间产物，保证流之间不直接耦合。

# 数据流关键结构示例（JSON 序列化后的 ConflictReport）
{
  "conflict_id": "conf-20250321-001",
  "timestamp": 1711036800,
  "pairs": [
    {"metric_a": "latency_p99", "metric_b": "throughput", "severity": 0.87},
    {"metric_a": "conversion_rate", "metric_b": "diversity_index", "severity": 0.62}
  ],
  "source_layer": "business_objective"
}

# 决策流关键结构示例（TradeoffPlan）
{
  "plan_id": "plan-20250321-001",
  "strategy": "epsilon_constraint",
  "epsilon": 0.15,
  "primary_metric": "conversion_rate",
  "constraint_metrics": ["diversity_index", "latency_p99"],
  "valid_until": 1711037400
}

3.5 选型权衡

3.6 风险点与应对

• 风险1：冲突检测器误报 — 导致无效裁决，消耗算力。应对：配置自适应阈值 + 静默期过滤。
• 风险2：策略权衡层单点故障 — 整个决策流阻塞。应对：策略层做无状态水平扩展，状态下沉至共享存储。
• 风险3：缓解动作回滚困难 — 错误调参影响线上服务。应对：所有动作写入变更日志，支持按时间戳批量回滚。

3.7 落地步骤（5阶段）

1. 阶段1：指标梳理与分层映射 — 列出所有业务指标，确认所属层次，建立指标字典。
2. 阶段2：冲突检测接入 — 在业务目标层部署检测器，配置容忍区间与上报频率。
3. 阶段3：策略引擎开发 — 实现可插拔的权衡策略（先支持加权和与 ε‑约束两种）。
4. 阶段4：缓解执行器与回滚机制 — 对接配置中心，开发动作执行与回滚模块。
5. 阶段5：闭环联调与灰度放量 — 用仿真数据验证双流闭环，逐步切 1% → 10% → 100% 流量。

3.8 验收标准