一种基于融合微服务架构的系统的制作方法

本发明涉及微服务技术领域，特别涉及一种基于融合微服务架构的系统。

背景技术：

微服务架构是一种特定的软件应用程序设计方式—将大型软件拆分为多个独立可部署服务组合而成的套件方案。虽然这种架构风格的确切定义还存在争议，但并不妨碍其在众多企业的实际应用中被实践，并体现出了具备通用特征的业务功能、自动化部署、端点智能化以及对语言与数据的离散化控制能力。

另外，Docker 作为一种开源的应用容器引擎，帮助开发者将他们的应用以及依赖打包到一个可移植的容器中，便于应用的部署和扩展。而随之产生的微容器概念和微服务正好相辅相成，通过 Docker 封装的应用可以轻松运行在以扩容能力见长的云计算平台上。数人云作为专业的数据中心管理系统，提供了基于 Mesos 和 Docker 技术的企业级容器云生产环境，通过一键部署、横向扩展、持续集成等特性，助力微服务架构在企业应用环境的实践。

微服务架构近年来尤其受各大互联网公司的追捧，比如微信、七牛云、陆金所、敦煌网等知名企业都在运用其来架构自己的平台。这些互联网企业拥有庞大的用户数据、更专业规范的企业级的PaaS服务，他们通过整合了微服务到各个功能模块中实现快速处理海量数据、及时输出产品、优化产品体验、提升产品服务质量。在整个互联网技术发展的趋势下，快速融合微服务架构到产品的研发中能够使产品开发质量、进度得到进一步的保障。

传统的应用研发成本高，主要原因是：传统的垂直的架构、产品功能开发模式导致代码重复率过高；代码重复率过高导致功能需求变更困难（主要体现为功能修改不一致引起后续的测试、部署问题）；当代码重复率过高及需求变更困难导致产品无法赶上日益变化的市场需求，不能快速上线、敏捷交付产品。

同时，传统的架构设计导致运维效率低。产品业务不断新增使得整个系统的可维护性愈来愈差，产品各个功能模块关联孤立。当这种情况体现到整个企业管理中时，会使得所有的功能模块运维困难。

微服务架构（Microservices Architecture）的诞生和容器（Docker）技术的流行而是互联网时代倒逼传统技术和架构而产生的变革。以Docker为代表的容器技术为微服务架构解决了快速部署、优化资源利用率、高适配的问题。

技术实现要素：

本发明的目的在于提供一种基于融合微服务架构的系统，整合了微服务的构架使的每个产品功能的设计粒度化，以提高系统的可调度性，为新需求的快速准确开发提供了可靠性的保障。

为达到上述目的，本发明实施例公开了一种基于融合微服务架构的系统，技术方案如下：

一种基于融合微服务架构的系统，包括：应用模块、接口访问模块、业务服务模块、公共服务模块、资源管理模块；

所述应用模块发送数据请求；

所述接口访问模块用于接收并处理所述应用模块发送的数据请求，并根据所述数据请求确定执行所述数据请求的微服务单元，且发送有关所述微服务单元的信息；

所述业务服务模块用于接收所述接口访问模块发送的所述微服务单元信息，并根据所述微服务单元信息调用所述微服务；

所述公共服务模块用于根据预先设置的微服务与服务的对应关系查找对应的服务，所查找到的服务用于接收所述微服务的指令；

所述资源管理模块用于存放所述公共服务模块中服务的数据，用于将对应的数据根据所述服务的请求回传至所述公共服务模块，并经由所述微服务发送至所述业务服务模块，所述业务服务模块将所述数据通过所述接口访问模块发送至所述应用模块。

其中，所述应用模块为应用程序或web。所述接口访问模块为API网关；

所述微服务单元的信息，包括：所述微服务的调用接口信息。

所述公共服务模块根据预设类别划分为一个或多个服务组，每个服务组对应多个微服务。

所述微服务运行于Docker容器上。

所述公共服务模块，包括：支付子模块、消息通知子模块、即时通讯服务子模块、日志采集服务子模块、任务管理子模块。

所述资源管理模块，包括：数据库子模块、缓存子模块。

