CN117707592A - 一种适用于微服务架构应用的运维方法及装置 - Google Patents

Abstract

本发明可用于人工智能技术在金融方面应用的技术领域，本发明提供了一种适用于微服务架构应用的运维方法及装置，对应的方法包括：根据预先获取的制品构建号生成RPA参数文件；根据所述RPA参数文件修改所述微服务架构应用的应用配置，所述应用配置包括应用级参数配置以及模板级参数配置；根据所述RPA参数文件以及所述应用配置生成所述微服务架构应用的测试环境；根据所述应用配置以及所述测试环境对所述微服务架构应用进行运维。本发明简化了研发运维一体化及微服务架构落地后增加运维工作难度，提供一种实现简单，实施成本低，能够模拟人机交互、执行基于一定规则的可重复性任务、协同异构业务系统间的运维方法。

Description

一种适用于微服务架构应用的运维方法及装置

技术领域

本申请属于人工智能技术领域，特别是机器人流程自动化技术领域，具体涉及一种适用于微服务架构应用的运维方法及装置。

背景技术

目前，随着研发运维一体化(Development Operations，DevOps)的不断落地，应用系统引入了大量相关工具链。应用系统也从传统的单体架构转型为微服务架构，微服务架构具有灵活性高、独立扩展等优点，但是应用系统同时变得越来越复杂，增加了运维工作的难度。运维人员需要频繁在各种工具链之间切换，执行大量的重复性操作，可以理解的是，这种运维方式极其容易出现人为错误。

具体地，由于微服务架构应用系统的复杂性、频繁切换工具链等原因，增加了运维工作的难度，主要存在以下缺点：

(1)异构系统之间难以实现流程联动，运维人员需要频繁在不同系统之间切换，如需联动通常需要破坏企业原有IT结构；

(2)运维人员难以做到7×24小时值守；

(3)运维人员需要执行大量重复性操作；

(4)人工执行任务的准确率难以做到100％，可能出现人为错误。

发明内容

本发明可用于人工智能技术在金融方面应用的技术领域，也可用于除金融领域之外的任意领域。

本发明的一个目的在于提供一种适用于微服务架构应用的运维方法，该方法可以实现以下目的：

第一、独立于现有系统，采用非侵入方式实现异构系统之间的流程联动，且不破坏企业原有的IT结构。

第二、将日常运维的高频操作预先定义为明确的流程规则，并基于规则执行相应的任务流程，通过RPA机器人模拟人工操作，将企业员工从重复、繁琐、低价值的密集型劳动中释放出来。

第三、实现运维7×24小时不间断工作。

第四、提升运维操作执行的准确率，避免出现人为错误。

本发明的另一个目的在于提供一种适用于微服务架构应用的运维装置。本发明的还一个目的在于提供一种电子设备，该电子设备包括存储器和处理器，存储器存储有计算机程序，处理器执行计算机程序时实现上述适用于微服务架构应用的运维方法的步骤。本发明的还一个目的在于提供一种可读介质，其上存储有计算机程序，计算机程序被处理器执行时实现上述适用于微服务架构应用的运维方法的步骤。

为解决本申请背景技术中的技术问题，本发明提供以下技术方案：

第一方面，本发明提供一种适用于微服务架构应用的运维方法包括：

根据预先获取的制品构建号生成RPA参数文件；

根据所述RPA参数文件修改所述微服务架构应用的应用配置，所述应用配置包括应用级参数配置以及模板级参数配置；

根据所述RPA参数文件以及所述应用配置生成所述微服务架构应用的测试环境；

根据所述应用配置以及所述测试环境对所述微服务架构应用进行运维。

在本发明的一些实施例中，所述RPA参数文件的格式为键值对格式；

所述根据预先获取的制品构建号生成RPA参数文件，包括：

将所述制品构建号转换为所述键值对格式，其中所述制品构建号为键值对的值；

将所述制品构建号插入初始的RPA参数文件，以生成所述RPA参数文件。

在本发明的一些实施例中，当所述应用配置为所述应用级参数配置时，根据所述RPA参数文件修改所述微服务架构应用的应用配置，包括：

按参数名称从所述RPA参数文件筛选需要修改的参数记录；

根据所述参数记录在内存参数表中修改对应参数名称对应的参数值；

根据所述内存参数表生成实体参数文件。

在本发明的一些实施例中，当所述应用配置为所述模板级参数配置时，

根据所述RPA参数文件修改所述微服务架构应用的应用配置，还包括：

如果所述参数名称与模版名称匹配，根据所述参数记录在内存参数表中修改对应参数名称对应的参数值，并根据所述内存参数表生成实体参数文件；

如果所述参数名称与模版名称不匹配，在所述内存参数表中复制对应的参数记录，并裁剪所述模版名称，并根据所述内存参数表生成实体参数文件。

在本发明的一些实施例中，根据所述RPA参数文件以及所述应用配置生成所述微服务架构应用的测试环境，包括：

根据所述RPA参数文件以及所述应用配置确定页面元素对应的ID；其中所述ID保持不变；

在所述ID对应的参数页面中填写所述RPA参数文件中测试环境参数；

根据所述参数页面生成所述测试环境。

在本发明的一些实施例中，根据所述应用配置以及所述测试环境对所述微服务架构应用进行运维，包括：

根据所述应用配置以及所述测试环境对所述微服务架构应用进行投产验证；

根据所述应用配置以及所述测试环境修改所述微服务架构应用的代码库分支标签。

在本发明的一些实施例中，根据所述应用配置以及所述测试环境对所述微服务架构应用进行投产验证，包括：

