CN108762769B

CN108762769B - 微服务应用编排和部署方法、装置及计算机终端

Info

Publication number: CN108762769B
Application number: CN201810565230.0A
Authority: CN
Inventors: 王剑文; 容赜; 许汝全; 陈闻捷
Original assignee: Wanhui Investment Management Co ltd
Current assignee: Wanhui Investment Management Co ltd
Priority date: 2018-06-04
Filing date: 2018-06-04
Publication date: 2022-06-21
Anticipated expiration: 2038-06-04
Also published as: CN108762769A

Abstract

本发明提出了一种微服务应用编排和部署方法、装置及计算机终端，该方法包括：读取预先存储的一微服务应用的依赖关系树，其中，所述微服务应用为所述依赖关系树的根节点；根据预设规则遍历所述依赖关系树中所有节点并确定所有节点的启动顺序；根据所述启动顺序将所有节点对应的应用部署到运行环境中，从而完成所述微服务应用的部署。本发明避免了用户直接编写复杂的程序来实现应用的编排和部署，快速搭建微服务运行的多套环境，加速持续集成、持续交付、持续部署，实现一键部署所有应用，提升企业的技术水平。

Description

微服务应用编排和部署方法、装置及计算机终端

技术领域

本发明涉及容器技术领域，特别涉及一种微服务应用编排和部署方法、装置及计算机终端。

背景技术

近年来很多互联网公司已开始全面推行“微服务”架构，原来复杂的单体业务系统被分拆成多个微服务应用，其带来的问题也显而易见，包括微服务应用的数目剧增、繁杂的配置，以及微服务应用之间的依赖的错综复杂性等。另一方面，由于多人协作开发、产品持续更新及迭代速度加快等原因，开发、测试、运维都需要快速搭建使用环境。传统的运维方式需要先准备机器(可以是实体机，也可以是虚拟机)并安装诸如应用服务器、数据库、缓存、消息中间件等基础环境，然后再部署应用，整个过程相当繁杂、枯燥、效率低下。

Docker容器技术的应用在一定程度上可减少运维的工作量，特别是Dockerswarm、Kubernetes、Mesos等容器编排工具的出现，较大程度简化了容器集群的管理。然而，无论是容器技术，还是容器集群管理技术，都无法管理和维护微服务应用之间复杂的依赖关系。这样就催生了以Docker Compose、Kubernetes原生编排、Kubernetes helm等应用编排技术。以上应用编排工具或多或少存在以下不足：

(1)使用门槛过高，无法在公司大面积推广。Docker Compose、Kubernetes原生编排的应用编排技术都是通过编写yaml(Yet Another Markup Language另一种标记语言)文件来描述应用之间的依赖关系，这样需要熟悉Docker compose的语法，或者熟悉kubernetes中内置的复杂对象如deployment、service等，才能够编写yaml文件。Kubernetes helm应用编排技术采用了基于charts包的实现方案，其中charts包中包含Charts.yaml(用于描述应用自身信息)、templates文件夹(用于存放go模板语言编写的yaml文件)、requirements.yaml(用于描述应用的依赖)等文件，其yaml文件是基于go模板语言编写的，复杂的go模板语言让人望而生畏。

(2)指定微服务应用与其依赖组件之间的启动顺序相当的困难。比如，应用A依赖于应用B，应用B又依赖于应用C和应用D，正确的启动顺序应该是先启动应用C和应用D，然后启动应用B，最后启动应用A，但实际上基于上述编排技术想实现上面的启动顺序却比较困难。

发明内容

有鉴于此，本发明实施例的目的在于提供一种微服务应用编排和部署方法、装置及计算机终端，以解决现有技术的不足。

根据本发明的一个实施方式，提供一种微服务应用编排和部署方法，该微服务应用编排和部署方法包括：

读取预先存储的一微服务应用的依赖关系树，其中，所述微服务应用为所述依赖关系树的根节点；

根据预设规则遍历所述依赖关系树中所有节点并确定所有节点的启动顺序；

根据所述启动顺序将所有节点对应的应用部署到运行环境中，从而完成所述微服务应用的部署。

在上述的微服务应用编排和部署方法中，所述“读取预先存储的所述微服务应用的依赖关系树”之前还包括：

