一种兼容多种开发架构的系统架构改造方法及系统架构

摘要

本发明提供一种兼容多种开发架构的系统架构改造方法，用于对目标业务系统进行改造，该改造方法包括：将所述目标业务系统拆分为多个微服务，每个所述微服务包括相应的功能模块和web模块，所述web模块用于启动对应的所述微服务；构建主依赖模块，所述主依赖模块包含所述目标业务系统中的公用工具类和公用接口；构建API模块，所述API模块负责依赖所述主依赖模块并定义所述多个微服务之间的接口；构建单体启动模块，所述单体启动模块依赖各个所述微服务中的功能模块。经过本发明改造后的系统架构既能支持微服务方式开发及部署，又能支持传统单体开发及部署。

说明书

技术领域

本发明涉及计算机开发领域，尤其涉及一种兼容多种开发架构的系统架构改造方法及系统架构。

背景技术

目前，一些单体架构的业务系统庞大并存在比较复杂的业务逻辑。例如，电子招标采购系统发展至今，已经不再单纯是一个面向企业内部使用的管理系统，其涉及到供应商、采购方、代理机构、专家等多方企业及用户协同开展工作，从而才能完成整个招标采购全流程业务。对于一些大中型集团性企业来说，由于其业务体量较大，系统还涉及到一些系统高并发的场景，比如开标及评标业务环节，一旦项目比较集中在某个时间段同时开评标，将对系统造成较大的性能压力，此时单体架构的各种问题必将暴露无遗。

随着互联网技术的发展，此类系统架构暴露出的问题已经有了不错的解决方案，那便是近两年来非常火热的微服务架构。如今电子采购系统正逐步向互联网采购平台进行转变，同时业务逻辑也逐渐变得愈来愈复杂，还需要与周边各类系统打通。因此对庞大成熟的采购业务系统进行微服务架构的改造成为了必然的趋势。

然而，一套业务系统通常是面向广泛的企业使用的，企业规模不同，对产品架构的技术要求及性能要求也会有所不同，同时拘泥于自身信息化程度及配套IT技术运维团队等各方面因素，所以并不是每个企业对微服务架构系统要求迫切；其次对于系统开发人员来说，在本地进行功能开发时，往往要启动若干个服务，才能调试自己写的程序，而一般情况下，本地机器的资源有限，在启动若干个服务后，很容易造成内存不足，机器出现卡顿状况，从而影响系统的开发效率，因此，亟待提供即能支持微服务方式开发及部署，又能支持传统单体开发及部署的系统架构。

发明内容

针对上述现有技术的不足，本发明的目的在于提供一种兼容多种开发架构的系统架构改造方法及系统架构，以使改造后的系统架构既能支持微服务方式开发及部署，又能支持传统单体开发及部署。

为了实现上述目的，本发明提供一种兼容多种开发架构的系统架构改造方法，用于对目标业务系统进行改造，该改造方法包括：

将所述目标业务系统拆分为多个微服务，每个所述微服务包括相应的功能模块和web模块，所述web模块用于启动对应的所述微服务；

构建主依赖模块，所述主依赖模块包含所述目标业务系统中的公用工具类和公用接口；

构建API模块，所述API模块负责依赖所述主依赖模块并定义所述多个微服务之间的接口；

构建单体启动模块，所述单体启动模块依赖各个所述微服务中的功能模块。

在本发明一个优选实施例中，所述主依赖模块还包含多个模块的版本号、若干过滤器和/或拦截器。

在本发明一个优选实施例中，所述API模块包含JAVA本地接口模块以及至少一种微服务架构的微服务接口模块，所述微服务接口模块均继承至所述JAVA本地接口模块。

在本发明一个优选实施例中，所述至少一种微服务架构包括SpringCloud、Dubbo和/或HSF架构。

在本发明一个优选实施例中，当所述API模块包含SpringCloud架构的微服务接口模块时，所述改造方法还包括：增加适用于SpringCloud架构的服务注册中心、服务配置中心、服务网关及监控模块。

在本发明一个优选实施例中，当所述API模块包含Dubbo架构的微服务接口模块时，所述改造方法还包括：增加适用于Dubbo架构的服务代理层、注册中心层、路由层、监控层、远程调用层、信息交换层、网络传输层和数据序列化层。

在本发明一个优选实施例中，当所述API模块包含HSF架构的微服务接口模块时，所述改造方法还包括：增加适用于HSF架构的地址注册中心、持久化配置中心、元数据存储中心和控制台。

