CN117785240A - 一种分布式任务调度系统的滚动升级方法 - Google Patents

Abstract

本发明涉及一种分布式任务调度系统的滚动升级方法。本方法包括：通过持续部署工具对任务管理器或任务执行器中的应用服务进行部署，当目标服务不存在对应容器时，直接启动部署工作；当目标服务存在对应容器时，先通知该对应容器停止，然后拉取该对应容器的状态，直到拉取到的状态为可停止状态时对该对应容器进行销毁；销毁完成后在Docker容器中对新版本的应用服务进行部署和运行。本方法采用通过自定义的节点监控状态检查机制来完成任务调度系统的可启停控制的策略，实现了分布式任务调度系统的滚动升级，本方法无需占用额外的升级资源，不存在任务调度系统停机丢失实例或丢失实例关联数据的问题、以及任务中断和中断任务重新执行的问题。

Description

一种分布式任务调度系统的滚动升级方法

技术领域

本发明属于分布式任务调度系统升级方法技术领域，尤其涉及一种分布式任务调度系统的滚动升级方法。

背景技术

分布式任务调度系统在使用过程中，经常会遇到漏洞修复或者版本升级需要对应的服务重新部署的情况，在这个过程中，如果直接采用停止旧服务部署新服务的方式，系统会存在不可控的停机时间，从而会对正在运行的系统业务造成影响，比如丢失实例状态、丢失实例等，甚至会造成更严重的情况，比如在数据迁移或者数据计算的场景下，中途停机可能会导致数据丢失与计算失败，造成重复抽取、计算和数据错乱等故障。

为了解决这个问题，我们需要尽可能地减少或者消除停机时间，以避免系统升级对业务带来的不利影响，滚动升级技术能够很好地解决此类问题。目前主流的滚动升级方案有蓝绿发布、红黑发布、灰度发布等，但是都存在一定的不足，比如蓝绿发布会产生资源冗余，当出现故障时，对业务影响较大，尤其对于一些政企单位来说，相关资源申请和使用的流程比较繁琐，对于资源冗余会更加敏感，这也是本发明关注的核心问题之一；红黑分布只有部分服务器提供服务，经常会导致系统过载；灰度发布系统复杂，开发测试运维成本很高。

发明内容

为了克服现有分布式任务调度系统滚动升级技术存在的上述不足，解决调度系统升级过程中出现的实例数据丢失和常规滚动升级方案中出现的资源冗余问题，本发明提出了一种新的分布式任务调度系统的滚动升级方法。

术语解释

滚动升级：滚动升级是一种平滑过渡的升级方式，通过逐步替换的策略，保证整体系统的稳定。在滚动升级中，新版本的应用程序会逐步替换旧版本的应用程序，直到所有的应用程序都被更新为止。这种升级方式可以减少服务中断的时间，同时也可以保证应用程序的稳定性。滚动升级通常通过控制器来实现，控制器会根据用户的要求，逐步将旧版本的组件替换为新版本的组件。在升级过程中，可以及时发现问题并进行修复，以保证升级过程的稳定性。滚动升级适用于分布式系统，可以降低升级风险，提高系统的可用性和可靠性。

蓝绿发布：在蓝绿发布中，有两个相同的环境，一个为蓝色环境(当前正在运行的生产环境)，另一个为绿色环境(新的待发布环境)。在升级过程中，将所有流量切换到绿色环境，同时关闭蓝色环境进行维护或升级。一旦绿色环境准备好并经过验证，将流量切换回蓝色环境，并将绿色环境升级为下一个版本。这种模式的好处是可以减少停机时间，因为在切换环境时，用户只会短暂地感受到服务中断。

红黑发布：红黑发布与蓝绿发布类似，但有一个额外的验证步骤。在这种模式下，黑色环境代表当前的生产环境，红色环境是新的待发布环境。当红色环境准备好后，并不是直接将所有流量切换到红色环境，而是将一小部分流量引导到红色环境进行验证，如果验证成功，则逐步增加红色环境的流量比例，同时减少黑色环境的流量。这种模式的好处是可以逐步验证新环境的稳定性和性能，并降低潜在风险。

灰度发布：在灰度发布中，新版本的应用程序与旧版本同时运行。新版本被引入到一小部分用户或服务器中，以便进行验证和监控。如果新版本表现良好并经过验证，则可以逐步增加新版本的比例，同时减少旧版本的比例，直到所有用户都迁移到新版本。这种模式的好处是可以逐步引入新功能，并在实际生产环境中进行验证，从而减少潜在风险。

