CN111522633A - 服务部署方法和迁移方法 - Google Patents

Abstract

本发明提供了一种服务部署方法和迁移方法。该部署方法包括：将服务拆分为独立的多个服务模块；对所述多个服务模块进行分类并组装生成多个服务运行模型；实现所述多个服务模块的实例，并根据所述服务运行模型组合生成服务实例；其中，通过命名空间标识所述服务模块。本发明通过将服务拆分为通过命名空间描述的服务模块，解耦了服务中的各个模块，实现了服务的可插拔和可移植，实现业务的快速配置以及在不同运行环境中的快速迁移，降低了服务部署和运行维护的难度。

Description

服务部署方法和迁移方法

技术领域

本申请涉及软件服务技术领域，特别地涉及一种服务部署方法和迁移方法。

背景技术

传统软件服务开发和部署的过程通常都是紧耦合的，服务开发者通过各种方式定义本服务使用的存储资源及本服务依赖的服务资源，服务各个模块会混杂在一起，部署过程需要了解开发者对存储资源和服务资源的定义和组织结构，为每个服务定义其依赖并部署服务。因此，存储、计算或服务资源的调整或迁移都需要做出硬编码调整，服务的部署和维护过程较为复杂和困难，无法实现快速、自动的服务部署，也无法迅速的迁移现有的应用服务。

发明内容

本发明旨在至少解决现有技术或相关技术中存在的技术问题之一。

为了解决上述问题，本发明提供了一种服务模型部署方法和迁移方法，实现服务的快速部署和迁移，降低服务部署和运行维护的难度

根据本发明的第一方面，提供了一种服务部署方法，包括：

将服务拆分为独立的多个服务模块；

对所述多个服务模块进行分类并组装生成多个服务运行模型；

实现所述多个服务模块的实例，并根据所述服务运行模型组合生成服务实例；

其中，通过命名空间标识所述服务模块。

其中，所述服务模块包括业务逻辑模块、存储资源模块和服务依赖模块。

其中，所述对所述多个服务模块进行分类并组装生成多个服务运行模型包括：

根据业务逻辑模块、存储资源模块、服务依赖模块的类型进行分类；

按照服务拆分的逻辑将所述业务逻辑模块、存储资源模块和服务依赖模块组合在一起，生成多个服务运行模型。

其中，所述实现所述多个服务模块的实例，并根据所述服务运行模型组合生成服务实例包括：

实现业务逻辑的实例、存储资源的实例和服务依赖的实例；

根据所述多个服务运行模型中模块的组合方式，将所述实例组合在一起生成多个服务实例；

根据所述多个服务运行模型之间的关系，组合所述多个服务实例。

其中，组合所述多个服务实例包括服务实例的复用和不同服务实例的插接。

其中，基于所述命名空间识别服务模块的能力以实现多个服务模块的组合。

根据本发明的第二方面，提供了一种服务迁移方法，包括：

确定第一运行环境中需要迁移的多个服务实例，所述服务实例是根据第一方面所述的方法生成的；

根据所述多个服务实例之间的依赖关系，找出支撑该服务实例的各个服务模块的实例；

将所述各个服务模块的实例迁移至第二运行环境，按照所述依赖关系重新组合生成服务实例。

本发明通过将服务拆分为通过命名空间描述的服务模块，解耦了服务中的各个模块，实现了服务的可插拔和可移植；通过标准化的能力描述方式，实现了各个服务模块之间的插接；通过服务模块之间的依赖关系构建了服务运行模型，可实现业务的快速构建和快速重配置，以及在不同运行环境中的快速迁移，降低了服务部署和运行维护的难度。

本发明的附加方面和优点将在下面的描述部分中给出，部分将从下面的描述中变得明显，或通过本发明的实践了解到。

附图说明

本发明的上述和/或附加的方面和优点从结合下面附图对实施例的描述中将变得明显和容易理解，其中：

图1为根据本发明的服务部署方法的流程图；

图2为根据本发明一个实施例的服务模块的示意图；

图3为根据本发明一个实施例的服务运行模型的示意图；

图4为根据本发明的服务迁移方法的流程图；

图5为根据本发明一个实施例的服务实例迁移过程的示意图。

具体实施方式

为了能够更清楚地理解本发明的上述目的、特征和优点，下面结合附图和具体实施方式对本发明进行进一步的详细描述。需要说明的是，在不冲突的情况下，本申请的实施例及实施例中的特征可以相互组合。

在下面的描述中阐述了很多具体细节以便于充分理解本发明，但是，本发明还可以采用其他不同于在此描述的其他方式来实施，因此，本发明的保护范围并不受下面公开的具体实施例的限制。

