中心化-去中心化调度设计

在综合解读xxl-job和elastic-Job的源码，记录一下自己的一些体会。

中心化/去中心化.jpg

xxl-job是中心化设计，在xxl-job中，所有定时任务的执行是在调度中心执行，调度中心判断作业到了执行的时间，然后通知业务系统去执行，也就是说，作业与业务系统没有直接关系，相当于业务系统接收到调度中心请求，然后处理自己的业务。

中心化例子.jpg

中心化设计举例，假如我们开发一个系统(xx宝项目)，这个项目有一个系统owner，这个系统owner负责好几个项目，xx宝项目只是其中一个，在xx宝项目中，又有三个开发，开发A，开发B，开发C负责开发任务，当有需求要开发的时候，开发ABC三个人是不会知道自己要做什么的,这个时候，真正知道需求的人是系统owner，系统owner接收到需求，会告诉开发ABC其中一个，让开发ABC某一个人去做，开发ABC分别负责一个需求，然后分别去做自己的功能，开发ABC之间是不知道自己要做什么的，需求任务的拆分是由系统owner去统一管理的。开发ABC三个人，每个人能力是不一样的，有的人能力强，做事快，接收到需求能够很快做完，有的能力差一点，做事慢，当有任务要求高，或者任务量比较大的时候，交给一个开发（假设开发A）去做这件事情，可能会花更多的时间去处理这件事情，在这个时候，其他开发(开发B，开发C)一直出于没事做的状态，这个时候，系统owner会想，要不要把这个任务分成多份，三个开发分别负责一部分，能力强的多分几份任务。

xxl-job架构图.jpg

将这个例子的系统owner改为调度中心，将三个开发看作是三个执行器。
首先，系统开发、运维会在调度中心配置调度任务（架构师告诉系统owner要做哪些需求），业务系统在启动的时候，会通过注册线程往注册中心注册，这个时候，调度中心就会知道执行器要监听哪几个任务，（新增了一个开发，首先向系统owner报道，系统owner下次分配开发需求就会告诉开发），然后调度中心在作业到时间该执行的时候，通过RPC或者http请求通知其中一个业务系统去执行job任务（系统owner会告诉某个开发做哪个需求）,等作业执行完成之后，会将任务完成状态和任务日志通过http请求或者是rpc方式回传给调度中心（开发将需求开发完成，会告诉系统owner完成情况和文档产出交付给系统owner）。当调度系统发现任务过多时，会将一个任务分成好几份任务，然后通知多个执行器各自执行一部分，也就是任务分片功能（系统owner将一个大任务拆分为几个小任务），然后各自执行一部分任务（多个开发完成一个需求任务的一部分）。

去中心化设计举例.jpg

去中心化举例，还是开发XX宝项目，这个时候没有系统owner了，这个时候，有一个需求到了，三个开发ABC都知道这个需求任务，那么谁来做？？
开发A说：我刚来，不适合。
开发B说：以前都是我做的，要不开发C来。
开发C说：这个活我没做过，你们两来。
这个时候，尴尬了，没人干活了。怎么办呢，大家都不干活。
领导一看，不行啊，没人干活了，三个人得选一个临时领导，来负责分配一下以后的需求任务，活要人干啊。然后就将开发ABC三个人召集在一起，说，这个活要有人干，你们三个选一个临时负责人吧，负责分一下任务。
然后三个开发一合计，要不猜拳定临时负责人，然后分配任务。

再然后，三个开发就选了一个临时负责人（开发X）来分配工作。
开发X然后说，就一个需求需求来吧，第一个任务A来做，第二个任务B来做，第三个任务C来做，以此类推。
就这样做了两个月，没矛盾，这个时候，突然来了一个大的需求，一个人开发需要很久，然后临时负责人(开发X)会根据任务的大小，分配给这几个开发，然后分配做这件事情。

elasticJob设计.jpg

看elasticJob架构设计图中，在elastic-job-Lite中，作业随着业务系统的启动而启动，在启动的时候，首先会往注册中心zookeeper注册作业（有点像入职员工需要入职报道一样），在作业要执行的时候，各自执行（APP1，app2）都开始执行，发现一个任务两个app不知道哪个系统执行（几个开发不知道哪一个做这个任务），会选举出一个主节点，（几个开发选一个负责人），主节点负责分配任务，将任务分片（开发负责人会将需求任务分解），在主节点分配任务的时候，其他从节点等待(在开发负责人负责拆解任务的时候，其他开发等着分配工作给自己)，等到主节点任务分配完成，各节点（app1，app2）各自执行自己的作业，然后执行结束之后，判断有没有其他失败的作业需要执行（其他开发任务不会做），如果有，则将失败的作业再执行一次，没有结束（有没有其他开发需要帮忙的，有的话就帮忙，没有就结束），然后将作业的执行日志写到文件里，将作业的执行状态记录推送Event事件推送出去。
fyi