应用部署更新方法、系统、电子设备及存储介质与流程

1.本发明涉及软件更新技术领域，尤其涉及应用部署更新方法、系统、电子设备及存储介质。


背景技术：

2.当前，微服务架构盛行，虽然带来了架构上的灵活性，但是也给产品交付、部署、升级、运维等带来挑战。从技术架构层次上来看，一个微服务一般由多个层组成，比如说，从底往上依次是：底座层、公共组件层、公共服务层、业务功能层等，每个层次之间都存在依赖关系，每个层次都有自己的交付物，每个层次都会独立发布新版本，我们将这样的层次称之为微服务单元，微服务单元拆分的越细，软件在研发、测试、交付、部署升级复杂度就会越高。为了解决该技术问题现提出一种应用部署更新方法、系统、电子设备及存储介质。


技术实现要素：

3.为了解决上述现有技术中存在的技术问题，本发明提供了一种应用部署更新方法、系统、电子设备及存储介质，本发明制定统一微服务模型，贯穿整个软件生命周期，包括设计、编码实现、测试、交付物提交等阶段，在部署阶段，部署工具基于这份微服务模型描述，进行部署和升级。
4.为实现上述目的，本发明实施例提供了如下的技术方案：
5.第一方面，在本发明提供的一个实施例中，提供了应用部署更新方法，该方法包括以下步骤：
6.获取微服务；
7.其中，所述微服务至少包括一个微服务单元；所述微服务单元，包括交付物的列表和微服务单元之间的依赖关系；
8.将需要部署的交付物和获取的所述微服务部署到交付物仓库中；
9.根据微服务单元所包括的交付物的列表和微服务单元之间的依赖关系，从交付物仓库中获取需要部署的交付物，对获取的交付物根据需求进行打包，然后部署到指定的服务器上。
10.作为本发明的进一步方案，所述交付物部署到指定的服务器上完成后，框架自动更新微服务列表信息，所述列表信息包括文件名、文件大小、文件md5码、文件路径信息。
11.作为本发明的进一步方案，所述微服务单元类型包括业务微服务单元和非业务微服务单元。
12.作为本发明的进一步方案，所述交付物仓库为测试仓库、uat仓库、生产仓库任一类型。
13.作为本发明的进一步方案，所述对获取的交付物根据需求进行打包，其被打包成zip、rpm、docker image任一格式。
14.作为本发明的进一步方案，该方法还包括，对微服务进行更新，基于更新后的微服
务获取更新前后的交付物列表，将获取的更新前后的交付物列表进行比对；若有新增交付物，若为新增则将新增交付物加入到增量中；
15.若有更新交付物，且对比更新交付物的md5码，获得需要更新的增量；
16.若有删除交付物，则标记所述删除交付物为删除状态；
17.对增量进行打包部署。
18.第二方面，在本发明提供的又一个实施例中，提供了应用部署更新系统，该系统包括：
19.微服务获取模块、交付物和微服务转移模块和部署模块；
20.所述微服务获取模块，用于获取微服务，其中，所述微服务至少包括一个微服务单元；所述微服务单元，包括交付物的列表和微服务单元之间的依赖关系；
21.所述交付物和微服务转移模块，用于将需要部署的交付物和所述微服务部署到交付物仓库中；
22.所述部署模块用于根据微服务单元所包括的交付物的列表和微服务单元之间的依赖关系，从交付物仓库中获取需要部署的交付物，对获取的交付物根据需求进行打包，然后部署到指定的服务器上。
23.作为本发明的进一步方案，该系统还包括更新模块；
24.所述更新模块用于对微服务进行更新，基于更新后的微服务获取更新前后的交付物列表，将获取的更新前后的交付物列表进行比对；若有新增交付物，若为新增则将新增交付物加入到增量中；
25.若有更新交付物，且对比更新交付物的md5码，获得需要更新的增量；
26.若有删除交付物，则标记所述删除交付物为删除状态；
27.对增量进行打包部署。
28.第三方面，在本发明提供的又一个实施例中，提供了一种电子设备，包括存储器和处理器，所述存储器存储有计算机程序，所述处理器加载并执行所述计算机程序时实现应用部署更新方法的步骤。
29.第四方面，在本发明提供的再一个实施例中，提供了一种存储介质，存储有计算机程序，所述计算机程序被处理器加载并执行时实现所述应用部署更新方法的步骤。
30.本发明提供的技术方案，具有如下有益效果：
31.本发明提供的应用部署更新方法、系统、电子设备及存储介质，该方法获取微服务；其中，所述微服务至少包括一个微服务单元；所述微服务单元，包括交付物的列表和微服务单元之间的依赖关系；将需要部署的交付物和获取的所述微服务部署到交付物仓库中；根据微服务单元所包括的交付物的列表和微服务单元之间的依赖关系，从交付物仓库中获取需要部署的交付物，对获取的交付物根据需求进行打包，然后部署到指定的服务器上。本发明有效的规范和指导整个软件生命周期管理，在部署阶段，运维框架通过消费这份模型数据，使部署、更新更加简单高效，达到事半功倍的效果。
32.本发明的这些方面或其他方面在以下实施例的描述中会更加简明易懂。应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本发明。
33.本发明的这些方面或其他方面在以下实施例的描述中会更加简明易懂。应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本发明。
附图说明
34.为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的实施例。
35.图1为本发明一个实施例的应用部署更新方法的流程图。
36.图2为本发明一个实施例的应用部署更新系统中结构框图一。
37.图3为本发明一个实施例的应用部署更新系统中结构框图二。
38.图中：微服务获取模块-100、交付物和微服务转移模块-200、部署模块-300、更新模块-400。
具体实施方式
39.下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
40.附图中所示的流程图仅是示例说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解、组合或部分合并，因此实际执行的顺序有可能根据实际情况改变。
41.应当理解，在此本发明说明书中所使用的术语仅仅是出于描述特定实施例的目的而并不意在限制本发明。如在本发明说明书和所附权利要求书中所使用的那样，除非上下文清楚地指明其它情况，否则单数形式的“一”、“一个”及“该”意在包括复数形式。
42.具体地，下面结合附图，对本发明实施例作进一步阐述。
43.请参阅图1，图1是本发明实施例提供的一种应用部署更新方法的流程图，如图1所示，该应用部署更新方法包括步骤s10至步骤s40。
44.s10、获取微服务，其中，所述微服务至少包括一个微服务单元；所述微服务单元，包括交付物的列表和微服务单元之间的依赖关系。
45.在本发明的实施例中，所述微服务单元，它是构成微服务的一部分，从设计、开发、编码、打包、测试、部署、维护升级等，在每个软件生命周期阶段，微服务单元之间需要有清晰的边界。
46.在本发明的实施例中，所述微服务单元要对外发布，必须首先定义微服务单元，其描述性文件随着安装包一并发布。
47.在本发明的实施例中，所述微服务单元的主要属性还包括：编号、名称、类型、包含的交付物的列表、微服务单元之间的依赖关系。
48.其中，所述编号必须唯一，唯一标识。
49.在本发明的实施例中，所述微服务单元类型主要有：业务微服务单元和非业务微服务单元。在选择微服务单元时，类型起到过滤作用，有些微服务单元可能是底座、公共组件、公共服务等，他们没有业务含义，其他有业务含义的微服务单元依赖这些基础设施，实施人员只关注有业务含义的微服务单元。
50.在本发明的实施例中，所述交付物的列表，微服务应用部署，其本质是应用程序的交付物部署，每个交付物都隶属一个微服务单元，这个是微服务单元必须也应该遵守的原则。
51.在本发明的实施例中，所述微服务单元之间的依赖关系，业务微服务单元会依赖基础设施，公共组件或服务微服务单元一般情况下也存在依赖。依赖是一个链式结构，只描述直接依赖，间接依赖通过依赖链查找，因此，顶层的业务微服务单元，通过依赖关系，即可获取到所有的微服务单元。
52.s20、将需要部署的交付物和获取的所述微服务部署到交付物仓库中；
53.在本发明的实施例中，单个微服务由一个或多个微服务单元组合而成，有时用户的应用服务器不足，为了减少应用部署数量，支持选择多个业务微服务合并部署，但在微服务创建时会做版本检查，检查多个业务微服务依赖的基础设施是否存在版本冲突，存在冲突的业务微服务单元，需要拆开部署。
54.所述交付物仓库主要用于存储交付物，产品发布的升级包首先更新到交付物仓库，每个交付物仓库可以设置多个微服务单元。所述交付物仓库有多个类型，比如说测试仓库、uat仓库、生产仓库。
55.s30、根据微服务单元所包括的交付物的列表和微服务单元之间的依赖关系，从交付物仓库中获取需要部署的交付物，对获取的交付物根据需求进行打包，然后部署到指定的服务器上。
56.其中，部署完成后，框架自动更新微服务列表信息，所述列表信息包括文件名、文件大小、文件md5码、文件路径等信息。
57.具体的，所述对获取的交付物根据需求进行打包，其可以被打包成zip、rpm、docker image等格式。
58.在本发明实施例中，所述交付物是通过运维工具，部署到指定的服务器上的。
59.s40、对微服务进行更新，基于更新后的微服务获取更新前后的交付物列表，将获取的更新前后的交付物列表进行比对；若有新增交付物，若为新增则将新增交付物加入到增量中；
60.若有更新交付物，且对比更新交付物的md5码，获得需要更新的增量；
61.若有删除交付物，则标记所述删除交付物为删除状态；
62.对增量进行打包部署。
63.其中，所述s40，还包括对被标记为删除状态的交付物进行删除。
64.本发明为了解决交付物重新分发的问题，先将交付物更新到交付物仓库，然后基于微服务模型定义，抽取微服务对应的交付物，然后将交付物重新打包成不同的文件形式，比如zip、rpm、dock image等格式，最后进行部署或升级。本发明以微服务模型为核心，有效的规范和指导整个软件生命周期管理，在部署阶段，运维框架通过消费这份模型数据，使部署、更新更加简单高效，达到事半功倍的效果。
65.交付物文件信息包括：
66.属性编号属性名称属性类型id唯一标识stringname文件string
path文件路径stringmd5文件md5stringsize文件大小long
67.其中，微服务单元定义(microserviceunit)如下表所示：
[0068][0069]
文件列表，支持指定文件夹以及文件，有的文件夹可能多个微服务单元共用，需要将其他微服务单元的文件刨除掉，可以设置忽略的文件。
[0070]
具体的，所述微服务单元定义包括：基本信息定义、交付物列表定义和微服务单元依赖关系定义。
[0071]
a)基本信息定义
[0072]
角色：产品经理
[0073]
描述：根据微服务单元的职责，确定微服务单元基本信息：编号、名称、类型，编号唯一且不得随意改动。
[0074]
b)交付物列表定义
[0075]
角色：开发人员
[0076]
描述：当新增交付物时，在提交该交付物的同时，一并更新交付物列表。
[0077]
c)微服务单元依赖关系定义
[0078]
角色：开发人员
[0079]
描述：一般在微服务单元创建时确定依赖关系，中间可以调整依赖关系。
[0080]
微服务定义(microservice)如下表所示：
[0081]
属性编号属性名称属性类型id唯一标识stringcode编号stringname名称stringdescription描述stringcreatetime创建时间date
[0082]
具体的，所述微服务定义包括：
[0083]
角色：实施人员
[0084]
描述：根据产品最佳实践和用户的需求，可以选择一个业务微服务单元以及其依赖的微服务单元，作为一个微服务进行部署，也可以为了减少应用服务的部署数量，选择多
个业务微服务单元组合部署。
[0085]
微服务-微服务单元关联表
[0086]
属性编号属性名称属性类型microserviceid微服务idstringmicroserviceunitcode微服务单元编号string
[0087]
微服务与微服务是多对多关系。
[0088]
已经部署的微服务，为了实现增量部署，通过对比文件md5码，获取增量，当文件较多时，计算md5码比较耗时，为了提升获取增量的性能，在微服务部署和升级时，记录微服务的文件md5码用于比对。
[0089]
交付物仓库信息表：
[0090][0091][0092]
按照交付物仓库的用途来划分，可以分为测试仓库、uat仓库、生产仓库。不同交付物仓库的相互隔离。
[0093]
具体的，所述交付物仓库定义包括：
[0094]
角色：实施人员
[0095]
描述：主要设置交付物仓库包含的微服务单元列表。
[0096]
所述交付物仓库的内容升级，包括：
[0097]
角色：实施、运维人员
[0098]
描述：当微服务单元有新版本时，可以下载新版本更新，也支持手动上传升级包进行更新。
[0099]
交付物仓库-微服务单元关联
[0100]
属性编号属性名称属性类型id唯一标识stringrepositoryid仓库idstring微服务单元id微服务单元idstring
[0101]
该表描述的是仓库和微服务单元的关联关系，设置仓库存储微服务单元的交付物。
[0102]
从以上表格可以看出，微服务单元是核心模型，贯穿整个部署更新过程。
[0103]
具体的，所述微服务部署和升级，包括如下内容：
[0104]
微服务部署
[0105]
角色：实施、运维人员
[0106]
描述：用户选择要部署的微服务，系统通过微服务描述、微服务单元描述、微服务
单元和交付物包含关系，从交付物仓库中抽取文件，将文件按目录组织好，然后通过各种打包工具，可以打包成各种形式的安装包，比如zip、rpm、docker等文件格式。
[0107]
微服务增量升级
[0108]
角色：实施、运维人员
[0109]
描述：用户选择要升级的微服务，系统查询该微服务当前文件版本和交付物仓库中的文件版本，做对比，得到增量，然后打包形成各种文件形式的增量包。
[0110]
应该理解的是，上述虽然是按照某一顺序描述的，但是这些步骤并不是必然按照上述顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，本实施例的一部分步骤可以包括多个步骤或者多个阶段，这些步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。
[0111]
在一个实施例中，参见图3所示，在本发明的实施例中还提供了应用部署更新系统，该系统包括微服务获取模块100、交付物和微服务转移模块200和部署模块300。
[0112]
所述微服务获取模块100，用于获取微服务，其中，所述微服务至少包括一个微服务单元；所述微服务单元，包括交付物的列表和微服务单元之间的依赖关系。
[0113]
在本发明的实施例中，所述微服务单元，它是构成微服务的一部分，从设计、开发、编码、打包、测试、部署、维护升级等，在每个软件生命周期阶段，微服务单元之间需要有清晰的边界。
[0114]
在本发明的实施例中，所述微服务单元要对外发布，必须首先定义微服务单元，其描述性文件随着安装包一并发布。
[0115]
在本发明的实施例中，所述微服务单元的主要属性还包括：编号、名称、类型、包含的交付物的列表、微服务单元之间的依赖关系。
[0116]
其中，所述编号必须唯一，唯一标识。
[0117]
在本发明的实施例中，所述微服务单元类型主要有：业务微服务单元和非业务微服务单元。在选择微服务单元时，类型起到过滤作用，有些微服务单元可能是底座、公共组件、公共服务等，他们没有业务含义，其他有业务含义的微服务单元依赖这些基础设施，实施人员只关注有业务含义的微服务单元。
[0118]
在本发明的实施例中，所述交付物的列表，微服务应用部署，其本质是应用程序的交付物部署，每个交付物都隶属一个微服务单元，这个是微服务单元必须也应该遵守的原则。
[0119]
在本发明的实施例中，所述微服务单元之间的依赖关系，业务微服务单元会依赖基础设施，公共组件或服务微服务单元一般情况下也存在依赖。依赖是一个链式结构，只描述直接依赖，间接依赖通过依赖链查找，因此，顶层的业务微服务单元，通过依赖关系，即可获取到所有的微服务单元。
[0120]
所述交付物和微服务转移模块200，用于将需要部署的交付物和所述微服务部署到交付物仓库中。
[0121]
在本发明的实施例中，单个微服务由一个或多个微服务单元组合而成，有时用户的应用服务器不足，为了减少应用部署数量，支持选择多个业务微服务合并部署，但在微服
务创建时会做版本检查，检查多个业务微服务依赖的基础设施是否存在版本冲突，存在冲突的业务微服务单元，需要拆开部署。
[0122]
所述交付物仓库主要用于存储交付物，产品发布的升级包首先更新到交付物仓库，每个交付物仓库可以设置多个微服务单元。所述交付物仓库有多个类型，比如说测试仓库、uat仓库、生产仓库。
[0123]
所述部署模块300用于根据微服务单元所包括的交付物的列表和微服务单元之间的依赖关系，从交付物仓库中获取需要部署的交付物，对获取的交付物根据需求进行打包，然后部署到指定的服务器上。
[0124]
其中，部署完成后，框架自动更新微服务列表信息，所述列表信息包括文件名、文件大小、文件md5码、文件路径等信息。
[0125]
具体的，所述对获取的交付物根据需求进行打包，其可以被打包成zip、rpm、docker image等格式。
[0126]
在本发明实施例中，所述交付物是通过运维工具，部署到指定的服务器上的。
[0127]
本发明为了解决交付物重新分发的问题，先将交付物更新到交付物仓库，然后基于微服务模型定义，抽取微服务对应的交付物，然后将交付物重新打包成不同的文件形式，比如zip、rpm、dock image等格式，最后进行部署或升级。本发明以微服务模型为核心，有效的规范和指导整个软件生命周期管理，在部署阶段，运维框架通过消费这份模型数据，使部署、更新更加简单高效，达到事半功倍的效果。
[0128]
参见图3所示，在本发明的实施例中还提供了应用部署更新系统，该系统还包括更新模块400。
[0129]
所述更新模块400用于对微服务进行更新，基于更新后的微服务获取更新前后的交付物列表，将获取的更新前后的交付物列表进行比对；若有新增交付物，若为新增则将新增交付物加入到增量中；
[0130]
若有更新交付物，且对比更新交付物的md5码，获得需要更新的增量；
[0131]
若有删除交付物，则标记所述删除交付物为删除状态；
[0132]
对增量进行打包部署。
[0133]
其中，所述更新模块400还用于对被标记为删除状态的交付物进行删除。
[0134]
在一个实施例中，在本发明的实施例中还提供了一种电子设备，包括至少一个处理器，以及与所述至少一个处理器通信连接的存储器，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器执行所述的应用部署更新方法，该处理器执行指令时实现上述方法实施例中的步骤。
[0135]
所述电子设备包括用户设备与网络设备。其中，所述用户设备包括但不限于电脑、智能手机、pda等；所述网络设备包括但不限于单个网络服务器、多个网络服务器组成的服务器组或基于云计算(cloud computing)的由大量计算机或网络服务器构成的云，其中，云计算是分布式计算的一种，由一群松散耦合的计算机集组成的一个超级虚拟计算机。其中，所述电子设备可单独运行来实现本发明，也可接入网络并通过与网络中的其他电子设备的交互操作来实现本发明。其中，所述电子设备所处的网络包括但不限于互联网、广域网、城域网、局域网、vpn网络等。
[0136]
还应当进理解，在本发明说明书和所附权利要求书中使用的术语“和/或”是指相
关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。
[0137]
在本发明的一个实施例中还提供了一种存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述方法实施例中的步骤。
[0138]
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述方法的实施例的流程。其中，本发明所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和易失性存储器中的至少一种。
[0139]
以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。
[0140]
以上是本发明公开的示例性实施例，但是应当注意，在不背离权利要求限定的本发明实施例公开的范围的前提下，可以进行多种改变和修改。根据这里描述的公开实施例的方法权利要求的功能、步骤和/或动作不需以任何特定顺序执行。此外，尽管本发明实施例公开的元素可以以个体形式描述或要求，但除非明确限制为单数，也可以理解为多个。
[0141]
应当理解的是，在本文中使用的，除非上下文清楚地支持例外情况，单数形式“一个”旨在也包括复数形式。还应当理解的是，在本文中使用的“和/或”是指包括一个或者一个以上相关联地列出的项目的任意和所有可能组合。上述本发明实施例公开实施例序号仅仅为了描述，不代表实施例的优劣。
[0142]
所属领域的普通技术人员应当理解：以上任何实施例的讨论仅为示例性的，并非旨在暗示本发明实施例公开的范围(包括权利要求)被限于这些例子；在本发明实施例的思路下，以上实施例或者不同实施例中的技术特征之间也可以进行组合，并存在如上的本发明实施例的不同方面的许多其它变化，为了简明它们没有在细节中提供。因此，凡在本发明实施例的精神和原则之内，所做的任何省略、修改、等同替换、改进等，均应包含在本发明实施例的保护范围之内。