自2019年6月30日起，分布式任务调度SchedulerX 1.0（DTS）不再提供运维服务，提供服务的ECS实例也会裁撤，待所有用户下线后会完全下线，后续任务调度服务将由SchedulerX 2.0提供。本文介绍如何从SchedulerX 1.0迁移到SchedulerX 2.0。

迁移说明

  1. 在EDAS 组件概览页面开通分布式任务调度2.0。
  2. 进入分布式任务调度 2.0 应用管理页面，创建分组，groupId要和分布式任务管理1.0保持一致。
  3. 使用迁移工具进行迁移。
  4. 升级JAR包，重新发布应用。
  5. 在EDAS控制台通过分布式任务调度2.0验证接入成功。

注释事项

  • 目前只支持1000个任务以内的单个分组迁移到2.0，如果单分组任务数超过1000，请联系SchedulerX支持人员。
  • 一次性任务（指定具体某时某分执行的任务，工具会判断并打印出jobId）不支持迁移，有特殊需求的联系SchedulerX支持人员。
  • 原有报警不会迁移，如果任务有报警需求的需要手动订正。
  • 所有的秒级任务（如0/10 * * * * ?）迁移到2.0会变为second_delay任务，同时delay时间为10秒。
  • 同一个分组多次执行迁移一定要在同一台机器上执行，否则服务端会重复新增，所有成功迁移任务ID存储在客户端执行机器上。
  • 2.0部分地域（Region）不支持经典网络的机器。

升级JAR包的方案

分布式任务调度SchedulerX 从1.0迁移到2.0有重建和兼容两种方案。

方案一：重建（推荐）

使用迁移工具把SchedulerX 1.0的Job全量导入到2.0，然后使用SchedulerX 2.0的官方正式包（不兼容1.0的接口）修改代码。

  • 优势：

    • 使用2.0的接口和编程模型，可以享受到2.0的功能，例如可以直接在前端看到运行日志。
    • 2.0会不断迭代，每次升级都会增加新的功能并进行bug fix。（兼容版本客户端只会发布一个版本，后续不再更新）。
    • 因为2.0的接口和1.0完全不一样，不会导致冲突，可以同时使用，然后逐渐下线1.0，保证系统稳定。

  • 不足：

    需要修改代码，虽然改动比较小（主要是初始化的类，以及继承的processor接口），但是如果Job特别多，改动也会比较大。

方案二：兼容

使用迁移工具把SchedulerX 1.0的Job全量导入到2.0，然后使用SchedulerX 2.0的定制兼容包（schedulerx-worker-1.0.6-compatible），不需要修改代码。

  • 优势：

    不需要修改任何配置和代码。

  • 不足：

    • 后续无法升级，定制兼容包只会发布1.0.6-compatible这一个版本。
    • 因为兼容了1.0的接口，工程需要移除1.0的JAR包，完全用2.0替代，不能同时使用1.0和2.0。
    • 无法使用2.0新功能。如果想使用新功能，建议使用重建方案迁移。

前提条件

  1. 创建任务分组。
    1. 登录 EDAS 控制台EDAS 控制台，在页面左上角选择所需地域。
    2. 在分布式任务调度 2.0 应用管理页面选择迁移的目的地域和命名空间。
      任务管理
    3. 在创建应用分组对话框输入应用名和Group ID，然后单击确定。
      创建应用分组

      Group ID会因两种迁移方案而不同。

      • 如果使用重建方案，可以根据业务自定义Group ID，如xxx.defaultGroup。
      • 如果使用兼容方案，Group ID需要和要迁移的1.0的Group ID保持一致，这样不用修改任何配置和代码。Group ID可以在Scheduler 1.0 分组管理页面查看。
    4. 创建完成后，返回应用管理页面查看任务分组是否成功。
  2. 下载迁移工具（JAR 包），通过命令行进入迁移工具所在目录，并执行java -jar schedulerx-migrate-1.0.20190729.jar命令。

阿里云1.0非测试环境迁移到阿里云2.0非测试环境

在迁移工具的命令行交互页面根据提示完成迁移。

  1. 输入迁移类型（请输入 2）。
  2. 输入分布式任务系统1.0需要迁移分组ID。
    分组ID可以在Scheduler 1.0 分组管理页面查看。分组管理（1.0）
  3. 输入分布式任务系统1.0迁移分组所在的regionId（包含对应namespace的key）。

    在控制台进入分布式任务管理（SchedulerX 1.0）的分组管理页面，选择要迁移的分组所在的地域和命名空间，在URL中获取reginoNo的值（namespace的key即URL中的regionNo）。

    • 如果在默认命名空间中创建任务分组，regionNo中只有Region，没有Namespace，如cn-hangzhou。

      创建分组（只包含 Region）

    • 如果在非默认命名空间中的任务分组，regionNo会包含Region和Namespace，如cn-hangzhou:aaa。

      创建分组（包含 Namespace 和 Region）
  4. 输入分布式任务系统1.0迁移分组所在的命名空间的tid。

    迁移分组所在的命名空间的tid。可以在EDAS 控制台的命名空间页面获取。

    命名空间（1.0）
  5. 输入分布式任务系统1.0迁移分组所属主账号的ID。

    需要填写能够看到该1.0任务分组的主账号ID。可以在账号管理控制台的安全设置页面中获取。

    账号管理
  6. 输入迁入到分布式系统2.0分组的Group_ID。

    填写在使用创建应用设置的Group ID。

    说明 如果是兼容迁移，2.0中的Group ID要和1.0中的Group ID一致。
  7. 输入迁入到分布式系统2.0分组的主账号ak和SK。

    填写在SchedulerX 2.0中创建任务分组或有该分组操作权限的云账号的AccessKey ID和Access Key Secret。

  8. 输入迁入到分布式系统2.0分组对应的命名空间tid。
    如果SchedulerX 2.0和1.0的命名空间的tid相同，可以不填，直接单击回车跳过。
  9. 设置完成，单击回车，开始执行迁移。

