CN113434180B - 应用的数据处理方法、装置、服务器和存储介质 - Google Patents

Abstract

本申请实施例提供一种应用的数据处理方法、装置、服务器和存储介质，通过获取开发人员提交代码文件时创建的应用处理标签，应用处理标签包括应用标识和应用处理标识，基于应用处理标识，对应用标识对应的目标应用进行数据处理，实现了应用的程序与数据、应用的程序变更与回滚以及应用的数据变更与回滚的有机的统一，采用流水线的形式自动化的完成整个应用的变更、监控、回滚的过程，实现了应用的持续集成、持续部署和自动化回滚，有利于实现变更频繁的项目工程的快速迭代，提高整个项目工程的开发效率。

Description

应用的数据处理方法、装置、服务器和存储介质

技术领域

本申请实施例涉及数据处理技术领域，尤其涉及一种应用的数据处理方法、装置、服务器和存储介质。

背景技术

采用快速迭代的开发方式的互联网公司需要频繁地对已发布的应用进行变更，如版本更新、升级等，以及发现问题时及时回滚进行修改，保证应用的可变更性和可回滚性，对于控制风险、成本和保障应用的可靠性、可用性，都有重要的意义。

当前，应用的变更(主要指应用的程序或数据)主要是通过接入持续集成/交付/部署(continuous integration/delivery/deployment，CICD)流水线实现的，通过借助GitLab或者Jenkins的持续集成工具，通过配置特定的触发方式，完成应用的变更，而对于应用的回滚，现有方式主要还是通过手动触发实现。

因此，现有技术中亟需一种针对应用变更与回滚的完整的自动化解决方案。

发明内容

本申请实施例提供一种应用的数据处理方法、装置、服务器和存储介质，通过提供了一套针对应用变更与回滚的完整的自动化解决方案，以解决现有技术中存在应用开发效率低的问题。

第一方面，本申请实施例提供一种应用的数据处理方法，包括：

获取开发人员提交代码文件时创建的应用处理标签，所述应用处理标签包括应用标识和应用处理标识；

基于所述应用处理标识，对所述应用标识对应的目标应用进行数据处理。

可选地，所述基于所述应用处理标识，对所述应用标识对应的目标应用进行数据处理，包括：

若所述应用处理标识为应用程序更新标识，则通过应用程序更新流水线采用所述代码文件，对容器化服务平台上所述目标应用的程序进行更新；

通过设置在所述容器化服务平台上的监测探针，对更新后的目标应用进行健康存活检查。

可选地，所述健康存活检查为启动状态检查，所述方法还包括：

若检测到更新后的目标应用的启动状态为异常状态，则通过调用预设应用程序接口回滚到所述目标应用的稳定版本。

可选地，所述通过调用预设应用接口回滚到所述目标应用的稳定版本，包括：

调用所述预设应用程序接口，创建所述目标应用的回滚流水线标签，所述回滚流水线标签中包括所述目标应用的回滚版本号；

若验证所述回滚版本号为所述目标应用的上一个稳定版本号，则通过应用回滚流水线，回滚到所述目标应用的上一个稳定版本。

可选地，所述通过应用回滚流水线，回滚到所述目标应用的上一个稳定版本，包括：

从镜像仓库中拉取所述回滚版本号对应的应用镜像；

采用所述应用镜像对更新后的目标应用进行程序回滚。

可选地，所述基于所述应用处理标识，对所述应用标识对应的目标应用进行数据处理，包括：

若所述应用处理标识为应用数据更新标识，则通过应用数据更新流水线，采用所述代码文件，对所述目标应用的数据进行更新；

对更新过程中产生的日志进行存储。

可选地，所述日志中包括所述目标应用的数据更新时间、更新位置和更新类型，所述方法还包括：

当需要对所述目标应用进行数据回滚时，根据指定的待回滚数据和待回滚时间，基于所述更新时间，确定所述待回滚数据的更新位置和更新类型；

