CN114138259A - 适配多云平台的多微服务分布式框架的构建系统及方法 - Google Patents

Abstract

本发明公开了适配多云平台的多微服务分布式框架的构建系统，包括统一注解定义模块、多云平台多微服务框架注册引擎、多云平台多微服务框架打包引擎；其中：统一注解定义模块，提供统一抽象的注解标记以替换微服务框架运作配置自定义协议注解；多云平台多微服务框架注册引擎，用于识别出对应的中间件，同时自动根据该中间件约定的协议进行服务发现和注册；多云平台多微服务框架打包引擎，根据打包命令加上指定微服务框架的参数，构建出单个或多个微服务框架的可运行的业务系统部署包。采用本发明所述构建系统，企业可根据系统建设的需求，根据不同云平台采用所需的更合适的微服务框架以灵活应对。

Description

适配多云平台的多微服务分布式框架的构建系统及方法

技术领域

本发明涉及企业IT系统服务构建领域，特别涉及适配多云平台的多微服务分布式框架的构建系统及方法。

背景技术

近年来,中台理念的兴起，使得微服务应用作为可复用层的重要性大大提升。为了灵活应对不同企业的需求，现有技术有些采用公有云，有些使用私有云，有些偏向商业套件，有些则喜欢开源方式。

针对上述情况，具体而言，一般的解决方案有两种：

方案1：采用一套业务系统代码版本对应一种云平台微服务分布式框架来应对项目诉求。

方案2：采用一套业务系统代码版本包罗多种云平台的多种微服务分布式框架，并通过开关机制进行切换来应对项目诉求。

而针对这两种处理方案，均有其缺陷之处：

方案1：业务系统代码的研发和维护成本非常高，业务开发程序员需要熟练掌握多种微服务框架使用，并根据不同协议开发出不同版本代码。

方案2：业务系统代码的开发者需要熟练掌握多种协议使用之外，还需要把多种微服务框架所需要注解和XML配置代码写入业务系统代码当中，从而带来代码侵入和代码包冲突，业务代码会变得臃肿，维护难度大。方案2采用通过开关机制进行切换的方案，虽然开发成本和维护成本相比方案1有所减低，但是它带来了代码臃肿和增加设计难度的问题。

同时方案1、2在已有业务代码中无法面对新的云平台的新的微服务框架切换挑战。

发明内容

本发明的目的在于克服现有技术的缺点与不足，提供适配多云平台的多微服务分布式框架的构建系统，采用该系统，企业可根据系统建设的需求，根据不同云平台采用所需的更合适的微服务框架以灵活应对。

本发明的另一目的在于提供适配多云平台的多微服务分布式框架的构建方法。

本发明的目的通过以下的技术方案实现：

适配多云平台的多微服务分布式框架的构建系统，包括统一注解定义模块、多云平台多微服务框架注册引擎、多云平台多微服务框架打包引擎；其中：

统一注解定义模块，提供统一抽象的注解标记以替换微服务框架运作配置自定义协议注解，用于解除不同微服务分布式框架代码对业务系统代码的入侵，降低业务代码和微服务分布式框架的耦合度；

多云平台多微服务框架注册引擎，在业务系统运行时,收集根据统一抽象的注解标记所标记的业务系统对外提供或依赖的服务接口清单,并根据业务系统运行时所在环境识别出对应的中间件，自动根据该中间件约定的协议进行服务发现和注册，从而实现不同云平台的自适应的服务发现和注册；若同一个环境中同时使用了多个不同的中间件，多云平台多微服务框架注册引擎也会自动向所有中间件注册，从而实现多微服务框架混合环境的服务互通；所述中间件为服务发现和注册中间件；

多云平台多微服务框架打包引擎，根据打包命令加上用指定微服务框架的参数，构建出单个或多个微服务框架的可运行的业务系统部署包。

所述统一抽象的注解标记为@XMetaApi。统一采用元数据角度进行API抽象描述，而单词本身就是元数据前缀。

所述微服务框架运作配置自定义协议注解包括@FeignClient、@RestController、@HSFConsumer、@HSFProvider等。

本发明的另一目的通过以下的技术方案实现：

适配多云平台的多微服务分布式框架的构建方法，包括以下步骤：

A.开发阶段：在业务系统代码工程引入统一注解API包的声明；在提供业务服务接口类上加下统一抽象的注解标记，所述统一抽象的注解标记包括@XMetaApi注解；

B.打包阶段：多云平台多微服务打包引擎根据打包命令指定参数，构建出云平台单微服务框架和多微服务框架的可运行的业务系统部署包；

C.运行阶段：扫描统一抽象的注解标记所标记的业务服务接口，生成清单，根据微服务运行时所在环境识别出对应的中间件，自动根据中间件约定的协议调用一个或多个具体的微服务框架的服务注册接口动态生成客户端和服务端代理类，实现一个或多个服务注册和发现，以及服务调用的完整过程，从而实现同一环境中使用一个或多个不同中间件的服务互通；所述中间件为服务发现和注册中间件。

