xxlJob2.0版本研究
1 说明
描述本组件的设计意图，使用场景等。
对应的需求文档链接（如果有），对应的概要设计文档链接（如果有），
设计意图：XXL-JOB是一个轻量级分布式任务调度平台，主要用于项目中的定时任务设置，例如运力服务中定时同步车辆信息、同步司机信息。
项目中具体的使用场景：参考文档 20.xxl-job
2 组件设计
2.1 架构设计图
xxl-job2.0的架构图，包含的组件如图所示：
XXL-JOBv2.0.0 架构图
2.0版本较之前版本差异如下：
1、调度中心迁移到 springboot ；
2、底层通讯组件迁移至 xxl-rpc ；
3、容器化：提供官方 docker 镜像，并实时更新推送 dockerhub （ docker pull xuxueli/xxl-job-admin ），进一步实现产品开箱即用；
4、新增无框架执行器 Sample 示例项目 “xxl-job-executor-sample-frameless”。不依赖第三方框架，只需 main 方法即可启动运行执行器；
5、命令行任务：原生提供通用命令行任务 Handler （ Bean 任务，“CommandJobHandler”）；业务方只需要提供命令行即可；
6、任务状态优化，仅运行状态"NORMAL"任务关联至 quartz，降低 quartz 底层数据存储与调度压力；
7、任务状态规范：新增任务默认停止状态，任务更新时保持任务状态不变；
8、IP 获取逻辑优化，优先遍历网卡来获取可用 IP ；
9、任务新增的 API 服务接口返回任务 ID，方便调用方实用；
10、组件化优化，移除对 spring 的依赖：非 spring 应用选用 “XxlJobExecutor” 、spring 应用选用 “XxlJobSpringExecutor” 作为执行器组件；
11、任务 RollingLog 展示逻辑优化，修复超时任务无法查看的问题；
12、多项 UI 组件升级到最新版本，如：CodeMirror、Echarts、Jquery 等；
13、项目依赖升级 groovy 至较新稳定版本； pom 清理；
14、子任务失败重试重试逻辑优化，子任务失败时将会按照其预设的失败重试次数主动进行重试
2.2 实现方式
1、采用了代理的设计模式。
2、根据实现IJobHandler接口的类，进行扫描，并执行其中的方法。
2.3 使用问题
在项目中具体如何使用xxl_job，请参考文档：18、xxl-job定时任务配置说明
2.4 版本升级问题
2.4.1 直接升级
修改build.gradle里版本，然后运行：
会报错：
类型转换错误
还有一些其他错误：
应该是框架自身组件升级带来的不兼容的问题。
看来直接修改升级走不通。
2.4.2 实验新的升级方法
a、从源码着手。
下载源码：https://github.com/xuxueli/xxl-job/releases
b、源码目录解读
c、将项目源码导入到IDEA进行运行
其前端页面采用的是传统js、css和freemarker页面模板：
d、项目运行前准备工作
1、本地数据库新建xxl-job数据库，并且执行doc文档下的tables_xxl_job.sql脚本文件
执行后生成的表：
如果没有相应的数据库和表，项目无法启动。
2、修改项目的application.properties文件，主要是数据库对应的名称、用户名和密码，由于数据库版本问题，可以增加useSSL=false避免SSL检查
c、启动项目
启动成功界面，典型的springboot项目启动模式：
d、进入后台主界面
根据application.properties文件，可知项目的端口号是8080，项目路径是/xxl-job-admin，又可以根据IndexController，得知主页的路径，所以在浏览器输入localhost:8080/xxl-job-admin/便进入了主页
e、登陆到系统
根据application.properties文件，可知默认登录名和密码分别是admin和123456，点击登录进入系统：
主页面和之前版本主页面差距并不大
f、新增执行器
点击执行器管理，新增一个执行器：
可以参照之前的操作文档（18、xxl-job定时任务配置说明），新建一个job测试执行器：
g、新建任务
点击任务管理，选择刚刚新建的执行器，在此执行器下新建任务
任务配置：
h、定时任务项目里配置的修改
修改build.gradle里xxl-job-core版本为2.0.0
在application.properties文件里，修改xxl.job.admin.addresses为当前xxl-job后台管理系统路径地址
i、启动当前项目
现在项目启动没有报错啦！
j、执行一次定时任务
定时任务的位置：
服务注册成功：
在管理页面点击一次执行：
查看日志，发现失败：
h、解决方法：
断点调试：
执行器组信息：
任务信息：
触发器参数：
连接正常：
真正的方法执行器：
报错的地方：
说明是rpc调用出现了问题，应该是本地服务的问题：
对照项目例子和报错信息来看，项目缺少Jetty相关的依赖，这也是XXL-JOB改动比较大的地方：
添加项目依赖：
重启项目，执行任务运行：
发现报错信息变了：
找不到需要执行的服务了
要回到项目里去查看，应该是具体的任务没有注册到xxl-job管理中。
通过运行例子发现，项目中要添加初始化配置才能把配置文件里的基本配置信息注入到注册管理中心里。
那么在本项目里增加xxlConfig配置，配置需要初始化的配置项：
重启项目，再次执行一次项目，终于运行成功。
任务执行成功！
至此，xxl-job 2.0.0版本的配置和运行整个流程到此结束，跟之前版本相比改动幅度较大，需要谨慎升级！
2.4.3集成到envconfig
原来envconfig中xxl-job配置类中主要内容为：
由于新的xxl-job迁移到了envconfig中，可以在envconfig中将此处变更为：
实际上执行器XxlJobSpringExecutor是继承于原来的XxlJobExecutor，对原执行器的扩展：
如果这样改的话，可以不用在每个项目里建立config配置类。
具体实验方法如下：
a、修改evnconfig工程：
pom文件修改xxl-job-core为2.0.0版本
envconfig临时改为1.3.26版本
增加XxlJobAutoConfiguration类，并添加@ConditionalOnClass和@ConditionalOnMissingBean注解，这样会在项目启动时自动扫描注入配置类
同时在META-INF目录下的spring.factories里添加一个新的自动配置类的绝对路径（根据springboot原理分析），这个文件的主要作用是提供启动配置类的路径，方便进行扫描，从@SpringBootApplication->
@EnableAutoConfiguration->AutoConfigurationImportSelector.class->selectImports方法里的getCandidateConfigurations方法->SpringFactoriesLoader类的loadFactoryNames
->loadSpringFactories方法
实际上就是加载这个文件里的自动配置：
最后打包项目生成新的jar包
打包成功：
b、修改项目：
把生成的包放到gradle管理的jar包下
修改envconfig包：
启动项目：
xxl配置项配置成功：
项目启动成功：
执行任务：
执行成功：
2.4.4 新旧版本数据库对比
根据比对1.9.2和2.0.0版本，发现表结构并没有变化。
2.4.5其他考虑
升级的的话，后端修改幅度并不大，数据库也不用修改，前端直接用新的代码部署即可，详情过程请参考文档。