根据所述微服务应用与中间组件及其他微服务应用之间的依赖关系构造所述依赖关系树并存储。

在上述的微服务应用编排和部署方法中，还包括：

当所述微服务应用的依赖关系发生改变时，根据用户的修改操作更新所述依赖关系树。

在上述的微服务应用编排和部署方法中，所述预设规则包括：

以根节点为起点，查找所述依赖关系树中所有节点是否有子节点；

若所述节点有子节点，优先遍历所述子节点。

在上述的微服务应用编排和部署方法中，所述“将所有节点对应的应用部署到运行环境中”包括：

获取所述节点对应的应用的服务模板；

将所述服务模板实例化及生成当前运行环境所需的参数文件；

解析所述参数文件及根据解析结果创建所述应用的对象，将所述应用部署到运行环境中。

在上述的微服务应用编排和部署方法中，还包括：

响应用户的输入操作为所述应用编写所述服务模板并存储，其中，在所述服务模板中将不同运行环境传递的不同参数用占位符代替。

在上述的微服务应用编排和部署方法中，所述服务模板包括中间组件模板及微服务应用模板。

在上述的微服务应用编排和部署方法中，为每一个中间组件编写一个所述中间组件模板并存储。

在上述的微服务应用编排和部署方法中，针对所有微服务应用，抽取所述微服务应用的共同特征，为所有微服务应用编写一个通用的微服务应用模板并存储。

在上述的微服务应用编排和部署方法中，所述实例化包括：

获取所述微服务应用部署的运行环境所需的参数列表；

将所述服务模板中的所述占位符替换为当前运行环境所需的参数。

本发明的另一实施方式提供一种微服务应用编排和部署装置，该微服务应用编排和部署装置包括：

读取模块，用于读取预先存储的一微服务应用的依赖关系树，其中，所述微服务应用为所述依赖关系树的根节点；

遍历模块，用于根据预设规则遍历所述依赖关系树中所有节点并确定所有节点的启动顺序；

部署模块，用于根据所述启动顺序将所有节点对应的应用部署到运行环境中，从而完成所述微服务应用的部署。

本发明的另一实施方式提供一种计算机终端，该计算机终端包括存储器以及处理器，所述存储器用于存储计算机程序，所述处理器运行所述计算机程序以使所述计算机终端执行上述的微服务应用编排和部署方法。

本发明的另一实施方式提供一种计算机存储介质，该计算机存储介质存储上述的计算机终端中所使用的所述计算机程序

本发明微服务应用编排和部署方法、装置及计算机终端至少提供以下技术效果：通过可视化的应用编排方式，避免用户直接编写复杂的yaml文件来实现应用的编排，用户不需要过于专业的知识就可以实现应用的编排任务，降低使用门槛，提升企业devops(软件工程、技术运营和质量保障三者的交集)能力；自动按照正确的启动顺序把微服务应用、微服务应用所依赖的组件等全部部署到容器集群中，实现一键部署。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本发明的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本发明第一实施例提出的一种微服务应用编排和部署方法的流程示意图。

图2为本发明实施例提出的一种微服务应用依赖关系的结构示意图。

图3为本发明实施例提出的一种依赖关系树的结构示意图。

图4为本发明第二实施例提出的一种微服务应用编排和部署方法的流程示意图。

图5为本发明实施例提出的一种应用部署方法的流程示意图。

图6为本发明实施例提出的一种微服务应用编排和部署装置结构示意图。

主要元件符号说明：

10-微服务应用编排和部署装置；110-读取模块；120-遍历模块；130-部署模块。

具体实施方式

在下文中，将更全面地描述本公开的各种实施例。本公开可具有各种实施例，并且可在其中做出调整和改变。然而，应理解：不存在将本公开的各种实施例限于在此公开的特定实施例的意图，而是应将本公开理解为涵盖落入本公开的各种实施例的精神和范围内的所有调整、等同物和/或可选方案。

在下文中，可在本公开的各种实施例中使用的术语“包括”或“可包括”指示所公开的功能、操作或元件的存在，并且不限制一个或更多个功能、操作或元件的增加。此外，如在本公开的各种实施例中所使用，术语“包括”、“具有”及其同源词仅意在表示特定特征、数字、步骤、操作、元件、组件或前述项的组合，并且不应被理解为首先排除一个或更多个其它特征、数字、步骤、操作、元件、组件或前述项的组合的存在或增加一个或更多个特征、数字、步骤、操作、元件、组件或前述项的组合的可能性。