本发明与现有技术相比，具有如下优点和有益效果：

1、本发明的微服务框架注册引擎在提供了基于RESTful风格和基于API等多种服务展现方式的同时，并不增加开发和系统的复杂性。

例如当旧的业务系统使用基于API服务调用(例如：Duboo)，后续由于RESTful风格兴起，网络透传等更加友好，企业在新建设的业务系统都会考虑使用基于RESTful风格，那么为了打通与旧应用通讯，这时新建设的业务系统必须存在RESTful风格和基于API调用服务同时并存一段很长时间。那么新建设的业务系统通过微服务框架注册引擎增强之后，天然的同时具备RESTful协议调用和API协议调用的能力。

2、本发明为了隔离底层分布式调研框架对上层应用的影响，需要满足一套业务代码适配多种微服务框架，比如阿里云的EDAS及其在此基础上的微服务调用框架HSF/SpringCloud/Duboo等,以及直接使用Spring Cloud或Duboo而不使用云服务厂商所提供的微服务治理能力等。

业务开发者只是根据本发明提供注解声明和API规范进行业务开发，业务代码中不会涉及底层微服务框架代码依赖，从而不会受到底层分布式框架的更换带来业务代码修改。

3、本发明的业务系统代码的开发者只需要按照开发规范，在API接口类加上@XMetaApi即可使用多种微服务框架的适配，大大减少业务系统的开发复杂度。

4、本发明采用一个注解和一套业务代码，可以让企业可根据自己的需要，根据不同云平台采用所需的更合适的微服务框架以灵活应对。

5、未来有新的云平台的新的微服务框架，本发明只需要新增具体微服务协议处理模块即可实现。

当有新生的微服务框架流行时，企业业务应用需要适应新生的微服务框架运行，在不修改业务代码基础上，通过新增基于微服务框架统一注册接口的实现注册处理模块，原有业务应用通过更新新模块即可实现基于新生的微服务框架之后即可运行起来。

附图说明

图1为本发明所述适配多云平台的多微服务分布式框架的构建系统的结构示意图。

图2为本发明所述适配多云平台的多微服务分布式框架的构建方法的流程图。

图3为本发明所述多云平台多微服务注册引擎的工作流程图。

具体实施方式

下面结合实施例及附图对本发明作进一步详细的描述，但本发明的实施方式不限于此。

如图1，适配多云平台的多微服务分布式框架的构建系统，包括统一注解定义模块、多云平台多微服务注册引擎、多云平台多微服务打包引擎；其中：

统一注解定义模块，提供统一抽象的注解标记以替换微服务框架运作配置自定义协议注解，用于解除不同微服务分布式框架代码对业务系统代码的入侵，降低业务代码和微服务分布式框架的耦合度；

如图3，多云平台多微服务框架注册引擎，在业务系统运行时,收集根据统一抽象的注解标记所标记的业务系统对外提供或依赖的服务接口清单,并根据业务系统运行时所在环境识别出对应的中间件，自动根据该中间件约定的协议进行服务发现和注册，从而实现不同云平台的自适应的服务发现和注册；若同一个环境中同时使用了多个不同的中间件，多云平台多微服务注册引擎也会自动向所有中间件注册，从而实现多微服务框架混合环境的服务互通；所述中间件为服务发现和注册中间件；

如图3所示，已有的应用和已有的中心是企业在过去一段时间采用阿里云的HSF私有协议进行微服务应用建设，它们只是注册和发现在Diamond。新建设的应用和新建设的中心是后面企业采用RESTful协议在自建的云平台或其他新兴的云平台之上建设，而它们只是注册和发现在开源Nacos。但是新建设的应用和中心需要跟已有的应用和中心存在部分业务功能互通，可是在没有多云平台多微服务注册引擎增强条件下，新的应用和中心是无法跟已有的应用和中心进行互通调用，然而新的应用和中心则使用多云平台多微服务注册引擎进行增强，增强了之后的新的应用和中心在除了能够在Nacos注册，同时也注册到到Diamond上，这时，已有的应用和中心就能与新的应用和中心互相发现和进行服务调用，解决服务互通的能力了。

所述多云平台多微服务框架注册引擎，在同一环境内，对新建设的业务系统进行增强后，新建设的业务系统可以同时向多个服务发现注册中间件进行注册，既可以使用旧的微服务框架协议从而提供了与旧业务系统的互通能力，又可以使用新的微服务框架协议进行自身内部的交互，从而确保业务系统既能兼容已有系统，又可采用新兴技术。

所述多云平台多微服务框架注册引擎，在同一环境内，对新建设的业务系统进行增强，是指：多云平台多微服务框架注册引擎基于同一个注解的API，会生成两种协议注册代理类,使用HSF协议向Diamond注册，同时使用RESTful协议向Nacos注册。

多云平台多微服务框架打包引擎，根据打包命令加上用指定微服务框架的参数，构建出单个或多个微服务框架的可运行的业务系统部署包。

