多运行环境下的应用程序管理方法、设备、介质及产品与流程

1.本发明实施例涉及计算机技术领域，尤其涉及一种多运行环境下的应用程序管理方法、设备、介质及产品。


背景技术：

2.随着企业应用形态的不断变化和技术演进，越来越多的企业应用开发架构逐渐向微服务架构和云原生架构演进，应用系统的发布形态由单一环境集中式交付演变为多服务异构环境分散式交付场景。应用系统内部构成更加复杂多变，应用最终运行环境也随之变得复杂起来。从应用运行环境视角看，现阶段就会存在多种分散式单模形态运行环境混合在一起，即一个应用系统同时运行在各种容器云环境和传统虚拟化环境。双模应用就是针对这种特定场景提出的一种融合底层资源，屏蔽环境差异性，向应用提供统一的出口和管理平面，实现双模态应用自动化发布的机制。
3.现有应用发布系统管理维度主要立足于单模环境(虚拟机或者容器)组织发布资源，进行服务半自动化或者脚本化的发布，例如rancher(一个全面的可用于产品环境的容器管理平台)、walle(一个基于服务器形态进行应用自动化发布的开源项目)、jenkins(一个开源的持续集成与自动化发布系统)。但这些产品无法面对企业级、双模态应用需求多变、运行场景复杂、需统一纳管双模资源以及融合企业内部其他系统进行联合一体化协作管理。


技术实现要素：