在本公开的各种实施例中，表述“或”或“A或/和B中的至少一个”包括同时列出的文字的任何组合或所有组合。例如，表述“A或B”或“A或/和B中的至少一个”可包括A、可包括B或可包括A和B二者。

在本公开的各种实施例中使用的表述(诸如“第一”、“第二”等)可修饰在各种实施例中的各种组成元件，不过可不限制相应组成元件。例如，以上表述并不限制所述元件的顺序和/或重要性。以上表述仅用于将一个元件与其它元件区别开的目的。例如，第一用户装置和第二用户装置指示不同用户装置，尽管二者都是用户装置。例如，在不脱离本公开的各种实施例的范围的情况下，第一元件可被称为第二元件，同样地，第二元件也可被称为第一元件。

应注意到：如果描述将一个组成元件“连接”到另一组成元件，则可将第一组成元件直接连接到第二组成元件，并且可在第一组成元件和第二组成元件之间“连接”第三组成元件。相反地，当将一个组成元件“直接连接”到另一组成元件时，可理解为在第一组成元件和第二组成元件之间不存在第三组成元件。

在本公开的各种实施例中使用的术语“用户”可指示使用电子装置的人或使用电子装置的装置(例如，人工智能电子装置)。

在本公开的各种实施例中使用的术语仅用于描述特定实施例的目的并且并非意在限制本公开的各种实施例。如在此所使用，单数形式意在也包括复数形式，除非上下文清楚地另有指示。除非另有限定，否则在这里使用的所有术语(包括技术术语和科学术语)具有与本公开的各种实施例所属领域普通技术人员通常理解的含义相同的含义。所述术语(诸如在一般使用的词典中限定的术语)将被解释为具有与在相关技术领域中的语境含义相同的含义并且将不被解释为具有理想化的含义或过于正式的含义，除非在本公开的各种实施例中被清楚地限定。

实施例1

图1为本发明第一实施例提出的一种微服务应用编排和部署方法的流程示意图。该微服务应用编排和部署方法包括：

步骤S110，读取预先存储的一微服务应用的依赖关系树。

在部署新的微服务应用时，读取已存储到数据库中的该微服务应用的依赖关系树，并对该读取的依赖关系树进行分析，得到该依赖关系树中所有节点的信息及所有节点之间的连接关系。

步骤S120，根据预设规则遍历所述依赖关系树中所有节点并确定所有节点的启动顺序。

如图2所示，微服务应用1依赖于微服务应用2、缓存、数据库1和数据库2，微服务应用2又依赖于微服务应用3、自助分布式版本控制系统服务和消息队列，微服务应用3又依赖于服务注册中心。如果启动微服务应用1的话，正确的部署顺序应该是首先部署服务注册中心，其次部署微服务应用3、自助分布式版本控制系统服务和消息队列，再次部署微服务应用2、缓存、数据库1和数据库2，最部署微服务应用1。

本实施例中，预设规则包括：

以根节点为起点，查找所述依赖关系树中所有节点是否有子节点；若所述节点有子节点，优先遍历所述子节点。

例如，以图3中的依赖关系树为例来说明该预设规则的遍历顺序：

(1)创建一个空栈S，以根节点A为起点开始遍历；

(2)将当前节点A压入栈S中；

(3)判断该节点A是否有子节点，若有，先获取该节点A的第一个子节点B，将节点B压入栈S中；

(4)判断节点B是否有子节点，若有，先获取该节点B的第一个子节点F，将节点F压入栈S中；

(5)判断节点F是否有子节点，若有，先获取该节点F的第一个子节点I，将该节点I压入栈S中；

(6)判断节点I是否具有子节点，当前节点I为叶子节点，即节点I无子节点，则将栈S中节点I弹出；

(7)获取节点F的除了节点I之外的其他子节点，若无，将栈S汇总节点F弹出；

(8)获取节点B的除了节点F外的其他子节点，若有，获取该节点B的第二个子节点G，将节点G压入栈S中；