根据所述待回滚数据的更新位置和更新类型，连接到目标数据库环境，对所述待回滚数据进行反转处理。

第二方面，本申请实施例提供一种应用的数据处理装置，包括：

获取模块，用于获取开发人员提交代码文件时创建的应用处理标签，所述应用处理标签包括应用标识和应用处理标识；

处理模块，用于基于所述应用处理标识，对所述应用标识对应的目标应用进行数据处理。

第三方面，本申请实施例提供一种服务器，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现如上述第一方面所述的应用的数据处理方法。

第四方面，本申请实施例提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如上述第一方面所述的应用的数据处理方法。

本申请实施例提供的应用的数据处理方法、装置、服务器和存储介质，通过获取开发人员提交代码文件时创建的应用处理标签，应用处理标签包括应用标识和应用处理标识，基于应用处理标识，对应用标识对应的目标应用进行数据处理，实现了应用的程序与数据、应用的程序变更与回滚以及应用的数据变更与回滚的有机的统一，采用流水线的形式自动化的完成整个应用的变更、监控、回滚的过程，实现了应用的持续集成、持续部署和自动化回滚，有利于实现变更频繁的项目工程的快速迭代，提高整个项目工程的开发效率。

附图说明

图1为本申请实施例一提供的应用的数据处理方法的流程示意图；

图2为本申请实施例一提供的应用的数据处理的流水线框架图；

图3为本申请实施例二提供的应用的数据处理装置的结构示意图；

图4为本申请实施例三提供的一种服务器的结构示意图。

具体实施方式

下面结合附图和实施例对本申请作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释本申请，而非对本申请的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本申请相关的部分而非全部结构。

应用，即应用程序，也叫软件，主要由程序和数据两部分构成，其中，程序是指实现应用设计和性能需求的指令，数据，是指程序能够正常操纵信息的数据结构。本实施例提供的应用的数据处理方法，可用于对应用的程序和数据进行自动化更新和回滚等处理。

现有技术中，一方面，应用的程序或数据主要是通过直接连接数据库或者单独的构建流水线实现的，即应用的程序变更与数据变更之间没有相互依赖关联，对于企业级的工程项目(大工程项目)，由于数据变更较为频繁，且未纳入规范统一的版本管理中，在经历多少次版本升级或者回滚操作后，存在数据版本与程序版本不匹配，导致应用版本较为混乱，从而影响应用的版本管理。另一方面，若应用的程序发布(部署或变更)后存在问题，需要手动触发之前版本的流水线进行程序回滚操作，即应用程序的发布与回滚是分离的；而对于数据回滚需求，需要利用MYSQL相关的回滚工具进行手动回滚，未接入到持续集成工具中，即应用数据的变更与回滚也是分离的，导致回滚速度慢，从而影响应用的开发效率。

本申请技术方案的主要思路：基于现有技术中存在的技术问题，本申请实施例提供一种应用的数据处理方案，将应用的程序变更与数据变更纳入统一流水线的管理，将程序的变更与回滚、数据的变更与回滚也纳入统一流水线的管理中。从应用发布到应用健康检测再到应用回滚，实现了全流程的自动化，减少了人为操作，提高了应用的开发效率。

实施例一

图1为本申请实施例一提供的应用的数据处理方法的流程示意图，本实施例的方法可以由本申请实施例所提供的应用的数据处理装置执行，该装置可以由软件和/或硬件的方式来实现，并可集成于服务器中。如图1所示，本实施例的应用的数据处理方法，包括：

S101、获取开发人员提交代码文件时创建的应用处理标签。

本实施例中，开发人员将代码文件提交到代码仓库时，会创建与代码文件相关的标签(Tag)，即应用处理标签，该应用处理标签用于表征开发人员提交的代码文件的处理对象(对哪个应用进行处理)和处理类型(对应用进行哪种类型的处理)。

