基于springcloud的微服务构建方法及springcloud微服务架构与流程

本申请涉及微服务架构技术领域，具体而言，涉及一种基于springcloud的微服务构建方法，springcloud微服务架构，服务器及存储介质。

背景技术：

随着信息时代的蓬勃发展，系统复杂度越来越高，处理的数据量也越来越大。单体架构在规模比较小的情况下工作情况良好，但是随着系统规模的扩大，它暴露出来的问题也越来越多。规模扩大对系统的水平扩展能力提出了极高的要求，微服务应用应运而生。而所谓微服务，就是以较小的功能集作为独立的服务进行部署，模块间调用通过服务调用完成。当前比较流行的微服务架构就有springcloud，其中关键的服务间调用方法是通过feign组件完成。

从单体应用到微服务应用，最核心的一个问题是服务划分的粒度需要到什么程度，多小算是微服务。而对于中小型公司，既想利用微服务的优势，又担心服务划分带来的运维维护成本。服务划分粒度不够，没有达到微服务带来的水平扩展能力；服务划分太细，有些多余的划分，又会增加维护和运营成本。

技术实现要素：

本申请实施例的目的在于提供一种基于springcloud的微服务构建方法，springcloud微服务架构，服务器及存储介质，以改善目前微服务无法合理划分问题。

第一方面，本申请实施例提供一种基于springcloud的微服务构建方法，应用于服务器；所述方法包括：接收多个微服务的合并信息；将入参转换成http请求信息；所述入参表示合并的所述微服务之间调用的参数；将feign组件的路由配置和所调用的controller的层路由配置关联；基于所述http请求信息，构造springmvc参数，路由到所调用的controller层方法，进而完成调用。

在本申请中，将微服务进行合并，通过将入参转换成http请求信息，再将feign组件的路由配置和所调用的controller层路由配置关联，最后基于http请求信息，构造springmvc参数，路由到所调用的controller层方法，进而完成了合并后的微服务之间的调用。实现了在springcloud微服务架构下对已经划分好的微服务进行合并。进而解决了现有技术中的服务划分问题，可以根据实际业务发展，计算量的变化合理的规划微服务，改变微服务的组成。

结合上述第一方面提供的技术方案，在一些可能的实现方式中，通过以下步骤对多个所述微服务进行合并：确定一个所述微服务作为主服务，将需要合并的其他所述微服务的依赖关系添加到所述主服务，并声明多个所述微服务的合并信息。

在本申请中，通过确定一个微服务作为主服务，将需要合并的其他微服务的依赖关系添加到主服务，并声明多个微服务的合并信息，进而实现了微服务之间的合并。

结合上述第一方面提供的技术方案，在一些可能的实现方式中，通过以下步骤对合并的多个所述微服务进行拆分：将与所述主服务存在依赖关系的所述微服务删除，并声明所述微服务的拆分信息。

在本申请中，通过将与主服务存在依赖关系的微服务删除，并声明微服务的拆分信息。进而实现了合并后的微服务的拆分。解决了现有技术中，微服务架构中的微服务划分问题。

结合上述第一方面提供的技术方案，在一些可能的实现方式中，未合并的微服务调用合并的多个所述微服务中的一个所述微服务通过所述主服务进行调用，调用过程包括：通过所述feign组件动态代理构造http请求；通过springmvc处理所述http请求，对所述http请求进行解析；路由到controller层方法，进而完成调用。

结合上述第一方面提供的技术方案，在一些可能的实现方式中，所述http请求包括url、requestpayload；所述通过springmvc处理所述http请求，包括：将所述requestpayload构造成方法参数；相应的，路由到controller层方法，包括：通过url路由到controller层方法。

结合上述第一方面提供的技术方案，在一些可能的实现方式中，所述方法还包括：将合并后的多个所述微服务进行注册。

在本申请中，通过对合并后多个的微服务进行注册，进而使得其他未合并的微服务能够对合并的多个微服务进行调用。

第二方面，本申请实施例提供一种springcloud微服务架构，包括配置中心，以及部署装置；所述配置中心用于接收多个微服务的合并信息；所述部署装置用于将入参转换成http请求信息；所述入参表示合并的所述微服务之间调用的参数；以及将feign组件的路由配置和所调用的controller层的路由配置关联；以及基于所述http请求信息，构造springmvc参数，路由到所调用的controller层方法，进而完成调用。

结合上述第二方面提供的技术方案，在一些可能的实现方式中，所述部署装置还用于确定一个所述微服务作为主服务，将需要合并的其他所述微服务的依赖关系添加到所述主服务，并声明多个所述微服务的合并信息。