Nexus：Nexus是一个强大的软件仓库管理工具，它主要用于搭建Maven私服。

Habor：Habor是一个由VMware公司为中国企业用户设计的开源项目，是一个企业级的Docker镜像仓库。它的主要作用包括：权限管理，镜像复制，图形化用户界面，AD/LDAP支持，审计管理等。

Docker：Docker是一个开源的应用容器引擎，基于Go语言并遵从Apache2.0协议开源。它可以让开发者打包他们的应用以及依赖包到一个可移植的镜像中，然后发布到任何流行的Linux或Windows操作系统的机器上，也可以实现虚拟化。

具体地，本发明提供了一种分布式任务调度系统的滚动升级方法，本方法包括：

S1.通过持续部署工具对任务管理器或任务执行器中的应用服务进行部署，当目标服务不存在对应容器时，持续部署工具直接启动部署工作；当目标服务存在对应容器时，持续部署工具先通知该对应容器停止，然后拉取该对应容器的状态，直到拉取到的状态为可停止状态时对该对应容器进行销毁；

S2.目标服务的对应容器销毁完成后，在Docker容器中对新版本的应用服务进行部署和运行。

进一步地，本发明分布式任务调度系统的滚动升级方法步骤S1中还包括：当目标服务的对应容器接收到持续部署工具发送的停止请求后，先判断是否可以进入停止状态；

如果可以进入停止状态则直接停止，并将状态设置为可停止状态，等待持续部署工具拉取；

如果不可以进入停止状态，则将该应用节点从集群的负载均衡节点中移除，不再承接业务请求，等待该应用节点中的所有正在运行的任务结束后将其状态设置为可停止状态，等待持续部署工具拉取后再次通知停止。

进一步地，本发明分布式任务调度系统的滚动升级方法的数据流转过程如下：

任务管理器集群通过任务数据分片获取任务，然后逐条处理获取到的任务，通过负载均衡策略将任务分发给各任务执行器，任务执行器负责对任务包含的实际业务的执行。

进一步地，本发明分布式任务调度系统的滚动升级方法中所述的任务包含的实际业务包括：Datax数据抽取、Spark、MapReduce数据计算。

进一步地，本发明分布式任务调度系统的滚动升级方法中任务管理器的滚动升级流程如下：

(1)当任务管理器接收到持续部署工具发送的部署请求时，将应用服务设置为待停止状态；

(2)应用服务识别到本服务目前是待停止状态之后，不再接收任务的分片数据，将已接收但还未分发完的任务处理完成之后，将任务管理器应用状态设置为可停止状态，等待持续部署工具拉取，然后重新部署。

进一步地，本发明分布式任务调度系统的滚动升级方法中任务执行器的滚动升级流程如下：

(1)当任务执行器接收到持续部署工具发送的部署请求时，将应用服务设置为待停止状态；

(2)应用服务识别到本服务目前是待停止状态之后，不再参与任务执行器的负载均衡，任务管理器将无法对该任务执行器进行任务的分发，任务执行器将已接收但还未处理完的任务执行完之后，将应用状态设置为可停止状态，等待持续部署工具拉取，然后重新部署。

另外，本发明还提供了一种计算机可读存储介质，所述存储介质上存储有计算机程序，所述程序被处理器执行时实现上述的分布式任务调度系统的滚动升级方法的步骤。

另一方面，本发明还提供了一种分布式任务调度系统的滚动升级系统，本系统包括：

持续集成模块：通过gitlab对代码进行托管；使用Nexus搭建Maven私服对项目进行构建与管理；通过集成工具将对应的应用服务的代码打包成Docker镜像文件推送到Habor镜像仓库；

持续部署模块：通过持续部署工具，配置应用服务部署与升级的流程；通过拉取Habor镜像仓库中指定版本的Docker镜像文件，并分发到指定的服务器，完成对应服务器Docker镜像的加载和启动；对各应用服务Docker容器的自定义状态进行监听，发送应用服务启停的通知；

Docker容器：准备各应用服务运行所需要的环境；

各模块按照上述的分布式任务调度系统的滚动升级方法实施运行。

综上，本发明分布式任务调度系统的滚动升级方法采用通过自定义的节点监控状态检查机制来完成任务调度系统的可启停控制的策略，实现了分布式任务调度系统的滚动升级，本发明方法无需占用额外的升级资源，不存在任务调度系统停机丢失实例数据或者丢失实例的问题，也不存在任务中断与被动重新执行的问题。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面对本发明实施例叙述中需要使用的附图作简要介绍，显而易见地，下述附图仅是本发明中记载的一些实施例，对于本领域技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明的整体系统架构示意图。