根据所述应用配置以及所述测试环境确定投产验证的验证点、所述验证点版本号以及所述微服务架构应用的版本号；

根据所述验证点、所述验证点版本号以及所述微服务架构应用的版本号生成验证任务；

根据所述验证任务对所述微服务架构应用进行投产验证。

第二方面，本发明提供一种适用于微服务架构应用的运维装置，该装置包括：

参数文件生成模块，用于根据预先获取的制品构建号生成RPA参数文件；

应用配置修改模块，用于根据所述RPA参数文件修改所述微服务架构应用的应用配置，所述应用配置包括应用级参数配置以及模板级参数配置；

测试环境生成模块，用于根据所述RPA参数文件以及所述应用配置生成所述微服务架构应用的测试环境；

应用运维模块，用于根据所述应用配置以及所述测试环境对所述微服务架构应用进行运维。

在本发明的一些实施例中，所述RPA参数文件的格式为键值对格式；

所述参数文件生成模块包括：

构建号转换单元，用于将所述制品构建号转换为所述键值对格式，其中所述制品构建号为键值对的值；

构建号插入单元，用于将所述制品构建号插入初始的RPA参数文件，以生成所述RPA参数文件。

在本发明的一些实施例中，当所述应用配置为所述应用级参数配置时，所述应用配置修改模块包括：

书记录筛选单元，用于按参数名称从所述RPA参数文件筛选需要修改的参数记录；

参数值修改第一单元，用于根据所述参数记录在内存参数表中修改对应参数名称对应的参数值；

参数文件生成单元，用于根据所述内存参数表生成实体参数文件。

在本发明的一些实施例中，当所述应用配置为所述模板级参数配置时，所述应用配置修改模块还包括：

参数值修改第二单元，用于如果所述参数名称与模版名称匹配，根据所述参数记录在内存参数表中修改对应参数名称对应的参数值，并根据所述内存参数表生成实体参数文件；

参数记录复制单元，用于如果所述参数名称与模版名称不匹配，在所述内存参数表中复制对应的参数记录，并裁剪所述模版名称，并根据所述内存参数表生成实体参数文件。

在本发明的一些实施例中，所述测试环境生成模块包括：

ID确定单元，用于根据所述RPA参数文件以及所述应用配置确定页面元素对应的ID；其中所述ID保持不变；

环境参数填写单元，用于在所述ID对应的参数页面中填写所述RPA参数文件中测试环境参数；

测试环境生成单元，用于根据所述参数页面生成所述测试环境。

在本发明的一些实施例中，所述应用运维模块包括：

投产验证单元，用于根据所述应用配置以及所述测试环境对所述微服务架构应用进行投产验证；

分支标签修改单元，用于根据所述应用配置以及所述测试环境修改所述微服务架构应用的代码库分支标签。

在本发明的一些实施例中，所述投产验证单元包括：

版本号确定单元，用于根据所述应用配置以及所述测试环境确定投产验证的验证点、所述验证点版本号以及所述微服务架构应用的版本号；

验证任务生成单元，用于根据所述验证点、所述验证点版本号以及所述微服务架构应用的版本号生成验证任务；

应用投产验证单元，用于根据所述验证任务对所述微服务架构应用进行投产验证。

第三方面，本发明提供一种计算机程序产品，包括计算机程序/指令，该计算机程序/指令被处理器执行时实现一种适用于微服务架构应用的运维方法的步骤。

第四方面，本发明提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行程序时实现适用于微服务架构应用的运维方法的步骤。

第五方面，本发明提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现适用于微服务架构应用的运维方法的步骤。

从上述描述可知，本发明实施例提供一种适用于微服务架构应用的运维方法及装置，适用于微服务架构应用的运维方法包括：首先根据预先获取的制品构建号生成RPA参数文件；根据RPA参数文件修改微服务架构应用的应用配置，应用配置包括应用级参数配置以及模板级参数配置；接着，根据RPA参数文件以及应用配置生成微服务架构应用的测试环境；最后根据应用配置以及测试环境对微服务架构应用进行运维。

本发明克服了研发运维一体化(DevOps)及微服务架构落地后增加运维工作难度的不足，提供一种实现简单，实施成本低，能够模拟人机交互、执行基于一定规则的可重复性任务、协同异构业务系统间的运维方法。

附图说明

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

图1为本发明的实施例中适用于微服务架构应用的运维方法的流程示意图；

图2为本发明的实施例中适用于微服务架构应用的运维方法的步骤100的流程示意图；

图3为本发明的实施例中适用于微服务架构应用的运维方法的步骤200的流程示意图一；

图4为本发明的实施例中适用于微服务架构应用的运维方法的步骤200的流程示意图二；

图5为本发明的实施例中适用于微服务架构应用的运维方法的步骤200的流程示意图三；

图6为本发明的实施例中适用于微服务架构应用的运维方法的步骤300的流程示意图；

图7为本发明的实施例中适用于微服务架构应用的运维方法的步骤500的流程示意图；

图8为本发明的实施例中适用于微服务架构应用的运维方法的步骤401的流程示意图；

图9为本发明的具体实施方式中适用于微服务架构应用的运维系统的方块图；

图10为本发明的具体实施方式中适用于微服务架构应用的运维方法的流程示意图；

图11为本发明的具体实施方式中步骤S1的流程示意图；

图12为本发明的具体实施方式中步骤S2的流程示意图；

图13为本发明的具体实施方式中步骤S3的流程示意图；

图14为本发明的具体实施方式中步骤S4的流程示意图；

图15为本发明的具体实施方式中步骤S5的流程示意图；