可选地，本实施例中，应用处理标签为代码文件的名称，在开发人员提交代码文件时，通过按照预设格式要求对代码文件进行命名，完成代码文件的应用处理标签的创建。

需要说明的是，上述几种情况仅作为应用处理标签及应用处理标签创建的一些可能的示例，根据实际情况，也可以采用其他的方式进行应用处理标签的设置和创建，此处不作限制。

本实施例中，由开发人员创建的应用处理标签触发应用数据处理的自动化流程，具体地，本实施例中，可以实时或周期性地对代码仓库的动态进行监测，当监测到开发人员提交代码文件的操作或当检测到代码仓库中有新的代码文件时，获取该代码文件对应的应用处理标签。

为保证后续流程的顺利进行，本实施例中应用处理标签中应至少包括应用标识和应用处理标识。其中，应用标识用于唯一确定一个应用，例如可以是应用的名称、代号等。应用处理标识用于唯一确定一种处理操作，可以是处理操作的名称或编号等，本实施例中，涉及的应用处理操作包括应用程序更新和应用数据更新，示例性地，本实施例中，可以事先为应用程序更新和应用数据更新两种处理操作分别约定不同的标记或编号，如用0表示应用程序更新，用1表示应用数据更新，以实现对不同处理操作的区分。

可以理解的是，本实施方式中，根据应用处理标签中包括的应用标识和应用处理标识，就可以确定出开发人员提交的代码文件用于对哪个应用执行何种处理操作。

S102、基于应用处理标识，对应用标识对应的目标应用进行数据处理。

本步骤中，根据S101中获取的应用处理标签中的应用标识和应用处理标识，并基于开发人员提交的代码文件，对目标应用进行目标处理操作。其中，目标应用是指应用标识对应的应用，目标应用可以是移动端应用等常规应用，也可以是微服务等，目标处理是指由应用处理标识所确定的处理操作。

本实施例中，由于应用主要由程序和数据两部分构成，因此，对应用的处理包括对应用的程序处理和数据处理两种不同类型，而由于无论是程序的回滚，还是数据的回滚，通常都是在更新后的程序或数据的基础上进行的，因此，本步骤中，由标签触发的对目标应用的数据处理包括应用程序更新和应用数据更新两种类型。

本实施例中，若应用处理标签中的应用处理标识为应用程序更新标识(即对目标应用的程序进行更新的标识)，则通过应用程序更新流水线采用代码文件，对容器化服务平台上目标应用的程序进行更新，并通过设置在容器化服务平台上的监测探针，对更新后的目标应用进行健康存活检查。

