CN106487912A - 多服务应用的管理与发布方法及装置 - Google Patents

Abstract

本发明公开了一种多服务应用的管理与发布方法及装置，包括：接收多服务应用创建请求；根据所述多服务应用创建请求，创建组成多服务应用的服务；在创建组成多服务应用的服务的过程中，根据所述服务的依赖属性，设定所述服务之间的树形依赖关系；在发布多服务应用时，将所述树形依赖关系转换为线性发布顺序，并根据所述线性发布顺序，完成多服务应用的发布。本发明提供的所述多服务应用的管理与发布方法及装置，解决了多服务应用的多服务之间的依赖管理及联合发布问题。

Description

多服务应用的管理与发布方法及装置

技术领域

本发明涉及数据处理技术领域，特别是指一种多服务应用的管理与发布方法及装置。

背景技术

无论是以往的三层架构、SOA架构（Service Oriented Architecture，面向服务的体系结构），还是现在流行的微服务架构的应用一般都涉及到多个分别部署的模块或者服务。当迁移传统的应用或者流行的微服务架构的应用为SaaS（Software-as-a-Service：软件即服务）应用并部署到PaaS（Platform-as-a-Service：平台即服务）平台上时，不可避免地会遇到多服务应用的多服务联合发布的问题。

比如三层架构是将整个业务应用划分为：界面层（User Interface layer）、业务逻辑层（Business Logic Layer）、数据访问层（Data access layer）。将三层架构迁移到PaaS平台的多服务应用时一般可以包含三个服务：界面层服务、业务逻辑层服务以及数据访问层服务。

SOA面向服务的体系结构，是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。

面向服务的体系结构中的角色如图1所示。面向服务的体系结构中的每个实体都扮演着服务提供者、请求者和注册中心这三种角色中的某一种（或多种）当迁移SOA架构应用到PaaS平台的多服务应用时，每个服务实体都可以构成多服务应用的一个服务。

微服务架构应用，是把一个单独的应用程序开发为一套小服务，每个小服务运行在自己的进程中，并使用轻量级机制通信，通常是HTTP API。这些服务围绕业务能力来构建，并通过完全自动化部署机制来独立部署。微服务架构应用天生适合PaaS平台部署，每个小服务就构成多服务应用的一个服务。

Docker是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的Linux机器上，也可以实现虚拟化。Kubernetes是Google开源的Docker容器集群管理系统，它构建在Docker技术之上，为容器化的应用提供资源调度、部署运行、服务发现、扩容缩容等整一套功能，本质上可看作是基于容器技术的mini-PaaS平台。

然而，原生的Docker和Kubernetes的技术框架里虽然提出了服务的概念，但是并没有提出应用的概念，并且对于构成某个多服务应用的多服务之间的依赖管理和联合发布更是缺乏好的实现。因此，当PaaS平台基于Docker和Kubernetes的技术框架开发时，则需要解决多服务应用的多服务之间的依赖管理和联合发布的问题。

发明内容

有鉴于此，本发明的目的在于提出一种多服务应用的管理与发布方法及装置，很好地解决了多服务应用的多服务之间的依赖管理及联合发布问题。

基于上述目的本发明提供的多服务应用的管理与发布方法，包括：

接收多服务应用创建请求；

根据所述多服务应用创建请求，创建组成多服务应用的服务；在创建组成多服务应用的服务的过程中，根据所述服务的依赖属性，设定所述服务之间的树形依赖关系；

在发布多服务应用时，将所述树形依赖关系转换为线性发布顺序，并根据所述线性发布顺序，完成多服务应用的发布。

在一些可选实施方式中，所述根据所述多服务应用创建请求，创建组成多服务应用的服务的步骤，具体包括：

创建无依赖的服务；

创建有依赖的服务；并且，在所述有依赖的服务的服务定义过程中，在所述有依赖的服务的依赖服务属性里选择要依赖的服务；所述依赖服务属性包括已经开通的公共服务和所述多服务应用下已经创建的服务；