针对传统服务开发和部署的过程通常都是紧耦合的，导致服务部署过程复杂和难以在不同运行环境之间迁移的现状，本发明提出了一种可插入(Pluginable)、可迁移的(Portable)业务(Program)、数据(Data)和服务依赖(Service)运行模型(P3DS)，具体应用于服务部署和迁移的方法中。

参照图1，其示出了根据本发明的一种服务部署方法，包括：

S11、将服务拆分为独立的多个服务模块。

服务模块是指可以依赖其它服务模块实现一组功能，并对外提供服务能力的单元。如图2中示出的服务模块A需要依赖其它的服务模块B提供的服务能力1和服务模块C提供的服务能力2，对外提供服务能力3。

可选地，所述服务模块包括业务逻辑模块、存储资源模块和服务依赖模块。所述业务逻辑为服务的代码逻辑；所述存储资源为服务运行中需要使用的存储资源；服务依赖模块为业务逻辑模块所依赖的业务逻辑。

其中，通过命名空间描述所述服务模块的能力，优选地，所述命名空间包括多个区段。例如图2中的服务模块A需要命名空间为Data.postgres.OSM.v1的服务能力，服务模块B的命名空间为Data.postgres.OSM.v1，则基于命名空间的匹配，可以将服务模块A和B组装在一起，实现服务模块之间的可插拔性。

S12、对所述多个服务模块进行分类并组装生成多个服务运行模型。

可选地，包括：

根据业务逻辑模块、存储资源模块、服务依赖模块的类型进行分类；

按照服务拆分的逻辑将所述业务逻辑模块、存储资源模块和服务依赖模块组合在一起，生成多个服务运行模型

其中，根据命名空间可以区分服务模块的具体类型。

参照图3，其示出了服务运行模型的示例，其中业务逻辑模块，存储模块和服务依赖模块组合在一起。

S13、实现所述多个服务模块的实例，并根据所述服务运行模型组合生成服务实例。

可选地，包括：

实现业务逻辑的实例、存储资源的实例和服务依赖的实例；

根据所述多个服务运行模型中模块的组合方式，将所述实例组合在一起生成多个服务实例；

根据所述多个服务运行模型之间的关系，组合所述多个服务实例。

其中，组合所述多个服务实例包括服务实例的复用和不同服务实例的插接。将根据相同模式的服务运行模型生成的服务实例组合在一起可以构成复用的服务实例，将根据具有依赖关系的服务运行模型生成的服务实例组合则可实现业务逻辑的搭建，如图3所示，其中第一个服务实例包括业务逻辑模块的实例Inc.Service.NameSpace1，其依赖另一个业务逻辑模块的实例Inc.Service.NameSpace2,第二个服务实例包括一个业务逻辑模块的实例Inc.Service.NameSpace2和一个存储资源模块Inc.Data.Namespace2。

由此，通过将服务拆分为通过命名空间描述的服务模块，解耦了服务中的各个模块，实现了服务的可插拔和可移植；通过标准化的能力描述方式，实现了各个服务模块之间的插接；通过服务模块之间的依赖关系构建了服务运行模型，可实现业务的快速配置，降低了服务部署的难度。

命名空间可以由多层结构组成，可选地，包括四个区段，格式表达为aaa.bbb.ccc.ddd。本文仅以业务逻辑(Service)和存储资源(Data)两种类型为示例提出命名空间描述，其他类型可以用类似方法建立命名空间。

命名空间的第一区段包括业务逻辑(Service)、存储资源(Data)两种类型；

对于不同类型的服务模块，第二区段的命名约束不同。对于业务逻辑(Service)，第二区段的命名约束如下：

对于平台自身使用的服务使用字符Core，例如用户服务和元数据服务，该类型服务的前缀是Service.Core；

对于平台外部服务且运行在承载平台之上的服务使用字符Base，例如影像服务和目标服务，该类型服务的前缀是Service.Base；

对于平台外部服务不运行在承载平台之上的使用字符External，例如某个早期开发的运行在xp上的服务，该类型服务的前缀是Service.External；

对于开发阶段或者未定义接口类型的服务，使用字段temp,例如开发阶段的某服务可以被定义为Service.Temp。

对于存储资源(Data)，第二区段的命名约束如下：

对于平台内部数据源使用数据类型使用数据存储类型缩写，例如Dfs、Postgresql、Dameng等，该数据类型的前缀是Service.Dfs|Postgresql|Dameng；

对于平台内部数据源使用数据类型使用External.数据存储类型缩写，例如External.Oracle等，该数据类型的前缀是Service.External.Oracle；

对于开发阶段或者未定义接口类型的存储资源，使用字段temp,例如开发阶段的某服务可以被定义为Data.Temp。

第三区段为服务接口类型、数据单元类型和应用类型的唯一标识，例如ImageManager、PlaceNameOSM、VideoPlayer。