其中，应用程序更新流水线是预先创建的对应用程序进行部署或更新的一套自动化处理流程，示例性地，基于gitlab的应用程序更新流水线包括：(1)对代码文件进行maven编译和打包，得到目标应用的新程序，并生成一个内容为该新程序的可执行的jar包(即后缀是.jar的文件)；(2)使用docker构建目标应用的新程序镜像，并将构建的新程序镜像发布的镜像仓库中；(3)使用docker从镜像仓库中拉取目标应用的新程序镜像，并采用新程序镜像对容器化服务平台上目标应用的已有程序进行更新(即对目标应用进行版本更新，如若目标应用的当前版本为1.0，则更新后的版本为1.1。

可以理解的是，在进行应用程序部署时，可以直接通过上述应用程序更新流水线，将目标应用的程序部署到部署容器化服务平台上即可。

可选地，本实施例中，开发人员创建的应用处理标签中还可以包括目标应用的待更新版本号、使用的数据库、部署环境等信息，相应地，本步骤中可以根据待更新版本号和部署环境信息对目标应用进行更新，得到对应新版本的目标应用。

容器化服务平台，是指目标应用的部署平台，可以是服务器或服务器集群等。容器化服务平台上除部署有目标应用外，还可以部署其他应用。

监测探针，是预埋在容器化服务平台上的，本实施例中的监测探针，主要用于对更新后的目标应用进行健康存活检查，以达到对更新后的目标应用的健康状态的监控，从而判断是否需要对更新后的目标应用进行回滚。

在一种可能的实施方式中，健康存活检查为启动状态检查，相应地，本实施例中，若监测探针检测到更新后的目标应用的启动状态为异常状态，即更新后的目标应用的启动存在问题，如无法启动、启动耗时大于设定阈值等，则本实施例中，调用预设的外部应用程序接口(application programming interface，API)回滚到目标应用的稳定版本。

可选地，监测探针为K8S(Kubernetes)的探针存活工具，监测探针用于对更新后的目标应用的存活情况进行周期性检测。当检测到目标应用的存活情况存在问题时，及时进行问题的上报，以触发目标应用自动回滚。

本实施例中，通过在容器化服务平台中设置监测探针，对更新后的目标应用进行健康存活检查，实现了目标应用程序的更新与回滚之间的有机统一，不仅不需要人工的干预，节省人力，还可以在发现更新后的版本存在问题时，第一时间回滚到稳定的版本，保证目标应用的可用性，减少可能造成的经济损失。

在一种可能的实施方式中，本实施例中，调用预设外部API(如GitLab API)，回滚到目标应用的稳定版本，具体包括如下步骤：

(1)创建目标应用的回滚流水线标签。

本步骤中，通过调用预留的外部API，创建目标应用的回滚流水线标签，回滚流水线标签中包括目标应用的回滚版本号。

其中，回滚版本号为目标应用回滚后的版本序号。在进行回滚流水线标签创建时，可以按照设定的算法，如获取容器化服务平台上目标应用的当前版本号，并通过当前版本号减1，得到目标应用的回滚版本号(通常情况下，目标应用当前版本的上一个版本为稳定版本)。

(2)验证回滚流水线标签中的回滚版本号是否为目标应用的上一个稳定版本号，若是，则执行步骤(3)，若否，则结束流程。

本步骤中，通过版本校验，判断回滚流水线标签中的回滚版本号与目标应用的上一个稳定版本号是否一致，若不一致，则很有可能导致回滚失败，因此，结束流程，若一致，才执行步骤(3)，从而保证目标应用能够回滚到稳定的版本，达到有效回滚的目的。

可以理解的是，上一个稳定版本号是指离目标应用的当前版本最近的一个稳定版本所对应的版本序号，如若目标应用的当前版本为5.0，而其之前4.0和3.0均为稳定版本，则本步骤中的上一个稳定版本号为4.0。

(3)通过应用回滚流水线，回滚到目标应用的上一个稳定版本。

本步骤中，在确定回滚流水线标签中的回滚版本号为目标应用的上一个稳定版本号时，通过应用回滚流水线自动回滚到目标应用的上一个稳定版本。

示例性地，基于gitlab的应用回滚流水线包括：a、从镜像仓库中拉取回滚版本号对应的应用镜像；b、采用应用镜像对更新后的目标应用进行程序回滚，即通过回滚版本号对应的应用镜像对容器化服务平台上的目标应用进行更新。

本实施方式中，通过调用外部API创建回滚流水线标签，触发应用回滚流水线，实现目标应用上一版本的自动化构建，保证了应用自动化回滚的可实施性，并且，由于回滚过程中，可以通过直接从镜像仓库中拉取应用镜像，而无需重新对代码文件进行编译操作，从而提高了回滚的速度。

本实施例中，若应用处理标识为数据更新标识(即对目标应用的数据进行更新的标识)，则通过应用数据更新流水线，采用开发人员上传的代码文件，对目标应用的数据进行更新，同时，对目标应用更新过程中产生的日志进行归档和存储。

示例性地，基于gitlab的应用数据更新流水线包括：根据应用处理标签中的数据库信息，连接到对应目标应用的数据库环境，通过执行代码文件，对目标应用对应的数据库执行数据插入、修改和删除等操作，实现对目标应用的数据更新。

可选地，本实施例中的日志为Binlog日志，该日志中包括目标应用的数据更新时间(什么时候进行的更新)、更新位置(如哪个数据库环境)和更新类型(如插入、修改和删除中的一种)。

对于gitlab来说，由于CICD流水线中每个Job所运行的Runner是通过K8S集群搭建，不同job间的执行器为Docker，数据并不互通，因此，通过对目标应用更新过程中产生的日志进行存储(通常存储在gitlab服务器中特定的目录下)，为后续数据的自动回滚提供了依据。

当需要对目标应用进行数据回滚时，具体地，根据指定的待回滚数据和待回滚时间，通过获取目标应用的日志，筛选出待回滚数据的所有日志记录，首先，根据指定的待回滚时间与日志中更新时间的比对结果，确定对应时间对待回滚数据的更新时用到的数据库环境(即目标数据库环境)和执行的具体操作，即更新位置和更新类型，然后，根据确定的更新位置连接到目标数据库环境，并根据确定的更新类型，对待回滚数据执行反转处理，实现目标应用的数据回滚。

可以理解的是，若待回滚数据有多条，则本实施例，通过按照上述步骤逐条对待回滚数据进行反转处理，完成整个回滚处理。

反转处理，即执行与更新类型对应的操作的反操作，将对应的数据回滚为更新前的数据，例如，“插入”操作的反转处理为“删除”操作，“删除”操作的反转处理为“删除”操作。

本实施例中，通过保存目标应用在数据更新过程中产生的日志，实现了数据更新与数据回滚的有机统一，在无需人工干预的情况下，实现了整个数据变更与回滚流程的自动化，。

示例性地，图2为本申请实施例一提供的应用的数据处理的流水线框架图，从图2不难看出，由于应用程序的变更，通常也伴随着应用数据的变更，因此，在这种情况下，在对目标应用进行程序变更的过程中，也可以同时伴随数据的变更处理，相应地，在对程序进行回滚的过程中，也同时伴随着数据的回滚处理，如表结构的变更。而由于常规数据的处理过程中不需要对程序进行变更，因此，只需要执行数据的变更流程即可，相应地，在对其进行回滚的过程中，也只需要执行数据的回滚流程即可。

可以理解的是，本实施例中，若需要对目标应用进行数据更新，则代码文件为数据更新脚本，相应地，在图2的数据更新流水线中执行的代码文件为数据更新脚本；若需要对目标应用进行程序更新，则代码文件为程序更新脚本，相应地，在图2中程序更新流水线中，执行的是对程序更新脚本的编译、打包等处理。

需要说明的是，本实施例中，由于对程序的更新可以仅对其对应用的代码进行变更，也可以对其代码和数据同时进行变更，因此，程序更新脚本中可以只包括代码更新脚本，也可以同时包括代码更新脚本和数据更新脚本。相应地，在进行程序更新时，可以通过检测程序更新脚本中是否包括数据更新脚本，确定是只对程序进行代码更新，还是同时对程序的代码和数据进行更新。

本实施例中，通过获取开发人员提交代码文件时创建的应用处理标签，应用处理标签包括应用标识和应用处理标识，基于应用处理标识，对应用标识对应的目标应用进行数据处理，实现了应用的程序与数据、应用的程序变更与回滚以及应用的数据变更与回滚的有机的统一，采用流水线的形式自动化的完成整个应用的变更、监控、回滚的过程，实现了应用的持续集成、持续部署和自动化回滚，有利于实现变更频繁的项目工程的快速迭代，提高整个项目工程的开发效率。

实施例二

图3为本申请实施例二提供的应用的数据处理装置的结构示意图，如图3所示，本实施例中应用的数据处理装置10包括：

获取模块11和处理模块12。

获取模块11，用于获取开发人员提交代码文件时创建的应用处理标签，所述应用处理标签包括应用标识和应用处理标识；

处理模块12，用于基于所述应用处理标识，对所述应用标识对应的目标应用进行数据处理。

可选地，处理模块12具体用于：

若所述应用处理标识为应用程序更新标识，则通过应用程序更新流水线采用所述代码文件，对容器化服务平台上所述目标应用的程序进行更新；

通过设置在所述容器化服务平台上的监测探针，对更新后的目标应用进行健康存活检查。

可选地，所述健康存活检查为启动状态检查，处理模块12还用于：

若检测到更新后的目标应用的启动状态为异常状态，则通过调用预设应用程序接口回滚到所述目标应用的稳定版本。

可选地，处理模块12具体用于：

调用所述预设应用程序接口，创建所述目标应用的回滚流水线标签，所述回滚流水线标签中包括所述目标应用的回滚版本号；

若验证所述回滚版本号为所述目标应用的上一个稳定版本号，则通过应用回滚流水线，回滚到所述目标应用的上一个稳定版本。

可选地，处理模块12具体用于：

从镜像仓库中拉取所述回滚版本号对应的应用镜像；

采用所述应用镜像对更新后的目标应用进行程序回滚。

可选地，处理模块12具体用于：

若所述应用处理标识为应用数据更新标识，则通过应用数据更新流水线，采用所述代码文件，对所述目标应用的数据进行更新；

对更新过程中产生的日志进行存储。

可选地，所述日志中包括所述目标应用的数据更新时间、更新位置和更新类型，处理模块12还用于：

当需要对所述目标应用进行数据回滚时，根据所指定的待回滚数据和待回滚时间，基于所述更新时间，确定所述待回滚数据的更新位置和更新类型；

根据所述待回滚数据的更新位置和更新类型，连接到目标数据库环境，对所述待回滚数据进行反转处理。

本实施例所提供的应用的数据处理装置可执行上述方法实施例所提供的应用的数据处理方法，具备执行方法相应的功能模块和有益效果。本实施例的实现原理和技术效果与上述方法实施例类似，此处不再一一赘述。

实施例三

图4为本申请实施例三提供的一种服务器的结构示意图，如图4所示，该服务器20包括存储器21、处理器22及存储在存储器上并可在处理器上运行的计算机程序；服务器20处理器22的数量可以是一个或多个，图4中以一个处理器22为例；服务器20中的处理器22、存储器21可以通过总线或其他方式连接，图4中以通过总线连接为例。

存储器21作为一种计算机可读存储介质，可用于存储软件程序、计算机可执行程序以及模块，如本申请实施例中的获取模块11和处理模块12对应的程序指令/模块。处理器22通过运行存储在存储器21中的软件程序、指令以及模块，从而服务器的各种功能应用以及数据处理，即实现上述的应用的数据处理方法。

存储器21可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序；存储数据区可存储根据终端的使用所创建的数据等。此外，存储器21可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实例中，存储器21可进一步包括相对于处理器22远程设置的存储器，这些远程存储器可以通过网格连接至服务器。上述网格的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

实施例四

本申请实施例四还提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序在由计算机处理器执行时用于执行一种应用的数据处理方法，该方法包括：

获取开发人员提交代码文件时创建的应用处理标签，所述应用处理标签包括应用标识和应用处理标识；

基于所述应用处理标识，对所述应用标识对应的目标应用进行数据处理。

当然，本申请实施例所提供的一种包计算机可读存储介质，其计算机程序不限于如上所述的方法操作，还可以执行本申请任意实施例所提供的应用的数据处理方法中的相关操作。

通过以上关于实施方式的描述，所属领域的技术人员可以清楚地了解到，本申请可借助软件及必需的通用硬件来实现，当然也可以通过硬件实现，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如计算机的软盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(RandomAccess Memory，RAM)、闪存(FLASH)、硬盘或光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网格设备等)执行本申请各个实施例所述的方法。