阿里云1.0测试环境迁移到阿里云2.0测试环境

在迁移工具的命令行交互页面根据提示完成迁移。

  1. 输入迁移类型（请输入 3）。
  2. 输入分布式任务系统 1.0 需要迁移分组 ID。
    分组 ID 可以在Scheduler 1.0 分组管理页面查看。分组管理（1.0）
  3. 输入分布式任务系统 1.0 迁移分组所属主账号的 ID。

    需要填写能够看到该 1.0 任务分组的主账号 ID。可以在账号管理控制台的安全设置页面中获取。

    账号管理
  4. 输入要迁入到分布式系统2.0的regionName（测试（华东1））。
  5. 输入迁入到分布式系统2.0分组的Group_ID。

    填写在使用创建应用设置的Group ID。

    说明 如果是兼容迁移，2.0中的Group ID要和1.0中的Group ID一致。
  6. 请输入要迁入SchedulerX 2.0对应分组appkey。
    输入上一步中应用管理列表里面Group_ID对应的appkey。应用管理（2.0）
  7. 输入迁入到分布式系统2.0分组对应的命名空间tid。
    在命名空间页面查看对应的列表。输入测试的命名空间ID。命名空间（2.0）
  8. 设置完成，单击回车，开始执行迁移。

阿里云1.0测试环境迁移到阿里云2.0其它正式环境

在迁移工具的命令行交互页面根据提示完成迁移。

  1. 输入迁移类型（请输入 3）。
  2. 输入分布式任务系统 1.0 需要迁移分组 ID。
    分组 ID 可以在Scheduler 1.0 分组管理页面查看。分组管理（1.0）
  3. 输入分布式任务系统 1.0 迁移分组所属主账号的 ID。

    需要填写能够看到该 1.0 任务分组的主账号 ID。可以在账号管理控制台的安全设置页面中获取。

    账号管理
  4. 输入要迁入到分布式系统2.0的regionName。

    在SchedulerX 2.0选择您要迁入的地域名称。直接复制区域名称即可。

    应用管理（2.0）
  5. 输入迁入到分布式系统2.0分组的Group_ID。

    填写在使用创建应用设置的Group ID。

    说明 如果是兼容迁移，2.0中的Group ID要和1.0中的Group ID一致。
  6. 输入迁入到分布式系统 2.0 分组的主账号 ak 和 SK。

    填写在 SchedulerX 2.0 中创建任务分组或有该分组操作权限的云账号的 AccessKey ID 和 Access Key Secret。

  7. 输入迁入到分布式系统 2.0 分组对应的命名空间 tid。
    在命名空间页面查看对应的列表。输入测试的命名空间 ID。命名空间（2.0）

执行结果

  • 在迁移工具中验证迁移结果

    执行结束后命令行页面会提示此次的迁移任务总数和失败、成功的任务数。

    结果验证-任务数

    如果失败，还会提示失败的原因。并可以到到${user.home}/logs/schedulrx2-migrate/migrate.log日志中搜索具体jobid查看失败原因。

    说明 同一个分组多次传输需要在同一台机器上操作，所有的成功信息都会存放到本地文件中，请勿删除，具体位置在${user.home}/migrate_jog中。

    如果不选择同一台机器，任务会重复迁移，文件被删除，第二次迁移还是会全量迁移。

  • 升级JAR包

    1. 如果任务量比较多，把schedulerx-client的JAR包替换为：

      <dependency>
<groupId>com.aliyun.schedulerx</groupId>
<artifactId>schedulerx2-worker</artifactId>
<version>1.0.6-compatible</version>
</dependency>

    2. 如果任务量比较少，可以在SchedulerX 2.0控制台手动重建任务，并把schedulerx-client的JAR包替换为：

      <dependency>
<groupId>com.aliyun.schedulerx</groupId>
<artifactId>schedulerx2-worker</artifactId>
<version>1.0.6</version>
</dependency>
  • 登录SchedulerX 2.0的控制台，验证接入2.0成功，非常重要。
    • 在应用管理页面单击连接机器，能看到机器列表。
    • 在任务管理页面单击运行一次，能触发到业务代码。
    • 运行一次之后，在执行列表能看到触发记录。