(9)判断节点G是否具有子节点，若无，将栈S中节点G弹出；

(10)获取节点B的除了节点F外的其他子节点，若有，获取该节点B的第三个子节点H，将节点H压入栈S中；

(11)判断节点H是否具有子节点，若无，将栈S中节点H弹出；

(12)获取节点B的除了节点F、G、H之外的其他子节点，若无，将栈S汇总节点B弹出；

(13)获取节点A的除了节点B外的其他子节点，若有，获取该节点A的第二个子节点C，将节点C压入栈S中；

(14)判断节点C是否具有子节点，若无，将栈S中节点C弹出；

(15)获取节点A的除了节点B、C外的其他子节点，若有，获取该节点A的第二个子节点D，将节点D压入栈S中；

(16)判断节点D是否具有子节点，若无，将栈S中节点D弹出；

(17)获取节点A的除了节点B、C、D外的其他子节点，若有，获取该节点A的第二个子节点E，将节点E压入栈S中；

(18)判断节点E是否具有子节点，若无，将栈S中节点E弹出；

(19)获取节点A的除了节点B、C、D、E外的其他子节点，若无，将栈S中节点A弹出。

至此，通过该预设规则的遍历方法获取的节点顺序为：IFGHBCDEA，并以该节点顺序作为启动顺序。

值得注意的是，每一节点的所有子节点的遍历顺序不受限制，如节点A具有四个子节点B、C、D和E，通过该预定规则遍历节点A的子节点时，可从节点B、C、D和E中任一个节点开始遍历，如BCDE、BDCE、BEDC、BDEC、CDEB、CBDE、CEDB、DBCE等。

由此，根据该预设规则对图3中的依赖关系树进行遍历，还可以得到其他遍历结果，如：IFHGBCDEA；IFHGBDCEA；IFHGBEDCA；IFHGBECDA；CDEIFGHBA；CDEGHIFBA；CGIFHBDEA等。

优选地，该预设规则还可以通过递归算法来实现。例如，对于节点A，若其具有子节点，总是先遍历其子节点；对于节点A的所有子节点B、C、D、E，若其具有子节点，同样先遍历其子节点，直至该节点为叶子节点，既所述依赖关系树中每一节点都执行一遍上述预设规则的遍历方法。

步骤S130，根据所述启动顺序将所有节点对应的应用部署到运行环境中，从而完成所述微服务应用的部署。

将依赖关系树中所有节点对应的应用按照步骤S120中获得的启动顺序进行部署，避免人为的控制微服务应用部署过程中各应用的启动顺序，便于自动化运维，实现与所述微服务应用及与所述微服务应用之间有依赖关系的所有应用的一键部署。

由于在运行环境中包括千万个微服务应用，所以在部署的过程中，每一个微服务应用都根据上述的部署方法进行部署。另外，若某一个微服务应用同时被多个微服务应用所依赖，那么该微服务应用只需部署一次。

例如，微服务应用100同时被微服务应用99及微服务应用89所依赖，在部署微服务应用99时，已经将该微服务应用100、微服务应用100所依赖的中间组件、微服务应用100所依赖的其他微服务应用一并部署到运行环境中。那么，在部署微服务应用89时，首先检测微服务应用89所依赖的应用如微服务100是否已经部署，若已经部署，则不再部署该微服务应用100。

在步骤S110之前，还包括：

根据所述微服务应用自身的基本信息获知该微服务应用的依赖关系。对于一个微服务应用来说，通常会依赖诸如缓存、数据库、消息队列等中间组件，除了中间组件外，还会依赖于其他微服务应用。

其中，所述基本信息可以包括名称、端口个数、端口编号等信息。

中间组件可包括缓存、数据库、消息队列、自助分布式版本控制系统服务及服务注册中心等。

如图2所示为本发明实施例提出的一种微服务应用依赖关系的结构示意图。

例如，微服务应用1不仅依赖于缓存、数据库1、数据库2及服务注册中心，还依赖于微服务应用2；微服务应用2除了依赖于消息队列及自助分布式版本控制系统服务外，还依赖于微服务应用3；微服务应用3依赖于服务注册中心，不依赖于其他的微服务应用。