值得注意的是，上述应用的数据处理装置的实施例中，所包括的各个单元和模块只是按照功能逻辑进行划分的，但并不局限于上述的划分，只要能够实现相应的功能即可；另外，各功能单元的具体名称也只是为了便于相互区分，并不用于限制本申请的保护范围。

注意，上述仅为本申请的较佳实施例及所运用技术原理。本领域技术人员会理解，本申请不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本申请的保护范围。因此，虽然通过以上实施例对本申请进行了较为详细的说明，但是本申请不仅仅限于以上实施例，在不脱离本申请构思的情况下，还可以包括更多其他等效实施例，而本申请的范围由所附的权利要求范围决定。

Claims (8)

1.一种应用的数据处理方法，其特征在于，包括：

获取开发人员提交代码文件时创建的应用处理标签，所述应用处理标签包括应用标识和应用处理标识；

基于所述应用处理标识，对所述应用标识对应的目标应用进行数据处理；

其中，所述基于所述应用处理标识，对所述应用标识对应的目标应用进行数据处理，包括：

若所述应用处理标识为应用程序更新标识，则通过应用程序更新流水线采用所述代码文件，对容器化服务平台上所述目标应用的程序进行更新；

通过设置在所述容器化服务平台上的监测探针，对更新后的目标应用进行健康存活检查；