图16为本发明的具体实施方式中步骤S6的流程示意图；

图17为本发明的具体实施方式中步骤S7的流程示意图；

图18为本发明的具体实施方式中步骤S8的流程示意图；

图19为本发明的具体实施方式中步骤S9的流程示意图；

图20为本发明的具体实施方式中步骤S10的流程示意图；

图21为本发明的具体实施方式中步骤S11的流程示意图；

图22为本发明的具体实施方式中步骤S12的流程示意图；

图23为本发明的实施例中适用于微服务架构应用的运维装置的方块图；

图24为本发明的实施例中参数文件生成模块10的方块图；

图25为本发明的实施例中应用配置修改模块20的方块图一；

图26为本发明的实施例中应用配置修改模块20的方块图二；

图27为本发明的实施例中测试环境生成模块30的方块图；

图28为本发明的实施例中应用运维模块40的方块图；

图29为本发明的实施例中投产验证单元40a的方块图；

图30为本发明的实施例中的电子设备的结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整的描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

本申请技术方案中对数据的获取、存储、使用、处理等均符合法律法规的相关规定。

本发明的实施例提供一种适用于微服务架构应用的运维方法的具体实施方式，参见图1，该方法具体包括如下内容：

步骤100：根据预先获取的制品构建号生成RPA参数文件；

步骤200：根据所述RPA参数文件修改所述微服务架构应用的应用配置，所述应用配置包括应用级参数配置以及模板级参数配置；

步骤300：根据所述RPA参数文件以及所述应用配置生成所述微服务架构应用的测试环境；

步骤400：根据所述应用配置以及所述测试环境对所述微服务架构应用进行运维。

从上述描述可知，本发明实施例提供一种适用于微服务架构应用的运维方法，包括：首先根据预先获取的制品构建号生成RPA参数文件；根据RPA参数文件修改微服务架构应用的应用配置，应用配置包括应用级参数配置以及模板级参数配置；接着，根据RPA参数文件以及应用配置生成微服务架构应用的测试环境；最后根据应用配置以及测试环境对微服务架构应用进行运维。本发明具有以下有益效果：

独立于现有系统，采用非侵入方式实现异构系统之间的流程联动，且不破坏企业原有的IT结构。将日常运维的高频操作预先定义为明确的流程规则，并基于规则执行相应的任务流程，通过RPA机器人模拟人工操作，将企业员工从重复、繁琐、低价值的密集型劳动中释放出来。实现运维7×24小时不间断工作。提升运维操作执行的准确率，避免出现人为错误。

可以理解的是，步骤100中的RPA是指机器人流程自动化(Robotic ProcessAutomation，RPA)，是以软件机器人及人工智能(AI)为基础的业务流程自动化技术，通过模拟并增强人与计算机的交互过程、执行基于一定规则的可重复性任务、协同异构业务系统间的数据交互等方式，最终达到降本增效、降低业务操作风险的目的。步骤100的实施可以通过将制品构建号保存至预先生成的RPA的初始参数文件而实现。

针对步骤200，微服务架构应用的应用配置中的参数根据作用域不同分为应用级参数和模板级参数，两种参数的修改逻辑不同，应用级参数可根据参数名称直接修改，模板级参数需要根据参数名称和模板名称修改，而由于参数和模板是多对多关系，故需要进行一定的逻辑判断实施步骤200。

针对步骤300，生成测试环境资源是运维人员一项高频的重复性工作。现有的做法是运维人员登陆测试环境资源申请系统手工申请，由于需要填写较多的参数，工作效率较低。现在的做法是使用RPA编程的方式，自动化实现。由于申请页面会根据输入的参数是“新台账”或“旧台账”参数发生变化，无法使用一般的RPA录屏定位方法实现定位页面元素。本申请的实现方法是在测试环境资源申请系统开发阶段就和开发人员确定页面元素对应的ID，且页面元素对应的ID保持不变。自行使用JS实现通过ID定位页面元素的方法，从而实现自动填写页面参数并申请测试环境资源。

对于步骤400，本申请对于微服务架构应用运维包括以下几个方面：1)自动部署版本并在办公即时通讯软件中发通知；2)修改应用配置；3)申请测试环境资源；4)投产验证；5)修改代码库分支标签；(6)版本持续交付系统中的流水线修复；(7)收集性能测试监控结果；(8)修复PaaS云平台容器启动失败；9)检查日志级别；10)修正应用参数错误；11)检查微服务架构应用部署脚本文件正确性；以及12)在制品库录入过程版本号。

在本发明的一些实施例中，所述RPA参数文件的格式为键值对格式；参见图2，步骤100包括：

步骤101：将所述制品构建号转换为所述键值对格式，其中所述制品构建号为键值对的值；

步骤102：将所述制品构建号插入初始的RPA参数文件，以生成所述RPA参数文件。

在本发明的一些实施例中，当所述应用配置为所述应用级参数配置时，参见图3，步骤200包括：

步骤201：按参数名称从所述RPA参数文件筛选需要修改的参数记录；

具体地，首先读取RPA参数表，以获取需要修改的数据列表，并从云端平台下载应用参数表并保存至本地，接着，读取应用参数表，并按照参数名称从应用参数表筛选出需要修改的参数记录。

步骤202：根据所述参数记录在内存参数表中修改对应参数名称对应的参数值；

步骤203：根据所述内存参数表生成实体参数文件。

具体地，根据内存参数表生成实体参数文件，并使用该实体参数文件更新云端平台对应的应用参数表。

在本发明的一些实施例中，当所述应用配置为所述模板级参数配置时，参见图4，步骤200还包括：

