4. 任务模型设计：任务类型、属性与状态机
任务模型是异步任务编排引擎的“数据骨架”。在 IAM 平台中，每一次权限变更、角色同步、策略下发最终都会抽象为一个或多个任务实例。本章从任务类型、任务属性、任务状态机三个维度，定义引擎的核心数据模型。
4.1 任务类型：同步 / 异步 / 补偿
根据执行方式与业务语义，任务分为三种基础类型：
| 类型 | 执行方式 | 典型场景 | 是否参与编排 |
|---|---|---|---|
| 同步任务 | 调用方线程阻塞等待结果 | 本地缓存刷新、轻量校验 | 否（直接返回） |
| 异步任务 | 提交到线程池或消息队列，回调通知 | 跨系统策略下发、批量用户同步 | 是（DAG 节点） |
| 补偿任务 | 由编排引擎在失败后自动触发 | 回滚已执行的子任务、发送告警 | 是（失败分支） |
设计要点：同步任务不进入编排引擎的 DAG 调度队列，仅用于快速前置检查；异步任务和补偿任务才是编排引擎的核心处理对象。补偿任务必须幂等，且支持多次重试。
4.2 任务属性：ID、类型、超时、重试策略
每个任务实例携带一组结构化属性，用于调度决策和异常处理：
- 任务 ID（taskId）：全局唯一，推荐使用雪花算法或 UUID，用于追踪全链路日志。
- 任务类型（type）：SYNC / ASYNC / COMPENSATION，决定调度行为。
- 超时时间（timeoutMs）：任务执行的最大等待时间，超时后触发 Timeout 状态。
- 重试策略（retryPolicy）：包含最大重试次数、重试间隔（固定/指数退避）、重试条件。
- 依赖列表（dependencies）：前置任务 ID 集合，用于 DAG 拓扑排序。
- 上下文（context）：JSON 格式的输入参数，如目标用户 ID、策略内容。
// 任务属性结构示例（Java POJO）
public class TaskDefinition {
private String taskId; // 全局唯一 ID
private TaskType type; // SYNC | ASYNC | COMPENSATION
private long timeoutMs; // 超时时间，单位毫秒
private RetryPolicy retryPolicy; // 重试策略
private List<String> dependencies; // 前置依赖任务 ID
private Map<String, Object> context; // 执行上下文
}
实践建议：重试间隔推荐使用指数退避（Exponential Backoff），初始间隔 1s，最大间隔 60s，避免重试风暴压垮下游系统。
4.3 任务状态机：Pending → Running → Success / Failed / Timeout
任务状态机定义了任务从创建到终态的完整生命周期。IAM 平台采用五态模型，确保状态流转清晰可审计：
状态流转规则如下：
- Pending → Running：编排引擎根据 DAG 拓扑顺序，将就绪任务提交到执行器。
- Running → Success：任务正常执行完毕，返回结果。
- Running → Failed：任务抛出异常或返回错误码，进入失败状态。
- Running → Timeout：任务执行时间超过
timeoutMs，引擎强制中断并标记超时。 - Failed → Pending：若重试策略允许且未达到最大重试次数，引擎将任务重新入队调度。
避坑指南：Timeout 状态不应自动重试，因为超时通常意味着下游系统负载过高或网络分区，重试会加剧问题。建议 Timeout 任务直接触发补偿流程或人工告警。
4.4 任务模型与编排引擎的关系
任务模型是编排引擎的“数据单元”，引擎通过任务属性中的 dependencies 构建 DAG，通过 type 决定调度策略，通过 retryPolicy 控制容错行为。一个典型的编排流程如下：
- 用户提交一个包含多个任务的 DAG 定义。
- 引擎解析每个任务的
dependencies，生成拓扑排序。 - 引擎从 Pending 状态的任务开始调度，依次推进。
- 遇到 Failed 任务时，根据
retryPolicy决定是否重试或触发补偿。 - 所有任务到达 Success 或 Timeout 终态后，引擎输出整体执行结果。