基于微服务的后端拆分策略的制作方法

本发明属于微服务拆分技术领域，特别是涉及一种基于微服务的后端拆分策略。

背景技术：

随着互联网的快速发展，微服务拆分早已成为业界流行的实施方案。微服务拆分可以满足需求的快速迭代，实现敏捷快发，满足快速变化的市场需求，迅速占领市场。微服务拆分主要实现的是各个服务之间的解耦，降低彼此之间的耦合性，在相互不影响的情况下能够实现各个团队的敏捷开发。

微服务拆分后成为单独的一个服务系统，基于该微服务的所有需求的迭代都在此微服务上进行，此微服务没有在进一步拆分分层，所有的更新或者重构都是基于一个工程，在这个工程中完成api接口的调用和对数据库相应的执行操作，从而完成整个后端服务的调用过程。

现有微服务成为一个独立的系统之后，随着代码的不断迭代，一个独立的微服务系统最后有可能变成一个庞大臃肿的复杂系统，给后期系统的维护带来庞大的工作量，如果想要对系统进行升级，也有可能造成一个小的改动而影响整个微服务系统，造成系统的不可用。如果后期对微服务系统进行重构，也会带来庞大的工作量。

因此，我们采用的微服务后端拆分分层方案是将一个微服务后端进行再次分层，一共分为上下两层。上层可以称为微服务的portal层，主要负责api接口中数据的传输和返回；下层可以称为微服务的core层，主要负责业务的逻辑处理与数据库的交互；这样一个微服务就可以分为相互解耦的上下两层，实现微服务的再次轻量化，同时可以避免api接口的直接调用对数据库的访问，实现更高的安全性。后期对微服务进行维护或者升级亦或重构都可以实现更轻量化的操作，更利于系统的维护、升级。

技术实现要素：

本发明的目的在于提供基于微服务的后端拆分策略，微服务后端拆分为portal层和core层，core层提供基本、全面的业务逻辑处理接口，一个接口可以被portal层的多个接口调用，进行不同的数据封装，达到一对多的效果，避免了在一个微服务中相似接口存在大量冗余代码的情况，使整个代码结构更清晰。

为解决上述技术问题，本发明是通过以下技术方案实现的：

本发明为基于微服务的后端拆分策略，所述微服务拆分为包括portal层和core层的上下两侧；

所述portal层对外提供接口，用于接收接口调用的入参、返回处理数据以及简单业务逻辑处理；所述portal层所有接口都调用core层接口；所述portal层用于对core层的基本接口进行不同的封装；

所述core层为基础层，负责主要业务逻辑处理；所述core层为portal层的下层，提供portal层接口对下层接口调用的支撑，负责与数据库的交互。

优选地，所述core层接口与portal层接口是一对一或者一对多的关系，即所述core层的基本接口对应portal层的单独接口或core层的基本接口对应portal层的若干接口。

优选地，所述core层还为portal层提供基本数据接口，所述portal层根据需要对core层的基本数据接口进行封装。

优选地，所述core层接口用于组织或公司内部对内其他开发团队提供需要支持的接口，即内部api接口。

本发明具有以下有益效果：

1、本发明微服务后端拆分为portal层和core层，core层提供基本、全面的业务逻辑处理接口，一个接口可以被portal层的多个接口调用，进行不同的数据封装，达到一对多的效果，避免了在一个微服务中相似接口存在大量冗余代码的情况，使整个代码结构更清晰；

2、本发明微服务后端的拆分方案中core层接口可以暴露给组织或公司内部不同开发团队使用，core层接口有利于内部组织之间的相互调用；提供内部api功能，使得内部团队之间的交流更加方便，开发协作更加便利，有利于高效开发；

3、本发明微服务拆分为portal层和core层，使微服务在结构上变得更加轻薄，更加有利于系统的整体维护、升级和重构；core层作为基础层，接口可以提供丰富、全面的数据，portal层可以因需改变，封装为不同的接口，实现portal层动态改变。