步骤204：如果所述参数名称与模版名称匹配，根据所述参数记录在内存参数表中修改对应参数名称对应的参数值，并根据所述内存参数表生成实体参数文件；

步骤205：如果所述参数名称与模版名称不匹配，在所述内存参数表中复制对应的参数记录，并裁剪所述模版名称，并根据所述内存参数表生成实体参数文件。

在步骤204以及步骤205中，由于模版级参数配置的应用配置中的参数和模版是多对多的关系，故修改模版级参数的判断的次数为指数级的。另外，在本发明的一些实施例中，参见图5，在步骤205之前，步骤200还包括：

步骤206：如果参数名称与模版名称仍旧不匹配，将完全不匹配的参数记录直接写入内存参数表中。

在本发明的一些实施例中，参见图6，步骤300包括：

步骤301：根据所述RPA参数文件以及所述应用配置确定页面元素对应的ID；其中所述ID保持不变；

步骤302：在所述ID对应的参数页面中填写所述RPA参数文件中测试环境参数；

步骤303：根据所述参数页面生成所述测试环境。

在步骤301至步骤303中，由于测试环境申请页面会根据输入的参数是“新台账”或“旧台账”参数发生变化，无法使用一般的RPA录屏定位方法实现定位页面元素。故这里在测试环境资源申请系统开发阶段就和开发人员根据RPA参数文件以及应用配置确定页面元素对应的ID，且页面元素对应的ID保持不变。并使用JS实现通过ID定位页面元素的方法，从而实现自动填写页面参数并申请测试环境资源。

在本发明的一些实施例中，参见图7，步骤400包括：

步骤401：根据所述应用配置以及所述测试环境对所述微服务架构应用进行投产验证；

步骤402：根据所述应用配置以及所述测试环境修改所述微服务架构应用的代码库分支标签。

随着DevOps的不断落地实施，微服务架构应用已经进入了持续交付标准化的时代，即将应用拆分为发布单元，一个发布单元对应一个部署节点，这样做的好处是可以实现应用解耦，避免出现“版本火车”的情况。与此同时会导致代码库的数量激增，增加配置管理人员的手工操作工作量，且容易出现人为操作失误导致的生产问题。例如：每期版本投产后，配置管理人员为区分不同的月度版本，需要手工修改代码库分支的标签，就是一项高度重复性的工作，且容易出现操作失误。

基于上述原因，使用步骤402的方式，实现了自动化修改Gerrit代码库分支标签。需要修改的标签及对应的文件路径预先保存在RPA参数文件中，提前设置好全局提交模板作为提交代码时自动录入的标识信息，自动启动Git Extentions完成拉取代码及相关标签修改动作，最后完成修改后的代码提交及推送。

在本发明的一些实施例中，参见图8，步骤401包括：

步骤4011：根据所述应用配置以及所述测试环境确定投产验证的验证点、所述验证点版本号以及所述微服务架构应用的版本号；

需要说明的事，步骤401的验证点包括容器健康检查、配置文件参数验证、镜像版本验证等内容。

步骤4012：根据所述验证点、所述验证点版本号以及所述微服务架构应用的版本号生成验证任务；

步骤4013：根据所述验证任务对所述微服务架构应用进行投产验证。

在步骤4011至步骤4013中，可以理解的是，微服务架构应用投产后验证是运维工作必不可少的工作内容。现有的做法是通过云端平台导入验证要点并实施投产后验证。由于微服务架构系统规模庞大，产生大量的验证结果，需要人工逐条查验，工作效率低且容易出现遗漏的情况。

而步骤4011至步骤4013实现了上述过程的自动化，即自动化投产验证以及自动化检查验证结果并将结果汇总后给用户发通知邮件，有效提高工作效率，避免人为操作失误。

对于步骤4013，需要特别说明的是关于分页的处理算法，具体地，先找到向前翻页按钮“Previous”，再定位到它的最后一个兄弟元素“Next”，”Next”的前一个页码即为需要分页的页数。

在一种具体实施方式中，本发明还提供一种适用于微服务架构应用的运维方法的具体实施方式，具体包括以下内容。

首先，参见图9，本发明提供一种适用于微服务架构应用的运维系统，该系统包括设计器、控制器以及客户端三个部分，具体地：

设计器(开发IDE)：RPA流程开发工具，所有自动化流程通过RPA专用开发工具进行开发；依托python、vb等多种开发语言进行机器人流程开发，依托录屏、控件抓取等进行用户UI交互和辅助开发流程发布于控制器。

控制器：RPA控制台，在前台制作和控制所有机器人代理的活动，负责任务调度、并将任务分配到每个客户端，负责客户端工作过程监督、管理及控制客户端运行过程出现异常，可由人工接管流程。

客户端：RPA客户端，在目标机器上执行命令。可部署在计算机物理终端和虚拟终端，执行具体任务，记录执行过程，支持集中或分散部署。

基于上述的适用于微服务架构应用的运维系统，参见图10，本发明提供的一种适用于微服务架构应用的运维方法的具体实施方式包括以下步骤：

S1：部署版本并在办公即时通讯软件中发通知。

在现有技术中，测试环境部署版本并通知测试人员进行测试是一项高频的日常运维工作。现有的做法是运维人员先登录VCDS(版本持续交付系统)获取制品的构建号，然后登录PaaS(平台即服务，一种云计算服务，提供了一种在云端运行应用程序的方式)完成制品部署相关工作，最后在办公及时通讯软件(IM)中群发消息通知测试人员进行测试。通过使用RPA编程方式，实现VCDS、PaaS、IM三个异构系统之间联动，不同系统之间通过RPA参数文件实现数据耦合，自动化完成上述操作，且不需要各系统对外暴露接口，或破坏原有的IT结构。程序处理逻辑流程图如图11所示。