组成所述多服务应用的服务均已创建完成后，根据服务之间的依赖关系生成所述多服务应用的树形拓扑图。

在一些可选实施方式中，所述创建无依赖的服务的步骤包括：

对于本身无依赖的服务，创建为无依赖的服务；

对于有依赖但所依赖的服务当前不存在的服务，先创建为无依赖的服务，待其所依赖的服务被创建后，再更改所述服务的依赖服务属性，使其成为有依赖的服务。

在一些可选实施方式中，将所述树形依赖关系转换为线性发布顺序，并根据所述线性发布顺序，完成多服务应用的发布的步骤，具体包括：

遍历所述树形拓扑图，标记每个服务节点的层级；

按所述服务节点的层级，完成多服务应用的发布。

在一些可选实施方式中，所述按所述服务节点的层级，完成多服务应用的发布的步骤，具体包括：

找到所有服务节点的最高层级，设为M；

如果M=0，则对应的服务节点表示为根服务节点，发布完成所述根服务结点后返回；否则循环执行下面步骤：

依次发布层级为M的服务节点；

完成层级为M的服务节点的发布后，令M=M-1。

本发明还提供了一种多服务应用的管理与发布装置，包括：

接收模块，用于接收多服务应用创建请求；

创建模块，用于根据所述多服务应用创建请求，依次创建组成多服务应用的服务；在依次创建组成多服务应用的服务的过程中，根据所述服务的依赖属性，设定所述服务之间的树形依赖关系；

发布模块，用于在发布多服务应用时，将所述树形依赖关系转换为线性发布顺序，并根据所述线性发布顺序，完成多服务应用的发布。

在一些可选实施方式中，所述创建模块，具体用于：

创建无依赖的服务；

创建有依赖的服务；并且，在所述有依赖的服务的服务定义过程中，在所述有依赖的服务的依赖服务属性里选择要依赖的服务；所述依赖服务属性包括已经开通的公共服务和所述多服务应用下已经创建的服务；

组成所述多服务应用的服务均已创建完成后，根据服务之间的依赖关系生成所述多服务应用的树形拓扑图。

在一些可选实施方式中，所述创建模块，还具体用于：

对于本身无依赖的服务，创建为无依赖的服务；

对于有依赖但所依赖的服务当前不存在的服务，先创建为无依赖的服务，待其所依赖的服务被创建后，再更改所述服务的依赖服务属性，使其成为有依赖的服务。

在一些可选实施方式中，所述发布模块，具体用于：

遍历所述树形拓扑图，标记每个服务节点的层级；

按所述服务节点的层级，完成多服务应用的发布。

在一些可选实施方式中，所述发布模块，还具体用于：

找到所有服务节点的最高层级，设为M；

如果M=0，则对应的服务节点表示为根服务节点，发布完成所述根服务结点后返回；否则循环执行下面步骤：

依次发布层级为M的服务节点；

完成层级为M的服务节点的发布后，令M=M-1。

从上面所述可以看出，本发明提供的多服务应用的管理与发布方法及装置，通过在创建组成多服务应用的服务的过程中设定服务之间的树形依赖关系，从而在发布时按照基于树形依赖关系的线性发布顺序完成多服务应用的发布，从而实现了多服务应用的多服务一键联合发布并方便了多服务之间的依赖关系的管理。

附图说明

图1为现有技术中面向服务的体系结构的示意图；

图2为本发明提供的多服务应用的管理与发布方法的一个实施例的流程示意图；

图3为本发明提供的多服务应用的管理与发布方法的另一个实施例的流程示意图；

图4为本发明提供的多服务应用的管理与发布装置的一个实施例的模块结构示意图；

图5为本发明提供的多服务应用的管理与发布方法及装置实施例中树形拓扑图的示例性结构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明白，以下结合具体实施例，并参照附图，对本发明进一步详细说明。

