大家好~ 我是 花椒直播 周洋，上次火丁笔记投稿了《花椒总线系统》后，发现阅读量较大，但点赞(看一看)数很少。受到了公众号攻略组的调侃。要求 改善或解释 点赞量过低的原因。
针对这个需求，我决定在技术文章后增加一个互联网圈的时事讨论环节。所以大家对我的内容不感兴趣的，可以直接跳转到话题讨论环节。并且如果大家 不认可 我的话题观点，可以通过 点赞 的方式辅助我做运营统计。对，是不认可才点赞
- 《Distributed Periodic Scheduling with Cron》
- 《Reliable Cron across the Planet》
- 定时任务的高可用策略，包括对任务本身容错性等级，是否满足幂等性，执行状态的监控，以及任务所在服务器down机情况下的处理
- 大规模cron管理的部署问题，包括可靠的调度系统保障cron的执行和失败处理能够跨主机的迁移，对于失败任务进行补偿执行等。
- cron job迁移过程中，如果保障中间结果数据和状态数据的迁移，如何管理或保障迁移后，新服务器也具备原有cron进程具备所有依赖的环境.
- cron job的隔离性，以及cron job的按硬件资源的分配和调度问题。运行间隔短暂的job，在调度过程中保障实时性和按时执行的准确性问题。
- cron的状态存储，并没有选用gfs和hdfs，而是作为这套cron分布式系统子服务的一部分，原因是这套系统的高可用级别需要尽可能减少外部服务的依赖，另外高频与小文件的读写需求，使用gfs和hdfs并不合适。
- 使用Fast Paxos算法，来设计保障高可用系统，去中心化，保障大部分节点正常情况下，整个系统可以稳定运行。
- 主要单元结构如下，选用了Fast Paxos，有主从节点的概念，所有节点都保存了任务的分配和调度信息，但只有主节点作为cron服务的任务执行进程，主节点当机，重新组内选举，新的主节点由于保存了和同步了之前主节点所有的状态信息，可以接管之前这个单元的任务执行。整个执行单元通过rpc与任务调度中心进行通信。
- 主节点视角的任务执行过程如下，执行的起始和结束都通过paxos协议同步通知同组的其他节点，并且只有leader可以与调度中心通信。
- 主节点down机，从节点接管任务的执行，对于执行一半的任务，会有复杂的配置策略，通过与数据调度中心进行联动进行决策。临界情况的处理复杂，对外依赖的任务，尽量要满足幂等性设计，否则需要在risking a double launch and risking skipping a launch中间进行权衡。另外对于任务的执行，整个系统还设计了很多策略，比如防止群振效应。(业务线每天凌晨开始执行任务瞬时全部启动，影响集群可用性)
-
google的论文实现侧重于全球数据中心的高可用，但对于我们一般性的创业公司来讲，高可用是重要的点，但场景和规模并没有那么复杂，所以是可以用简化方案实现的。这一部分，花椒直播的系统团队也做了多次权衡和考量。其中一种方案也考虑google的实现，但只是将fast paxos换成开源库中更成熟的raft方案，其他类似。但即使是使用raft，整个系统的完备性测试也是一个非常复杂的问题，这个项目本身也是与pepperbus并行的，开发资源有限。经过多次考量，我们决定，再降低一次难度，直接使用etcd进行状态的存储和主从节点的选举。这样整体又降低了一个难度。系统的调试和测试也可以通过访问etcd的日志和etcd本身提供的版本数据，进行追溯和排查。
-
如果使用了etcd来保存状态，实际上也并不需要原论文中的主从概念了，所有节点都能拿到etcd中的数据和执行的状态，只是根据节点的角色和预先的配置进行sharding，执行不同的job即可。etcd选举的leader节点就是原论文中的 Datacenter scheduler的角色，只有这个leader节点进行job的存储，分配，管理，迁移工作。其他节点只是按照拿到的配置进行周期性的cron任务。当任何一个子节点down机，leader节点拿到信息后，将这个节点的数据再转移给其他节点即可。当leader节点down机，其他节点进行选举选出新的leader节点，然后获取原有leader存储的信息，重新进行任务分配工作。
-
另外需求上，根据推荐系统团队的一些常见需求进行了重新梳理，丰富了一些新的功能。
- Cron任务的规范与管理
- Cron任务结果可视化与执行状态监控，报警
- 父子任务，互斥任务，任务并发度控制，简单的任务编排
- 支持秒级别Cron任务，支持永久循环执行任务
- 未来会对容器化场景的任务集成与监控，提供同样友好的支持
-
整个系统的结构图如下:
-
根据需求定制的可视化后台,实时展示任务列表和执行情况
-
展示每个cron执行节点的任务与执行状态
-
任务创建过程，有三种类型 其中cron类型就是常规的cron语法配置
-
任务执行状况的在线日志查看
- 看了一些文章，基本上大厂的中台，主要是解决技术复用，基础资源复用，技术经验复制，技术认知同步和技术迭代的同步。操作上又分成业务中台，服务总台，架构中台等其他概念，为了不同的目的，做技术团队集中化或者虚拟的集中化策略。这是大厂节省资源的一个刚需，你可以理解一个又有事业群，又有事业部，又有项目部等网状，树状的大厂，技术上百花齐放，从高层看起来一定是让人很焦虑的，从底层看，可能更像是神仙打架。
- 对于早期初创可能不需要考虑这个问题，当具备一定规模后，还是要有中台这个概念。可能是EP，系统开发团队来承担的横向串联的角色。其目的是提升整个团队效率为基础，以技术能力输出，统一服务输出，技术创新与培训，等不同维度的工作进行推进，打破小团队的技术封闭，转化和扩大小团队内部受影响力限制的最佳实践。
- 创业公司的中台相比较大公司，还是有很多政策优势的。大公司虽然有智力优势，但技术的标准化意味着自由度被控制在一定范围内，比如语言技术栈就是一个限制。因此敢于大范围的尝试对接和转化新技术能力，并且能快速推进整体集团的改变和认知同步，我是持怀疑的。当然类似RN，weex，flutter这种级别创新往往孕育在大厂中，但如何选择，我觉得一定是没有具备中台技术积累的创业公司选择的自由度大。
- 对于创业公司来说，甚至可以有集成客户端，服务端一起的中台，提供统一的可以复制的能力，这在大厂项目中可以实现，但不可能像创业公司那样，一个集中技术中台可以迅速影响整个公司。尤其创业公司在缺少技术人才情况下，如果集中力量办大事，确实是一个值得思考的问题。
- 当然一个没有中台概念或者类似效能组织的创业公司也可能是运行良好的。但从逻辑推理上来看，他一定需要更多的人，买更多的技术，然后团队不停的分裂下去。如果业务蒸蒸日上，也并不需要感知这些问题。但如果业务发展不顺利崩盘那一天，他是什么也剩不下的，即使二次创业，技术上也是从零开始。
- 对于每个开发者来讲，创业结束后你还剩下什么，我觉得如果不是财务自由，那中台的代码库希望能让你略感欣慰一些~