为了实现上述目的，本发明还提供一种兼容多种开发架构的系统架构，包括：

多个微服务，每个所述微服务包括相应的功能模块和web模块，所述web模块用于启动对应的微服务；

主依赖模块，所述主依赖模块包含所述目标业务系统中的公用工具类和公用接口；

API模块，所述API模块负责依赖所述主依赖模块并定义所述多个微服务之间的接口；

单体启动模块，所述单体启动模块依赖各个所述微服务中的功能模块。

在本发明一个优选实施例中，所述API模块包含JAVA本地接口模块以及至少一种微服务架构的微服务接口模块，所述微服务接口模块均继承至所述JAVA本地接口模块。

通过采用上述技术方案，本发明具有如下有益效果：

本发明将目标业务系统拆分为多个微服务，并构建了所述主依赖模块、API模块和单体启动模块；当需要微服务部署时，可以通过每个服务的web模块启动对应的所述微服务，启动完成后，就组成了一个分布式的微服务系统；当需要单体部署时，只需启动单体启动模块一个服务即可，由于单体启动模块可以直接调用各个微服务中的功能模块，因而所有功能都可正常运行。从而，可灵活应对不同架构需求，能够在简单修改原代码的前提下，完成不同模式开发及部署方式的工作。此外，本发明还可以兼容多种微服务架构，真正做到同一套代码，能正常运行于不同微服务治理平台下。

附图说明

图1为本发明一种兼容多种开发架构的系统架构改造方法的一个实施例的原理图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

在本发明使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本公开。在本公开和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

实施例一

本实施例提供一种兼容多种开发架构的系统架构改造方法，用于对目标业务系统(如电子采购系统)进行改造，如图1所示，该改造方法包括以下步骤：

S1，将所述目标业务系统拆分为多个微服务，每个所述微服务包括相应的功能模块和web模块，所述功能模块用于实现相应的业务，所述web模块用于启动对应的所述微服务。在本实施例中，微服务的拆分主要遵循单一职责原则、服务颗粒度适中原则、以业务模型切入原则以及演进式原则。按照上述原则，可以将目标业务系统拆分为多个微服务，并且对微服务进行了分组，微服务内按照小的业务功能点又划分出不同的小模块，模块内部的结构按照传统的开发工程结构进行设计。

遵循以上原则的目的主要是为了让系统整体架构在未来的演进过程中变得灵活多变，各模块或服务能够做到可拆可合，并可按需部署。

当多个微服务需要合并时，只需要创建一个新的微服务，将其他微服务所依赖的模块导入即可。而当一个微服务内的模块需要再进行拆分时，只需要对某几个微服务的内模块抽取出来，并创建一个新的web模块将其引入即可，然后适当的修改原有微服务之间的接口调用。

在图1所示的实施例中，ebs-demo1-service和ebs-demo2-service为拆分得到的两个微服务。在ebs-demo1-service微服务中包含对应的功能模块demo1-module1、web模块demo1-web、公用模块demo1-common，在ebs-demo2-service微服务中包含对应的功能模块demo2-module1、web模块demo2-web、公用模块demo2-common，其中，功能模块demo1-module1、demo2-module1分别用于实现相应微服务的业务功能，demo1-web、demo2-web分别用于启动相应的微服务，公用模块demo1-common、demo2-common分别包含相应微服务中各模块的公用工具类。

S2，构建主依赖模块，所述主依赖模块包含所述目标业务系统中的公用工具类和公用接口，还可以包含系统内各模块(包含第三方模块)的版本号以及一些过滤器和/或拦截器等。在图1所示的实施例中，ebs-common为主依赖模块，位于系统架构的最顶层。

S3，构建API模块，所述API模块负责依赖所述主依赖模块并定义所述多个微服务之间的接口。此处，所述API模块包含JAVA本地接口模块以及至少一种微服务架构的微服务接口模块(即远程调用接口)，所有微服务接口模块均继承至所述JAVA本地接口模块。在图1所示的实施例中，ebs-api为API模块，其负责依赖ebs-common，并定义各微服务间的接口，其中，图中的api-demo1、api-demo1-feign、api-demo1-dubbo模块为微服务ebs-demo1-service的接口。在本申请中，依赖是指如果A模块功能的实现需要调用B模块的接口，则A模块依赖B模块。

