从本篇开始，我将尝试一种新的写作方式，边进行项目开发边进行博客记录，通过这种方式，更加细致的带领读者体验一个框架从想法到实现的完整过程。

这次我将要实现的手写框架为：“shield-job”分布式任务调度框架，整个时间周期可能会持续一到数个月，不怂，就是干。

什么是分布式任务调度框架

首先，简单介绍下什么是分布式任务调度框架。

任务调度是指: 基于给定的时间点，在一定时间间隔或者给定执行次数自动执行的任务。

WEB服务器接受请求时，会创建一个新的线程服务。但是由于资源有限，必须对资源进行控制，首先就是限制服务线程的最大数目，其次考虑以线程池共享服务的线程资源，降低频繁创建、销毁线程的消耗；然后任务调度信息的存储包括运行次数、调度规则以及运行数据等。这些就是一个任务调度框架要考虑的问题点。

主流的分布式任务调度框架简介

接着我们简单介绍下市面上主流的分布式任务框架。

常见的分布式任务调度框架有：Quartz、Elastic-job、TBSchedule、xxl-job、spring-schedule等。

其中，Quartz是传统项目中使用较为广泛的一个调度框架，可以与J2EE与J2SE应用程序相结合也可以单独使用。Quartz可以用来创建简单或为运行十个，百个，甚至是好几万个Jobs这样复杂的程序。

Elastic-job是当当官方出品的一款云环境下的大规模、高并发、分布式的调度框架，功能强大。

TBSchedule是淘系的调度框架，据官方说法，TBSchedule的使命就是将调度作业从业务系统中分离出来，降低或者是消除和业务系统的耦合度，进行高效异步任务处理。被应用于阿里巴巴、淘宝、支付宝、京东、聚美、汽车之家、国美等很多互联网企业的流程调度系统。

xxl-job是github上很火的一个个人发起的轻量级调度框架，经过今日头条内部大规模实践证明是一款稳定高效的调度产品。其核心设计目标是开发迅速、学习简单、轻量级、易扩展。现已开放源代码并接入多家公司线上产品线，开箱即用。

至于spring-schedule就不需要多解释了，相信很多读者都在项目中使用过，它的特点就是轻量级，注解支持，基本没有上手门槛。

为什么要写自己的调度框架

又是一个老生常谈的问题，它的核心其实还是是否要造轮子的问题。

对我而言，写自己的轮子，或者说实现已经有的轮子并不是要搞一个很牛逼的框架然后替换已有的实现，这个就目前而言我也做不到，哈哈。其实出发点还是通过自己实现一个具体的框架，体会其中的实现细节和理解对应的设计思路，从而更好的理解市面上已有的成熟框架，在生产中使用的更加得心应手。

而且这个过程中，对个人的编码能力也一定是有显著的提升意义。

需求描述

我们要实现的分布式调度框架定位是：轻量级、易开发、学习成本低。

具体的工作流程如下：

通过任务管理中心发布任务，并能够绑定任务到已注册的任务调度器。任务调度器根据对应任务的调度策略对任务进行执行，并能够及时的反馈任务调度和执行的结果。

具体的交互流程如下：

1. 任务管理后台对任务进行定义、发布及管理
2. 当任务发布之后，在任务后台对任务进行主动的推送操作，任务信息发往MQ中间件
3. 任务注册中心同步最新的任务列表，并对任务调度器进行注册管理
4. 当调度器启动后，会主动向任务注册中心注册自身，在管理后台能够查看到调度器的详细信息
5. 后台定义好一个任务后，可以绑定给某个调度器，调度器之间又可以依据业务成为一个调度器组
6. 调度器绑定任务之后，能够按照自己的逻辑执行业务操作，也可以绑定到某个topic对该topic指定的任务进行调度工作，基于当前的这条，我们能够扩展出很多的业务实现，比如：配置更新、邮件发送等等
7. 当任务调度的时候，会对任务状态进行相应的变更操作，该操作通过消息触发，最终均由管理后台进行状态的统一管理。每一次的状态变更都会通知给任务注册中心。
8. 所有的业务模块在调度的时候均是从注册中心获取到任务的详细信息，这里是想对任务的元数据做读写分离，读操作均走注册中心，写操作均走任务管理后台
9. 之所以引入MQ，是为了避免频繁的拉取导致服务端、数据库压力过大。引入MQ之后，只有任务元数据发生变更才会通知任务后台进行更新，系统稳定性更高。

小结

本文主要对任务调度中心做了简单的介绍，并提出了shield-job调度框架要实现的需求，并对交互流程做了解释。下一篇，我们将详细的讲解各个模块的任务划分和工程的结构。