S2：修改应用配置。

可以理解的是，微服务架构应用转型为微服务架构后，实现了应用和配置分离。配置文件中的参数目前的做法是需要运维人员手工修改，参数根据作用域不同分为应用级参数和模板级参数，两种参数的修改逻辑不同，应用级参数可根据参数名称直接修改，模板级参数需要根据参数名称和模板名称修改，由于参数和模板是多对多关系，修改模板级参数的判断次数呈指数级增长，需要运维人员完成大量重复性工作，容易出现错误。通过使用RPA编程的方式，实现了上述应用配置自动化修改，程序逻辑流程如图12所示。

S3：申请测试环境资源。

在现有技术中，申请测试环境资源是运维人员一项高频的重复性工作。现有的做法是运维人员登陆测试环境资源申请系统手工申请，由于需要填写较多的参数，工作效率较低。现在的做法是使用RPA编程的方式，自动化实现。由于申请页面会根据输入的参数是“新台账”或“旧台账”参数发生变化，无法使用一般的RPA录屏定位方法实现定位页面元素。步骤S3的实现方法是在测试环境资源申请系统开发阶段就和开发人员确定页面元素对应的ID，且页面元素对应的ID保持不变。自行使用JS实现通过ID定位页面元素的方法，从而实现自动填写页面参数并申请测试环境资源的目标，如图13所示。

S4：投产验证。

参见图14，首先登陆PaaS平台，导入验证要点(容器健康检查、配置文件参数验证、镜像版本验证)，接着选择微服务架构应用和验证要点的版本号，判断验证要点的数目是否超过预设阈值(例如100条)，如果超过，则选择当前页面要点开翻页，然后继续判断验证要点的数目是否超过预设阈值，如此进行循环操作。如果没有超过，则选择需要执行的验证业务，遍历验证结果并收集任务信息，最后登陆邮件系统给用户发送通知邮件。

对于上述的翻页操作有：先找到向前翻页按钮“Previous”，再定位到它的最后一个兄弟元素“Next”，”Next”的前一个页码即为需要分页的页数。

S5：修改Gerrit代码库分支标签。

随着DevOps的不断落地实施，微服务架构应用已经进入了持续交付标准化的时代，即将应用拆分为发布单元，一个发布单元对应一个部署节点，这样做的好处是可以实现应用解耦，避免出现“版本火车”的情况。但与此同时会导致代码库的数量激增，增加配置管理人员的手工操作工作量，且容易出现人为操作失误导致的生产问题。例如：每期版本投产后，配置管理人员为区分不同的月度版本，需要手工修改代码库分支的标签，就是一项高度重复性的工作，且容易出现操作失误。步骤S5通过使用RPA编程的方式，实现了自动化修改Gerrit代码库分支标签。需要修改的标签及对应的文件路径预先保存在RPA参数文件中，提前设置好全局提交模板作为提交代码时自动录入的标识信息，自动启动Git Extentions完成拉取代码及相关标签修改动作，最后完成修改后的代码提交及推送。程序处理逻辑的流程图如图15所示。具体地，首先读取RPA参数表并设置全局提交模板，接着启动GitExtentions，把分支拉取到本地，切换到要操作的分支；修版本库报定路径下所有文件中的版本库标签，最后对修改内容提交并推送。

S6：修复版本持续交付系统(VCDS)流水线。

持续集成流水线是应用版本持续集成的调度单位，应用版本通过持续集成流水线完成编译、构建、部署、测试等一系列工作，是DevOps的重要组成部分。在持续集成阶段经常出现持续集成流水线执行失败的情况，修复流水线失败是运维人员一项高频重复性工作，根据以往工作经验判断，重启流水线即可解决大多数的流水线失败问题。通过采用流水线自动重启与转人工相结合的方式，使用RPA编程实现了流水线自动修复功能，程序逻辑处理流程如图16所示。具体地，登陆VCDS系统，从RPA参数表读取流水线名称，按照名称对流水线进行查询。接着，检测流水线的状态，当流水线的状态为正常时，生产检测记录并写入结果文件，运维人员检查结果文件并按需转人工处理。当流水线的状态为异常时，进行快速修复，生成流水线修复记录并写入结果文件，运维人员检查结果文件并按需转人工处理。

S7：收集性能测试监控结果。

性能测试是DevOps的重要组成部分，实施微服务架构转型后，系统的架构变得非常复杂，节点数量众多，在每个节点上部署监控工具，并收集监控结果(运行日志、CPU、内存等性能测试监控指标)变成了一项高度重复性的工作，之前的做法是全部依靠人工处理，工作效率低且容易出现错误。目前使用RPA编程的方法实现了在服务器上自动部署性能测试监控工具，性能测试结果自动截图，自动下载应用程序运行日志等功能，程序逻辑流程图如图17所示。

S8：修复PaaS云平台容器启动失败。