4.本发明实施例提供一种多运行环境下的应用程序管理方法、设备、介质及产品，以实现多运行环境下应用程序的自动化发布，提高发布效率。
5.第一方面，本发明实施例提供一种多运行环境下的应用程序管理方法，应用于后端服务设备，所述方法包括：
6.接收用户在所述后端服务设备的交互界面中输入的对应用程序在各运行环境下发布的配置指令，其中配置指令包括各运行环境中的目标运行资源、配置参数、以及程序包；
7.将所述各运行环境下发布的配置指令分别发送至对应的各运行环境的控制端，以使各运行环境的控制端根据接收到的配置指令在对应运行环境下的目标运行资源上按照配置参数以及程序包进行应用程序发布。
8.第二方面，本发明实施例提供一种多运行环境下的应用程序管理方法，应用于虚拟机运行环境的处理设备，所述处理设备配置有代理进程，所述方法包括：
9.通过所述代理进程接收后端服务设备发送的应用程序在虚拟机运行环境下发布的配置指令，所述配置指令包括虚拟机运行环境的目标运行资源、配置参数、以及程序包；
10.由所述代理进程根据所述配置指令在目标运行资源中按照配置参数以及程序包创建所述应用程序的服务进程。
11.第三方面，本发明实施例提供一种多运行环境下的应用程序管理方法，应用于容器运行环境的控制设备，所述方法包括：
12.接收后端服务设备发送的应用程序在容器运行环境下发布的配置指令，所述配置指令包括容器运行环境的目标运行资源、配置参数、以及程序包；
13.根据所述配置指令通过软件开发工具包sdk在目标运行资源中按照配置参数以及程序包构建所述应用程序的镜像。
14.第四方面，本发明实施例提供一种后端服务设备，包括：
15.接收模块，用于接收用户在所述后端服务设备的交互界面中输入的对应用程序在各运行环境下发布的配置指令，其中配置指令包括各运行环境中的目标运行资源、配置参数、以及程序包；
16.发送模块，用于将所述各运行环境下发布的配置指令分别发送至对应的各运行环境的控制端，以使各运行环境的控制端根据接收到的配置指令在对应运行环境下的目标运行资源上按照配置参数以及程序包进行应用程序发布。
17.第五方面，本发明实施例提供一种虚拟机运行环境的处理设备，处理设备配置有代理进程，所述处理设备包括：
18.通信模块，用于通过所述代理进程接收后端服务设备发送的应用程序在虚拟机运行环境下发布的配置指令，所述配置指令包括虚拟机运行环境的目标运行资源、配置参数、以及程序包；
19.处理模块，用于由所述代理进程根据所述配置指令在目标运行资源中按照配置参数以及程序包创建所述应用程序的服务进程。
20.第六方面，本发明实施例提供一种容器运行环境的控制设备，包括：
21.通信模块，用于接收后端服务设备发送的应用程序在容器运行环境下发布的配置指令，所述配置指令包括容器运行环境的目标运行资源、配置参数、以及程序包；
22.处理模块，用于根据所述配置指令通过软件开发工具包sdk在目标运行资源中按照配置参数以及程序包构建所述应用程序的镜像。
23.第七方面，本发明实施例提供一种后端服务设备，包括：至少一个处理器；以及存储器；
24.所述存储器存储计算机执行指令；
25.所述至少一个处理器执行所述存储器存储的计算机执行指令，使得所述至少一个处理器执行如第一方面所述的方法。
26.第八方面，本发明实施例提供一种虚拟机运行环境的处理设备，包括：至少一个处理器；以及存储器；
27.所述存储器存储计算机执行指令；
28.所述至少一个处理器执行所述存储器存储的计算机执行指令，使得所述至少一个处理器执行如第二方面所述的方法。
29.第九方面，本发明实施例提供一种容器运行环境的控制设备，包括：至少一个处理器；以及存储器；
30.所述存储器存储计算机执行指令；
31.所述至少一个处理器执行所述存储器存储的计算机执行指令，使得所述至少一个
处理器执行如第三方面的所述的方法。
32.第十方面，本发明实施例提供一种多运行环境下的应用程序管理系统，包括如第七方面所述的后端服务设备、如第八方面所述的一种虚拟机运行环境的处理设备以及如第九方面所述的一种容器运行环境的控制设备。
33.第十一方面，本发明实施例提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，当处理器执行所述计算机执行指令时，实现如第一方面、或第二方面、或第三方面所述的方法。
34.第十二方面，本发明实施例提供一种计算机程序产品，包括计算机指令，该计算机指令被处理器执行时，实现如第一方面、或第二方面、或第三方面所述的方法。
35.本发明实施例提供的多运行环境下的应用程序管理方法、设备、介质及产品，通过后端服务设备接收用户在所述后端服务设备的交互界面中输入的对应用程序在各运行环境下发布的配置指令，其中配置指令包括各运行环境中的目标运行资源、配置参数、以及程序包；将各运行环境下发布的配置指令分别发送至对应的各运行环境的控制端，以使各运行环境的控制端根据接收到的配置指令在对应运行环境下的目标运行资源上按照配置参数以及程序包进行应用程序发布。通过后端服务设备对各运行环境的统筹管理，包括管理各运行环境的基础资源和程序包，实现不同运行环境下应用程序的集中管控，实现应用程序的自动化发布和自动化操作，无需跨网切换环境操作，减少人工介入环节，基于一套发布流程和规范，形成灵活的多层次的应用管理模式，实现应用程序基于统一入口，业务视角更清晰，避免以往通过资源维度去观测应用发布状态，应用发布的执行效率大幅提升，管理成本大幅下降。
附图说明
36.此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。
37.图1为本发明一实施例提供的多运行环境下的应用程序管理系统架构图；
38.图2为本发明一实施例提供的多运行环境下的应用程序管理方法流程图；
39.图3a为本发明一实施例提供的后端服务设备的交互界面示意图；
40.图3b为本发明另一实施例提供的后端服务设备的交互界面示意图；
41.图4为本发明一实施例提供的虚拟机运行环境交互示意图；
42.图5为本发明一实施例提供的容器运行环境交互示意图；
43.图6为本发明另一实施例提供的多运行环境下的应用程序管理方法流程图；
44.图7为本发明另一实施例提供的多运行环境下的应用程序管理方法流程图；
45.图8为本发明一实施例提供的后端服务设备的结构图；
46.图9为本发明一实施例提供的虚拟机运行环境的处理设备的结构图；
47.图10为本发明一实施例提供的容器运行环境的控制设备的结构图；
48.图11为本发明另一实施例提供的后端服务设备的结构图；
49.图12为本发明另一实施例提供的虚拟机运行环境的处理设备的结构图；
50.图13为本发明另一实施例提供的容器运行环境的控制设备的结构图。
51.通过上述附图，已示出本公开明确的实施例，后文中将有更详细的描述。这些附图
和文字描述并不是为了通过任何方式限制本公开构思的范围，而是通过参考特定实施例为本领域技术人员说明本公开的概念。
具体实施方式
52.这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。
53.随着企业应用形态的不断变化和技术演进，越来越多的企业应用开发架构逐渐向微服务架构和云原生架构演进，应用系统的发布形态由单一环境集中式交付演变为多服务异构环境分散式交付场景。应用系统内部构成更加复杂多变，应用最终运行环境也随之变得复杂起来。近年来以cncf社区主导的云原生技术理念和相关开源技术体系受到业界越来越多的关注，并逐渐发展成为主流技术形态。
54.如果说云计算的出现和发展相当于数字世界的重大发明成果，那么云原生就相当于一次“集装箱式”的创新变革，其具体表现形式就是推动应用向微服务架构转型，向以镜像封装应用运行环境为服务载体构建不可变的基础设施环境模式发展，现在的技术发展更加面向自动化设计、面向交付设计、面向弹性设计。在这种技术趋势下，以cncf kubernetes容器技术为底座搭建各种形态的容器云及其衍生系统成为交付弹性服务的主要途径。每一种新技术的流行，人们往往只看到新技术的优势，而忽略新技术背后的复杂性和自身技术现状以及企业历史技术债务问题。
55.可以预见的一种情况是，在相当长的时期内，大量的业务系统还是运行在以传统资源虚拟化技术主导的虚拟机环境中。从应用运行环境视角看，现阶段就会存在多种分散式单模形态运行环境混合在一起，即一个应用系统同时运行在各种容器云环境和传统虚拟化环境。双模应用就是针对这种特定场景提出的一种融合底层资源，屏蔽环境差异性，向应用提供统一的出口和管理平面，实现双模态应用自动化发布的机制。
56.现有应用发布系统管理维度主要立足于单模环境(虚拟机或者容器)组织发布资源，进行服务半自动化或者脚本化的发布，例如rancher(一个全面的可用于产品环境的容器管理平台)、walle(一个基于服务器形态进行应用自动化发布的开源项目)、jenkins(一个开源的持续集成与自动化发布系统)。这些产品在某些细分领域的具体实现已经做到极致，但是在面对企业级、双模态应用需求多变、运行场景复杂、需统一纳管双模资源以及融合企业内部其他系统进行联合一体化协作管理时又显得力不从心。所以，迫切需要一种新型的面向双模应用自动化发布的技术手段，实现既能匹配未来规模化应用云原生技术体系的需求，又能兼容现阶段技术混合发展的现状。
57.现有的双模应用发布主要存在以下几点不足：
58.1)双模应用区别于传统单一技术栈应用系统，其运行环境更加复杂，服务实例数更多，应用发布人员需要在不同发布系统和虚拟化环境中进行操作，来回切换操作导致发布效率低下，技术成本较高，同时很多应用系统没有实现全过程自动化的发布能力，操作过程断点多，人工介入环节较多，需要手工操作和执行脚本的辅助，极容易出现操作失误的现象。双模应用通常运行在不同环境，隶属于不同的工作空间，分散在不同的数据中心，使用
不同的流程，会引入更多风险。增加更多的人员往往不能解决这方面的问题，甚至可能会适得其反。
59.2)应用双模化逐渐成为常态，应用实际运行所需的各类制品包来源较多，包括虚拟机形态构建的运行包和容器形态的镜像包，根据历史经验发现，系统问题经常暴露在应用发布时，常见的现象就是运行包版本不一致。对于双模应用来说，环境更复杂，影响因素更多，影响面更大，现有技术虚拟机环境与容器环境镜像构建的制品物是分散管理的，其特征就是不同平台不同来源，容易出现实际运行程序版本不一致的现象，最终导致应用运行状态不符合预期效果，严重时服务甚至不可用，影响用户体验。
60.3)现有技术实现中双模应用没有收口到同一管理平面，技术能力集约化程度不高，其表现特征就是过于关注物理资源，没有以应用为视角，导致应用服务构成、运行实例、服务配置参数、资源配额、运行状态监控是分散到不同系统中的，应用基础运行环境呈现出一种发散的态势，技术要素不能聚合收敛，难以统一管控，导致应用发布综合成本、协同管理的效率和质量大打折扣，难以匹配生产环境的严苛要求。
61.针对上述至少一个技术问题，本发明实施例提供一种多运行环境下的应用程序管理方法，基于多运行环境下的应用程序管理系统，多运行环境下的应用程序管理系统中包括后端服务设备以及多运行环境的运行设备，多运行环境可以包括虚拟机运行环境和容器运行环境，后端服务设备可以接收用户在所述后端服务设备的交互界面中输入的对应用程序在各运行环境下发布的配置指令，其中配置指令包括各运行环境中的目标运行资源、配置参数、以及程序包；将所述各运行环境下发布的配置指令分别发送至对应的各运行环境的控制端，以使各运行环境的控制端根据接收到的配置指令进行对应运行环境下的应用程序发布。通过后端服务设备对各运行环境的统筹管理，包括管理各运行环境的基础资源和程序包，实现双模应用的集中管控，实现应用程序的自动化发布和自动化操作，无需跨网切换环境操作，减少人工介入环节，基于一套发布流程和规范，形成灵活的多层次的双模应用管理模式，实现双模应用基于统一入口，业务视角更清晰，避免以往通过资源维度去观测应用发布状态，应用发布的执行效率大幅提升，管理成本大幅下降。
62.本发明实施例提供一种多运行环境下的应用程序管理系统，其系统架构如图1所示，包括后端服务设备、虚拟机运行环境以及容器运行环境；其中，虚拟机运行环境的处理设备中除了部署应用程序的业余进程外，还部署有代理(agent)进程，用于与后端服务设备连接，接收后端服务设备的发布指令处理虚拟机运行环境的自动化操作；而容器运行环境中包括多个服务器集群，还部署有容器运行环境的控制设备，用于与后端服务设备连接，接收后端服务设备的发布指令处理容器运行环境的自动化操作，其中容器运行环境的控制设备通过软件开发工具包(software development kit，sdk)与容器运行环境的各服务器集群连接。而应用程序通常包括多个服务，每个服务包括至少一个服务实例，可以根据实际情况选择各服务实例在虚拟机运行环境的至少一个进程运行和/或在容器运行环境的至少一个服务器运行。基于上述多运行环境下的应用程序管理系统，可通过后端服务设备对各运行环境的统筹管理，实现应用程序的自动化发布和自动化操作。
63.下面以具体地实施例对本发明的技术方案以及本技术的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本发明的实施例进行描述。
64.图2为本发明实施例提供的多运行环境下的应用程序管理方法的流程图。本实施例提供了一种多运行环境下的应用程序管理方法，其执行主体为应用于后端服务设备，该多运行环境下的应用程序管理方法具体步骤如下：
65.s201、接收用户在所述后端服务设备的交互界面中输入的对应用程序在各运行环境下发布的配置指令，其中配置指令包括各运行环境中的目标运行资源、配置参数、以及程序包。
66.在本实施例中，后端服务设备配置有交互界面，通过后端服务设备的交互界面可以对各运行环境下的应用程序进行集中管理，其中运行环境包括但不限于虚拟机运行环境和容器运行环境，后端服务设备的交互界面可以进行运行资源管理，如图3a所示，例如对工作空间的管理、不同运行环境资源管理、应用资源配额管理等；后端服务设备的交互界面还可应用程序发布和管理，例如在不同运行环境下发布应用程序、以及对应用程序中的某个目标服务进行启动、停止、重启、对应用程序进行更新，还可监控不同运行环境下的应用程序的运行状态等等；后端服务设备的交互界面还可以进行程序制品物管理，例如包括对虚拟机运行环境中服务软件运行包的管理、对容器运行环境中镜像包的管理；此外，后端服务设备的交互界面还可以进行服务实例管理，例如分配服务实例的运行环境等。当然后端服务设备的交互界面还可以进行其他的功能，此处不再一一赘述。后端服务设备提供了与应用程序发布不同运行环境的交互接口api，承载着整个应用程序自动化发布后端核心交互逻辑的实现。可选的，如图3b所示，后端服务设备的交互界面在同一界面集中管理应用程序在多个运行环境多种工作空间的所有实例，例如应用a的服务a的各实例，可显示实例的发布状态，例如待发布、发布中、发布成功、异常等，应用程序组织结构、运行环境、工作空间、实例信息均可轻易获取到，极大地提升了应用程序在复杂环境下的管理效率。应用服务是承载应用实际可运行的程序包，通常一个典型应用会包含web服务、数据服务、集成服务、console(控制台)服务或者类似结构构成，服务具体表现上是一个实际可运行的程序载体，该程序载体可以使用java、python、golang、nodejs(javascript)、c/c 等任一种开发语言编写。
67.在需要进行应用程序的发布时，如图3a所示，基于后端服务设备的交互界面，用户可以对待发布的应用程序在各运行环境中分配目标运行资源，例如可以先分配工作空间，工作空间可包括开发态工作空间(开发区)、测试态工作空间(测试区)、预发态工作空间、生产态工作空间、灰度工作空间，工作空间的定义与运用方式取决于企业的管理规范，工作空间是指从管理模式上针对不用运行环境下应用程序进行多维度聚合管理的一种组织方法，这种划分方法充分融合了不同运行环境(可包括经典虚拟机和容器)、应用内部服务组成结构、服务实际运行的实例、服务运行的状态等多元化信息，将应用程序多场景的管理要素融为一体，进一步的，在分配工作空间后，还可对于工作空间分配各运行环境的运行资源，包括经典虚拟机形态ip信息和容器集群信息；用户还可以在交互界面输入配置参数、以及程序包等等，配置参数还可包括应用信息，应用信息通常采集应用名称、负责人、所属业务线、应用描述等内容。
68.s202、将所述各运行环境下发布的配置指令分别发送至对应的各运行环境的控制端，以使各运行环境的控制端根据接收到的配置指令在对应运行环境下的目标运行资源上按照配置参数以及程序包进行应用程序发布。
69.在本实施例中，后端服务设备在接收到对应用程序在各运行环境下发布的配置指令后，将各运行环境下发布的配置指令分别发送至对应的各运行环境的控制端。
70.可选的，对于虚拟机运行环境，将所述虚拟机运行环境下发布的配置指令发送给虚拟机运行环境的处理设备上的代理进程，以使所述代理进程根据接收到的配置指令在所述虚拟机运行环境下的目标运行资源中按照配置参数以及程序包创建所述应用程序的服务进程。
71.在本实施例中，虚拟机运行环境的处理设备上部署代理(agent)进程，用于根据后端服务设备的发布指令处理虚拟机运行环境的自动化操作，包括与后端服务接口通信获取应用部署包进行部署动作，通常执行指令有启动服务、停止服务、重启服务、更新程序包，其中，对于应用程序的每一业务进程，可以对应一个代理进程，通过该进程实现对业务进程的启动、停止、重启、更新等。另外，agent进程还可定期轮询监测应用的运行状态，健康检查，捕捉应用的调用链信息，上报应用运行日志。
72.后端服务设备可根据经典虚拟机形态的ip信息自动化部署agent进程，该进程基于ip地址信息与部署实例通信。目前存在一种通信方式，通过采集账户信息、端口信息、认证key等信息，基于ssh账户认证或者ssh(secure shell，安全外壳协议)key免密通信，该方法经常被安全扫描规则所限制，也被视为安全风险较高的环节，本实施例中虚拟机运行环境下的目标运行资源，也即应用部署实例，与后端服务设备通信方法是基于http标准协议进行通信，http通信容易穿越防火墙，同时也可以充分利用企业内部waf(web application firewal，网络应用防火墙)防护能力。如图4所示，在经典虚拟机运行环境形态下本实施例中应用程序自动化发布的交互过程，经典虚拟机运行环境包括基于openstack构建的私有云、商业iaas资源池管理系统、公有云ecs云主机、vmware虚拟化等环境提供的虚拟机运行环境，可选的，直接基于物理机安装操作系统提供的运行环境也适用于本方法。
73.可选的，对于容器运行环境，将所述容器运行环境下发布的配置指令发送给容器运行环境的控制设备，以使所述控制设备根据接收到的配置指令通过软件开发工具包在所述容器运行环境下的目标运行资源中按照配置参数以及程序包构建所述应用程序的镜像。
74.在本实施例中，容器运行环境部署控制设备，控制设备可安装有服务自动化发布执行程序，用于实现基于kubernetes搭建的容器云环境应用服务的自动化发布能力，无须通过脚本提交yaml编排文件方式与kubernetes平台交互，本实施例控制设备直接与kubernetes底层api server进行交互，控制粒度更精细准确，更能匹配双模应用对运行环境苛刻的要求，其交互方式可采用http标准协议。
75.在本实施例中，后端服务设备可根据容器集群信息对应用程序进行基于容器平台创建workload(工作负载，是一种基于kubernetes容器平台抽象的服务运行类型的分类描述，常用的workload包括无状态服务deployment、有状态服务statefulset、一次性任务job、定时任务cronjob、守护任务控制器daemonset，本实施例中可采用deployment和cronjob类型的workload)的过程，容器平台可以为kubernetes容器平台，在容器运行环境的控制设备中，容器端自动发布程序基于开源项目fabric8io kubernetes-client sdk与kubernetes api server进行交互，可选的，也可通过fabric8io sdk与redhat openshift(另外一种基于kubernetes的商业化容器平台)进行交互，可实现与社区版kubernetes容器平台类似的发布效果。基于fabric8io kubernetes-client sdk软件开发工具包所提供的
dsl(domain specified language，一种领域专用描述语言)开发的代码与cncf kubernetes声明式资源描述机制保持良好的兼容性，例如fabric8io定义基础资源类kubernetesresource映射kubernetes api resource，编码逻辑较为清晰。本实施例中容器运行环境的控制设备的容器端自动发布程序基于fabric8io kubernetes-client sdk实现了应用程序对应容器环境多个集群的命名空间，该容器命名空间与应用所分配的工作空间相关关联，基于工作空间与容器命名空间多对多的关联关系，灵活实现跨容器集群自动化部署。如图5展示了基于kubernetes容器环境下应用程序自动化发布的交互过程，容器运行环境的控制设备可根据后端服务设备的发布指令处理容器运行环境的自动化操作，包括与后端服务接口通信获取应用部署包进行部署动作，通常执行指令有启动服务、停止服务、重启服务、更新程序包，另外，还可定期轮询监测应用的运行状态，健康检查，捕捉应用的调用链信息，上报应用运行日志。
76.应用程序发布所需的可执行的制品程序包由系统制品物管理模块实现，包括虚拟机服务软件运行包、容器镜像包，也可以通过openapi方式接入企业内部其他devops构建的制品物。
77.在多运行环境发布应用程序时，经常容易出现的一种错误现象，也即不同运行环境实际运行的载体程序包版本不一致导致的服务异常，问题根源在于传统单模运行环境下，服务构建过程是分离的，本实施例中应用程序自动化发布时，强调通过与经典虚拟机环境同源的软件运行程序包构建双模形态下的运行制品物，即应用所属服务的容器镜像，单独管理应用制品物版本，本实施例则可基于应用发布单做一致性校验，也即对不同运行环境的应用制品物版本做一致性校验。特别的，容器运行态所需的镜像基于虚拟机服务软件运行包同源的可运行程序作为基础依赖，在系统内实现一套自动化编译构建容器镜像和镜像仓库的管理能力，统一构建并标识相同的版本号，通过技术手段保障双模环境下服务最终运行载体的一致性，减少系统发布事故。可选的，本实施例在将所述各运行环境下发布的配置指令分别发送至对应的各运行环境的控制端时，可以先检测各运行环境下发布的配置指令中程序包的版本是否相同；若版本相同，则将所述各运行环境下发布的配置指令分别发送至对应的各运行环境的控制端，从而保证不同运行环境的应用制品物版本的一致性。
78.在本实施例中，应用程序的自动化发布，通过在某个工作空间中选择具体的服务，填写服务运行所需的必备参数信息、选择系统内的程序运行包或者容器镜像，设置双模应用各个服务的目标资源，由自动化执行程序完成对目标资源全过程自动化发布，并对外提供服务，无须脚本或者进入服务器物理环境或者shell交互界面操作，实现无人值守模式全自动化的服务发布，同时实现应用健康自检、服务暴露、日志上报、环境清理等能力。
79.可选的，本实施例应用执行过程中涉及到资源库搭建、应用工作空间关联、应用资源申请、配额申请、服务发布、服务管理(上下线、重启、升降配、扩缩容等操作)等环节均需要通过流程审批模块执行，流程通过后才可以执行后续动作。本实施例自动化发布过程提供统一的流程操作入口，确保所有的操作留痕，可追溯。
80.在上述实施例的基础上，用户可基于后端服务设备的交互界面实现对各运行环境下的应用程序的某些目标操作，所述目标操作包括但不限于对应用程序的目标服务的启动操作、停止操作、重启操作、以及对应用程序更新操作，后端服务设备在接收到用户通过所述交互界面输入的对应用程序的操作指令(所述操作指令包括对目标运行环境下的应用程
序的目标操作)后，根据所述操作指令向目标运行环境的控制端发送目标操作对应的控制指令，以使所述目标运行环境的控制端根据控制指令对所述应用程序执行所述目标操作，其中对于虚拟机运行环境，由虚拟机运行环境的处理设备上的代理进程执行所述目标操作，对于容器运行环境，由容器运行环境的控制设备执行所述目标操作。
81.在上述实施例的基础上，各运行环境的控制端还可对应用程序的运行状态进行监控，其中对于虚拟机运行环境，由虚拟机运行环境的处理设备上的代理进程监控应用程序的运行状态，对于容器运行环境，由容器运行环境的控制设备监控应用程序的运行状态，后端服务设备可接收任一运行环境的控制端发送的应用程序的运行状态监控信息，并将所述运行状态监控信息显示于所述交互界面，以展示给用户、或者在应用程序的运行状态异常时进行告警。
82.本实施例提供的多运行环境下的应用程序管理方法，通过后端服务设备接收用户在所述后端服务设备的交互界面中输入的对应用程序在各运行环境下发布的配置指令，其中配置指令包括各运行环境中的目标运行资源、配置参数、以及程序包；将各运行环境下发布的配置指令分别发送至对应的各运行环境的控制端，以使各运行环境的控制端根据接收到的配置指令在对应运行环境下的目标运行资源上按照配置参数以及程序包进行应用程序发布。通过后端服务设备对各运行环境的统筹管理，包括管理各运行环境的基础资源和程序包，实现不同运行环境下应用程序的集中管控，实现应用程序的自动化发布和自动化操作，无需跨网切换环境操作，减少人工介入环节，基于一套发布流程和规范，形成灵活的多层次的应用管理模式，实现应用程序基于统一入口，业务视角更清晰，避免以往通过资源维度去观测应用发布状态，应用发布的执行效率大幅提升，管理成本大幅下降。
83.在云原生相关技术逐渐发展成为主流技术趋势下，现有企业应用在向微服务架构和云原生架构演进的过渡阶段所面临的应用混合发布、环境多变、事故多发的问题，本实施例提出一种针对不同运行环境固有特点构建应用管理体系以及自动化发布方法，区别于以往单模环境基于资源视角的自动化发布方法和系统，本实施例开创性地从设计源头上就考虑基于资源融合式、面向双模应用特色、面向交付设计，围绕应用微服务化，提出基于工作空间划分双模物理层资源，统一纳管不用运行环境基础资源和运行态制品物，保障基础环境和最终运行应用程序载体的一致性，构建天然适配多服务异构环境的自动化发布机制，以虚拟机形态自动化发布服务agent程序和基于cncf kubernetes为技术底层的容器云自动化执行器程序协作实现不同运行环境目标资源的自动化操作，实现应用程序全局视角的管控平面，磨平了应用程序在异构环境和工作空间的差异性，解决了双模形态下跨平台多种类型工作空间应用服务过于分散而不能协同管理的问题，提高应用生命周期全过程集约化管理的程度，减少人工介入环节，极大程度避免对运行环境误操作导致的事故，从技术手段上对应用程序在不同运行环境进行合理分离和整合，有效地保障了应用系统运行环境的稳定性和安全性。
84.本实施例在资源管理方法上区别于以往单模环境的资源管理，本实施例站在应用视角，以工作空间和分组两个维度管理双模环境的所有资源，包括虚拟机资源池和容器集群，最终聚合形成面向应用全局可用的资源池，进而在发布应用程序时分配资源。从应用构成到发布运行的全过程管理均在同一系统，一套自动化发布规范实现双模形态的服务自动化发布与管理职能，无须跨网切换环境操作。
85.业界实践证明容器是现阶段打包和运行应用服务程序的最佳实践，其主要特征就是为应用构建标准化的容器镜像，作为程序实际运行载体对外暴露服务。传统方式在对应双模场景时往往不注重容器镜像构建所采用的制品包与虚拟机形态制品包的一致性，也就是说，如果想减少应用出错的概率，就需要确保构建容器镜像所采用的程序运行包和虚拟机形态的制品包版本的一致性。特别的，本实施例实现了基于虚拟机制品包和自定义dockerfile文件统一构建标准化的镜像，并统一纳管镜像和软件制品包，作为应用程序自动化发布的基础依赖，从技术手段上维护最终运行程序的版本一致性。
86.本实施例通过后端服务设备从统一的管理平面纳管不同运行环境基础资源并在物理资源操作层面实施自动化发布，填平双模应用发布过程的断点，以业务线、应用、工作空间、服务、分组细粒度组织双模应用资源，聚合资源管理、服务配置参数、统一管理真实环境运行制品物(虚拟机形态软件运行包和容器镜像)，基于一套发布流程和规范，形成灵活的多层次的双模应用管理模式，实现双模应用基于统一入口，管理跨工作空间异构环境的应用服务和所有实例，业务视角更清晰，避免以往通过资源维度去观测应用发布状态，应用发布的执行效率大幅提升，管理成本大幅下降。
87.图6为本发明实施例提供的多运行环境下的应用程序管理方法的流程图。本实施例提供了一种多运行环境下的应用程序管理方法，其执行主体为虚拟机运行环境的处理设备，所述处理设备配置有代理进程，该多运行环境下的应用程序管理方法具体步骤如下：
88.s501、通过所述代理进程接收后端服务设备发送的应用程序在虚拟机运行环境下发布的配置指令，所述配置指令包括虚拟机运行环境的目标运行资源、配置参数、以及程序包；
89.s502、由所述代理进程根据所述配置指令在目标运行资源中按照配置参数以及程序包创建所述应用程序的服务进程。
90.本实施例提供的多运行环境下的应用程序管理方法是虚拟机运行环境的处理设备侧的方法，其具体实现和技术效果可参见上述实施例，此处不再赘述。
91.进一步的，所述多运行环境下的应用程序管理方法还包括：
92.通过所述代理进程接收后端服务设备发送的控制应用程序执行目标操作的控制指令；由所述代理进程根据所述控制指令对所述应用程序执行所述目标操作。可选的，所述目标操作包括对应用程序的目标服务的启动操作、停止操作、重启操作、以及对应用程序更新操作。
93.进一步的，所述多运行环境下的应用程序管理方法还包括：
94.通过所述代理进程监控应用程序的运行状态，得到应用程序的运行状态监控信息；通过所述代理进程将所述运行状态监控信息发送给所述后端服务设备，以显示于后端服务设备的交互界面，以展示给用户、或者在应用程序的运行状态异常时进行告警。
95.图7为本发明实施例提供的多运行环境下的应用程序管理方法的流程图。本实施例提供了一种多运行环境下的应用程序管理方法，其执行主体为容器运行环境的控制设备，该多运行环境下的应用程序管理方法具体步骤如下：
96.s601、接收后端服务设备发送的应用程序在容器运行环境下发布的配置指令，所述配置指令包括容器运行环境的目标运行资源、配置参数、以及程序包；
97.s602、根据所述配置指令通过软件开发工具包sdk在目标运行资源中按照配置参
数以及程序包构建所述应用程序的镜像。
98.本实施例提供的多运行环境下的应用程序管理方法是容器运行环境的控制设备侧的方法，其具体实现和技术效果可参见上述实施例，此处不再赘述。
99.进一步的，所述多运行环境下的应用程序管理方法还包括：
100.接收后端服务设备发送的控制应用程序执行目标操作的控制指令；根据所述控制指令通过sdk对所述应用程序执行所述目标操作。其中，可选的，所述目标操作包括对应用程序的目标服务的启动操作、停止操作、重启操作、以及对应用程序更新操作。
101.进一步的，所述多运行环境下的应用程序管理方法还包括：
102.通过sdk监控应用程序的运行状态，得到应用程序的运行状态监控信息；将所述运行状态监控信息发送给所述后端服务设备，以显示于后端服务设备的交互界面，以展示给用户、或者在应用程序的运行状态异常时进行告警。
103.图8为本发明实施例提供的后端服务设备的结构图。本实施例提供的后端服务设备可以执行后端服务设备侧的方法实施例提供的处理流程，如图8所示，所述后端服务设备700包括接收模块701以及发送模块702。
104.接收模块701，用于接收用户在所述后端服务设备的交互界面中输入的对应用程序在各运行环境下发布的配置指令，其中配置指令包括各运行环境中的目标运行资源、配置参数、以及程序包；
105.发送模块702，用于将所述各运行环境下发布的配置指令分别发送至对应的各运行环境的控制端，以使各运行环境的控制端根据接收到的配置指令在对应运行环境下的目标运行资源上按照配置参数以及程序包进行应用程序发布。
106.在上述任一实施例的基础上，所述运行环境包括虚拟机运行环境和容器运行环境。
107.在上述任一实施例的基础上，所述发送模块702在将所述各运行环境下发布的配置指令分别发送至对应的各运行环境的控制端，以使各运行环境的控制端根据接收到的配置指令在对应运行环境下的目标运行资源上按照配置参数以及程序包进行应用程序发布时，用于：
108.将所述虚拟机运行环境下发布的配置指令发送给虚拟机运行环境的处理设备上的代理进程，以使所述代理进程根据接收到的配置指令在所述虚拟机运行环境下的目标运行资源中按照配置参数以及程序包创建所述应用程序的服务进程；和/或
109.将所述容器运行环境下发布的配置指令发送给容器运行环境的控制设备，以使所述控制设备根据接收到的配置指令通过软件开发工具包sdk在所述容器运行环境下的目标运行资源中按照配置参数以及程序包构建所述应用程序的镜像。
110.在上述任一实施例的基础上，所述发送模块702在将所述各运行环境下发布的配置指令分别发送至对应的各运行环境的控制端时，用于：
111.检测各运行环境下发布的配置指令中程序包的版本是否相同；
112.若版本相同，则将所述各运行环境下发布的配置指令分别发送至对应的各运行环境的控制端。
113.在上述任一实施例的基础上，所述接收模块701还用于，接收用户通过所述交互界面输入的对应用程序的操作指令，所述操作指令包括对目标运行环境下的应用程序的目标
操作；
114.所述发送模块702还用于，根据所述操作指令向所述目标运行环境的控制端发送所述目标操作对应的控制指令，以使所述目标运行环境的控制端根据控制指令对所述应用程序执行所述目标操作。
115.在上述任一实施例的基础上，所述目标操作包括对应用程序的目标服务的启动操作、停止操作、重启操作、以及对应用程序更新操作。
116.在上述任一实施例的基础上，所述接收模块701还用于，接收任一运行环境的控制端发送的应用程序的运行状态监控信息；将所述运行状态监控信息显示于所述交互界面，以展示给用户、或者在应用程序的运行状态异常时进行告警。
117.本发明实施例提供的后端服务设备可以具体用于执行上述图2所提供的后端服务设备侧的方法实施例，具体功能此处不再赘述。
118.图9为本发明实施例提供的虚拟机运行环境的处理设备的结构图。本实施例提供的可以执行虚拟机运行环境的处理设备侧的方法实施例提供的处理流程，所述虚拟机运行环境的处理设备配置有代理进程，如图9所示，所述虚拟机运行环境的处理设备810包括通信模块811以及处理模块812。
119.通信模块811，用于通过所述代理进程接收后端服务设备发送的应用程序在虚拟机运行环境下发布的配置指令，所述配置指令包括虚拟机运行环境的目标运行资源、配置参数、以及程序包；
120.处理模块812，用于由所述代理进程根据所述配置指令在目标运行资源中按照配置参数以及程序包创建所述应用程序的服务进程。
121.在上述任一实施例的基础上，所述通信模块811还用于，通过所述代理进程接收后端服务设备发送的控制应用程序执行目标操作的控制指令；
122.所述处理模块812还用于，由所述代理进程根据所述控制指令对所述应用程序执行所述目标操作。
123.在上述任一实施例的基础上，所述目标操作包括对应用程序的目标服务的启动操作、停止操作、重启操作、以及对应用程序更新操作。
124.在上述任一实施例的基础上，所述处理模块812还用于，通过所述代理进程监控应用程序的运行状态，得到应用程序的运行状态监控信息；
125.所述通信模块811还用于，通过所述代理进程将所述运行状态监控信息发送给所述后端服务设备，以显示于后端服务设备的交互界面，以展示给用户、或者在应用程序的运行状态异常时进行告警。
126.本发明实施例提供的虚拟机运行环境的处理设备可以具体用于执行上述图6所提供的虚拟机运行环境的处理设备侧的方法实施例，具体功能此处不再赘述。
127.图10为本发明实施例提供的容器运行环境的控制设备的结构图。本实施例提供的容器运行环境的控制设备可以执行容器运行环境的控制设备侧的方法实施例提供的处理流程，如图10所示，所述容器运行环境的控制设备820包括通信模块821以及处理模块822。
128.通信模块821，用于接收后端服务设备发送的应用程序在容器运行环境下发布的配置指令，所述配置指令包括容器运行环境的目标运行资源、配置参数、以及程序包；
129.处理模块822，用于根据所述配置指令通过软件开发工具包sdk在目标运行资源中
按照配置参数以及程序包构建所述应用程序的镜像。
130.在上述任一实施例的基础上，所述通信模块821还用于，接收后端服务设备发送的控制应用程序执行目标操作的控制指令；
131.所述处理模块822还用于，根据所述控制指令通过sdk对所述应用程序执行所述目标操作。
132.在上述任一实施例的基础上，所述目标操作包括对应用程序的目标服务的启动操作、停止操作、重启操作、以及对应用程序更新操作。
133.在上述任一实施例的基础上，所述处理模块822还用于，通过sdk监控应用程序的运行状态，得到应用程序的运行状态监控信息；
134.所述通信模块821还用于，将所述运行状态监控信息发送给所述后端服务设备，以显示于后端服务设备的交互界面，以展示给用户、或者在应用程序的运行状态异常时进行告警。
135.本发明实施例提供的容器运行环境的控制设备可以具体用于执行上述图7所提供的容器运行环境的控制设备侧的方法实施例，具体功能此处不再赘述。
136.图11为本发明实施例提供的后端服务设备的结构示意图。本发明实施例提供的后端服务设备可以执行后端服务设备侧的多运行环境下的应用程序管理方法实施例提供的处理流程，如图11所示，电子设备900包括存储器901、处理器902、计算机程序；其中，计算机程序存储在存储器901中，并被配置为由处理器902执行以上实施例所述的后端服务设备侧的多运行环境下的应用程序管理方法。此外，后端服务设备900还可具有通讯接口903，用于传输指令和数据。
137.图11所示实施例的后端服务设备可用于执行上述后端服务设备侧的方法实施例的技术方案，其实现原理和技术效果类似，此处不再赘述。
138.另外，本实施例还提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行以实现上述实施例所述的后端服务设备侧的方法。
139.另外，本实施例还提供一种计算机程序产品，包括计算机指令，该计算机指令被处理器执行时实现上述实施例所述的后端服务设备侧的方法。
140.图12为本发明实施例提供的虚拟机运行环境的处理设备的结构示意图。本发明实施例提供的虚拟机运行环境的处理设备可以执行虚拟机运行环境的处理设备侧的多运行环境下的应用程序管理方法实施例提供的处理流程，如图12所示，虚拟机运行环境的处理设备910包括存储器911、处理器912、计算机程序；其中，计算机程序存储在存储器911中，并被配置为由处理器912执行以上实施例所述的虚拟机运行环境的处理设备侧的多运行环境下的应用程序管理方法。此外，虚拟机运行环境的处理设备910还可具有通讯接口913，用于传输指令和数据。
141.图12所示实施例的虚拟机运行环境的处理设备可用于执行上述虚拟机运行环境的处理设备侧的方法实施例的技术方案，其实现原理和技术效果类似，此处不再赘述。
142.另外，本实施例还提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行以实现上述实施例所述的虚拟机运行环境的处理设备侧的方法。
143.另外，本实施例还提供一种计算机程序产品，包括计算机指令，该计算机指令被处理器执行时实现上述实施例所述的虚拟机运行环境的处理设备侧的方法。
144.图13为本发明实施例提供的容器运行环境的控制设备的结构示意图。本发明实施例提供的容器运行环境的控制设备可以执行容器运行环境的控制设备侧的多运行环境下的应用程序管理方法实施例提供的处理流程，如图13所示，容器运行环境的控制设备920包括存储器921、处理器922、计算机程序；其中，计算机程序存储在存储器921中，并被配置为由处理器922执行以上实施例所述的容器运行环境的控制设备侧的多运行环境下的应用程序管理方法。此外，电子设备920还可具有通讯接口923，用于传输指令和数据。
145.图13所示实施例的容器运行环境的控制设备可用于执行上述容器运行环境的控制设备侧的多运行环境下的应用程序管理方法实施例的技术方案，其实现原理和技术效果类似，此处不再赘述。
146.另外，本实施例还提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行以实现上述实施例所述的容器运行环境的控制设备侧的多运行环境下的应用程序管理方法。
147.另外，本实施例还提供一种计算机程序产品，包括计算机指令，该计算机指令被处理器执行时实现上述实施例所述的容器运行环境的控制设备侧的多运行环境下的应用程序管理方法。
148.在本发明实施例所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
149.所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
150.另外，在本发明实施例各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。
151.上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本发明实施例各个实施例所述方法的部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(read-only memory，rom)、随机存取存储器(random access memory，ram)、磁碟或者光盘等各种可以存储程序代码的介质。
152.本领域技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。上述描述的装置的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
153.以上各实施例仅用以说明本发明实施例的技术方案，而非对其限制；尽管参照前
述各实施例对本发明实施例进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明实施例各实施例技术方案的范围。
154.本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本发明旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求书指出。
155.应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求书来限制。