所述统一抽象的注解标记为@XMetaApi。统一采用元数据角度进行API抽象描述，而单词本身就是元数据前缀。

所述微服务协议运作配置自定义协议注解包括@FeignClient、@RestController、@HSFConsumer、@HSFProvider等。

图1中，所述代码包扫描分析模块，用于根据配置规则扫描带有@XMetaApi的API接口类，接着按照API和实现服务类的匹配规则，分析出哪些需要进行客户端注册，哪些服务端需要进行服务注册。

如图2，适配多云平台的多微服务分布式框架的构建方法，包括以下步骤：

A.开发阶段：在业务系统代码工程引入统一注解API包的声明；在提供业务服务接口类上加下统一抽象的注解标记，所述统一抽象的注解标记包括@XMetaApi注解；

B.打包阶段：多云平台多微服务打包引擎根据打包命令指定参数，构建出云平台单微服务框架和多微服务框架的可运行的业务系统部署包；

C.运行阶段：扫描统一抽象的注解标记所标记的业务服务接口，生成业务系统对外提供或依赖的服务接口清单，根据微服务运行时所在环境识别出对应的中间件，自动根据中间件约定的协议调用一个或多个具体的微服务框架的服务注册接口动态生成客户端和服务端代理类，实现一个或多个服务注册和发现，以及服务调用的完整过程，从而实现同一环境中使用一个或多个不同中间件的服务互通；所述中间件为服务发现和注册中间件。

上述实施例为本发明较佳的实施方式，但本发明的实施方式并不受上述实施例的限制，其他的任何未背离本发明的精神实质与原理下所作的改变、修饰、替代、组合、简化，均应为等效的置换方式，都包含在本发明的保护范围之内。

Claims (6)

1.适配多云平台的多微服务分布式框架的构建系统，其特征在于：包括统一注解定义模块、多云平台多微服务框架注册引擎、多云平台多微服务框架打包引擎；其中：

统一注解定义模块，提供统一抽象的注解标记以替换微服务框架运作配置自定义协议注解，用于解除不同微服务分布式框架对业务系统代码的个性的入侵，降低业务代码和微服务分布式框架的耦合度；

多云平台多微服务框架注册引擎，在业务系统运行时,收集根据统一抽象的注解标记所标记的业务系统对外提供或依赖的服务接口清单,并根据业务系统运行时所在环境识别出对应的中间件，自动根据该中间件约定的协议进行服务发现和注册，从而实现不同云平台的自适应的服务发现和注册；若同一个环境中同时使用了多个不同的中间件，多云平台多微服务注册引擎也会自动向所有中间件注册，从而实现多微服务框架混合环境的服务互通；所述中间件为服务发现和注册中间件；

多云平台多微服务框架打包引擎，根据打包命令加上用指定微服务框架的参数，构建出单个或多个微服务框架的适应云平台运行的业务系统部署包。

2.根据权利要求1所述适配多云平台的多微服务分布式框架的构建系统，其特征在于：所述统一抽象的注解标记为@XMetaApi。

3.根据权利要求1所述适配多云平台的多微服务分布式框架的构建系统，其特征在于：所述微服务框架运作配置自定义协议注解包括@FeignClient、@RestController、@HSFConsumer、@HSFProvider。

4.根据权利要求1所述适配多云平台的多微服务分布式框架的构建系统，其特征在于：所述多云平台多微服务框架注册引擎，在同一环境内，对新建设的业务系统进行增强后，新建设的业务系统可以同时向多个服务发现注册中间件进行注册，既可以使用旧的微服务框架协议从而提供了与旧业务系统的互通能力，又可以使用新的微服务框架协议进行自身内部的交互，从而确保业务系统既能兼容已有系统，又可采用新兴技术。

5.根据权利要求4所述适配多云平台的多微服务分布式框架的构建系统，其特征在于：所述多云平台多微服务框架注册引擎，在同一环境内，对新建设的业务系统进行增强，是指：多云平台多微服务框架注册引擎基于同一个注解的API，会生成两种协议注册代理类,使用HSF协议向Diamond注册，同时使用RESTful协议向Nacos注册。

6.适配多云平台的多微服务分布式框架的构建方法，其特征在于，包括以下步骤：

A.开发阶段：在业务系统代码工程引入统一注解API包的声明；在提供业务服务接口类上加下统一抽象的注解标记，所述统一抽象的注解标记包括@XMetaApi注解；

B.打包阶段：多云平台多微服务打包引擎根据打包命令指定参数，构建出云平台单微服务框架和多微服务框架的可运行的部署包；

C.运行阶段：扫描统一抽象的注解标记所标记的业务服务接口，生成清单，根据微服务运行时所在环境识别出对应的中间件，自动根据中间件约定的协议调用一个或多个具体的微服务框架的服务注册接口动态生成客户端和服务端代理类，实现一个或多个服务注册和发现，以及服务调用的完整过程，从而实现同一环境中使用一个或多个不同中间件的服务互通；所述中间件为服务发现和注册中间件。

Images