微服务架构应用转型为微服务架构后，实现上云、容器化。由于应用变得更加复杂，涉及的容器数量众多，当容器状态异常时，增加了运维人员定位及处理的工作量。在工作实践中发现，导致容器启动失败的常见原因是k8s集群资源不足以及镜像文件在镜像仓库中不存在。以前的解决方法是依靠运维人员在数以百计的容器当中逐个排查、解决，效率低且增加了运维人员的工作压力。现在通过RPA编程方式，实现了自动化解决上述两类问题。程序的实现逻辑是通过页面元素定位获取对应容器状态的的html代码，然后对代码进行语法分析，判断对应的容器状态是成功还是失败。通过PaaS平台页面提示信息可以判断容器启动失败的原因，如果是由于k8s集群资源不足导致容器启动失败，则登陆统一视图平台查询剩余内存最多的集群，并将模板名称、模板版本、集群名称计入《更新部署集群表》，使用《更新部署集群表》在PaaS平台将模板更换到资源充足的集群，重新部署模板并启动容器。通过PaaS平台页面提示信息判断容器启动失败原因如果为镜像不存在，首先从PaaS平台页面获取不存在的镜像名称，然后从镜像仓库拉取不存在镜像，重新部署模板并重启。容器启动失败的详细处理逻辑如图18所示。

S9：检查应用日志级别参数。

在实际运维工作当中经常出现将测试环境的应用日志级别参数(通常为DEBUG，打印详细的日志信息，会产生大量的日志)带入生产环境(生产环境的日志级别通常为ERROR，仅输出比较严重的错误信息，产生的日志量少)的情况，导致生产环境因在短时间内产生大量日志而发生告警的问题。为避免此类问题发生，之前的做法是由运维人员对所有参数文件中关于日志级别的配置进行人工检查并修改不正确的配置。随着实施微服务、DevOps持续交付标准化改造，应用被拆分为大量发布单元(每个发布单元对应一种类型的节点且都具备独立的参数文件，例如应用、web等)，每个发布单元对应一个单独的代码库，可以单独的编译沟通，发布单元之间不存在依赖关系。导致代码库和应用节点数量大幅增长，给运维人员检查应用的日志级别带来巨大的工作压力。现在使用RPA编程的方法，实现自动化检查应用日志级别，并可以将检查结果给运维人员自动发送通知邮件，程序的处理逻辑如图19所示。

S10：修正应用参数错误。

实施应用微服务架构转型以后，实现了应用和配置分离，开发、测试、生产环境使用不同的配置文件，配置文件中的参数会因环境不同而存在差异。每期版本投产前、后，运维人员都需要手工修改应用配置文件中的参数，以适应不同环境及版本的需要，存在因参数修改错误，影响应用环境使用的风险。为规避上述风险，使用RPA编程的方法，实现应用参数错误自动修正功能。应用参数错误自动修正功能模块的程序处理逻辑如图20所示，具体地，首先从RPA参数表读取应用名称、上期参数名称和本期参数名称，接着登陆PaaS平台并按照参数名称下载上期和本期的参数文件，将上期和本期参数文件按照参数名称、所属模板名称为关键字进行比对，当两者不匹配时，生成删减表文件，并转人工处理。当两者匹配时，生成本期变量增量表文件并按照测试环境实际值进行修改，本期变量增量表文件和上期变量表文件合并生成新的本期变量参数文件，最后将新的本期变量参数文件提交到PaaS平台。

S11：检查微服务架构应用部署脚本文件正确性。

实施微服务架构转型后，配置管理人员经常需要修改应用的部署脚本文件(compose.json),经常出现由于人为修改导致的错误，影响应用系统正常构建及部署。根据工作实践中的经验，部署脚本文件(compose.json)会在PaaS平台中的指定页面加载，如果文件出现了修改错误会导致PaaS平台对应的页面加载失败。根据上述原理，使用RPA编程的方式实现了自动化检查微服务架构应用部署脚本文件(compose.json)的正确性。具体的程序处理逻辑参见图21。

S12：在制品库录入过程版本号。

参见图22，制品在交付到生产环境之前需要在制品库系统(以下简称SPMS)中录入过程版本号，之前的做法是运维人员手工将几十个过程版本号在SPMS中手工录入，工作效率低且容易出现人为操作失误。现有的做法是使用RPA编程的方式自动化实现。首先，从RPA参数文件中读取预先保存的制品库系统(SPMS)登陆相关信息，以及过程版本相关信息(包括版本号、应用名称、服务群组、发布范围、开发部门等信息)。然后，登陆制品库系统(SPMS)，模拟人工键盘、鼠标操作，循环完成全部过程版本信息的录入。最后，人工完成录入结果确认，确保结果准确无误。

从上述描述可知，本发明具体应用实例提供一种适用于微服务架构应用的运维方法，包括：首先根据预先获取的制品构建号生成RPA参数文件；根据RPA参数文件修改微服务架构应用的应用配置，应用配置包括应用级参数配置以及模板级参数配置；接着，根据RPA参数文件以及应用配置生成微服务架构应用的测试环境；最后根据应用配置以及测试环境对微服务架构应用进行运维。本发明具有以下有益效果：

(1)提高效率：能够模拟人类操作，自动执行重复性、繁琐的任务，从而提高了工作效率。这些任务通常需要花费大量时间和人力，而本发明可以快速、准确地完成它们，减少了人工操作的时间和错误。

(2)降低成本：自动化执行许多任务，因此企业可以减少雇佣人力来完成这些任务的成本。此外，本发明还可以在非工作时间自动执行任务，避免了人力成本的浪费。

(3)提高质量：准确地执行任务，避免了任务错误和疏漏。这有助于提高工作质量，减少错误和漏洞。

(4)增强安全性：可以避免任务操作可能带来的安全风险，例如操作失误或数据泄露等。此外，还可以通过加密、身份验证等措施来保护数据的安全性。

(5)促进创新：可以帮助企业将人力资源从繁琐、重复的任务中解放出来，从而让他们有更多的时间和精力投入到创新和增值工作中。这有助于企业实现转型升级，提高竞争力。