图2为本发明方法的数据流转示意图。

图3为本发明滚动升级方法的实施流程示意图。

图4为本发明方法中任务管理器滚动升级流程图。

图5为本发明方法中任务执行器滚动升级流程图。

图6为本发明方法整体实施流程示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合具体实施例及相应的附图对本发明的技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本发明一部分实施例，而不是全部的实施例，本发明还可以通过另外不同的具体实施方式加以实施或应用，本说明书中的各项细节也可以基于不同观点与应用，在没有背离本发明的精神下进行各种修饰或改变。

同时，应理解，本发明的保护范围并不局限于下述特定的具体实施方案；还应当理解，本发明实施例中使用的术语是为了描述特定的具体实施方案，而不是为了限制本发明的保护范围。

实施例1：一种分布式任务调度系统的滚动升级方法

如图1所示，本发明的技术架构如下：

本发明的完整系统架构包括三部分：CI(持续集成)、CD(持续部署)、Docker容器。

CI(持续集成)：通过gitlab对代码进行托管；使用Nexus搭建Maven私服对项目进行构建与管理；通过集成工具将对应的应用服务的代码打包成Docker镜像文件推送到Habor镜像仓库。

CD(持续部署)：通过持续部署工具，配置应用服务部署与升级的流程，通过拉取Habor中指定版本的Docker镜像，分发到指定的服务器，完成对应服务器Docker镜像的加载和启动；同时还负责各个应用服务Docker容器的自定义状态的监听与应用服务启停的通知，如图2所示。

Docker容器：负责准备各个应用服务运行所需要的环境以及应用服务的启动运行。

如图2所示，本发明方法的数据流转流程如下：

任务的管理器集群通过数据分片分别获取一部分任务，然后逐条处理获取到的任务，通过负载均衡策略将任务分发给某一个执行器，执行器负责对任务包含的实际业务的执行，比如Datax数据抽取、Spark、MapReduce数据计算等。

如图3和图6所示，本发明滚动升级方法的具体流程如下：

流程分为两部分：持续部署工具对应用服务的启停以及Docker容器中应用服务的运行。

在对调度系统进行滚动升级的时候，首先，通过持续部署工具对任务管理器(调度系统管理器)或者任务执行器(调度系统执行器)应用服务的部署流程进行操作。当目标服务不存在对应容器时，直接进行部署启动工作；当目标服务存在对应容器时，部署工具会通知目标容器停止，然后拉取对应容器的状态，直到获取到的状态为可停止状态才对目标容器进行销毁。销毁完成后对新版本的应用进行部署。集群状态下，各个应用服务的滚动升级流程中存在新旧版本同时存在的情况，不需要额外的部署资源的申请与添加。当目标容器接收到部署工具发送过来的停止请求后，进行是否可以进入停止的判断；如果可以停止会直接停止，并将系统状态设置为可停止状态，等待持续部署工具拉取；如果不可以停止，则将该应用节点从集群的负载均衡节点中移除，不再承接业务请求；等待应用中的所有正在运行的任务结束后将应用状态置为可停止状态，等待部署工具拉取后通知停止。任务调度系统中对应应用服务的滚动升级流程如图4和图5所示。

如图4所示，本发明的任务管理器的滚动升级流程如下：

当任务管理器容器接收到CD部署工具发送过来的部署请求时，会将应用服务设置为待停止状态；应用服务识别到服务目前是待停止状态之后，不再接收任务的分片数据(数据按照管理器服务个数进行哈希取模)，将已经接收了但是还未分发完的任务处理完成之后，将管理器应用状态置为可停止状态，等待CD部署工具拉取，然后重新部署。

如图5所示，本发明的任务执行器的滚动升级流程如下：

当任务执行器容器接收到CD部署工具发送过来的部署请求时，会将应用服务设置为待停止状态；应用服务识别到服务目前是待停止状态之后，不再参与执行器的负载均衡，任务管理器将无法对该执行器进行任务的分发，执行器将已经接收了但是还未处理完的任务执行完之后，将应用状态置为可停止状态，等待CD部署工具拉取，然后重新部署。

实施例2：一种分布式任务调度系统的滚动升级系统

本系统包括：

持续集成模块：通过gitlab对代码进行托管；使用Nexus搭建Maven私服对项目进行构建与管理；通过集成工具将对应的应用服务的代码打包成Docker镜像文件推送到Habor镜像仓库；

