一种微服务环境中的服务开发和运行方法及其模型与流程

本发明涉及计算机软件领域，尤其涉及一种微服务环境中的服务开发和运行方法及其模型。

背景技术

传统服务设计和开发模式中，服务中包含存储资源、(离线)计算逻辑、依赖的服务资源以及服务的业务逻辑和接口实现；各个模块是紧耦合的，存储、计算或服务资源的调整或迁移都需要做出硬编码调整。这种紧耦合的设计是引发上述问题的根源，由改模式构建的服务很难重现部署，很难实现多动态运行多实例，难以维护和迁移。

传统服务开发和部署的过程通常都是紧耦合的，服务开发者通过各种方式定义本服务使用的存储资源及本服务依赖的服务资源，部署过程需要了解开发者对存储资源和服务资源的定义和组织结构，部署过程困难，同时和比较难实现服务的多次快速部署(由于服务部署过程的复杂性)，很难实现真正意义上的一次部署多次使用，服务的部署和维护过程对实施和维护人员要求也非常高，不利于服务运营。

由于服务和存储资源和服务资源的紧耦合，服务的一次开发多次运行是需要多次相对复杂的部署过程的，并不能实现真正意义上的服务一次开发和多次运行。本发明将帮助服务部署程序实现服务的快速部署，实现服务模板到多个服务实例的实现过程。

由于服务开发过程的开放性，服务部署过程也会相对复杂；服务部署人员通常是由相对专业的准服务开发人员负责的，大量服务的使用、部署和运行维护过程对人员的要求很高。

对于服务的存储资源依赖的问题，aws和阿里云等云服务商给出了部分解决方案，但是通常都需要大量的人工操作，操作人员对云基础设施(文件系统、数据库等)有相当程度的了解，且并不能很好的解决服务存储资源依赖的问题，现有的服务依然需要通过传统的方式解决。

此外，现有服务基础设施，如dubbo、springcloud等，都给出了服务依赖的解决方法，但都存在较大的问题。且至今没有同时解决上述问题的方案提出。

技术实现要素：

为了解决服务开发和服务部署过程紧耦合的问题，帮助服务的依次开发多次运行，并降低服务部署和运行维护的难度，本发明提供了一种微服务环境中的服务开发和运行方法及其模型。

本发明采用的技术方案是：一种微服务环境中的服务开发和运行方法，包括：

步骤1、开发模型：将服务拆解为若干个独立的业务逻辑单元、存储资源单元和服务资源单元；

步骤2、服务编排：根据步骤1中的拆分逻辑，将业务逻辑单元、存储资源单元和服务资源单元按服务的类型进行分类；将同类服务的业务逻辑、存储资源和服务资源组装在一起，形成服务运行模型；

步骤3、服务部署：根据步骤2中的运行模型，将相关的业务逻辑、存储资源和服务资源组装后形成服务实例，并进行服务运行。

进一步地，所述业务逻辑单元为代码逻辑，剥离服务中存储和服务依赖及配置硬编码的部分。

进一步地，所述存储资源单元为服务运行中需要使用的存储资源，包括关系型数据库、文件存储资源和键值对存储资源。

进一步地，所述服务资源单元为待开发服务运行时依赖的应用程序。

一种微服务环境中的服务模型，包括相互独立的以下结构：存储资源单元、计算逻辑单元、服务资源单元和业务逻辑单元；

所述业务逻辑单元为实现的逻辑代码的部分；

所述存储资源单元为服务运行中需要使用的存储资源，包括关系型数据库、文件存储资源和键值对存储资源；

所述计算逻辑单元为业务逻辑所需要并行计算单元，表现为算法库或某种算法服务；

所述服务资源单元为待开发服务运行时依赖的应用程序；

所述服务模型还包括深度调度层，用于连接存储资源单元、计算逻辑单元、服务资源单元和业务逻辑单元，并将储资源单元、服务资源单元和业务逻辑单元组合为服务实例。

进一步地，所述计算逻辑单元可重复使用，在服务运行环境中独立。

本发明通过分离业务逻辑、数据资源、计算资源和服务资源的依赖设计模式优点主要体现在：

1.实现了服务开发和服务部署和维护的解耦；

2.降低了运维成本；

3.降低了多服务实例的部署难度。

附图说明

图1为本发明的运行方法的流程图。

图2本发明服务开发模型的结构图。

图3为资源调度层将各个模块连接运行形成为服务实例图。

具体实施方式

下面结合附图和具体实施方式对本发明作进一步详细的说明。

【实施例1】如图1，微服务环境中的服务开发和运行方法，包括：

步骤1、服务设计和开发过程，将服务拆解为业务逻辑、存储资源和服务资源若干个独立的单元；业务逻辑即为代码逻辑(剥离了存储和服务依赖、剥离了配置硬编码的部分)；存储资源即为服务运行中需要使用的存储资源，包括关系型数据库、文件存储或键值对存储等；服务资源为该服务运行时依赖的服务；

步骤2、根据步骤1中的拆分逻辑，按服务类型对业务逻辑单元、存储资源单元和服务资源单元进行分类；将同类服务的业务逻辑、存储资源和服务资源组合在一起，形成服务运行模型；计算资源单元在整个服务运行环境中可被复用；

步骤3、根据步骤2中的运行模型，将相关的业务逻辑、存储资源和服务资源组合后形成为可以运行的服务实例。

【实施例2】如图2，微服务环境中的服务开发模型，相互独立的以下结构,：

业务逻辑单元：服务实现的逻辑代码的部分，形式可以为各种运用的编译后的形式，例如java的jar包、war包；python程序的代码文件夹和二进制依赖环境等；业务逻辑实现的主要改造在于这里的业务逻辑要避免存在直接读取或配置存储资源、计算逻辑和服务资源的模块；业务逻辑必须被标识为某种具体的类型。

存储资源单元：存储资源是业务逻辑的数据，形式为数据库、文件存储或其他形式的持久化存储；存储资源需要被标识为某种具体的类型。

计算逻辑单元：计算逻辑是业务逻辑所需要并行计算单元，计算逻辑的表现形式可以是某种算法库或某种算法服务；计算逻辑需要被标识为某种具体的类型。

服务资源单元：待开发服务运行时依赖的应用程序；

深度调度层，用于连接存储资源单元、计算逻辑单元、服务资源单元和业务逻辑单元，并将储资源单元、服务资源单元和业务逻辑单元组合为服务实例。

将每个服务按单元类型拆分，其中，业务逻辑提供的接口被规定为service1.v1，存储资源类型规定为datastore1.v1，计算资源类型被规定为algorithm1.v1，服务依赖类型被规定为service2.v2，注意这里只有业务逻辑是实体，其他依赖的都为类型定义。根据上述模式，服务被展开成为服务实例、业务逻辑和对应类型的存储资源。

随后，资源调度层将各个模块连接运行形成为服务实例，如图3所示。

在该服务模型中，计算逻辑单元在整个服务运行环境中可被重复使用，是一个独立的实例；业务逻辑1通过与数据存储类型1和服务资源1连接形成服务类型1；业务逻辑的2通过与数据存储类型2和服务类型2连接形成服务类型2。

可见，该模型通过分离业务逻辑、数据资源、计算资源和服务资源的依赖设计模式，实现了服务开发和服务部署和维护的解耦，降低了运维成本，降低了多服务实例的部署难度。

上述实施方式并非是对本发明的限制，本发明也并不仅限于上述举例，本技术领域的技术人员在本发明的技术方案范围内所做出的变化、改型、添加或替换，也均属于本发明的保护范围。