一种应用升级方法、应用升级平台、电子设备及存储介质与流程

1.本发明涉及云计算技术领域，尤其是涉及一种应用升级方法、应用升级平台、电子设备及存储介质。


背景技术：

2.近年来，云计算在国内不断普及和发展。开源容器技术作为一种轻量化虚拟技术，由于其使用程序打包镜像的方式实现快速应用的部署和运行，大幅提供开发效率，被广泛使用与云计算领域。相较于传统的虚拟机，容器共享主机内核，自身占用极少资源，为用户提供了灵活的资源分配和调度方式，现已成为云计算系统的核心功能。开源容器技术的兴起，催生了一大批优秀的应用编排管理系统，典型的系统如kubernetes、dockerswarm以及mesosphere。其中kubernetes以其强大的应用编排管理和自动化运维能力成为容器编排领域的领导者。现有技术提出一种基于kubernetes的应用发布方法，该方法支持多种技术栈的通用应用发布系统，但是未考虑应用在业务场景中后续的维护和升级。


技术实现要素：

3.本发明提供一种应用升级方法、应用升级平台、电子设备及存储介质，该方法能够实现应用的维护和升级。
4.为解决上述技术问题，本发明提供的第一个技术方案为：提供一种应用升级方法，包括：将待升级的应用程序的新版本数据与旧版本数据进行比对，生成比对数据；对所述比对数据进行资源校验，确定系统资源是否满足升级条件；响应于校验通过，基于所述比对数据生成所述待升级的应用程序的升级调度计划；基于所述调度计划对所述应用程序进行升级。
5.其中，所述将待升级的应用程序的新版本数据与旧版本数据进行比对，生成比对数据的步骤，包括：将所述待升级的应用程序的新版本数据与旧版本数据中的应用拓扑变更信息、容器运行环境信息进行比较，生成所述比较数据；所述应用拓扑变更信息包括增加微服务、减少微服务中至少一种；所述容器运行环境信息包括环境变量、网络资源、容器存储信息以及计算资源中至少一种。
6.其中，所述基于所述比对数据生成所述待升级的应用程序的升级调度计划的步骤，包括：基于所述比对数据创建所述待升级的应用程序升级对应的副本信息，并整合所述副本信息生成升级方案；基于所述升级方案生成所述调度计划。
7.其中，所述副本信息包括副本名称、服务信息中至少一种，所述服务信息包括应用镜像、端口配置中至少一种。
8.其中，所述基于所述升级方案生成所述调度计划的步骤，包括：对所述升级方案中的所述副本信息进行调度，以为所述副本信息生成调度结果，所述调度包括为所述副本信息绑定计算资源节点、分配存储目录、生成ip信息中至少一种；基于所述调度结果利用所述升级方案中的所述副本信息更新所述应用程序，以得到所述应用程序的升级策略；基于所
述升级策略生成所述调度计划。
9.其中，所述基于所述升级策略生成所述调度计划的步骤，包括：利用微服务根据应用拓扑生成层级调度计划，所有层级调度计划形成所述调度计划。
10.其中，所述利用微服务根据应用拓扑生成层级调度计划的步骤，包括：利用依赖的服务基于所述应用拓扑进行ip/域名的渲染，以及利用数据库基于所述应用拓扑保存所述升级策略、所述副本信息、所述调度结果，进而得到所述层级调度计划。
11.其中，所述对所述升级方案中的所述副本信息进行调度，以为所述副本信息生成调度结果的步骤之后，包括：基于升级脚本调用openapi升级所述副本信息。
12.其中，所述基于所述调度计划对所述应用程序进行升级的步骤，包括：基于所述调度计划创建容器，每一所述容器相互独立；基于所述容器对所述应用程序进行升级。
13.为解决上述技术问题，本发明提供的第二个技术方案为：提供一种应用升级平台，包括：业务层，将待升级的应用程序的新版本数据与旧版本数据进行比对，生成比对数据；对所述比对数据进行资源校验，确定系统资源是否满足升级条件；响应于校验通过，基于所述比对数据生成所述待升级的应用程序的升级调度计划；基础层，所述基础层用于基于所述调度计划对所述应用程序进行升级。
14.其中，所述业务层包括：网关服务、应用中心、镜像中心。
15.其中，所述基础层包括：主节点，所述主节点对应多个子节点；所述主节点包括接口服务、控制器、调度器以及键值数据库；所述子节点包括节点代理组件、网络代理组件、容器服务、网络插件、至少一个副本。
16.为解决上述技术问题，本发明提供的第三个技术方案为：提供一种电子设备，包括：存储器和处理器，其中，所述存储器存储有程序指令，所述处理器从所述存储器调取所述程序指令以执行上述任一项所述的方法。
17.为解决上述技术问题，本发明提供的第四个技术方案为：提供一种计算机可读存储介质，存储有程序文件，所述程序文件能够被执行以实现上述任一项所述的方法。
18.本发明的有益效果，区别于现有技术的情况，本发明将待升级的应用程序的新版本数据与旧版本数据进行比对，生成比对数据；对所述比对数据进行资源校验，确定系统资源是否满足升级条件；响应于校验通过，基于所述比对数据生成所述待升级的应用程序的升级调度计划；基于所述调度计划对所述应用程序进行升级。该方法能够实现应用的维护和升级。
附图说明
19.为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图，其中：
20.图1为本发明应用升级方法的一实施例的流程示意图；
21.图2a为镜像更新的示意图；
22.图2b为应用拓扑结构变更的示意图；
23.图3为图1中步骤s13的一实施例的流程示意图；
24.图4a为本发明简单调度模式下的升级方法流程示意图；
25.图4b为本发明复杂调度模式下的升级方法流程示意图；
26.图5为本发明应用升级平台的一实施例的结构示意图；
27.图6为本发明电子设备的一实施例的结构示意图；
28.图7为本发明计算机可读存储介质的结构示意图。
具体实施方式
29.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本技术的一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
30.本技术中的术语“第一”、“第二”、“第三”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”、“第三”的特征可以明示或者隐含地包括至少一个该特征。本技术的描述中，“多个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。本技术实施例中所有方向性指示(诸如上、下、左、右、前、后
……
)仅用于解释在某一特定姿态(如附图所示)下各部件之间的相对位置关系、运动情况等，如果该特定姿态发生改变时，则该方向性指示也相应地随之改变。此外，术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。
31.在本文中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本技术的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。
32.在某些大型应用升级中，为保障应用数据的完整性，系统应用升级需备份数据，或进行系统某些数据的初始化等灵活升级的需求。如：博客系统在大的应用版本迭代升级时需要先进行应用下线，备份博客系统mysql数据，然后进行应用的整体升级。
33.本技术的旨在于提供一种实现容器云平台基于应用粒度的部署、升级方案。标准的kubernetes(开源系统，k8s)只提供基于容器编排的方案底层调度和基础设施管理，在业务应用(多个微服务组成)调度和管理方面捉襟见肘。本提案主要以用户业务场景出发，降低使用kubernetes的技术难度等方面考虑，独创了一种基于k8s之上的业务应用概念。一个用户的应用可由多个微服务或者组件编排形成拓扑结构，各个微服务之间相互协作、依赖调用，最终用户在私有云平台进行应用的部署，提供服务。由于经常有用户业务项目在迭代的同时，应用进行版本升级的需求也十分迫切，因此针对用户应用升级场景进行梳理(包括应用内部容器镜像升级、应用拓扑变更、业务数据升级)，构建整体应用升级功能。
34.请参见图1，为本发明应用升级方法的一实施例的流程示意图，具体包括：
35.步骤s11：将待升级的应用程序的新版本数据与旧版本数据进行比对，生成比对数据。
36.在日常的业务迭代开发中，经常有业务应用需要进行内部微服务升级的需要，比如已上线的应用的内部微服务需要进行修改上线，如图2a所示，需要定期进行版本功能升级迭代，添加一些评论功能或者修复一些已知缺陷，例如，将tomcat1.0升级为tomcat2.0。在容器云环境中，这种微服务的更新即为镜像或者配置以及资源(例如cpu、内存、存储)等的更新。
37.在某些业务大版本特性升级或者业务代码逻辑重构中，由于架构或者业务微服务组件的更新导致应用拓扑结构变更。如图2b所示，博客系统在流量逐增时为了稳定性和良好的用户体验加入redis组件进行缓存，微服务需要依赖redis组件对外提供博客服务。这种更新为应用内部服务的依赖拓扑变更。
38.在一实施例中，将待升级的应用程序的新版本数据与旧版本数据进行比对，包括将新版本数据与旧版本数据的应用拓扑进更信息进行比对，例如确定新版本数据相对于旧版本数据，是否增加微服务或者减少微服务。或者，包括将将新版本数据与旧版本数据的容器运行环境信息进行比较，例如确定新版本数据相对于旧版本数据部分组件的配置以及资源是否发生改变，具体的，确定环境变量、网络资源、容器存储信息以及计算资源中至少一种是否发生改变。
39.在对比完成后，生成比对数据。
40.步骤s12：对所述比对数据进行资源校验，确定系统资源是否升级条件。
41.对比对数据进行资源校验，确定系统资源是否升级条件。检验主要包括计算升级所需要的资源以及升级所释放的资源等等，主要是确定系统目前的资源是否能够支持本次升级。例如，计算系统剩余的存储空间，确定剩余的存储空间是否满足升级需要，若满足，则确定系统满足升级条件；否则，确定系统不满足升级条件，并向用户反馈提示指令。
42.步骤s13：响应于校验通过，基于所述比对数据生成所述待升级的应用程序的升级调度计划。
43.在确定系统满足升级条件的情况下，也即校验通过的情形下，基于比对数据生成待升级的应用程序的升级调度计划。
44.具体的，基于比对数据创建待升级的应用程序升级对应的副本信息，并整合副本信息生成升级方案。也即一个升级方案中包含多个副本信息。进一步基于升级方案生成调度计划。在一实施例中，副本信息包括副本名称、服务信息等中至少一种，其中服务信息包括应用镜像、端口配置中至少一种。
45.在一实施例中，如图3所示，基于升级方案生成调度计划包括：
46.步骤s31：对所述升级方案中的所述副本信息进行调度，以为所述副本信息生成调度结果。
47.具体的，在一实施例中，所述调度包括为所述副本信息绑定计算资源节点、分配存储目录、生成ip信息中至少一种。也即本步骤是为升级方案中的副本信息绑定计算资源节点、分配存储目录、生成ip信息。
48.步骤s32：基于所述调度结果利用所述升级方案中的所述副本信息更新所述应用程序，以得到所述应用程序的升级策略。
49.调度结果包括副本信息绑定计算资源节点、分配存储目录、生成ip信息中至少一种，基于调度结果利用副本信息更新应用程序，能够得到应用程序的升级策略。
50.步骤s33：基于所述升级策略生成所述调度计划。
51.进一步的，基于微服务根据应用拓扑生成层级调度计划，具体的，层级调度计划注意基于微服务的依赖关系进行确定，基于所述应用拓扑对有依赖的服务进行ip/域名的渲染，以及利用数据库基于所述应用拓扑保存所述升级策略、所述副本信息、所述调度结果，进而得到所述层级调度计划。所有的层级调度计划形成升级过程对应的整体调度计划。
52.在一实施例中，调度计划包括复杂调度模式和简单调度模式。复杂调度模式为一行异步的调度部署方式，该部署方式中，用户可以进行自主可控的调度。而调度计划的模式可以由用户自行选择，如果用户指定简单调度模式，系统依据生成的调度计划进行逐步拉起应用微服务副本信息。也即简单调度模式用户不可自主控制。
53.步骤s14：基于所述调度计划对所述应用程序进行升级。
54.具体的，系统基于调度计划对应用程序进行升级，如果用户选择简单调度模式，则依据生成的调度计划进行逐步拉起应用微服务副本信息。进而完成升级。若用户选择复杂调度模式，则在对所述升级方案中的所述副本信息进行调度时，从一行异步的调度部署容器(cf容器)中获取升级脚本，基于所述升级脚本调用openapi升级副本信息。然后继续上述实施例中所示的步骤，完成系统的升级。
55.在一实施例中，进一步基于所述调度计划创建容器，每一所述容器相互独立；基于所述容器对所述应用程序进行升级。
56.具体的，如图4a所示，为本发明简单调度模式下的升级方法流程示意图。流程包括：
57.1、用户发送升级指令；
→
2、应用中心(appstore)将待升级的应用程序的新版本数据与旧版本数据进行比对，得到比对数据；
→
3、基于比对数据创建副本信息，并对副本信息进行调度，得到升级方案；
→
4、向用户反馈升级过程；
→
5、生成层级调度计划，并进一步生成调度计划；
→
6、将调度计划反馈至k8s；
→
7、k8s内的容器服务docker基于调度计划创建容器；
→
8、docker将容器创建状态反馈至master；
→
9、master将微服务创建状态反馈至appstore，用户可以基于appstore查询应用升级状态，确定升级是否完成。
58.如图4b所示，为本发明复杂调度模式下的升级方法流程示意图。流程包括：
59.1、用户发送升级指令；
→
2、应用中心(appstore)将待升级的应用程序的新版本数据与旧版本数据进行比对，得到比对数据；
→
3、基于比对数据创建副本信息，并对副本信息进行调度，得到升级方案；
→
4、向用户反馈升级过程；
→
5、appstore向cf容器下发升级消息；
→
6、触发cf容器中用户升级脚本；
→
7、基于用户升级脚本调用openapi升级所述副本信息；
→
8、生成层级调度计划，并进一步生成调度计划；
→
9、将调度计划反馈至k8s；
→
10、k8s内的容器服务docker基于调度计划创建容器；
→
11、docker将容器创建状态反馈至master；
→
12、master将微服务创建状态反馈至appstore；
→
13、appstore将副本升级信息发送至cf容器；
→
14、cf容器向appstore发送应用升级成功信息；用于可以基于appstore查询应用升级状态，确定升级是否完成。
60.本提案的最大特点是：简化了原生kubernetes的使用难度，引入业务应用编排的概念，在详细分析了应用升级在业务场景中的需求，针对不同场景进行综合，设计完成了一套应用的升级方法，补充了kubernetes在业务应用更上层的不足，通过开源和自研方案的结合，在私有云领域大大简化了容器使用的难度，为业务应用方开发效率带来提升。本提案
将通过开源、自造业务等方式对应用升级和部署流程进行描述，独创应用升级流程，在面对业务版本快速迭代升级中，开放普通、高级等应用升级模式，在满足普通用户的需求时候，也通过开发接口，为复杂应用升级开放openapi接口，通过多升级模式的组合，为用户提供灵活的应用升级方式。
61.请参见图5，为本发明应用升级平台的一实施例的结构示意图，具体包括：业务层51以及基础层52。
62.其中，业务层51用于将待升级的应用程序的新版本数据与旧版本数据进行比对，生成比对数据；对所述比对数据进行资源校验，确定系统资源是否满足升级条件；响应于校验通过，基于所述比对数据生成所述待升级的应用程序的升级调度计划。
63.具体的，业务层51包括：网关服务(gateway)、应用中心(appstore)、镜像中心(image-registry)。具体的，在进行应用程序升级时，新旧版本的比对、资源校验、副本创建、调度均在应用中心(appstore)中执行。
64.基础层52为k8s层，包括：主节点(master)，所述主节点对应多个子节点node；所述主节点包括接口服务api-server、控制器controller-manager、调度器scheduler以及键值数据库etcd。子节点包括节点代理组件kubelet、网络代理组件kube-proxy、容器服务docker、网络插件calico、至少一个副本pod。
65.基础层52用于基于所述调度计划对所述应用程序进行升级。具体的，应用中心生成调度计划后，将调度计划发送给基础层52，基础层52中的容器服务docker为调度计划中的副本创建容器，每一副本对应的容器相互独立，互不影响。在容器创成功后，通过主节点(master)中的接口服务api-server、控制器controller-manager、调度器scheduler以及键值数据库etcd进行应用升级。
66.本提案的最大特点是：简化了原生kubernetes的使用难度，引入业务应用编排的概念，在详细分析了应用升级在业务场景中的需求，针对不同场景进行综合，设计完成了一套应用的升级方法，补充了kubernetes在业务应用更上层的不足，通过开源和自研方案的结合，在私有云领域大大简化了容器使用的难度，为业务应用方开发效率带来提升。本提案将通过开源、自造业务等方式对应用升级和部署流程进行描述，独创应用升级流程，在面对业务版本快速迭代升级中，开放普通、高级等应用升级模式，在满足普通用户的需求时候，也通过开发接口，为复杂应用升级开放openapi接口，通过多升级模式的组合，为用户提供灵活的应用升级方式。
67.请参见图6，为本发明电子设备的一实施例的结构示意图，电子设备包括相互连接的存储器202和处理器201。
68.存储器202用于存储实现上述任意一项的方法的程序指令。
69.处理器201用于执行存储器202存储的程序指令。
70.其中，处理器201还可以称为cpu(central processing unit，中央处理单元)。处理器201可能是一种集成电路芯片，具有信号的处理能力。处理器201还可以是通用处理器、数字信号处理器(dsp)、专用集成电路(asic)、现场可编程门阵列(fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
71.存储器202可以为内存条、tf卡等，可以存储设备的电子设备中全部信息，包括输
入的原始数据、计算机程序、中间运动结果和最终运动结果都保存在存储器中。它根据控制器指定的位置存入和取出信息。有了存储器，电子设备才有记忆功能，才能保证正常工作。电子设备的存储器按用途可分为主存储器(内存)和辅助存储器(外存),也有分为外部存储器和内部存储器的分类方法。外存通常是磁性介质或光盘等，能长期保存信息。内存指主板上的存储部件，用来存放当前正在执行的数据和程序，但仅用于暂时存放程序和数据，关闭电源或断电，数据会丢失。
72.在本技术所提供的几个实施例中，应该理解到，所揭露的方法和装置，可以通过其它的方式实现。例如，以上所描述的装置实施方式仅仅是示意性的，例如，模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
73.作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施方式方案的目的。
74.另外，在本技术各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
75.集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本技术的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，系统服务器，或者网络设备等)或处理器(processor)执行本技术各个实施方式方法的全部或部分步骤。
76.请参阅图7，为本发明计算机可读存储介质的结构示意图。本技术的存储介质存储有能够实现上述所有方法的程序文件203，其中，该程序文件203可以以软件产品的形式存储在上述存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本技术各个实施方式方法的全部或部分步骤。而前述的存储装置包括：u盘、移动硬盘、只读存储器(rom，read-only memory)、随机存取存储器(ram，random access memory)、磁碟或者光盘等各种可以存储程序代码的介质，或者是计算机、服务器、手机、平板等终端设备。
77.以上仅为本发明的实施方式，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。