所述系统还包括：服务管理架构，与所述业务服务模块相连，用于对所述业务服务模块进行展示、管理和配置；

所述服务管理架构，包括：服务展示子模块、服务配置子模块、服务管理子模块。

应用本发明技术方案，通过应用模块发送数据后接口访问模块接受并处理该数据，并确定由哪个微服务单元来执行数据请求，业务服务模块启动接口访问模块确定的执行数据请求的微服务单元，然后公共服务模块中的服务用以执行，可以看的出本发明实施例整合了微服务的构架使的每个产品功能的设计粒度化，以提高系统的可调度性，为新需求的快速准确开发提供了可靠性的保障。

附图说明

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

图1为本发明实施例提供的基于融合微服务架构的系统的第一种结构图；

图2为本发明实施例提供的基于融合微服务架构的系统的第二种结构图；

图3为本发明实施例提供的基于融合微服务架构的系统的第三种结构图；

图4为本发明实施例提供的基于融合微服务架构的系统的第四种结构图；

图5为本发明实施例提供的基于融合微服务架构的系统的第五种结构图。

具体实施方式

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

为解决上述技术问题，本发明实施例提供了一种基于融合微服务架构的系统，以下分别进行详细说明。

图1为本发明实施例提供的基于微服务的管理系统的第一种结构图，系统包括：应用模块1、接口访问模块2、业务服务模块3、公共服务模块4、资源管理模块5；

应用模块1发送数据请求；接口访问模块2用于接收并处理应用模块1发送的数据请求，并根据数据请求确定执行数据请求的微服务单元，且发送有关微服务单元的信息；业务服务模块3用于接收接口访问模块2发送的微服务单元信息，并根据微服务单元信息调用微服务；公共服务模块4用于根据预先设置的微服务与服务的对应关系查找对应的服务，所查找到的服务用于接收微服务的指令；资源管理模块5用于存放公共服务模块4中服务的数据，用于将对应的数据根据服务的请求回传至公共服务模块4，并经由微服务发送至业务服务模块3，业务服务模块3将数据通过接口访问模块2发送至应用模块1。

本领域技术人员可以理解的是，应用模块为应用程序或web，示例性的，应用模块为应用程序，例如购物软件，购物软件运行于客户终端，用户在发送购买请求后进行支付，购物软件将支付请求发送至接口访问模块2。接口访问模块2是一个统计接收用户发送请求的管理接口，以根据请求的类型发送给相应的执行单元，如接收到购物请求以后确定由1号管理接口进行处理，1号管理接口根据数据请求确定执行数据请求的微服务单元，将确定的微服务的信息发送至业务服务模块3。

业务服务模块3中由很多的微服务，假设，根据微服务的接口信息确定调用的微服务为微服务A。公共服务模块4根据微服务A与服务的对应关系，查找到微服务A对应的为支付服务，那么由支付服务来执行本次的数据请求。在执行以后，支付服务再将支付的信息发送至业务服务模块3，业务服务模块3将数据通过接口访问模块2发送至应用模块1，用以告诉客户本次支付的执行结果，即完成了数据的双向过程。具体的，可以是微服务对应的接口信息，可以理解的是每个微服务都有对应的接口，在微服务被调用的时候接到有关接口的调用信息就会启动相应的微服务。具体的，资源管理模块5用于存放公共服务模块4中服务的数据，用于将对应的数据根据所述服务的请求回传至公共服务模块4，包括：数据库子模块、缓存子模块。

本发明主要是融合微服务构架的快速平台，其整合了当下主流的技术框架、适配第三方服务接口、独立设计研发了自主的分布式服务框架。

参见图2，图2为本发明实施例提供的基于微服务的管理系统的第二种结构图，接口访问模块为API网关；微服务单元的信息，包括：微服务的调用接口信息。

具体的，当接口访问模块为API网关时，API接收并处理应用模块1发送的数据请求，如图2所示，根据请求确定执行数据请求的微服务单元为：微服务1。具体的，一个API网关下面可以对应多个微服务，而且确定执行数据请求的微服务可以为一个，也可以为多个，本发明实施例在此不对其进行限定。