为了描述和管理微服务应用之间的复杂的依赖关系，基于微服务应用依赖关系的特点，根据该依赖关系构造树形数据结构来描述所述微服务应用之间的依赖关系。其中，该依赖关系树为非标准树形结构，在该依赖关系树中，树中的某一个节点可以有两个以上的父节点，即某一个节点对应的应用可同时被多个服务应用所依赖。

如图3所示为本发明实施例提出的一种依赖关系树的结构示意图。该微服务应用的依赖关系树根据图2中的微服务应用的依赖关系抽象而成。其中，各个节点对应一微服务应用。

每一微服务应用或中间组件通常对应一docker镜像，每次部署新的微应用之前，都要先录入微服务应用自身的基本信息，并选择与该微服务应用关联的镜像文件，并将以上所有服务应用与对应的镜像文件之间的关联关系、所有服务应用的依赖关系持久化到数据库中形成依赖关系树。通过该种方式可以直观地、可视化地描述微服务应用之间的关系。优选地，当微服务应用的依赖关系发生改变时，通过可视化的方式响应用户的输入操作更新该依赖关系对应的所述依赖关系树，便于用户通过更直观的方式对该依赖关系树进行维护，且非专业技术人员也可以通过该可视化的方式对依赖关系树进行修改、更新。

例如，当微服务应用的依赖关系发生改变时，用户可通过可视化的方式执行修改节点之间的依赖关系、添加节点及该节点与其他节点之间的依赖关系至依赖关系树中、删除节点及该节点与其他节点之间的依赖关系等等操作，并根据该修改、添加、删除等操作更新所述依赖关系树。通过该种方式便于维护微服务之间复杂的依赖关系，通过可视化的方式展现、并维护微服务应用之间的依赖关系，当微服务的依赖很多、层次很深时，维护其复杂的依赖关系变得更简单直观。

实施例2

步骤S210，获取微服务应用的基本信息。

步骤S220，判断微服务应用是否依赖于其他应用。

在本实施例中，所述其他应用包括中间组件及其他微服务应用。若该微服务应用依赖于其他应用，前进至步骤S230；若该微服务应用不依赖与其他应用，前进至步骤S270。

步骤S230，根据微服务应用的依赖关系构造依赖关系树并存储。

例如，图2中所示的微服务应用1与中间组件及其他微服务应用之间的依赖关系。

在该微服务应用与其他服务应用之间存在依赖关系时，根据该依赖关系的本质，构造出该依赖关系的树形结构，并将该树形结构存储到数据库中。如图3所示为本发明实施例提出的一种依赖关系树的结构示意图，该依赖关系树根据图2所示的微服务应用的依赖关系进行构造而成。

所述依赖关系树中每一节点对应有具体的应用，其中，该节点与应用之间的关系存储在数据库中。

例如，如下表所示的为该依赖关系树的存储形式，可通过表格的方式进行描述。

节点	应用	父节点
			A	微服务应用1	NULL
B	微服务应用2	A
			C	缓存	A
D	数据库1	A
			E	数据库2	A
F	微服务应用3	B
			G	自助式分布式版本控制系统服务	B
H	消息队列	B
			I	服务注册中心	A或F

上表中，依赖关系树中节点A对应的为微服务应用1，由于节点A为该依赖关系树的根节点，所以其父节点为空；节点B对应的为微服务应用2，其父节点为节点A。另外，节点I的父节点为节点A、节点F，可只记录节点A为其父节点，也可以只记录节点F为其父节点，只要从服务部署的优先级上保证节点I优先于节点A、节点F之前部署到应用环境中即可。

进一步，在该微服务应用的依赖关系发生变化时，可根据用户的输入操作可视化的对该依赖关系树进行修改，根据修改信息更新存储的依赖关系树。

步骤S240，读取预先存储的所述微服务应用的依赖关系树。

步骤S250，根据预设规则遍历所述依赖关系树中所有节点并确定所有节点的启动顺序。

在本实施例中，所述预设规则包括：

以根节点为起点，若所述节点具有子节点，总是优先遍历其子节点。其中，对某一节点的所有子节点，即兄弟节点的遍历顺序不受限制。

步骤S260，针对启动顺序中的每一节点。

