linux的运维者，逃脱不了定时任务的命题，最常用和快捷简单的是crontab，在少量机器的情况下，crontab效率还是比较高和比较便捷。但当机器越多、应用越多的情况下，继续使用crontab进行定时任务的管理配置，那严重影响工作效率。
机器多、服务多的情况下，就会遇到以下问题：
1.不知道哪个定时任务没配置好，瞎跑；
2.运维人员需要登录服务进行配置和管理；
3.运维人员需要全场参与到定时任务的生命周期；
4.定时任务运行异常告警难以统一对接；
5. 任务A和任务B如果存在互斥关系，crontab就很难进行互斥处理；
6.难于信息管理；运维管理者可能都不知道线上跑了多个定时任务，每个定时任务什么时候运行，属于哪个应用和哪个开发负责。
基于这些问题，我们就决定做一个定时任务管理系统。
当我们做完这个系统的时候，在某次运维大会上，发现暴风也存在这样的系统，有兴趣大家可以猛戳
实现目标：
1. 信息化管理；
2.开发同事自助管理，无需运维同事进行介入；
3.系统需要有分布式功能和冗余功能，提供高并发和冗灾能力；
4.具有定时任务的执行数据图表；
5.支持运行失败告警，同时支持多种类告警（微信、邮件、公司IM通信工具）；
6.与crontab的时间格式需一致，满足现用户使用习惯。
7.引入审核流程，开发pm需要审核非pm开发创建的定时任务。
8.远程应用本地程序运行，需要支持用户自上传定时任务代码包。
9.进行安全性检测，执行权限、代码包风险性检查、危险行为检查等。
定时任务对象：
1.web接口模式，该模式只需要进行web调用就能进行定时任务的调动；
2.本地运行模式，有些定时任务需要运行到应用本地，以脚本(shell python java等等)形式存在。
效果：
定时任务列表
自助配置页
定时任务类型：调用接口（web api调用）；调用脚本（远程脚本的运行）
依赖任务：本任务运行是否依赖其它任务，如果选择，本任务则需要在依赖任务运行完后才能运行，如果超出本次运行开始时间则本次不执行。
告警：可以设置检测到关键字才进行告警。
调用脚本：用户选择该相则同时需要上传代码包。
执行结果列表：
单次执行结果：
整个任务执行数据统计
整体架构
1.用户web把定时任务信息写入数据库中；
2.主控端读取db中定时任务信息，并进行相应封装；
3.主控把对应的任务发送到不同的消息队列中（接口:web api调用;远程本地:应用服务器中的常驻内存进程每分钟进行队列查询 ）；
4.web：http调用；远程：常驻内存程序每分钟进行队列查询，如果存在本应用定时任务则执行。（队列进行了相关分布式封装）
6.结果写入结果队列（5忘记写了）;
7.主控端读取结果队列数据；
8.主控端进行结果写入。
主控端逻辑
队列后端的数据流
队列：选用httpsqs；
nginx：进行分布式任务分派，使得httpsqs冗余和协同工作。
总结：
1.系统上存在1k+个定时任务配置。
2.运行了两年，不怎么需要人力维护，也和之前提到代码更新系统一样处于放养状态。
3.运维同事已经基本不用介入定时任务的生命周期中，开发同事自助。
4.能快速统计定时任务相关信息，例如：某某12调整，只需一点就能查询到12点运行的定时任务有哪些。
5.定时任务信息化、实时告警化，相关任务能实时掌握到定时任务的异常情况。
更多内容，请关注微信订阅号：轻量运维
阅读(1696) | 评论(0) | 转发(0) |
