本文是我在一个技术分享群里面，对于任务调度和开源软件opencron的分享和使用体会，现在整理成文字，供大家参考。
大家好，下面我来分享一下 部署和使用 opencron 任务调度工具的一些经验和体会
我计划从五个方面来进行分享
1 任务调度需求与要素分析
任务调度，平时在大家的工作中应该会遇到比较多的，对于运维来说，操作系统的重要文件的每天定时备份，操作系统时间同步，各种数据库的备份，日志和监控信息的抓取等，都需要配置各种定时任务
对于开发和业务来说，一般也会定时运行一些操作或作业，实现一定的开发需求和业务需求
任务调度的需求，在各个地方都会有很多，如果想要建设自动化运维平台，任务调度，也是一个非常重要和基础的模块
一般来说，少量的任务调度，都会使用操作系统本身的 crontab 来实现，把想要执行的任务封装成shell脚本，或者python脚本，添加到 crontab中进行定时运行，任务运行的结果写入null中，或者记录到一个日志文件中
这种方式，比较稳定，简单，在定时任务数量很少，需求也比较简单的时候，是一种很常见的解决方案； 但当需要执行的任务数量很多，需求更复杂，需要能调度、可视化展示、结果分析等功能时，这种方式就不太能适合需求了
以我现在的实际工作而言，每天需要调度几十个计算任务、同步任务，在用crontab之后，会有一些痛点，让我不得不考虑更合适的任务调度策略
我大致梳理了一下，任务调度需要满足的几个基本要素：
1. 通信便捷性：调度server端与agent执行端可以方便通信；
2. 作业配置性：所有的作业都可以方便进行配置和修改；
3. 执行控制性：可以一般情况下定时调度，也可以异常情况处理；
4. 日志展示性：每个任务执行的结果可以方便看到，不用登陆每个机器翻日志来获取结果；
5. 结果概览性：可以概览知道一共配置了多少作业，今天是否正常，是否异常；
这几个任务调度平台的要素，是我现在实际工作中一些痛点，和自己想要任务调度可以达到的目标
在对调度需求和要素进行梳理了，我和同事也进行了调研和思考，目前调研和使用的就是 opencron 任务调度程序
2 opencron特点和部署
这里首先感谢一些 opencron作者的无私分享@B e n-opencron
对于opencron，该项目的特点和解决的问题如下：
通过对这些特点进行了解后，觉得和我需要的几个方面的任务调度需求，还是比较契合的
于是和同事一起，首先在测试环境进行测试，然后在生产环境逐步进行一些测试脚本的定时调度，逐步添加个别生产任务，最后大规模添加生产任务，按照这样的思路和过程，逐步确认和使用
对于 opencron 的部署，从架构上讲，是采用的 C/S 的架构， 需要有Server端和agent端，整体开发是用Java语言， 需要JDK 1.7 以上的版本； server端的web是用 Tomcat进行支持，需要 Tomcat server 1.8 以上的版本支持
server端的 执行器信息，JOB作业信息，日志信息，用户访问控制信息，都是存储在MySQL数据库表中，所以还需要一个MySQL数据库作为后台
部署opecron系统的顺序一般是：
1. 准备MySQL数据库；
2. 确认server端的jdk和Tomcat环境，用jar包的方式，或者 执行 server.sh 的方式部署好 server端，并在浏览器进行界面登陆和确认；
3. 部署agent端，确认好agent所需的jdk环境，安装agent包，执行 startup.sh 启动agent服务，并确认agent和server之间的主机防火墙等可以开通；
4. 在server图形界面，添加agent主机作为执行器；
5. 在server图形界面，添加job作业，指定执行器，调度时间，执行脚本内容等；
6. 手工，或自动定时执行作业后，在server图形界面查看作业执行情况，日志细节等
我在一开始部署的时候，是直接拷贝同事编译好的包，到server端，然后启动Tomcat服务，就可以在浏览器里面查看了
现在作业已经把整个部署过程，简化成是三个shell脚本，内置 Tomcat等环境，下载了github相关程序后，直接执行 server.sh 就可以完成服务端的部署和启动； 直接执行 agent.sh 就可以完成 agent端的部署和启动
这样使整个opencron的安装部署过程，变得比较简便了
我现在生产环境中的 opencron界面为：
一个具体配置作业的显示为
3 opencron注意点与使用经验
opencron部署和使用后，可以对于一开始设想的任务调度要素，与opencron的实际情况进行一个对比
通信便捷性
opencron 的server端，和agent端之间的通信，不需要新创建操作系统用户，配置ssh互信， 两者之间的通信是通过 server和agent本身的socket通信来实现的，在网络可以连通的情况下，只要server端和agent端进程可以启动，状态正常，就可以相互通信，完成作业的分发和调度,通信非常便捷
作业配置性
可以看到 opencron的任务配置，最核心的是必须要指定的 执行器主机，作业时间规则，命令内容，作业的名称和备注
其他附加的还有，运行身份，失败重跑，超时时间，失败报警，流程作业设置等功能
整体上配置一个作业是比较简单的，与原本在crontab中添加一个作业需要填写的内容，没有太多区别
@朱红亮_稠州_运维 我先按照思路分享，一会分享后，我们再探讨和交流一下这个问题吧
执行控制性
执行可控性，可以从 执行前，执行中，执行后三个角度来看待
执行前，每一个作业，可以按照确定的时间，定时执行，也可以点击执行按钮手工执行，手工执行，在确认作业任务，或者异常情况需要手工执行时，非常有用
新版本opencron中，每个作业，还添加了 “禁用/启用”功能，对于一个定时任务，可以 用“禁用”将这个任务暂定调度执行，或者用 “启用”恢复任务的调度执行
这样在任务执行前，就更加可控了
执行中的作业，可以“调度记录”-“正在运行”的界面中看到，可以对任务直接执行暂定，或者关闭后重新运行
执行后的作业，主要就是 “调度记录”-“已完成”界面中，可以获取该调度任务的具体信息包括最主要的 开始时间，执行时间，是否成功，任务类型等
可以方便地获知任务执行后的各种状态结果
日志展示性
这个在前面的截图中，已经可以看到，每个任务执行的记录，可以不写入到日志文件，而是直接存储在日志表中，在作业执行后结果中显示
这样一方面不用登陆到每个机器分别查询日志文件来获取状态，直接在图形界面中看到结果内容
另一方面，对于作业执行结果，除了我自己关心，很多相关业务人员也非常关系各自的业务任务，每天的执行情况
有了这样一个日志统一收集和展示的方式，再结合 完善的权限设置，给需要的业务方开放只读账号，让他们可以根据自己的需求，查看任务配置和任务执行情况
这样就可以使 opencron不仅仅是自己使用的一个 作业调度工具，更成为各相关方进行信息共享与展示的 任务平台了
结果概览性
在图形界面中，通过对 执行器，作业，作业日志的控制，就可以清楚地知道相关的配置情况
在一开始的界面中，有仪表盘方式的显示，对成功任务，失败任务，有很清晰地展示，就可以很方便地控制和获知 整体任务执行情况
获知任务状态的效率非常高
首页下方，也还有一个监控概况，可以选择已经添加的任一一个 执行器 主机，以图形化的方式实时显示系统的 cpu，内存，进程，磁盘空间等信息
这样发起一个作业后，对于客户端主机的资源消耗情况，进行一个实时的监控，对系统状态，就可以有更好的把控了
通过对比，目前opencron的功能，与我需要的任务调度诉求，还是比较契合的，所以整体上也在线上运行了一段时间，状态比较良好
Opencron使用时的注意点
当然在使用opencron时，还有一些地方也需要注意下：
a. 部署软件包规划
由于部署opencron对Java jdk 和Tomcat都有一定要求，如果部署的系统中，已经有不同版本的jdk或Tomcat，建议不要替换整个系统中的环境版本，只需要安装一个新目录，然后在opencron中指定对应位置
这样既可以满足opencron部署需求，又可以不影响原有线上环境
b. 基础环境规划
基础环境，比如网络环境，主机资源环境等，一定要估算和确认好，避免基础环境影响任务调度
比如把opencron底层的mysql实例，server启动命令，agent启动命令，都添加到 /etc/rc.lcal 中开机自动启动，避免实例重启，agent进程不在，就无法调度任务了；
另外如果网络环境不好，也可能出现在执行器界面，显示server与agent失联的情况；
我的环境中，有时就会出现 agent由于网络条件不好，显示为失联状态，但实际所有任务都会调度成功
c. 平台权限完善
权限控制的完善, 目前opencron中只有 superadmin 和 admin两种角色，这两种角色都是读写权限，可以查看和修改作业；
但如果想给不了解调度，只需要知道结果的业务人员来说，就只能给他们分配 只读权限，这样就即可以实现信息共享，又能避免作业被随意修改的问题；
我目前采用的折中方案，是对opencron底层的MySQL数据库，开放了一个select只读用户，并提供了查看作业执行结果的sql语句，发给业务方，让他们能够通 过只读用户访问底层表，来获知作业相关信息
4 opencron与其他常见任务调度方案的引申
通过对opencron的说明和对比，可以看底层的信息
opencron底层在MySQL数据库中，创建了一个 opencron_db 库，里面建了10张MySQL表
其中改变比较多的，就是 T_AGENT 执行器信息， T_JOB 作业流程信息， T_RECORD 作业执行日志信息 这几个表
opencron底层在MySQL数据库中，创建了一个 opencron_db 库，里面建了10张MySQL表
其中改变比较多的，就是 T_AGENT 执行器信息， T_JOB 作业流程信息， T_RECORD 作业执行日志信息 这几个表
把这些主要的表再抽象一下，就可以知道满足任务调度的五个基本需求，进行对比，实际上就是 以“任务”为维度，在执行前保证好 “执行器和作业”的配置， 在执行过程中，保证“正在执行的任务”可用，在执行后可以将“作业调度的详细结果和整体结果”展示
这样，配置“执行器任务”信息，监测时间调度作业，最后图形展示作业结果，这就形成了一个闭环，也抽象出了任务调度核心三各本质点
再加上平台都需要的 权限管理，邮件发送，报警通知，界面展示等，就可以完成一个不错的任务调度平台
反过来说，把每个部分用不同的技术对待，或者细化，深化，就形成了新的任务调度体系
比如 从作业元信息获取命令和参数，用worker通讯和执行； 在调度阶段用 beat 一直监视是否到时间，调用的多个命令，不是直接发起，而是引入消息队列，实现各种不同的并行或串行； 最后的结果，用redis存储，用flower展示
通用的权限，邮件，报警，界面 这些用Django框架实现
这样就是目前 Django + celery 的任务调度实现思路
所用方法和技术不同，但任务调度的要素和本质都是相同的
当然，我所知道的，直接用python语言，Python常用和自带的各种包，来实现各个过程，成为一个任务调度平台，也是有的
5 opencron的展望和建议
最后在回到opencron本身，通过刚才的思考和讨论，从整体上看待opencron后，又对opencron的一些细节，进行了对比
从opencron这个具体的，能够很好解决问题工具，延伸出一种平台和实现思路
可以使opencron本身的功能，获得更多的完善和增进
作者把好的项目开源出来，大家通过使用，反馈，建议，再回馈给作者
这样就可以使 opencron 和社区都不断变好
甚至有人从这种框架和实现思路中，得到启发和借鉴，在有时间和精力的前提下，也不断深化和完善某个模块，产生出新的开源项目
opencron 是一个很好的，能够解决实际的问题的“鱼”，任务调度和编排是一种相对通用的“渔”，具体的实现技术和方式，可以有很多种
能够用“鱼”来解决问题，且能够从中思考“渔”，两者皆受，会收获更多！
我今天的分享就到这里了
谢谢大家！
原文地址：http://blog.51cto.com/yumushui/2060256