需要说明的是，本发明实施例中所有使用“第一”和“第二”的表述均是为了区分两个相同名称非相同的实体或者非相同的参量，可见“第一”“第二”仅为了表述的方便，不应理解为对本发明实施例的限定，后续实施例对此不再一一说明。

为弥补原生的Docker和Kubernetes技术框架的不足，本发明实施例提供的PaaS平台开发了一种通用方法可以为基于Docker和Kubernetes技术框架开发的PaaS平台实现多服务应用的多服务一键联合发布并方便管理多服务之间的依赖关系。

云计算PaaS平台是一个供多租户发布运维应用的平台，我们把可以供多租户使用的平台级服务比如数据库服务，中间件服务作为公共服务。公共服务包含开通、停用、启用、删除等通用接口。应用中的服务可以依赖的服务包含两种类型：一种是该租户开通的公共服务，该公共服务可以被当前应用或者该租户的其他应用所依赖；另一种是当前应用包含的其他服务（即，除了当前定义的服务和公共服务以外的当前应用包含的其他服务）。

基于前述目的，本发明实施例的第一个方面，提供了一种能够解决多服务应用的多服务之间的依赖管理及联合发布问题的多服务应用的管理与发布方法的一个实施例。如图2所示，为本发明提供的多服务应用的管理与发布方法的一个实施例的流程示意图。

所述多服务应用的管理与发布方法，可选的，应用于发布应用的PaaS平台，包括：

步骤101：接收多服务应用创建请求；

步骤102：根据所述多服务应用创建请求，创建组成多服务应用的服务；在创建组成多服务应用的服务的过程中，根据所述服务的依赖属性，设定所述服务之间的树形依赖关系；

步骤103：在发布多服务应用时，将所述树形依赖关系转换为线性发布顺序，并根据所述线性发布顺序，完成多服务应用的发布。

从上述实施例可以看出，本发明实施例提供的多服务应用的管理与发布方法，通过在创建组成多服务应用的服务的过程中设定服务之间的树形依赖关系，从而在发布时按照基于树形依赖关系的线性发布顺序完成多服务应用的发布，从而实现了多服务应用的多服务一键联合发布并方便了多服务之间的依赖关系的管理。

本发明还提供了一种能够解决多服务应用的多服务之间的依赖管理及联合发布问题的多服务应用的管理与发布方法的另一个实施例。如图3所示，为本发明提供的多服务应用的管理与发布方法的一个实施例的流程示意图。

所述多服务应用的管理与发布方法，可选的，应用于发布应用的PaaS平台，包括：

步骤101：接收用户发送的多服务应用创建请求；这里，用户通过其在PaaS平台租户门户创建一个空应用，从而向PaaS平台发出了所述多服务应用创建请求。

步骤201：接收用户发送的公共服务创建请求；这里，用户根据自己想要创建的多服务应用的定义，决定是否需要选择或创建公共服务，若需要创建公共服务，则调用PaaS平台的创建公共服务的模块，亦即，向PaaS平台发出所述公共服务创建请求。

步骤202：循环创建所述多服务应用所需的公共服务；这里，公共服务都是基础服务，因此，互相之间不存在相互依赖关系。

步骤203：公共服务创建完成后，将相关的公共服务的连接调用参数返回给用户。

步骤102：根据所述多服务应用创建请求，创建组成多服务应用的服务；在创建组成多服务应用的服务的过程中，根据所述服务的依赖属性，设定所述服务之间的树形依赖关系。

可选的，所述根据所述多服务应用创建请求，创建组成多服务应用的服务的步骤102，具体可包括以下步骤：

步骤1021：创建无依赖的服务；其中，可选的，对于本身无依赖的服务，创建为无依赖的服务；对于有依赖但所依赖的服务当前不存在的服务，先创建为无依赖的服务，待其所依赖的服务被创建后，再更改所述服务的依赖服务属性，使其成为有依赖的服务；比如如果在创建服务a的时候服务b尚未创建，那么在服务a的服务依赖属性里无法选择服务b，这时可以先创建一个无依赖的服务a，在服务b创建完成后，再修改服务a的依赖属性，选择依赖服务b；

