Saturn Amazing Feature Description
As you know Saturn is originated from Dangdang's elastic job. But we enhance it according to our requirement and understandings. Here is the list to show their difference to help you how to make your decision between them. For the feature map, please refer to Feature Map
首先，我们使用Elastic Job的时间节点比较早，Elastic Job那时还在密集开发中。
其次，是我们唯品会内部对于任务调度的需求和当当有不少差异的地方，如我们需要支持秒级调度，需要支持消息调度，需要本地类型作业等等，更重要的是我们需要兼容原有的的PHP的CRON TABLE模式的作业，这个正是当时Elastic Job不支持的地方。
再者，我们的运维管理模式与当当还是有许多不同之处，这个对于我们系统的功能设计也带来了影响。如我们的物理机体系的单进程管理模式，如何能高效的利用资源和增强作业的容错性等方面这些都是我们需要重点考虑的地方。当时Elastic Job难以在短时间内在开源版本提供给我们。
所以以Elastic Job做为Saturn的Code base成为了我们的选择。当然这中间Elastic Job的开发者们给了我们很大的帮助和支持，在此一并感谢！
控制台的功能变更和功能增强主要的指导思想是符合我们自己的运维管理思路为主。因为从运维管理的角度看，以往我们PHP的CRON TABLE的方式管理作业遇到了很多的问题和瓶颈例如：作业被分散在不同的机器上，没有一个很好的维度做统一的管理和监控，特别是PHP的作业容易发生僵死无运维无法知道等等。
所以在考虑Console的时候，我们是希望做到统一的配置即在中央管理上做一次配置，就可以让多个作业运行；统一管理即可以在中央管理上控制作业的启用、禁止等等无需登录对应的机器操作；统一监控即可以提供不同维度的视图为管理做出指引。
作业运行时的监控管理对于运维而言是很重要的，如何帮助运维能一眼看到图标就能判断出作业是否有问题，或者存在风险尤为重要。所以我们为执行节点(Executor)和作业提供了Dashboard视图。
- Executor Dashboard: 展示一个命名空间下online和offline的executor的数量，并展示每个executor的运行作业负荷情况已经作业分片列表。运维人员可以通过该试图立即判断出是否有executor下线，是否某个executor负荷过重造成风险等等。
- Executor List: 重点增加了Executor版本的监控，以及启动时间的监控。例如从启动时间可以看出Executor是否被重启了、是否用错了版本等。
- Job Dashboard: 展示一个命名空间下不同状态的作业数(ready, running, stopped, stopping)，以及每个作业的成功率。运维人员可以快速定位错误率高的作业。
- Job List: 重点增加了作业的启动时间以及下次启动的预估，同时展示了对应的分片落在那台机器上等。
作业管理出了做基本的配置之外，我们还提供了更多的丰富的管理功能，帮助业务快速上线以及日常管理，包括：
- 作业批量查询
- 作业批量导入、导出(这个帮助开发人员在测试环境下将测试好的数据导入到生产环境中，避免再次配置的人为失误)
- 作业暂停时间设置(这个对于非核心作业任务，可以设置在大促期间不运行，让出资源给别的系统)
- 作业动态增加作业以及删除作业(无需更新Executor以及停止Executor运行才能操作)
- 优先节点配置 (可以将作业人为安排在某个节点运行，如已经被授权过的连接银行的系统等，只有在全部优先节点都offline后才漂移到其它执行节点)
- 只使用优先节点 (如果选择这个选项，则全部优先节点都offline也不会漂移，尽管还有其它的可用节点)
- 超时配置 (作业如果运行操作指定时间会被kill掉，避免僵死)
- 本地模式作业配置 (作业没有分片，只要有Executor就会跑，类似一个机器一个分片，同时无需failover，这样机器伸缩对于作业无影响，无需重新配置)
- 立即执行一次(手动方式触发作业，可以快速验证刚上线的但是调度周期还未到的作业)
- 负荷配置 (逻辑设置作业的分片的相对负荷，调度器可以自动根据这个配置将作业分配到何时的Executor)
- 自定义参数 (针对每个分片，可以将配置的自定义参数传给对应的分配处理逻辑。如数据分库，每一个分片处理一个库，则自定义参数可以为对应的数据库链接配置)
资源平衡的目标是将作业尽可能平均到不同的执行节点上，避免某个执行节点负荷过重造城影响。使用这个功能的前提是需要合理的配置作业对应的相对负荷值，然后调度算法会根据执行节点的总负荷情况，动态的均衡分配作业的分片到不同的执行节点上。
目前Saturn是重度使用Zookeeper，如果作业数量多的时候，一套zookeeper集群性能是无法满足。所以需要通过支持多套zookeeper集群分散作业以达到支持更多作业的目的
为了支持多语言的异构体系，我们提供除java作业的基础上增加了shell作业的支持。主要可以支持类似PHP, Python等脚本作业
- Java作业(通过实现Saturn的接口来完成业务的开发，作业和执行节点在同一个进程的不同ClassLoader)
- Shell作业(直接通过系统调用的方式启动进程外的Shell脚本)
在日常的作业管理中，我们会遇到这样的场景，我们希望作业能在每一台机器运行，如果机器offline后，在该机器的作业无需漂移到别的机器去。例如需要每天清理机器的垃圾日志文件等。这种模式就是我们的“本地作业模式”，同时该模式也比较合适配合容器的自动伸缩
- 分布式模式(由sharding算法将作业分片调度到不同的执行节点运行)
- 本地作业模式(没有分片的概念，每个执行节点都会运行，除非指定优先执行节点)
- 失效转移（在执行节点以外断开，在该节点运行的作业将被转移到正常的执行节点上运行）
- 超时控制 (根据配置的时间，如果作业运行超过这个配置时间，对应的执行会被中断)
- 结果反馈 (作业的结果会定期上报到zookeeper，便于统计成功率等信息)
通过不同的ClassLoader，框架和业务代码是完全隔离的，不会引起包冲突，同时也有利于框架的升级，而无需去重新编译业务代码。同时支持与tomcat等集成，框架以嵌入式的方式运行。并且提供相关的回调函数，协助业务开发处理超时前、超时后的处理。
Saturn是通过与Mesos+Marathon的rest-api集成，提供执行节点的伸缩性支持。对应的执行节点的容器是长周期运行的即如果不是伸缩，容器是不会在作业处理完成后被销毁的。这样的设计的目的是确保作业在启动成功后，会有固定的资源运行，而不会因为资源释放后再次启动因资源不足造成作业无法运行的问题。毕竟目前我们的场景有不少作业是核心业务的。
- 网络无关性(支持VLAN, NAT等网络模式)
- 资源动态迁移 (支持在Executor升级时，动态迁移作业使用的容器资源，避免作业终端)
- 容器资源使用情况查询
- 容器伸缩
- 直接创建容器资源
注意： ＊表示还未开发