当然，实施本发明的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例描述所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明的基于微服务的后端拆分策略的结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。

请参阅图1所示，本发明为基于微服务的后端拆分策略，微服务拆分为包括portal层和core层的上下两侧；

portal层提供对外api接口功能，所有对外调用该微服务的接口都在portal层实现，由portal层实现接口的统一接入；portal层用于接收接口调用的入参、返回处理数据以及简单业务逻辑处理；portal层所有接口都调用core层接口；portal层用于对core层的基本接口进行不同的封装；

具体的，portal层主要用来接受接口调用的入参和最终返回的处理数据以及一些简单的业务逻辑处理。而portal层所有接口都调用core层接口，core层作为一个基本层，这样portal层的代码厚度就会变薄；同时，因为portal层是提供对外api能力的，所以可以在core层提供一个基本接口的情况下，在portal层对core层的基本接口进行不同的封装，实现core层接口的高复用率。这样做的好处还可以降低外部对微服务的恶意攻击；当有外部服务想要恶意调用某个微服务的接口的时候，因为对外提供的portal层接口与数据库没有交互，在portal层与core层增加接口的拦截验证，就可以有效避免恶意攻击调用接口对数据库造成的压力以及对真正的业务造成的影响。

core层为基础层，负责主要业务逻辑处理；core层为portal层的下层，提供portal层接口对下层接口调用的支撑，负责与数据库的交互；core层接口与portal层接口是一对一或者一对多的关系，即core层的基本接口对应portal层的单独接口或core层的基本接口对应portal层的若干接口；core层还为portal层提供基本数据接口，portal层根据需要对core层的基本数据接口进行封装；core层接口用于组织或公司内部对内其他开发团队提供需要支持的接口，即内部api接口。

具体的，微服务中的core层作为基础层，是主要的业务逻辑处理层；同时作为portal层的下层，提供portal层接口对下层接口调用的支撑能力；负责与数据库的交互。core层接口与portal层接口是一对一或者一对多的关系；即core层某个接口可能只对应portal层的某个单独的接口，也有可能core层的一个接口对应portal层的多个接口。core层接口可以提供最为全面的数据，然后有portal层的接口根据需要对相同的数据进行不同的封装；这样portal层接口可以实现灵活可变，且core层接口只需提供最基本、全面的数据接口，实现core层接口的冗余，减少代码开发量，core层整体也可以由厚变薄。core层接口除了用于提供对portal层接口的支撑外，还可以更方便的用于组织或公司内部对内其他开发团队提供需要支持的接口，即内部api接口。不同的开发团队在相互调用彼此内部接口的时候，可以省去繁琐的内部相互调用接口的验证，使内部团队的开发效率更加高效、便捷。

实际使用中：微服务的整体分层结构，可以使portal层和core层结构都变得更加轻薄，且更利于管理。随着业务的不断改进，微服务可能需要不断的升级，在这种情况下一般只需要后期对portal层接口进行修改即可；而core层接口一般不会有太大的变动，可以减少后期随着服务升级带来的大量的工作量，且系统分层后更利于系统的维护，一旦生产环境出现问题，可以及时定位问题发生的原因。如果需要重构微服务，也可以有针对性的对portal层或core层进行重构，避免因对整个微服务进行重构而带来的工作量。

值得注意的是，上述系统实施例中，所包括的各个单元只是按照功能逻辑进行划分的，但并不局限于上述的划分，只要能够实现相应的功能即可；另外，各功能单元的具体名称也只是为了便于相互区分，并不用于限制本发明的保护范围。

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

以上公开的本发明优选实施例只是用于帮助阐述本发明。优选实施例并没有详尽叙述所有的细节，也不限制该发明仅为所述的具体实施方式。显然，根据本说明书的内容，可作很多的修改和变化。本说明书选取并具体描述这些实施例，是为了更好地解释本发明的原理和实际应用，从而使所属技术领域技术人员能很好地理解和利用本发明。本发明仅受权利要求书及其全部范围和等效物的限制。