调度系统设计准则
Posted by Akilis
on 31 Jul, 2022
Introduction
现代调度系统诸如DolphinScheduler, Airflow, Oozie [1]等都是Apache项目孵化出来，经过大数据领域的实践，沉淀出了通用的基础功能，相似的设计方案，以及易用的用户交互界面。但这些系统之间又各有侧重和区别，长短板明显。在新系统构建、开源方案选型、以及系统迁移等场景中，需要利用这些经验和思想加以指导和甄别，落地、定制符合自身业务场景的调度系统。
Design Guidelines
- 开源社区
- 选择开源方案作为框架时，要看社区活跃度和企业应用范围。
- 二次开发
- 永远意识到No-free-lunch，一般都要结合自身业务，进行用户权限管理、中间件集成、部署发布平台等整合开发。
- 技术栈
- 根据团队的编程语言等技术栈和演进方向，选取对应技术生态的系统尤为重要。
- 明确产品方向的是侧重用户界面提升，系统吞吐能力、还是API的可编程化。
- 性能
- 随着调度作业的数量级增加，要求调度能力能够具备linear scalability。
- 调度协调节点可能会出现架构性的bottleneck，让协调节点具备多实例、分布式能力，基于数据库分片扫描调度作业达到embarrassingly parallel。
- 可用性
- 对于单点瓶颈环节，应该使用监听技术，引入standby节点，实现HA。
- task之间的大量数据传递要保证高效率Serde和持久化。
- 易用性
- 大数据场景的调度作业类型细分，方便完善生命周期的托管、清理。
- task状态对外应当精简，能够让用户快速明确问题出现在系统侧还是业务侧，以及如何自助解决问题。
- 部署运维
- Task执行节点随着时间、用户量增多而需要不断扩容，维护这些节点的大数据软件版本、客户端环境，做到高效发版、回滚等是非常重要的。
- 实现高度的CI/CD。落地end2end的integration test, 监控CI/CD过程并不断优化。
- 插件化
- plugin设计风格可以让框架采用者实现自己的服务，灵活替换既定方案。例如服务注册可以基于Zookeeper，Etcd等来实现，或接入自身的已有中间件。
- 可扩展
- 模板化
- 告警推送格式等的模板化，降低使用门槛，帮助扩展、规范格式，提升下游自助化。
- 业务优先级
- 对用户不应开放优先级，所有人可以设置优先级等价于没有优先级。或者是业务角度相对优先级，平台应当统筹总体优先级。
- 设计类似人工售票多窗口，一般有特殊排队窗口，持有证明即可排队，用窗口帮助业务优先级的提升，规范加速流程，防止优先级滥用。
- 日志展示
- 避免大量I/O流经协调节点。
- 执行日志放在执行节点，上层应用例如web端可以通过RPC直接读取节点日志。
- 事件驱动
- 提交任务、更新作业执行状态等使用异步方式。
- 借助Queue数据结构，让系统具备back pressure，保护过载。
- 项目制及ownership
- 给task标记作业类型，且不能指定执行机器，多租户资源隔离。
- 大数据任务类型可以设置队列，多租户对应Linux执行用户。
- 执行节点可按组划分，配置执行环境。
- 每个调度作业确保始终能找到owner，避免项目交接后发生无人维护，造成后期难以清理。
References
[1] Apache Incubator Project
WEB
SCCS
DESIGN
SCHEDULER
Share on:
Email