第三方面，本申请实施例提供一种服务器，包括：处理器和存储器，所述处理器和所述存储器连接；所述存储器用于存储程序；所述处理器用于调用存储在所述存储器中的程序，执行如上述第一方面实施例和/或结合上述第一方面实施例的一些可能的实现方式提供的方法。

第四方面，本申请实施例提供一种存储介质，其上存储有计算机程序，所述计算机程序在被处理器运行时执行如上述第一方面实施例和/或结合上述第一方面实施例的一些可能的实现方式提供的方法。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请实施例提供的一种服务器的结构示意图。

图2为本申请实施例提供的一种基于springcloud的微服务构建方法的步骤流程图。

图3为本申请实施例提供的一种微服务之间的调用方式的示意图。

图4为本申请实施例提供的另一种微服务之间的调用方式的示意图。

图5为本申请实施例提供的另一种基于springcloud的微服务构建方法的步骤流程图。

图6为本申请实施例提供的springcloud微服务架构的结构示意图。

图标：100-服务器；110-处理器；120-存储器；200-springcloud微服务架构；210-配置中心；220-部署装置；230-注册中心。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。

目前，从单体应用到微服务应用，最核心的一个问题是服务划分的粒度需要到什么程度，多小算是微服务。而对于中小型公司，既想利用微服务的优势，又担心服务划分带来的运维维护成本。服务划分粒度不够，没有达到微服务带来的水平扩展能力；服务划分太细，有些多余的划分，又会增加维护和运营成本。

鉴于上述问题，本申请发明人经过研究探索，提出以下实施例以解决上述问题。

请参阅图1，本申请实施例提供一种应用基于springcloud的微服务构建方法的服务器100的示意性结构框图。在结构上，服务器100可以包括处理器110和存储器120。

处理器110与存储器120直接或间接地电性连接，以实现数据的传输或交互，例如，这些元件相互之间可通过一条或多条通讯总线或信号线实现电性连接。处理器110用于执行存储器120中存储的可执行模块，处理器110可以在接收到执行指令后，执行计算机程序。

其中，处理器110可以是一种集成电路芯片，具有信号处理能力。上述的处理器110可以是通用处理器，包括中央处理器(centralprocessingunit，cpu)、网络处理器(networkprocessor，np)等；处理器110也可以是通用处理器，例如，可以是数字信号处理器(digitalsignalprocessor，dsp)、专用集成电路(applicationspecificintegratedcircuit，asic)、分立门或晶体管逻辑器件、分立硬件组件，可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。此外，通用处理器可以是微处理器或者任何常规处理器等。

存储器120可以是，但不限于，随机存取存储器(randomaccessmemory，ram)、只读存储器(readonlymemory，rom)、可编程只读存储器(programmableread-onlymemory，prom)、可擦可编程序只读存储器(erasableprogrammableread-onlymemory，eprom)，以及电可擦编程只读存储器(electricerasableprogrammableread-onlymemory，eeprom)。存储器120用于存储程序，处理器110在接收到执行指令后，执行该程序。

应当理解，图1所示的结构仅为示意，本申请实施例提供的服务器100还可以具有比图1更少或更多的组件，或是具有与图1所示不同的配置。此外，图1所示的各组件可以通过软件、硬件或其组合实现。

请参阅图2，图2为本申请实施例提供的基于springcloud的微服务构建方法的流程示意图，该方法应用于图1所示的服务器100。需要说明的是，本申请实施例提供的基于springcloud的微服务构建方法不以图2及以下所示的顺序为限制。该方法包括：步骤s101-步骤s104。

步骤s101：接收多个微服务的合并信息。

步骤s102：将入参转换成http请求信息。

步骤s103：将feign组件的路由配置和所调用的controller层路由配置关联。

步骤s104：基于http请求信息，构造springmvc参数，路由到所调用的controller层方法，进而完成调用。

下面，结合具体的示意对上述步骤s101-步骤s104进行详细的说明。

步骤s101：接收多个微服务的合并信息。

由于本申请是基于springcloud的微服务构建方法，因此在springcloud中包括配置中心，当将多个微服务进行合并时，配置中心接收到多个微服务的合并信息。比如微服务包括商品管理服务、用户管理服务以及订单管理服务，则在将商品管理服务、用户管理服务合并后，配置中心接收到商品管理服务以及用户管理服务的合并信息。

可选地，通过以下的步骤对多个微服务进行合并：确定一个微服务作为主服务，将需要合并的其他微服务的依赖关系添加到主服务，并声明多个微服务的合并信息。