(6)改进员工体验：可以帮助员工从繁琐、重复的任务中解脱出来，从而让他们有更多的时间和精力投入到更有意义的工作中。这有助于提高员工的工作满意度和归属感，从而改进员工体验。

(7)无需改造现有系统：独立于现有系统，采用非侵入式方式实现异构系统之间的流程联动，不会破坏企业原有IT结构。

基于同一发明构思，本申请实施例还提供了一种适用于微服务架构应用的运维装置，可以用于实现上述实施例所描述的方法，如下面的实施例。由于适用于微服务架构应用的运维装置解决问题的原理与适用于微服务架构应用的运维方法相似，因此适用于微服务架构应用的运维装置的实施可以参见适用于微服务架构应用的运维方法实施，重复之处不再赘述。以下所使用的，术语“单元”或者“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的系统较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

本发明的实施例提供一种能够实现适用于微服务架构应用的运维方法的适用于微服务架构应用的运维装置的具体实施方式，参见图23，一种适用于微服务架构应用的运维装置具体包括如下内容：

参数文件生成模块10，用于根据预先获取的制品构建号生成RPA参数文件；

应用配置修改模块20，用于根据所述RPA参数文件修改所述微服务架构应用的应用配置，所述应用配置包括应用级参数配置以及模板级参数配置；

测试环境生成模块30，用于根据所述RPA参数文件以及所述应用配置生成所述微服务架构应用的测试环境；

应用运维模块40，用于根据所述应用配置以及所述测试环境对所述微服务架构应用进行运维。

在本发明的一些实施例中，参见图24，所述RPA参数文件的格式为键值对格式；所述参数文件生成模块10包括：

构建号转换单元10a，用于将所述制品构建号转换为所述键值对格式，其中所述制品构建号为键值对的值；

构建号插入单元10b，用于将所述制品构建号插入初始的RPA参数文件，以生成所述RPA参数文件。

在本发明的一些实施例中，参见图25，当所述应用配置为所述应用级参数配置时，所述应用配置修改模块20包括：

书记录筛选单元20a，用于按参数名称从所述RPA参数文件筛选需要修改的参数记录；

参数值修改第一单元20b，用于根据所述参数记录在内存参数表中修改对应参数名称对应的参数值；

参数文件生成单元20c，用于根据所述内存参数表生成实体参数文件。

在本发明的一些实施例中，参见图26，当所述应用配置为所述模板级参数配置时，所述应用配置修改模块20还包括：

参数值修改第二单元20d，用于如果所述参数名称与模版名称匹配，根据所述参数记录在内存参数表中修改对应参数名称对应的参数值，并根据所述内存参数表生成实体参数文件；

参数记录复制单元20e，用于如果所述参数名称与模版名称不匹配，在所述内存参数表中复制对应的参数记录，并裁剪所述模版名称，并根据所述内存参数表生成实体参数文件。

在本发明的一些实施例中，参见图27，所述测试环境生成模块30包括：

ID确定单元30a，用于根据所述RPA参数文件以及所述应用配置确定页面元素对应的ID；其中所述ID保持不变；

环境参数填写单元30b，用于在所述ID对应的参数页面中填写所述RPA参数文件中测试环境参数；

测试环境生成单元30c，用于根据所述参数页面生成所述测试环境。

在本发明的一些实施例中，参见图28，所述应用运维模块40包括：

投产验证单元40a，用于根据所述应用配置以及所述测试环境对所述微服务架构应用进行投产验证；

分支标签修改单元40b，用于根据所述应用配置以及所述测试环境修改所述微服务架构应用的代码库分支标签。

在本发明的一些实施例中，参见图29，所述投产验证单元40a包括：

版本号确定单元40a1，用于根据所述应用配置以及所述测试环境确定投产验证的验证点、所述验证点版本号以及所述微服务架构应用的版本号；

验证任务生成单元40a2，用于根据所述验证点、所述验证点版本号以及所述微服务架构应用的版本号生成验证任务；

应用投产验证单元40a3，用于根据所述验证任务对所述微服务架构应用进行投产验证。

从上述描述可知，本发明实施例提供一种适用于微服务架构应用的运维装置，包括：参数文件生成模块，用于根据预先获取的制品构建号生成RPA参数文件；应用配置修改模块，用于根据RPA参数文件修改微服务架构应用的应用配置，应用配置包括应用级参数配置以及模板级参数配置；测试环境生成模块，用于根据RPA参数文件以及应用配置生成微服务架构应用的测试环境；应用运维模块，用于根据应用配置以及测试环境对微服务架构应用进行运维。

本发明克服了研发运维一体化(DevOps)及微服务架构落地后增加运维工作难度的不足，提供一种实现简单，实施成本低，能够模拟人机交互、执行基于一定规则的可重复性任务、协同异构业务系统间的运维方法。

本申请的实施例还提供能够实现上述实施例中的适用于微服务架构应用的运维方法中全部步骤的一种电子设备的具体实施方式，参见图30，电子设备具体包括如下内容：

处理器(processor)1201、存储器(memory)1202、通信接口(CommunicationsInterface)1203和总线1204；

其中，处理器1201、存储器1202、通信接口1203通过总线1204完成相互间的通信；通信接口1203用于实现服务器端设备以及用户端设备等相关设备之间的信息传输；

处理器1201用于调用存储器1202中的计算机程序，处理器执行计算机程序时实现上述实施例中的适用于微服务架构应用的运维方法中的全部步骤，例如，处理器执行计算机程序时实现下述步骤：