步骤S270，判断该节点对应的应用是否部署到运行环境中。

微服务应用的运行环境中可包含成千上万个微服务应用，一个微服务应用可同时被多个其他的微服务应用所依赖，所以，在部署一应用之前，首先判断微服务应用是否已经被部署，若已被部署，则不需要部署该应用。

针对启动顺序中的每一节点，判断其是否已经部署到运行环境中，若已经部署到当前运行环境中，则前进至步骤S290；若没有部署到当前运行环境中，前进至步骤S280。

步骤S280，部署该节点对应的应用。

如图5所示为本发明实施例提出的一种应用部署方法的流程示意图。该应用部署方法包括：

步骤S281，获取节点对应的应用的服务模板。

由于所述依赖关系树中节点对应的应用包括微服务应用和中间组件应用，所以，所述服务模板同样包括中间组件模板及微服务应用模板。

由于中间组件模板很多内容是固定不变的，而且重用性很高，可响应于用户的输入操作为每一中间组件编写一个中间组件模板；而对于微服务应用来说，每个应用环境包括成千上万个微服务应用，且每个微服务应用的内容是千差万别的，比如每个微服务的应用名称不一样、暴露的端口个数、端口编号等均不同，为每一个微服务应用都编写一个微服务应用模板需要耗费巨大的时间和精力，且编写的微服务应用模板的重用性很低，所以，为减少用户工作量，抽取所述微服务应用的共同特征，响应用户的输入操作为所有的微服务应用编写一个通用的微服务应用模板。

服务模板中包括占位符，该占位符用于替换不同运行环境所需的不同的参数文件，以此实现同一个应用在不同运行环境中部署。

例如，在开发环境中，某服务应用模板需要需要传递A参数，而在测试环境中，服务应用需要传递B参数，由于不同应用环境需要传递的参数不同，为了使编写的服务模板具有通用性，在服务模板编写的过程中，将传递的参数的该部分用占位符代替，在部署该应用的时候，可以将服务模板中占位符替换为不同当前应用环境所需的参数文件，如将该服务应用部署到开发环境中时，将服务模板中的占位符替换为A参数的yaml文件；将该服务应用部署到测试环境中时，将服务模板中的占位符替换为B参数的yaml文件。

通常一个微服务应用从开发、测试到最后部署，至少需要将该微服务应用部署到开发、测试、生产及预发布等运行环境中，为了便于将同一个微服务应用部署到多套环境中，对于不同运行环境需要的参数用占位符来描述，当部署多套运行环境时，将服务模板中的占位符替换为当前运行环境所需参数的yaml文件。

Docker Compose、Kubernetes原生编排在把同一个微服务应用部署到不同环境时必须为每一个环境编写一次，其繁琐程度可想而知了，该种方式解决了应用编排重复而繁琐、无法重用的问题，能快速部署多套运行环境，提高微服务应用的重用性，大大提升工作效率，加快产品持续更新及迭代速度，快速实现持续集成与持续交付。

服务模板编写完成后，将编写好的服务模板存储到存储器中。

步骤S282，将所述服务模板实例化及生成当前运行环境所需的参数文件。

所述实例化为将服务模板中的占位符替换为部署的运行环境所需的参数的过程。

将所述占位符替换为当前运行环境所需的参数后，将该服务模板生成当前运行环境的参数文件。

例如，在kubernetes环境，可将该服务模板生成yaml文件。

步骤S283，解析所述参数文件及根据解析结果创建所述应用的对象。

解析生成的当前运行环境所需的yaml文件，及根据解析结果创建该应用的对象，将所述应用部署到运行环境中。

例如，部署应用redis(缓存)时，需要在kubernetes环境中调用API(操作系统留给应用程序的调用接口)创建ConfigMap、Deployment及Service三个对象，实现redis的部署。

例如，一个微服务应用可能会依赖很多个中间组件，该依赖信息及依赖的所有应用的信息都描述在yaml文件中，判断一个微服务应用是否部署，通常是判断某一个关键的对象是否已经部署到kubernetes环境中。

本实施例中，可以通过FreeMarker标记语言来编写yaml文件。本发明的其他实施例中，还可以通过其他语言来编写yaml文件。

步骤S290，判断节点对应的应用是否部署完毕。

