分布式任务调度故障教训：我决定换掉LTS的真相

背景

作为一款老牌定时任务组件，LTS(light-task-scheduler)出生于2015年（github开源时间）寿终正寝于2017年，虽然后续也有commit但已经没有实质性的开发代码了。现如今网上关于LTS的文章也大多停留在六七年前。

不过真正让我下决心替换它的原因是前段时间发现有部分定时任务异常，经过排查发现是LTS在某个目录下找一个db文件找不到，然后试着去github主页找issue和搜索相关问题，最终无功而返。所以就干脆一不做二不休，直接替换！所以本文主要是介绍怎么使用xxl-job来替代LTS。（具体选型过程忽略，根据自身项目来，合适的就是最好的）

业务分析

当时具体报错大概是这个，之前还有一个缺少db文件的错，当时没有截图。不过这个看似是json转换问题，其实是因为LTS的服务端，在机器上会有一个failstore的db。但是这个库实际不存在（具体为啥我也搞不清了，有懂的可以评论留言）。所以这个LTS运行一段时间就会挂掉，严重影响线上业务数据。

架构对比

要想实现替换为xxl-job 要先知道他们两者架构上有什么区别，知其然也要知其所以然，那么在代码上就能做到快速取舍模块。
先看下LTS架构图：

由官方架构图可知，jobclient是客户端，用于提交任务（相当于生产者）;jobtracker用于存储和派发任务；tasktracker用于执行任务（相当于消费者）

再来看下xxl-job架构图：

可以看到xxl-job只有2部分：调度中心、执行器

• 调度中心项目：xxl-job-admin
• 作用：统一管理任务调度平台上调度任务，负责触发调度执行，并且提供任务管理平台。
  通过对比可以明显看出来：xxl-job没有独立的客户端，且调度中心干了LTS的3个部分的活：任务存储、分发（jobtracker），任务执行（tasktracker），任务管理平台（lts-admin）
• 客户端（也是执行器）：是直接集成到业务项目中的

替换为xxl-job

1. 当前定时任务业务模块
   业务项目是微服务架构，查看nacos 存在2个lts相关的服务
   
   

所有任务在client发出，由tasktracker派发和执行任务。同时还有一个lts-admin后台管理。

2. xxl-job所需要的业务模块
   查阅官方文档可知，简单集成xxl-job 只需要原业务模块引入xxl-job-core即可。为了平滑过渡，我是新增加了一个微服务
   

jobs目录下直接使用@xxlJob注解即可。也就是xxl-job这个服务既是客户端又是执行器。
那么还需要部署一套调度中心（xxl-job-admin）

3. 结果对比

在部署完后，也清晰知道在部署xxl-job会比LTS简单，少了1个模块。
也就是把原job-client里的任务移植到业务模块（xxl-job的执行器）中，把原jobtracker、tasktracker、lts-admin三者合并到了xxl-job的调度中心。最后，就可以放心的把原lts服务全部下线，到此改造完毕。