模型serving与策略编排集成教程 - 第2节
2.1 策略编排的核心概念
策略编排（Policy Orchestration）是指将多个独立的决策规则、业务逻辑或模型推理结果，按照预定义的流程与条件组合起来，形成一个可执行、可观测、可变更的自动化决策链路。在模型服务场景中，策略编排充当“决策大脑”，负责决定何时调用哪个模型、如何组合多个模型的输出、以及在异常或边界条件下执行何种降级策略。
核心三要素：
- 规则（Rule）： 原子化的决策条件，如“若用户信用分 > 700，则通过”。
- 流程（Flow）： 规则的执行顺序、分支、并行与聚合逻辑。
- 上下文（Context）： 规则与流程共享的输入参数、中间变量与最终输出。
策略编排与单纯的“规则执行”不同，它强调对多个决策单元的编排能力，包括顺序执行、条件跳转、并行分支、超时熔断、结果聚合等。这使得编排层能够灵活应对复杂的业务场景，例如风控评分、个性化推荐、实时定价等。
2.2 规则引擎与工作流引擎的区别
规则引擎（Rule Engine）和工作流引擎（Workflow Engine）是策略编排的两大核心组件，但它们的关注点与适用场景有显著差异。下表从多个维度进行对比：
| 对比维度 | 规则引擎 | 工作流引擎 |
|---|---|---|
| 核心关注点 | “如果…则…”的条件匹配与动作执行 | 任务步骤的顺序、分支、并行与状态流转 |
| 执行模型 | 基于 Rete / 决策表 / 决策树，批量匹配 | 基于 DAG / 状态机 / BPMN，逐步推进 |
| 典型组件 | Drools、EasyRules、OpenL Tablets | Camunda、Temporal、Airflow、Conductor |
| 数据流 | 输入 → 规则集 → 输出（单次决策） | 输入 → 步骤1 → 步骤2 → … → 输出（多步编排） |
| 状态管理 | 无状态或轻量级上下文 | 有状态，支持持久化、补偿、回滚 |
| 适用场景 | 风控规则、定价规则、特征转换 | 模型串联、A/B测试、人工审核流程 |
实践建议： 在模型服务中，通常将规则引擎用于“前置过滤”或“后置修正”，将工作流引擎用于“多模型编排”与“异步任务调度”。两者互补而非替代。
2.3 编排在微服务中的位置
在微服务架构中，策略编排层通常位于API网关与业务服务之间，或作为独立的编排服务存在。它不直接处理数据存储或业务逻辑，而是专注于决策流程的协调与控制。
下图展示了编排层在典型微服务调用链中的位置：
编排层在微服务中的核心职责包括：
- 请求路由与聚合： 根据业务场景将请求分发到不同的模型服务，并聚合多个模型的返回结果。
- 条件分支与熔断： 当某个模型服务超时或返回异常时，编排层可执行降级策略（如使用备用模型或返回默认值）。
- 状态追踪与审计： 记录每次编排执行的完整链路，便于问题排查与效果分析。
- 动态变更： 支持热更新规则或流程，无需重启服务即可调整决策逻辑。
常见误区： 不要将编排层与API网关的“请求路由”功能混淆。API网关负责流量分发与协议转换，而编排层负责业务决策流程的协调。编排层通常需要感知业务上下文，而API网关应保持无状态。
2.4 策略编排的典型工作模式
在实际系统中，策略编排通常采用以下三种工作模式之一：
- 顺序编排： 规则与模型按固定顺序执行，前一步的输出作为后一步的输入。适用于特征工程 → 模型推理 → 后处理的流水线。
- 条件编排： 根据上下文条件选择不同的执行路径。例如，用户等级为VIP时调用高精度模型，否则调用轻量模型。
- 并行编排： 同时调用多个模型或规则，然后通过投票、加权或取最值等方式聚合结果。适用于多模型集成或交叉验证。
下表总结了三种模式的适用场景与优缺点：
| 模式 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 顺序编排 | 特征处理 → 模型推理 → 结果修正 | 逻辑清晰，易于调试 | 延迟累加，单点故障影响全局 |
| 条件编排 | 用户分层、流量分配、A/B测试 | 灵活适配不同场景，节省资源 | 条件复杂度增加时维护成本高 |
| 并行编排 | 多模型集成、风险交叉验证 | 提升准确率与鲁棒性 | 资源消耗大，结果聚合逻辑复杂 |
选型建议： 在模型服务初期，优先使用顺序编排降低复杂度；当业务需要差异化决策时，引入条件编排；当对模型效果要求极高时，再考虑并行编排。