该平台提供根据实际应用来拆分功能的最小粒度；对于服务可以融合Dubbo构架，规范各种服务治理提高服务的效率和高可用性；同时融合Docker技术使各个服务单元环境一致，从而提高整体系统性能；而且该平台通过适配可以融合多种API接口的接入。

参见图3，图3为本发明实施例提供的基于微服务的管理系统的第三种结构图，公共服务模块4根据预设类别划分为一个或多个服务组，每个服务组对应多个微服务。公共服务模块4，包括：支付子模块、消息通知子模块、即时通讯服务子模块、日志采集服务子模块、任务管理子模块。本发明实施例中公共服务模块4所包含的子模块仅仅是示例性的，公共服务模块4中的子模块只要能够满足对业务服务模块3、资源管理模块5之间的数据请求和发送接口，在本领域就似乎人员未做出创造性劳动的情况下，均属于发明的保护范围。

参见图4，图4为本发明实施例提供的基于微服务的管理系统的第四种结构图，微服务运行于Docker容器上。示例性的，图4中，为一组微服务1-微服务5，具体的，微服务1运行在容器1上、微服务2运行在容器2上、微服务3运行在容器3上、微服务4运行在容器4上、微服务5运行在容器5上。实际应用中，一组微服务的数量可以为10、50、100、200等，本发明实施例仅仅是示例性的，不构成对本发明的限定。

本领域技术人员可以理解的是，容器为应用程序提供了隔离的运行空间：每个容器内都包含一个独享的完整用户环境空间，并且一个容器内的变动不会影响其他容器的运行环境。为了能达 到这种效果，容器技术使用了一系列的系统级别的机制诸如利用Linux namespaces来进行空间隔离，通过文件系统的挂载点来决定容器可以访问哪些文件，通过cgroups来确定每个容器可以利用多少资源。此外容器之 间共享同一个系统内核，这样当同一个库被多个容器使用时，内存的使用效率会得到提升。对于系统虚拟化技术来说，虚拟层为用户提供了一个完整的虚拟机：包括内核在内的一个完整的系统镜像。CPU虚拟化技术可以为每个用户提供一个独享且和其他用户隔离的系统环境，虚拟层可以为每个用户分配虚拟化后的CPU、内存和IO设备资源。因此，将微服务运行于容器之上，能够提高微服务的响应速度，提高数据的传输。对于用户而言，提高了用户的体验。

参见图5，图5为本发明实施例提供的基于微服务的管理系统的第五种结构图，该系统还包括：服务管理架构6，与业务服务模块相连，用于对业务服务模块进行展示、管理和配置；服务管理架构6，包括：服务展示子模块、服务配置子模块、服务管理子模块。

应用本发明图1-图5的实施例，整合了微服务架构，对于系统中的应用服务（Application Service）通过其职责和需要实现的技术来划分下属微服务单元（或实例）。这样能够尽可能的把功能服务专一化、基础职责明确化，方便代码开发和维护。同时该平台通过标准化的适配设置整合不同的功能应用接口。

通过功能的详细业务划分清晰的微服务单元，可以使一个涉及业务比较多的大功能细化，然后通过若干个自服务的调度来完成一个大功能的开发实现。在功能开发过程中对于如果有同类相似的功能点就可以通过适配来实现功能服务的接口来快速完成开发。每一个小的服务单元开发完成后就可以从前端界面到后台数据库自成一个微服务单元，它们都服务于某一个大的功能点。

微服务单元通过服务元数据来实现与它同级的微服务单元业务交换处理，互相提供服务和消费服务，当数据交换处理完成后变形成了一个完整的业务功能流程。

同时分布式的服务框架可以实现服务的负载均衡，在数据请求方面使用SEDA（Staged Event Driven Architecture）使得事件同步模式异步化，把不同的业务操作类型隔离区别对待从而提高海量、突发数据请求。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

本说明书中的各个实施例均采用相关的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本领域普通技术人员可以理解实现上述方法实施方式中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，所述的程序可以存储于计算机可读取存储介质中，这里所称得的存储介质，如：ROM/RAM、磁碟、光盘等。

以上所述仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内所作的任何修改、等同替换、改进等，均包含在本发明的保护范围内。