在当前的应用环境中，若所述启动顺序中的所有节点对应的应用部署完毕，结束该微服务应用及其依赖应用的部署；若所述启动顺序中还有节点对应的应用未被部署，前进至步骤S260，持续进行剩余未部署节点对应的应用，直到启动顺序中所有节点对应的应用均部署完毕。

实施例3

图6为本发明实施例提出的一种微服务应用编排和部署装置结构示意图。该微服务应用编排和部署装置10包括：读取模块110、遍历模块120和部署模块130。

读取模块110，用于读取预先存储的一微服务应用的依赖关系树，其中，所述微服务应用为所述依赖关系树的根节点。

遍历模块120，用于根据预设规则遍历所述依赖关系树中所有节点并确定所有节点的启动顺序。

部署模块130，用于根据所述启动顺序将所有节点对应的应用部署到运行环境中，从而完成所述微服务应用的部署。

本实施例还提出了一种计算机终端，该计算机终端，包括存储器以及处理器，所述存储器用于存储计算机程序，所述处理器运行所述计算机程序以使所述计算机终端执行上述的微服务应用编排和部署方法。

本实施例还提出了一种计算机可读存储介质，用于存储上述的微服务应用编排和部署方法。

以此，本发明提出了一种微服务应用编排和部署方法、装置及计算机终端，避免用户直接编写复杂的yaml文件来实现应用的编排，用户不需要过于专业的知识就可以实现应用的编排任务，降低使用门槛，提升企业devops(软件工程、技术运营和质量保障三者的交集)能力；自动按照正确的启动顺序把微服务应用、微服务应用所依赖的组件等全部部署到容器集群中，实现一键部署；通过可视化的方式更直观清晰对微服务应用的依赖关系及依赖关系树进行更新及维护；解决了应用编排重复而繁琐、无法重用的问题，能快速部署多套运行环境，提高微服务应用的重用性，大大提升工作效率，加快产品持续更新及迭代速度，快速实现持续集成与持续交付。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统和方法，也可以通过其它的方式实现。以上所描述的系统实施例仅仅是示意性的，例如，附图中的流程图和结构图显示了根据本发明的多个实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，结构图和/或流程图中的每个方框、以及结构图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

另外，在本发明各个实施例中的各功能模块或单元可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或更多个模块集成形成一个独立的部分。

所述功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是智能手机、个人计算机、服务器、或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。

Claims

1.一种微服务应用编排和部署方法，其特征在于，包括：

根据所述微服务应用与中间组件及其他微服务应用之间的依赖关系构造依赖关系树并存储；

根据所述启动顺序将所有节点对应的应用部署到运行环境中，从而完成所述微服务应用的部署；

当所述微服务应用的依赖关系发生改变时，根据用户的修改操作更新所述依赖关系树；

所述“将所有节点对应的应用部署到运行环境中”包括：

获取所述节点对应的应用的服务模板；

2.如权利要求1所述的微服务应用编排和部署方法，其特征在于，所述预设规则包括：

若所述节点有子节点，优先遍历所述子节点。

3.如权利要求1所述的微服务应用编排和部署方法，其特征在于，还包括：

4.如权利要求3所述的微服务应用编排和部署方法，其特征在于，所述实例化包括：

获取所述微服务应用部署的运行环境所需的参数列表；

5.一种微服务应用编排和部署装置，其特征在于，包括：

关系树构建模块，用于根据所述微服务应用与中间组件及其他微服务应用之间的依赖关系构造依赖关系树并存储；

部署模块，用于根据所述启动顺序将所有节点对应的应用部署到运行环境中，从而完成所述微服务应用的部署；

修改模块，用于当所述微服务应用的依赖关系发生改变时，根据用户的修改操作更新所述依赖关系树；

所述“将所有节点对应的应用部署到运行环境中”包括：

获取所述节点对应的应用的服务模板；

6.一种计算机终端，其特征在于，包括存储器以及处理器，所述存储器用于存储计算机程序，所述处理器运行所述计算机程序以使所述计算机终端执行根据权利要求1至4中任一项所述的微服务应用编排和部署方法。

7.一种计算机存储介质，其特征在于，其存储有权利要求6所述的计算机终端中所使用的所述计算机程序。