其中，确定一个微服务作为主服务可以是任意的，也可以是根据用户需求将对应的微服务作为主服务，比如微服务包括微服务a、微服务b以及微服务c，当将微服务a与微服务b进行合并时，可以将微服务a作为主服务，也可以将微服务b作为主服务，本申请不作限定。若将微服务a作为主服务，则将微服务b的依赖关系添加到微服务a中，并在配置中心中进行声明，声明微服务a与微服务b的合并信息，合并信息中还包括将微服务a作为主服务。当未合并的微服务c在调用微服务b的时候，会改变路由，将原先的路由到微服务b更改至微服务a。

步骤s102：将入参转换成http请求信息。

需要说明的是，步骤s102-步骤s104介绍的是当微服务进行合并后，如何实现合并后的多个微服务之间的调用。

其中，入参表示合并的微服务之间调用的参数。比如入参可以是微服务a在调用微服务b时发送的调用参数。对入参进行处理，转换成http(hypertexttransferprotocol，超文本传输协议)请求数据的内存模式。http请求中通常包括三部分，即url(uniformresourcelocator，统一资源定位符)、method以及requestpayload。本步骤中将入参转换成上述的http请求数据的内存模式。

步骤s103：将feign组件的路由配置和所调用的controller层的路由配置关联。

需要说明的是，feign组件是一个依赖组件。controller层作为控制层，主要处理外部请求。于本申请中，是基于springcloud微服务架构下，通过feign组件实现的微服务之间的调用。将feign组件的路由配置和所调用的controller层路由配置关联，可以理解为当服务a发布了一个接口post：/order/detail/{id}，则与服务a合并的服务b若需调用这个该接口post，则需在feign组件上声明/order/detail/{id}。因此，将feign组件的路由与接口服务a发布的接口post的路由配置进行匹配关联。也即，将feign组件的路由与所调用的controller层路由配置进行匹配关联。

步骤s104：基于http请求信息，构造springmvc参数，路由到所调用的controller层方法，进而完成调用。

其中，springmvc是一种web层mvc框架，用于处理响应请求。于本申请实施例中，构造springmvc参数，将http请求信息中的requestpayload构造成方法参数。通过http请求中的url路由到对应的controller层方法，进而完成调用。

综上所述，在本申请实施例中，将微服务进行合并，通过将入参转换成http请求信息，再将feign组件的路由配置和所调用的controller层路由配置关联，最后基于http请求信息，构造springmvc参数，路由到所调用的controller层方法，进而完成了合并后的微服务之间的调用。实现了在springcloud微服务架构下对已经划分好的微服务进行合并。进而解决了现有技术中的服务划分问题，可以根据实际业务发展，计算量的变化合理的规划微服务，改变微服务的组成。

可选地，本申请实施例还提供基于springcloud的微服务构建方法还包括将合并的多个微服务进行拆分。具体的，通过以下的步骤对多个微服务进行拆分：将与主服务存在依赖关系的微服务删除，并声明微服务的拆分信息。

可以理解的是，对于微服务的拆分，只需将与主服务存在依赖关系的微服务删除，同时去除对应的配置即可，然后再将拆分出的微服务独立部署。也即配置中心获取到多个微服务的拆分信息。

比如，微服务a、微服务b、微服务c三个微服务是合并的，微服务a为主服务，若将微服务b与微服务a进行拆分，仅需将微服务b与微服务a的依赖关系删除，并声明微服务b与微服务a已拆分。通过配置中心对拆分出的微服务b独立部署，即可完成拆分。微服务c的拆分方式同理，为了避免累赘，在此不作重复阐述。

需要说明的是，未合并的微服务调用合并的多个微服务中的其中一个微服务通过主服务进行调用。比如微服务包括微服务a、微服务b、微服务c以及微服务d。其中，微服务a、微服务b、微服务c三个微服务是合并的，微服务a为主服务，若微服务d需要调用微服务b，则需路由到微服务a，通过微服务a进行调用。

而合并的多个微服务中的其中一个微服务调用未合并的微服务则可直接调用。比如微服务包括微服务e、微服务f、微服务h以及微服务g。其中，微服务e、微服务f、微服务h三个微服务是合并的，微服务f为主服务，若微服务e需要调用微服务g，则直接通过http调用。

未合并的微服务调用合并的多个微服务中的其中一个微服务，以及合并的多个微服务中的其中一个微服务调用未合并的微服务，具体的调用过程包括：通过feign组件动态代理构造http请求。然后通过springmvc处理所述http请求，对所述http请求进行解析；路由到controller层方法，进而完成调用。

具体的，可参考图3所示。feign动态代理构造http请求，然后发送web请求至对应的所调用的微服务，然后springmvc处理http请求，对http请求进行解析，路由到controller层方法，完成调用。其中，springmvc处理http请求，对http请求进行解析，路由到controller层方法，包括将requestpayload构造成方法参数，通过url路由到controller层方法。