步骤1022：创建有依赖的服务；并且，在所述有依赖的服务的服务定义过程中，在所述有依赖的服务的依赖服务属性里选择要依赖的服务并为其设置别名；所述依赖服务属性包括已经开通的公共服务和所述多服务应用下已经创建的服务；设置所述别名是为了将依赖服务的参数关联到当前服务的参数；所述别名通常是当前服务已经定义好的参数名字；

步骤1023：组成所述多服务应用的服务均已创建完成后，根据服务之间的依赖关系生成所述多服务应用的树形拓扑图，从而直观显示服务之间的相互依赖关系；如图4所示，为本发明提供的多服务应用的管理与发布方法实施例中树形拓扑图的示例性结构示意图，所述树形拓扑图中，叶子节点是公共服务或者是无依赖的服务，当中的节点是有依赖的服务，根节点是没有被任何服务所依赖的服务；比如，服务a依赖服务b、服务g和公共服务c，而服务b又依赖公共服务d、e、f，这样，生成的树形依赖关系就如图5所示。

步骤103：在发布多服务应用时，调用树遍历算法，从而将所述树形依赖关系转换为多服务的线性发布顺序，并根据所述线性发布顺序，完成多服务应用的多服务发布。

所述将所述树形依赖关系转换为线性发布顺序，并根据所述线性发布顺序，完成多服务应用的发布的步骤103，具体可包括以下步骤：

步骤1031：遍历所述树形拓扑图，标记每个服务节点的层级；这里，服务节点是指形成为所述树形拓扑图中的其中一个节点的服务；

进一步的，所述遍历所述树形拓扑图，标记每个服务节点的层级的步骤1031，具体可包括以下步骤：

如果子树为空则直接返回，否则，采用以下步骤完成遍历：

访问根服务节点，标志层级为其父服务节点层级+1，如果为根服务节点则标记为0；

访问左一子树；

访问左二子树；

直到同一层级子树为空；

以图5为例就得到了各服务节点的层级如下：a[0]、c[1]、b[1]、d[2]、e[2]、f[2]、g[1]；[]中的数字即为对应服务节点的层级；

步骤1032：按所述服务节点的层级，完成多服务应用的发布；

进一步的，所述按所述服务节点的层级，完成多服务应用的发布的步骤1032，具体可包括以下步骤：

找到所有服务节点的最高层级，设为M；

如果M=0，则对应的服务节点表示为根服务节点，发布完成所述根服务结点后返回；否则循环执行下面步骤：

依次发布层级为M的服务节点；如果服务节点为公共服务则略过（公共服务已经提前开通好）；

完成层级为M的服务节点的发布后，令M=M-1。

这样，以图5为例就得到了发布服务的采用树遍历法生成的线性发布序列为：d→e→f→c→b→g->a。

从上述实施例可以看出，本发明实施例提供的多服务应用的管理与发布方法，通过在创建组成多服务应用的服务的过程中设定服务之间的树形依赖关系，从而在发布时按照基于树形依赖关系的线性发布顺序完成多服务应用的发布，从而实现了多服务应用的多服务一键联合发布并方便了多服务之间的依赖关系的管理。

基于前述目的，本发明实施例的第二个方面，提供了一种能够解决多服务应用的多服务之间的依赖管理及联合发布问题的多服务应用的管理与发布装置的一个实施例。如图4所示，为本发明提供的多服务应用的管理与发布装置的一个实施例的模块结构示意图。

如图4所示，所述多服务应用的管理与发布装置，包括：

接收模块301，用于接收多服务应用创建请求；

创建模块302，用于根据所述多服务应用创建请求，依次创建组成多服务应用的服务；在依次创建组成多服务应用的服务的过程中，根据所述服务的依赖属性，设定所述服务之间的树形依赖关系；