其中，所述健康存活检查为启动状态检查，所述方法还包括：

若检测到更新后的目标应用的启动状态为异常状态，则通过调用预设应用程序接口回滚到所述目标应用的稳定版本。

2.根据权利要求1所述的方法，其特征在于，所述通过调用预设应用接口回滚到所述目标应用的稳定版本，包括：

调用所述预设应用程序接口，创建所述目标应用的回滚流水线标签，所述回滚流水线标签中包括所述目标应用的回滚版本号；

若验证所述回滚版本号为所述目标应用的上一个稳定版本号，则通过应用回滚流水线，回滚到所述目标应用的上一个稳定版本。

3.根据权利要求2所述的方法，其特征在于，所述通过应用回滚流水线，回滚到所述目标应用的上一个稳定版本，包括：

从镜像仓库中拉取所述回滚版本号对应的应用镜像；

采用所述应用镜像对更新后的目标应用进行程序回滚。

4.根据权利要求1所述的方法，其特征在于，所述基于所述应用处理标识，对所述应用标识对应的目标应用进行数据处理，包括：

若所述应用处理标识为应用数据更新标识，则通过应用数据更新流水线，采用所述代码文件，对所述目标应用的数据进行更新；

对更新过程中产生的日志进行存储。

5.根据权利要求4所述的方法，其特征在于，所述日志中包括所述目标应用的数据更新时间、更新位置和更新类型，所述方法还包括：

当需要对所述目标应用进行数据回滚时，根据指定的待回滚数据和待回滚时间，基于所述更新时间，确定所述待回滚数据的更新位置和更新类型；

根据所述待回滚数据的更新位置和更新类型，连接到目标数据库环境，对所述待回滚数据进行反转处理。

6.一种应用的数据处理装置，其特征在于，包括：

获取模块，用于获取开发人员提交代码文件时创建的应用处理标签，所述应用处理标签包括应用标识和应用处理标识；

处理模块，用于基于所述应用处理标识，对所述应用标识对应的目标应用进行数据处理；

其中，处理模块具体用于：

若所述应用处理标识为应用程序更新标识，则通过应用程序更新流水线采用所述代码文件，对容器化服务平台上所述目标应用的程序进行更新；

通过设置在所述容器化服务平台上的监测探针，对更新后的目标应用进行健康存活检查；

其中，所述健康存活检查为启动状态检查，处理模块还用于：

若检测到更新后的目标应用的启动状态为异常状态，则通过调用预设应用程序接口回滚到所述目标应用的稳定版本。

7.一种服务器，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现如权利要求1-5中任一所述的应用的数据处理方法。

8.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现如权利要求1-5中任一所述的应用的数据处理方法。

Images