S4，构建单体启动模块，所述单体启动模块依赖各个所述微服务中的功能模块。在图1所示的实施例中，ebs-service为单体启动模块，其依赖ebs-demo1-service和ebs-demo2-service中的功能模块demo1-module1、demo2-module1，即，其可以直接调用demo1-module1、demo2-module1。

当需要单体启动时，例如本地需要开发调试时，只需要启动单体启动模块ebs-service，即可直接调用所有微服务的功能模块，所有功能可以正常运行。这里借用了Java接口调用这种实现思路，在所有模块都在同一个容器中，在API模块中定义的远程调用接口会优先取到本地接口进行调用，也就是说，这种情况下接口之间的通信方式将变成进程内的调用，而不会跨网络走远程过程调用。

当需要微服务启动时，通过各微服务的web模块即可启动所有的微服务，组成一个分布式系统。

可见，通过上述改造方法得到的系统架构既能支持微服务方式开发及部署，又能支持传统单体开发及部署。

需要说明的是，对于本实施例，为了简单描述，故将其表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。

在完成以上单体、分布式同时支持的改造后，本发明又继续对系统架构做了进一步完善，考虑将目前主流的微服务架构都做适配。目前互联网行业主流的微服务架构主要有3大派系，分别是SpringCloud系、Dubbo系及商业化的HSF系。

为了适配多种不同的微服务架构，本申请在API模块中配置了这些微服务架构对应的微服务接口模块。例如，在图1所示的实施例中，api-demo1为JAVA本地接口模块，其保留原始单体目标业务系统的接口定义；api-demo1-feign、api-demo1-dubbo分别为SpringCloud、Dubbo架构下微服务ebs-demo1-service对应的微服务接口模块，当然还可以根据需要增加HSF架构对应的微服务接口模块api-demo--hsf。

通过这样的设计，可以很轻松地切换到不同的微服务架构下进行运行，只需要在maven的pom文件中切换不同api类型依赖就能适配到另外的微服务调用方式(切换时，加载需要模式api对应的代码，将其它模式api对应的代码通过注释进行屏蔽)。以上适配过程中所涉及的方法，也是基于使用不同分布式架构总结出来的经验而涉及，其核心就是能够通过简单的配置，改变服务调用的通信方式及通信协议，而数据的输入及输出应该保持统一不变。

当所述API模块包含SpringCloud架构的微服务接口模块时，所述改造方法还包括：增加适用于SpringCloud架构的服务注册中心、服务配置中心、服务网关及监控模块。当所述API模块包含Dubbo架构的微服务接口模块时，所述改造方法还包括：增加适用于Dubbo架构的服务代理层、注册中心层、路由层、监控层、远程调用层、信息交换层、网络传输层和数据序列化层等。当所述API模块包含HSF架构的微服务接口模块时，所述改造方法还包括：增加适用于HSF架构的地址注册中心、持久化配置中心、元数据存储中心和控制台。增加的这些模块为SpringCloud、Dubbo、HSF架构中的常规模块，在此不再赘述。

本发明结合目前已经投入生产的电子采购系统应用成熟且业务逻辑复杂的现状，考虑到不同的业主和代理在业务流程和管理制度上的多样性，给出了多种产品技术架构及部署架构的解决方案，能够在简单的修改一些配置文件的前提下，完成不同模式开发及部署方式的工作。本方案主要基于满足单体部署、微服务部署方案设计理念，同时考虑兼容主流的Spring Cloud、Dubbo、HSF微服务架构，真正做到同一套代码，能正常运行于不同微服务治理平台下。

此外，对于服务生产者而言，我们在各服务的模块中，编写相关的实现代码，所有实现类都需要实现所在服务的微服务接口模块中的相应接口。对于SpringCloud模式下时，需要注意定义好FeignClient接口的实现；对于Dubbo模式模式下时，需要配置相关的xml配置文件；而对于HSF模式下时，需要定义好相应的HSFConfig配置类，并在其中配置好服务消费者接口信息。

对于服务消费者而言，需要依赖服务生产者对应的微服务接口模块，即可调用不同模式下的api接口。

另外，在不同模式下，需要扫描的包路径及文件也有所差异，可以编写几个核心的自动配置类，用于实现不同场景下需要扫描和加载的类信息。

除了以上描述的模块设计、配置及结构的改变，还会涉及到很多细节方面的代码需要做调整，涉及到的调整主要包括以下三个方面：