发布模块303，用于在发布多服务应用时，将所述树形依赖关系转换为线性发布顺序，并根据所述线性发布顺序，完成多服务应用的发布。

从上述实施例可以看出，本发明实施例提供的多服务应用的管理与发布装置，通过在创建组成多服务应用的服务的过程中设定服务之间的树形依赖关系，从而在发布时按照基于树形依赖关系的线性发布顺序完成多服务应用的发布，从而实现了多服务应用的多服务一键联合发布并方便了多服务之间的依赖关系的管理。

在一些可选实施方式中，所述创建模块302，还具体用于：

创建无依赖的服务；

创建有依赖的服务；并且，在所述有依赖的服务的服务定义过程中，在所述有依赖的服务的依赖服务属性里选择要依赖的服务；所述依赖服务属性包括已经开通的公共服务和所述多服务应用下已经创建的服务；

组成所述多服务应用的服务均已创建完成后，根据服务之间的依赖关系生成所述多服务应用的树形拓扑图。

通过上述实施例，按照顺序对组成多服务应用的多服务进行创建，从而形成较为完整的树形拓扑图，能够更好地对其进行管理。

在一些可选实施方式中，所述创建模块302，还具体用于：

对于本身无依赖的服务，创建为无依赖的服务；

对于有依赖但所依赖的服务当前不存在的服务，先创建为无依赖的服务，待其所依赖的服务被创建后，再更改所述服务的依赖服务属性，使其成为有依赖的服务。

通过上述实施例，使得对组成多服务应用的多服务进行创建的过程更加具有灵活性。

在一些可选实施方式中，所述发布模块303，具体用于：

遍历所述树形拓扑图，标记每个服务节点的层级；

按所述服务节点的层级，完成多服务应用的发布。

通过上述实施例，从而能够将所述树形拓扑图完整展开为线性发布顺序，使得多服务的发布更加具有规律，不易发生错漏。

在一些可选实施方式中，所述发布模块303，还具体用于：

找到所有服务节点的最高层级，设为M；

如果M=0，则对应的服务节点表示为根服务节点，发布完成所述根服务结点后返回；否则循环执行下面步骤：

依次发布层级为M的服务节点；

完成层级为M的服务节点的发布后，令M=M-1。

通过上述实施例，提出了一种具体的将所述树形拓扑图完整展开为线性发布顺序的方法，能够很好地实现所述转化。

所属领域的普通技术人员应当理解：以上任何实施例的讨论仅为示例性的，并非旨在暗示本公开的范围（包括权利要求）被限于这些例子；在本发明的思路下，以上实施例或者不同实施例中的技术特征之间也可以进行组合，步骤可以以任意顺序实现，并存在如上所述的本发明的不同方面的许多其它变化，为了简明它们没有在细节中提供。

另外，为简化说明和讨论，并且为了不会使本发明难以理解，在所提供的附图中可以示出或可以不示出与集成电路（IC）芯片和其它部件的公知的电源/接地连接。此外，可以以框图的形式示出装置，以便避免使本发明难以理解，并且这也考虑了以下事实，即关于这些框图装置的实施方式的细节是高度取决于将要实施本发明的平台的（即，这些细节应当完全处于本领域技术人员的理解范围内）。在阐述了具体细节（例如，电路）以描述本发明的示例性实施例的情况下，对本领域技术人员来说显而易见的是，可以在没有这些具体细节的情况下或者这些具体细节有变化的情况下实施本发明。因此，这些描述应被认为是说明性的而不是限制性的。

尽管已经结合了本发明的具体实施例对本发明进行了描述，但是根据前面的描述，这些实施例的很多替换、修改和变型对本领域普通技术人员来说将是显而易见的。例如，其它存储器架构（例如，动态RAM（DRAM））可以使用所讨论的实施例。

本发明的实施例旨在涵盖落入所附权利要求的宽泛范围之内的所有这样的替换、修改和变型。因此，凡在本发明的精神和原则之内，所做的任何省略、修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种多服务应用的管理与发布方法，其特征在于，包括：