需要说明的是，处于不同进程中的微服务之间的调用是通过http的web请求实现的，也即上述示例中的微服务e与微服务g处于不同进程、微服务f与微服务g处于不同进程、微服务h与微服务g处于不同进程。微服务e、微服务f、微服务h三者与微服务g之间的调用是通过http的web请求实现的。

请参阅图4，图4为合并后的微服务之间的调用方式的示意图。于本申实施例中，合并后的微服务之间的调用方式可以理解为通过将入参转换http请求信息，将feign组件的路由配置和所调用的controller层的路由配置关联，构建springmvc参数，路由到所调用的controller层方法，进而绕过了http的web请求，从而直接完成了进程内的方法调用。也即直接通过feign组件路由到controller层方法。

可选地，在将多个微服务进行合并后，该方法还包括：将合并后的多个微服务进行注册。

其中，springcloud中还包括注册中心。因此，在合并多个微服务后，将多个微服务在注册中心进行注册。注册的服务列表可以从配置中心中获得。

在本申请实施例中，通过对合并后多个的微服务进行注册，进而使得其他未合并的微服务能够对合并的多个微服务进行调用。

请参阅图5，下面对完整的基于springcloud的微服务构建方法进行说明。步骤包括：步骤s201-步骤s204。

步骤s201：根据预设规则，划分微服务。

步骤s202：通过feign组件声明微服务之间的调用。

步骤s203：接收多个微服务的合并信息，调整合并后的多个微服务之间的调用方式。

步骤s204：将合并后的多个所述微服务进行注册，以使其他微服务对合并的多个微服务进行调用。

需要说明的是，步骤s201中，根据预设规则，划分微服务可以是根据业务功能，划分微服务；也可以是根据模块运算量，划分微服务。本申请不作限定。

需要说明的是，在步骤s201中划分的微服务处于不同的进程中，因此，步骤s202中，通过feign组件声明微服务之间的调用表示微服务之间的调用是通过http的web请求实现的。

需要说明的是，上述步骤s203的过程即为上述实施中步骤s101-步骤s104的过程，因此，步骤s203的具体内容可以参考步骤s101-步骤s104。为了避免累赘，在此不作重复阐述。

可选地，在上述步骤s204之后，该方法还包括：对合并的多个微服务进行拆分。

由于在上述实施例中，对于微服务的拆分已阐述，因此，为了避免累赘，在此不作重复阐述。相同部分互相参考即可。

基于同一发明构思，请参阅图6，本申请实施例提供一种springcloud微服务架构200，包括配置中心210以及部署装置220。

其中，配置中心210，用于存放各类配置供微服务使用。于本申实施例中，配置中心210还用于接收多个微服务的合并信息。

其中，部署装置220，用于将入参转换成http请求信息；所述入参表示合并的所述微服务之间调用的参数；以及将所述feign组件的路由配置和所调用的controller层的路由配置关联；以及基于所述http请求信息，构造springmvc参数，路由到所调用的controller层方法，进而完成调用。

可选地，部署装置220还用于确定一个所述微服务作为主服务，将需要合并的其他所述微服务的依赖关系添加到所述主服务，并声明多个所述微服务的合并信息。

可选地，部署装置220还用于将与所述主服务存在依赖关系的所述微服务删除，并声明所述微服务的拆分信息。

可选地，部署装置220还用于通过feign组件动态代理构造http请求。

通过springmvc处理所述http请求，对所述http请求进行解析；路由到controller层方法，进而完成调用。

可选地，部署装置220还用于将所述requestpayload构造成方法参数以及通过url路由到controller层方法。

可选地，部署装置220将合并后的多个所述微服务发送至注册中心进行注册。

其中，部署装置220为spring组件，在使用时，将其引入springboot项目中即可。

可选地，springcloud微服务架构还包括注册中心230。注册中心230具备服务注册、服务发现及服务检查等功能。于本申请实施例中，注册中心230用于注册合并的多个微服务。

可选地，springcloud微服务架构还包括网关、负载均衡，消息总线。由于该结构为本领域技术人员所熟知，为了避免累赘，此处不再阐述。

基于同一发明构思，本申请实施例还提供一种存储介质，其上存储有计算机程序，计算机程序在被运行时执行上述实施例中提供的方法。

该存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，dvd)、或者半导体介质(例如固态硬盘solidstatedisk(ssd))等。

在本申请所提供的实施例中，应该理解到，所揭露装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

另外，作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

再者，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。

以上所述仅为本申请的实施例而已，并不用于限制本申请的保护范围，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。