持续部署模块：通过持续部署工具，配置应用服务部署与升级的流程；通过拉取Habor镜像仓库中指定版本的Docker镜像文件，并分发到指定的服务器，完成对应服务器Docker镜像的加载和启动；对各应用服务Docker容器的自定义状态进行监听，发送应用服务启停的通知；

Docker容器：准备各应用服务运行所需要的环境；

上述各模块按照实施例1所述的分布式任务调度系统的滚动升级方法实施运行。

以上所述，仅是本发明的较佳实施例而已，并非对本发明作任何形式上的限制，任何熟悉本专业的技术人员，在不脱离本发明技术方案范围内，当可利用上述揭示的技术内容作出些许更动或修饰获得等同变化的等效实施例，但凡是未脱离本发明技术方案的内容，依据本发明的技术实质对以上实施例所作的任何简单修改、等同变化与修饰，均应包含在本发明的权利要求保护范围之内。

Claims (8)

1.一种分布式任务调度系统的滚动升级方法，其特征在于，所述方法包括：

S1.通过持续部署工具对任务管理器或任务执行器中的应用服务进行部署，当目标服务不存在对应容器时，持续部署工具直接启动部署工作；当目标服务存在对应容器时，持续部署工具先通知该对应容器停止，然后拉取该对应容器的状态，直到拉取到的状态为可停止状态时对该对应容器进行销毁；

S2.目标服务的对应容器销毁完成后，在Docker容器中对新版本的应用服务进行部署和运行。

2.根据权利要求1所述的分布式任务调度系统的滚动升级方法，其特征在于，步骤S1中还包括：当目标服务的对应容器接收到持续部署工具发送的停止请求后，先判断是否可以进入停止状态；

如果可以进入停止状态则直接停止，并将状态设置为可停止状态，等待持续部署工具拉取；

如果不可以进入停止状态，则将该应用节点从集群的负载均衡节点中移除，不再承接业务请求，等待该应用节点中的所有正在运行的任务结束后将其状态设置为可停止状态，等待持续部署工具拉取后再次通知停止。

3.根据权利要求1所述的分布式任务调度系统的滚动升级方法，其特征在于，所述分布式任务调度系统的滚动升级方法的数据流转过程如下：

任务管理器集群通过任务数据分片获取任务，然后逐条处理获取到的任务，通过负载均衡策略将任务分发给各任务执行器，任务执行器负责对任务包含的实际业务的执行。

4.根据权利要求3所述的分布式任务调度系统的滚动升级方法，其特征在于，所述的任务包含的实际业务包括：Datax数据抽取、Spark、MapReduce数据计算。

5.根据权利要求1所述的分布式任务调度系统的滚动升级方法，其特征在于，所述分布式任务调度系统的滚动升级方法中任务管理器的滚动升级流程如下：

(1)当任务管理器接收到持续部署工具发送的部署请求时，将应用服务设置为待停止状态；

(2)应用服务识别到本服务目前是待停止状态之后，不再接收任务的分片数据，将已接收但还未分发完的任务处理完成之后，将任务管理器应用状态设置为可停止状态，等待持续部署工具拉取，然后重新部署。

6.根据权利要求1所述的分布式任务调度系统的滚动升级方法，其特征在于，所述分布式任务调度系统的滚动升级方法中任务执行器的滚动升级流程如下：

(1)当任务执行器接收到持续部署工具发送的部署请求时，将应用服务设置为待停止状态；

(2)应用服务识别到本服务目前是待停止状态之后，不再参与任务执行器的负载均衡，任务管理器将无法对该任务执行器进行任务的分发，任务执行器将已接收但还未处理完的任务执行完之后，将应用状态设置为可停止状态，等待持续部署工具拉取，然后重新部署。

7.一种计算机可读存储介质，所述存储介质上存储有计算机程序，所述程序被处理器执行时实现权利要求1-6任一项所述的分布式任务调度系统的滚动升级方法的步骤。

8.一种分布式任务调度系统的滚动升级系统，其特征在于，所述系统包括：

持续集成模块：通过gitlab对代码进行托管；使用Nexus搭建Maven私服对项目进行构建与管理；通过集成工具将对应的应用服务的代码打包成Docker镜像文件推送到Habor镜像仓库；

持续部署模块：通过持续部署工具，配置应用服务部署与升级的流程；通过拉取Habor镜像仓库中指定版本的Docker镜像文件，并分发到指定的服务器，完成对应服务器Docker镜像的加载和启动；对各应用服务Docker容器的自定义状态进行监听，发送应用服务启停的通知；

Docker容器：准备各应用服务运行所需要的环境。