接收多服务应用创建请求；

根据所述多服务应用创建请求，创建组成多服务应用的服务；在创建组成多服务应用的服务的过程中，根据所述服务的依赖属性，设定所述服务之间的树形依赖关系；

在发布多服务应用时，将所述树形依赖关系转换为线性发布顺序，并根据所述线性发布顺序，完成多服务应用的发布。

2.根据权利要求1所述的方法，其特征在于，所述根据所述多服务应用创建请求，创建组成多服务应用的服务的步骤，具体包括：

创建无依赖的服务；

创建有依赖的服务；并且，在所述有依赖的服务的服务定义过程中，在所述有依赖的服务的依赖服务属性里选择要依赖的服务；所述依赖服务属性包括已经开通的公共服务和所述多服务应用下已经创建的服务；

组成所述多服务应用的服务均已创建完成后，根据服务之间的依赖关系生成所述多服务应用的树形拓扑图。

3.根据权利要求2所述的方法，其特征在于，所述创建无依赖的服务的步骤包括：

对于本身无依赖的服务，创建为无依赖的服务；

对于有依赖但所依赖的服务当前不存在的服务，先创建为无依赖的服务，待其所依赖的服务被创建后，再更改所述服务的依赖服务属性，使其成为有依赖的服务。

4.根据权利要求2所述的方法，其特征在于，所述将所述树形依赖关系转换为线性发布顺序，并根据所述线性发布顺序，完成多服务应用的发布的步骤，具体包括：

遍历所述树形拓扑图，标记每个服务节点的层级；

按所述服务节点的层级，完成多服务应用的发布。

5.根据权利要求4所述的方法，其特征在于，所述按所述服务节点的层级，完成多服务应用的发布的步骤，具体包括：

找到所有服务节点的最高层级，设为M；

如果M＝0，则对应的服务节点表示为根服务节点，发布完成所述根服务结点后返回；否则循环执行下面步骤：

依次发布层级为M的服务节点；

完成层级为M的服务节点的发布后，令M＝M-1。

6.一种多服务应用的管理与发布装置，其特征在于，包括：

接收模块，用于接收多服务应用创建请求；

创建模块，用于根据所述多服务应用创建请求，依次创建组成多服务应用的服务；在依次创建组成多服务应用的服务的过程中，根据所述服务的依赖属性，设定所述服务之间的树形依赖关系；

发布模块，用于在发布多服务应用时，将所述树形依赖关系转换为线性发布顺序，并根据所述线性发布顺序，完成多服务应用的发布。

7.根据权利要求6所述的装置，其特征在于，所述创建模块，具体用于：

创建无依赖的服务；

创建有依赖的服务；并且，在所述有依赖的服务的服务定义过程中，在所述有依赖的服务的依赖服务属性里选择要依赖的服务；所述依赖服务属性包括已经开通的公共服务和所述多服务应用下已经创建的服务；

组成所述多服务应用的服务均已创建完成后，根据服务之间的依赖关系生成所述多服务应用的树形拓扑图。

8.根据权利要求7所述的装置，其特征在于，所述创建模块，还具体用于：

对于本身无依赖的服务，创建为无依赖的服务；

对于有依赖但所依赖的服务当前不存在的服务，先创建为无依赖的服务，待其所依赖的服务被创建后，再更改所述服务的依赖服务属性，使其成为有依赖的服务。

9.根据权利要求7所述的装置，其特征在于，所述发布模块，具体用于：

遍历所述树形拓扑图，标记每个服务节点的层级；

按所述服务节点的层级，完成多服务应用的发布。

10.根据权利要求9所述的装置，其特征在于，所述发布模块，还具体用于：

找到所有服务节点的最高层级，设为M；

如果M＝0，则对应的服务节点表示为根服务节点，发布完成所述根服务结点后返回；否则循环执行下面步骤：

依次发布层级为M的服务节点；

完成层级为M的服务节点的发布后，令M＝M-1。