第一方面，在原始目标业务系统中，会在每个模块的api-xxx模块中定义自己的api接口。本发明为了更好地兼容不同微服务架构部署方式下的接口调用方式，将api-xxx模块拆分出了api-xxx、api-xxx-feign、api-xxx-dubbo、api-xxx-hsf四个不同的模块，其中，api-xxx保留原来api-xxx模块中的接口，api-xxx-feign、api-xxx-dubbo、api-xxx-hsf分别定义Spring Cloud、Dubbo、HSF微服务架构下对应微服务的微服务接口。接口实现的命名由原来的xxxService最后变成xxxFeignService，对应的便是Spring Cloud架构；Dubbo对应的便是XXXDubbo接口文件；HSF对应的便是xxxHsfConfig接口文件。

这些在不同架构模式下，所定义的接口都继承至顶级接口api-xxx，然后在对应的api模块中增加一些个性化的接口定义。

第二方面，回调接口如果是跨服务间的调用，也需要做一定的修改。比如审批流的回调，在我们将审批流拆分为一个单独的微服务后，当有多个业务服务需要进行审批操作时均调用审批流实现，每次在审批通过或驳回时，可能都需要通知相应的业务服务修改某些业务数据的状态信息。而回调接口自然通常会涉及到一个接口多个实现问题，例如有多个业务微服务都调用审批流。故在此处，需要对此类回调接口定义及实现加上别名，用于区分回调时真正需要执行的实例对应的方法逻辑。这样设计的精妙之处在于对原有审批流的老代码改动极少，又能同时兼容不同的架构模式下的回调方式。

第三方面，关于静态资源的访问，对于原始单体架构的目标业务系统，静态资源通过maven相关插件将其打包到一个目录下进行部署。在本发明中，对于Spring Cloud架构模式时，将所有的静态资源都放置在服务网关中，由服务网关直接处理静态资源的访问。那么对于Dubbo及HSF架构模式时，由于没有了网关服务做路由，则将静态资源直接打包到Nginx目录下，然后直接将Nginx作为路由服务。

实施例二

本实施例提供一种兼容多种开发架构的系统架构，包括：

多个微服务，每个所述微服务包括相应的功能模块和web模块，所述web模块用于启动对应的微服务；

主依赖模块，所述主依赖模块包含所述目标业务系统中的公用工具类和公用接口；

API模块，所述API模块负责依赖所述主依赖模块并定义所述多个微服务之间的接口；

单体启动模块，所述单体启动模块依赖各个所述微服务中的功能模块。

在本实施例中，所述API模块包含JAVA本地接口模块以及至少一种微服务架构的微服务接口模块，所述至少一种微服务架构的微服务接口模块均继承至所述JAVA本地接口模块。

当需要单体启动时，例如本地需要开发调试时，只需要启动单体启动模块ebs-service，即可直接调用所有微服务的功能模块，所有功能可以正常运行。这里借用了Java接口调用这种实现思路，在所有模块都在同一个容器中,在API模块中定义的远程调用接口会优先取到本地接口进行调用，也就是说，这种情况下接口之间的通信方式将变成进程内的调用，而不会跨网络走远程过程调用。

当需要微服务启动时，通过各微服务的web模块即可启动所有的微服务，组成一个微服务系统。

可见，通过上述改造方法得到的系统架构既能支持微服务方式开发及部署，又能支持传统单体开发及部署。

在完成以上单体、分布式同时支持的改造后，本发明又继续对系统架构做了进一步完善，考虑将目前主流的微服务架构都做适配。目前互联网行业主流的微服务架构主要有3大派系，分别是SpringCloud系、Dubbo系及商业化的HSF系。

为了适配多种不同的微服务架构，本申请在API模块中配置了这些微服务架构对应的微服务接口模块。此外，当所述API模块包含SpringCloud架构的微服务接口模块时，本申请的系统架构还包括适用于SpringCloud架构的服务注册中心、服务配置中心、服务网关及监控模块。当所述API模块包含Dubbo架构的微服务接口模块时，本申请的系统架构还包括适用于Dubbo架构的服务代理层、注册中心层、路由层、监控层、远程调用层、信息交换层、网络传输层和数据序列化层。当所述API模块包含HSF架构的微服务接口模块时，本申请的系统架构还包括适用于HSF架构的地址注册中心、持久化配置中心、元数据存储中心和控制台。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。

以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。