1. 调度框架需求分析

开发一个通用任务调度框架，最容易犯的错误是先写代码、后补需求。结果往往是：定时任务能跑，但业务方要的“失败重试三次后告警”没有；单机跑得好，一上集群就重复执行；任务卡死时既看不到进度，也说不清卡在哪一步。因此，本章不从架构图开始，而从业务场景出发，把模糊的诉求翻译成可落地的框架能力。

一、先分清四类需求来源

调度框架的需求通常来自四个方向，它们决定了框架的边界：

• 任务定义：业务方如何描述“要做什么”。是调用一个 HTTP 接口、执行一段 Shell、跑一个 Python 脚本，还是触发一条数据同步链路？这决定了任务模型是“命令式”还是“声明式”。
• 触发方式：任务何时开始。是固定周期（每 5 分钟）、Cron 表达式（每天 02:00）、事件驱动（上游文件到达），还是手动触发？这决定了调度器的触发引擎设计。
• 执行约束：任务怎么跑才安全。是否允许并发、超时多久算失败、失败重试几次、依赖哪些前置任务、资源占用上限是多少？这决定了执行器的隔离与限流策略。
• 可观测性：任务跑得怎么样。需要看到执行状态、耗时、日志、重试次数、失败原因，并能对异常任务告警。这决定了监控与日志模块的采集粒度。

这四类需求不是并列的，而是层层递进：定义决定触发，触发决定执行，执行产生可观测数据。任何一层缺失，框架都会在真实场景中“漏气”。

二、把业务场景翻译成功能清单

假设我们面对一个典型的电商业务场景：每天凌晨 1 点，需要把前一天的订单数据从 MySQL 同步到数据仓库，同步完成后触发报表生成，报表生成后发送邮件通知运营。这个场景可以拆解出以下功能需求：

这张表就是功能清单的雏形。注意，每一项都对应一个可配置的参数，而不是写死在代码里。通用框架的价值，正在于把这些参数暴露给使用者，而不是替他们做决定。

三、非功能指标：决定框架能不能上生产

功能清单回答“能做什么”，非功能指标回答“做得好不好”。对于调度框架，以下五类指标必须提前定义，否则后期返工成本极高：

• 调度精度：触发时间与预期时间的偏差。例如 Cron 任务允许 ±1 秒偏差，事件驱动任务要求毫秒级响应。
• 吞吐能力：单集群每秒能触发多少任务。示例目标：1000 任务/秒，支持横向扩展。
• 可用性：调度器宕机后多久恢复。示例目标：99.9% 可用，故障切换在 30 秒内完成。
• 一致性：同一任务在集群中不重复执行。需要分布式锁或选主机制保证。
• 可扩展性：新增一种任务类型（如 K8s Job）需要改多少代码。目标：插件化接入，不改核心调度逻辑。

四、需求分析的可视化：从场景到指标的映射

下面的 SVG 展示了本节的核心逻辑：左侧是业务场景中的原始诉求，中间经过“任务定义—触发方式—执行约束—可观测性”四层过滤，右侧输出为框架的功能清单与非功能指标。这张图不是流程图，而是一张需求映射关系图，帮助你在做需求分析时逐项对照，避免遗漏。

五、需求分析的实际操作：从清单到验收标准

完成上面的映射后，还需要把功能清单转化为可验收的标准。例如“失败重试”不能只写“支持重试”，而要写成：任务失败后，按配置的重试次数和间隔自动重试；重试耗尽后，任务状态置为 FAILED，并触发告警通知；重试过程记录在任务执行历史中，可通过任务 ID 查询。

再比如“并发控制”，验收标准应明确：同一任务在同一时刻只允许一个实例运行；若上一次未结束，下一次触发被跳过并记录 SKIPPED 状态；跳过原因可在日志中查看。

六、形成框架功能清单的检查方法

最后，用三个问题检验需求分析是否完整：

1. 每个业务诉求是否都有对应的功能项？ 如果业务方说“报表要准时”，而功能清单里只有“Cron 触发”，没有“超时告警”和“延迟监控”，就说明可观测性缺失。
2. 每个功能项是否都有可配置参数？ 如果重试次数写死在代码里，框架就不通用。参数化是通用框架的基本要求。
3. 每个功能项是否都有验收标准？ 没有验收标准的需求，开发完成后无法判断是否达标，测试也无法设计用例。

完成本章的需求分析后，你将得到一份包含任务定义、触发方式、执行约束、可观测性四类功能项，以及调度精度、吞吐、可用性、一致性、可扩展性五类非功能指标的框架需求基线。这份基线是后续架构设计、模块划分和测试验收的共同依据，也是判断“框架是否通用”的第一把尺子。