全部产品
云市场

从分布式任务调度 1.0 迁移到 2.0

更新时间:2019-09-03 16:43:13

自 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 控制台。

    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命令。

  3. 阿里云1.0非测试环境迁移到阿里云2.0非测试环境,在命令行的交互页面根据提示完成迁移。

    1. 输入迁移类型

      阿里云用户请输入 2

    2. 输入分布式任务系统 1.0 需要迁移分组 ID

      分组 ID 可以在Scheduler 1.0 分组管理页面查看。

      查看 SchedulerX 1.0 分组 ID

    3. 输入分布式任务系统 1.0 迁移分组所在的 regionId 含对应 namespace 的 key

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

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

        regionNo(无命名空间)

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

        regionNo(包含命名空间)

    4. 输入分布式任务系统 1.0 迁移分组所在的命名空间的 tid

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

      查询命名空间 TID

    5. 输入分布式任务系统 1.0 迁移分组所属主账号的 ID

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

      查看云账号ID

    6. 输入迁入到分布式系统 2.0 分组的 Group_ID

      填写在使用创建任务分组设置的 Group ID。

      说明:如果是兼容迁移,2.0 中的 Group ID 要和 1.0 中的 Group ID 一致。

    7. 输入迁入到分布式系统 2.0 分组的主账号 ak

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

    8. 输入迁入到分布式系统 2.0 分组的主账号 SK

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

    9. 输入迁入到分布式系统 2.0 分组对应的命名空间 tid

      如果 SchedulerX 2.0 和 1.0 的命名空间的 tid 相同,可以不填,直接单击回车跳过。

    至此前置设置完成,单击回车,则开始执行迁移。

  4. 阿里云1.0测试环境迁移到阿里云2.0测试环境,在命令行的交互页面根据提示完成迁移。

    1. 输入迁移类型

      阿里云用户请输入 3

    2. 输入分布式任务系统 1.0 需要迁移分组 ID

      分组 ID 可以在Scheduler 1.0 测试分组管理页面查看。

      查看SchedulerX 1.0分组ID

    3. 输入分布式任务系统 1.0 迁移分组所属主账号的 ID

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

      查看云账号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。

      appKey

    7. 输入迁入到分布式系统 2.0 分组对应的命名空间 tid

      在命名空间页面查看对应的列表。输入测试的命名空间 ID。

      测试

    至此前置设置完成,单击回车,则开始执行迁移。

  5. 阿里云1.0测试环境迁移到阿里云2.0其它正式环境,在命令行的交互页面根据提示完成迁移。

    1. 输入迁移类型

      阿里云用户请输入 3

    2. 输入分布式任务系统 1.0 需要迁移分组 ID

      分组 ID 可以在Scheduler 1.0 测试分组管理页面查看。

      查看SchedulerX 1.0分组ID

    3. 输入分布式任务系统 1.0 迁移分组所属主账号的 ID

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

      查看云账号ID

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

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

      regionName

    5. 输入迁入到分布式系统 2.0 分组的 Group_ID

      填写在使用创建任务分组设置的 Group ID。

      说明:如果是兼容迁移,2.0 中的 Group ID 要和 1.0 中的 Group ID 一致。

    6. 输入迁入到分布式系统 2.0 分组的主账号 ak

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

    7. 输入迁入到分布式系统 2.0 分组的主账号 SK

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

    8. 输入迁入到分布式系统 2.0 分组对应的命名空间 tid

      在命名空间页面查看对应的列表。输入测试的命名空间 ID。

      命名空间

    至此前置设置完成,单击回车,则开始执行迁移。

  6. 迁移工具结果验证。

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

    迁移结果

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

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

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

  7. 升级 JAR 包。

    1. 如果任务量比较多,把schedulerx-client这个jar包替换为
      1. <dependency>
      2. <groupId>com.aliyun.schedulerx</groupId>
      3. <artifactId>schedulerx2-worker</artifactId>
      4. <version>1.0.6-compatible</version>
      5. </dependency>
    2. 如果任务量比较少,可以去2.0控制台手动重建任务,并把把schedulerx-client这个jar包替换为
      1. <dependency>
      2. <groupId>com.aliyun.schedulerx</groupId>
      3. <artifactId>schedulerx2-worker</artifactId>
      4. <version>1.0.6</version>
      5. </dependency>
  8. 登录 SchedulerX2.0 的控制台,验证接入 2.0 成功,非常重要!
    • 应用管理点击连接机器,能看到机器列表。
    • 任务管理,点击运行一次,能触发到业务代码。
    • 运行一次之后,执行列表能看到触发记录。