第四区段的定义为版本标识，方式为v[整数]，数量从1开始逐级上升。对于业务逻辑，不同的版本代表不同的接口类型，接口定义中的API数量的增减、传入参数的变化、返回值的修改、返回异常的修改都会引起版本变化；对于存储资源，不同的版本代表不同的数据类型，例如数据库结构的变化、hbase schema的变化、文件夹内初始目录结构的变化、消息存储的变化等都会引起版本变化。

相同的命名空间代表其提供的类型一致性，对于业务逻辑：相同的命名空间代表了相同的接口类型，对服务而言其提供的协议类型、api接口形式、请求参数、返回值都是符合相同模式的。对于数据存储：相同的命名空间代表了其提供相同的数据结构。

在完成服务部署后，当需要时，可以将服务快速地迁移至另一运行环境。参照图4，其示出了根据本发明的一种服务迁移方法，包括：

S41、确定第一运行环境中需要迁移的服务实例。

其中，所述服务实例是根据参照图1所述的方法生成的。

S42、根据所述多个服务实例之间的依赖关系，找出支撑该服务实例的各个服务模块的实例；

S43、将所述各个服务模块的实例迁移至第二运行环境，按照所述依赖关系重新组合生成服务实例。

参照图5，其示出了根据本发明的方法将图3所示的服务实例迁移的方法。在该待迁移的服务实例中，业务逻辑模块的实例Inc.Service.NameSpace1依赖另一个业务逻辑模块的实例Inc.Service.NameSpace2,后者包括一个业务逻辑模块的实例和一个存储资源模块的实例Inc.Data.Namespace2。根据该依赖关系，递归的遍历依赖树，即可找出支撑整个业务模块所需要的子模块的实例，包括业务逻辑模块的实例Inc.Service.NameSpace1、存储资源模块的实例Inc.Data.Namespace1、业务逻辑模块的实例Inc.Service.NameSpace2和存储资源模块的实例Inc.Data.Namespace2，将上述服务模块的实例从运行环境1搬移到另一个运行环境2，并按照依赖关系组合为可运行的服务实例，即可完成迁移。

由此，基于通过服务模块之间的依赖关系构建的服务运行模型，可实现业务的快速重配置，从而能够在不同运行环境中的快速迁移，降低了服务部署和运行维护的难度。

本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于一计算机可读存储介质中。

可以理解的是，虽然本发明已以较佳实施例披露如上，然而上述实施例并非用以限定本发明。对于任何熟悉本领域的技术人员而言，在不脱离本发明技术方案范围情况下，都可利用上述揭示的技术内容对本发明技术方案做出许多可能的变动和修饰，或修改为等同变化的等效实施例。因此，凡是未脱离本发明技术方案的内容，依据本发明的技术实质对以上实施例所做的任何简单修改、等同变化及修饰，均仍属于本发明技术方案保护的范围内。

Claims (7)

1.一种服务部署方法，其特征在于，包括：

将服务拆分为独立的多个服务模块；

对所述多个服务模块进行分类并组装生成多个服务运行模型；

实现所述多个服务模块的实例，并根据所述服务运行模型组合生成服务实例；

其中，通过命名空间标识所述服务模块。

2.根据权利要求1所述的方法，其特征在于，所述服务模块包括业务逻辑模块、存储资源模块和服务依赖模块。

3.根据权利要求2所述的方法，其特征在于，所述对所述多个服务模块进行分类并组装生成多个服务运行模型包括：

根据业务逻辑模块、存储资源模块、服务依赖模块的类型进行分类；

按照服务拆分的逻辑将所述业务逻辑模块、存储资源模块和服务依赖模块组合在一起，生成多个服务运行模型。

4.根据权利要求3所述的方法，其特征在于，所述实现所述多个服务模块的实例，并根据所述服务运行模型组合生成服务实例包括：

实现业务逻辑的实例、存储资源的实例和服务依赖的实例；

根据所述多个服务运行模型中模块的组合方式，将所述实例组合在一起生成多个服务实例；

根据所述多个服务运行模型之间的关系，组合所述多个服务实例。

5.根据权利要求4所述的方法，其中组合所述多个服务实例包括服务实例的复用和不同服务实例的插接。

6.根据权利要求1-5中任一所述的方法，其特征在于，基于所述命名空间识别服务模块的能力以实现多个服务模块的组合。

7.一种服务迁移方法，其特征在于，包括：

确定第一运行环境中需要迁移的多个服务实例，所述服务实例是根据权利要求1-6中任一所述的方法生成的；

根据所述多个服务实例之间的依赖关系，找出支撑该服务实例的各个服务模块的实例；

将所述各个服务模块的实例迁移至第二运行环境，按照所述依赖关系重新组合生成服务实例。

Images