步骤100：根据预先获取的制品构建号生成RPA参数文件；

步骤200：根据所述RPA参数文件修改所述微服务架构应用的应用配置，所述应用配置包括应用级参数配置以及模板级参数配置；

步骤300：根据所述RPA参数文件以及所述应用配置生成所述微服务架构应用的测试环境；

步骤400：根据所述应用配置以及所述测试环境对所述微服务架构应用进行运维。

本申请的实施例还提供能够实现上述实施例中的适用于微服务架构应用的运维方法中全部步骤的一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，该计算机程序被处理器执行时实现上述实施例中的适用于微服务架构应用的运维方法的全部步骤，例如，处理器执行计算机程序时实现下述步骤：

步骤100：根据预先获取的制品构建号生成RPA参数文件；

步骤200：根据所述RPA参数文件修改所述微服务架构应用的应用配置，所述应用配置包括应用级参数配置以及模板级参数配置；

步骤300：根据所述RPA参数文件以及所述应用配置生成所述微服务架构应用的测试环境；

步骤400：根据所述应用配置以及所述测试环境对所述微服务架构应用进行运维。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于硬件+程序类实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

虽然本申请提供了如实施例或流程图的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的装置或用户端产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。

为了描述的方便，描述以上装置时以功能分为各种模块分别描述。当然，在实施本说明书实施例时可以把各模块的功能在同一个或多个软件和/或硬件中实现，也可以将实现同一功能的模块由多个子模块或子单元的组合实现等。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内部包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本说明书实施例的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

以上所述仅为本说明书实施例的实施例而已，并不用于限制本说明书实施例。对于本领域技术人员来说，本说明书实施例可以有各种更改和变化。凡在本说明书实施例的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本说明书实施例的权利要求范围之内。

Claims (10)

1.一种适用于微服务架构应用的运维方法，其特征在于，包括：

根据预先获取的制品构建号生成RPA参数文件；

根据所述RPA参数文件修改所述微服务架构应用的应用配置，所述应用配置包括应用级参数配置以及模板级参数配置；

根据所述RPA参数文件以及所述应用配置生成所述微服务架构应用的测试环境；

根据所述应用配置以及所述测试环境对所述微服务架构应用进行运维。

2.根据权利要求1所述的适用于微服务架构应用的运维方法，其特征在于，所述RPA参数文件的格式为键值对格式；

所述根据预先获取的制品构建号生成RPA参数文件，包括：

将所述制品构建号转换为所述键值对格式，其中所述制品构建号为键值对的值；

将所述制品构建号插入初始的RPA参数文件，以生成所述RPA参数文件。

3.根据权利要求1所述的适用于微服务架构应用的运维方法，其特征在于，当所述应用配置为所述应用级参数配置时，根据所述RPA参数文件修改所述微服务架构应用的应用配置，包括：

按参数名称从所述RPA参数文件筛选需要修改的参数记录；

根据所述参数记录在内存参数表中修改对应参数名称对应的参数值；

根据所述内存参数表生成实体参数文件。

4.根据权利要求3所述的适用于微服务架构应用的运维方法，其特征在于，当所述应用配置为所述模板级参数配置时，根据所述RPA参数文件修改所述微服务架构应用的应用配置，还包括：

如果所述参数名称与模版名称匹配，根据所述参数记录在内存参数表中修改对应参数名称对应的参数值，并根据所述内存参数表生成实体参数文件；

如果所述参数名称与模版名称不匹配，在所述内存参数表中复制对应的参数记录，并裁剪所述模版名称，并根据所述内存参数表生成实体参数文件。

5.根据权利要求1所述的适用于微服务架构应用的运维方法，其特征在于，根据所述RPA参数文件以及所述应用配置生成所述微服务架构应用的测试环境，包括：

根据所述RPA参数文件以及所述应用配置确定页面元素对应的ID；其中所述ID保持不变；

在所述ID对应的参数页面中填写所述RPA参数文件中测试环境参数；

根据所述参数页面生成所述测试环境。

6.根据权利要求1所述的适用于微服务架构应用的运维方法，其特征在于，根据所述应用配置以及所述测试环境对所述微服务架构应用进行运维，包括：

根据所述应用配置以及所述测试环境对所述微服务架构应用进行投产验证；

根据所述应用配置以及所述测试环境修改所述微服务架构应用的代码库分支标签。

7.根据权利要求1所述的适用于微服务架构应用的运维方法，其特征在于，根据所述应用配置以及所述测试环境对所述微服务架构应用进行投产验证，包括：

根据所述应用配置以及所述测试环境确定投产验证的验证点、所述验证点的版本号以及所述微服务架构应用的版本号；

根据所述验证点、所述验证点的版本号以及所述微服务架构应用的版本号生成验证任务；

根据所述验证任务对所述微服务架构应用进行投产验证。

8.一种适用于微服务架构应用的运维装置，其特征在于，包括：

参数文件生成模块，用于根据预先获取的制品构建号生成RPA参数文件；

应用配置修改模块，用于根据所述RPA参数文件修改所述微服务架构应用的应用配置，所述应用配置包括应用级参数配置以及模板级参数配置；

测试环境生成模块，用于根据所述RPA参数文件以及所述应用配置生成所述微服务架构应用的测试环境；

应用运维模块，用于根据所述应用配置以及所述测试环境对所述微服务架构应用进行运维。

9.一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现权利要求1至7任一项所述的适用于微服务架构应用的运维方法的步骤。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该计算机程序被处理器执行时实现权利要求1至7任一项所述的适用于微服务架构应用的运维方法的步骤。