CN108270818A - 一种微服务架构系统及其访问方法 - Google Patents

Abstract

本发明公开了一种微服务架构系统，包括：由至少一个第一服务器组成的第三方接口微服务模块集群、由至少一个第二服务器组成的系统内微服务模块集群和由至少一个第三服务器组成的外接接口微服务模块集群；其中，所述第一服务器，用于接收客户端发送的访问请求消息，并根据所述访问请求消息启动第一微服务的第一进程，发送第一服务请求消息给第二服务器；所述第二服务器，用于根据所述第一服务请求消息，启动第二微服务的第二进程；并根据所述第一服务请求消息的预设类型确定是否启动第三微服务的第三进程，发送第二服务请求消息给第三服务器，以供所述第三服务器响应所述第二服务请求消息。本发明还同时公开了一种微服务架构系统的访问方法。

Description

一种微服务架构系统及其访问方法

技术领域

本发明涉及互联网技术领域，尤其涉及一种微服务架构系统及其访问方法。

背景技术

互联网时代的产品有着创新成本低、需求变化快以及用户群体庞大等特点，这些特点导致了互联网时代的产品市场的结构型变化，而目前云计算、开源、Docker等信息技术(IT，Information Technology)都给技术界带来了革命性的影响，因此，为了积极应对市场的变化，迅速对市场做出响应，企业需要应用不同的架构方式构建或者优化其IT系统。

传统的IT系统一般为单体(Monolithic)架构系统，如典型的Monolithic架构模式的WEB应用系统开发实例如图1所示。首先，采用Monolithic架构模式对WEB应用系统进行开发，根据应用功能的不同通常可以将Monolithic架构模式的WEB应用系统分成三层架构：表示层、业务逻辑层以及数据访问层，从而可以根据不同架构建立至少一个项目，并且各个项目所提供的代码ProJ不同；然后，对开发代码进行编译，编译时，这些项目被打包成单个JAR包，并最终合并成一个WAR包；最后，将该WAR包上传到Web容器中进行解压部署。可见，采用Monolithic架构模式对应用系统进行开发的流程包括：首先开发团队对应用系统的表示层、业务逻辑层以及数据访问层的代码进行开发，然后将不同层的代码进行编译，打包成一个应用，最后将应用部署到WEB容器中。上述代码实现、编译以及部署过程都是运行在同一机器的同一进程中。

上面介绍了采用Monolithic架构模式对应用系统进行开发的流程，进一步地，介绍Monolithic架构系统。图2为Monolithic架构系统的组成结构示意图，参照图2所示，按照用户访问触发系统的调用顺序，从上到下一般为表示层(WEB层)、业务层(BO层)、数据访问层(DAO层)以及数据库(DB)，其中，WEB层负责用户体验，BO层负责业务逻辑，DAO层负责DB的数据存取。Monolithic架构系统虽然上下层之间职责划分清晰，但是垂直方向上缺乏清晰的边界，上下层模块之间是多对多的依赖关系，如BO层的业务模块BO1可能调用DAO中所有模块，DAO1也可能被BO层所有模块调用。

从上述采用Monolithic架构模式对应用系统进行开发的流程以及Monolithic架构系统可以看出，虽然Monolithic架构系统通过水平分层，降低了业务复杂性，同时，不同应用功能模块之间通过进程内部调用使得技术实现简单；但是，Monolithic架构系统对垂直方向切分不彻底，上下层应用功能模块之间是多对多的依赖关系，而且不同应用功能模块的代码实现、编译以及部署过程都是运行在同一进程中，使得应用功能模块只是逻辑上的切分。因此，为了解决Monolithic架构系统存在的问题，亟需对IT系统进行优化。

发明内容

为解决现有存在的问题，本发明实施例期望提供一种微服务架构系统及其访问方法，能够解决Monolithic架构系统存在的问题。

为达到上述目的，本发明的技术方案是这样实现的：

本发明实施例提供了一种微服务架构系统，所述系统包括：

由至少一个第一服务器组成的第三方接口微服务模块集群、由至少一个第二服务器组成的系统内微服务模块集群和由至少一个第三服务器组成的外接接口微服务模块集群；其中，

所述第一服务器，用于接收客户端发送的访问请求消息，并根据所述访问请求消息启动与所述访问请求消息对应的第一微服务的第一进程；所述第一进程用于发送第一服务请求消息给第二服务器；

所述第二服务器，用于根据所述第一服务请求消息启动与所述第一服务请求消息对应的第二微服务的第二进程；并根据所述第一服务请求消息的预设类型确定是否启动与所述第一服务请求消息对应的第三微服务的第三进程；

其中，所述第二进程，用于根据所述第一服务请求消息，调用内部接口获取第一预设存储位置的数据，以响应所述第一服务请求消息，并生成第一响应结果；

所述第三进程，用于在确定启动时，发送第二服务请求消息给第三服务器，供所述第三服务器响应所述第二服务请求消息。

上述方案中，所述第三服务器，用于根据所述第二服务请求消息启动与所述第二服务请求消息对应的第四微服务的第四进程；

其中，所述第四进程，用于根据所述第二服务请求消息，调用内部接口获取第二预设存储位置的数据，以响应所述第二服务请求消息，并生成第二响应结果反馈给所述第二服务器。

上述方案中，所述系统还包括：

负载均衡器，用于根据预设的负载均衡策略，确定所述第三方接口微服务模块集群中用于接收所述访问请求消息的第一服务器；并对所述访问请求消息的目标访问地址进行重定向，以将所述访问请求消息转发给所述第一服务器。

上述方案中，所述系统还包括：接口性能参数采集器；其中，

所述第一服务器，还用于根据所述访问请求消息，生成参数采集请求消息，并将所述参数采集请求消息发送给接口性能参数采集器；

所述接口性能参数采集器，用于根据所述参数采集请求消息，采集各个第二服务器中微服务的进程和各个第三服务器中微服务的进程的接口性能参数，并向所述负载均衡器发送所述接口性能参数；

所述负载均衡器，具体用于根据所述接口性能参数，按照预设的负载均衡策略进行所述目标地址的重定向。

上述方案中，所述第二服务器，还用于将所述响应结果作为服务请求响应消息反馈给所述第一服务器；

所述第一服务器，还用于将所述服务请求响应消息经所述负载均衡器反馈给客户端。

本发明实施例还提供了一种微服务架构系统的访问方法，所述访问方法包括：

所述微服务架构系统中第三方接口微服务模块集群的第一服务器接收客户端发送的访问请求消息，并根据所述访问请求消息启动与所述访问请求消息对应的第一微服务的第一进程，发送第一服务请求消息给微服务架构系统中系统内微服务模块集群的第二服务器；

所述第二服务器根据所述第一服务请求消息启动与所述第一服务请求消息对应的第二微服务的第二进程，调用内部接口获取第一预设存储位置的数据，以响应所述第一服务请求消息，并生成第一响应结果；

所述第二服务器根据所述第一服务请求消息的预设类型确定是否启动与所述第一服务请求消息对应的第三微服务的第三进程；

其中，所述第三进程在确定启动时，发送第二服务请求消息给所述微服务架构系统中外接接口微服务模块集群的第三服务器，供所述第三服务器响应所述第二服务请求消息。

上述方案中，所述第三服务器响应所述第二服务请求消息包括：

所述第三服务器根据所述第二服务请求消息启动与所述第二服务请求消息对应的第四微服务的第四进程，调用内部接口获取第二预设存储位置的数据，以响应所述第二服务请求消息，并生成第二响应结果反馈给所述第二服务器。

上述方案中，所述第一服务器接收客户端发送的访问请求消息之前，所述访问方法还包括：

所述微服务架构系统中的负载均衡器根据预设的负载均衡策略，确定所述第三方接口微服务模块集群中用于接收所述访问请求消息的第一服务器；

所述负载均衡器对所述访问请求消息的目标访问地址进行重定向，以将所述访问请求消息转发给所述第一服务器。

上述方案中，所述第一服务器接收客户端发送的访问请求消息之后，所述访问方法还包括：

所述第一服务器根据所述访问请求消息，生成参数采集请求消息，并将所述参数采集请求消息发送给微服务架构系统中的接口性能参数采集器；

所述接口性能参数采集器根据所述参数采集请求消息，采集各个第二服务器中微服务的进程和各个第三服务器中微服务的进程的接口性能参数，并向所述负载均衡器发送所述接口性能参数，以供所述负载均衡器根据所述接口性能参数，按照预设的负载均衡策略进行所述目标地址的重定向。

上述方案中，所述第三服务器响应所述第二服务请求消息之后，所述访问方法还包括：

所述第二服务器将所述响应结果作为服务请求响应消息反馈给所述第一服务器；

所述第一服务器将所述服务请求响应消息经所述负载均衡器反馈给客户端。

本发明实施例提供的微服务架构系统及其访问方法，由至少一个第一服务器组成的第三方接口微服务模块集群、由至少一个第二服务器组成的系统内微服务模块集群和由至少一个第三服务器组成的外接接口微服务模块集群；其中，所述第一服务器，用于接收客户端发送的访问请求消息，并根据所述访问请求消息启动与所述访问请求消息对应的第一微服务的第一进程；所述第一进程用于发送第一服务请求消息给第二服务器；所述第二服务器，用于根据所述第一服务请求消息启动与所述第一服务请求消息对应的第二微服务的第二进程；并根据所述第一服务请求消息的预设类型确定是否启动与所述第一服务请求消息对应的第三微服务的第三进程；其中，所述第二进程，用于根据所述第一服务请求消息，调用内部接口获取第一预设存储位置的数据，以响应所述第一服务请求消息，并生成第一响应结果；所述第三进程，用于发送第二服务请求消息给第三服务器，以供所述第三服务器响应所述第二服务请求消息。

可见，通过所述第一服务器的第一微服务响应访问请求消息、所述第二服务器的第二微服务响应第一服务请求消息和所述第二服务器的第三微服务发送第二服务请求消息给所述第三服务器，以供第三服务器响应所述第二服务请求消息，从而实现了对一个服务的完整响应。由于上述第一服务器、第二服务器以及第三服务器的微服务都运行在独立的进程中，微服务之间通过远程调用的方式互相沟通，因此，实现了每一个应用功能区都是采用微服务完成的，同时也实现了将单一的服务分解为多个可管理的分支服务，解决了Monolithic架构系统存在的垂直方向切分不彻底和应用功能模块之间只是逻辑上的切分的问题。从而采用微服务架构模式对应用系统进行开发，开发的复杂程度更容易控制；并且，更容易构建高效的团队，能够缩短持续交付周期，提高弹性能力和可伸缩性。

附图说明

图1为Monolithic架构模式的WEB应用系统开发实例；

图2为Monolithic架构系统的组成结构示意图；

图3为本发明微服务架构系统实施例一的组成结构示意图；

图4为本发明微服务架构系统实施例二的组成结构示意图；

图5为本发明微服务架构系统的访问方法实施例一的实现流程示意图；

图6为本发明微服务架构系统的访问方法实施例二的实现流程示意图之一；

图7为本发明微服务架构系统的访问方法实施例二的实现流程示意图之二。

具体实施方式

本发明实施例提供的微服务架构系统，主要应用于云平台建设项目中，包括由至少一个第一服务器组成的第三方接口微服务模块集群、由至少一个第二服务器组成的系统内微服务模块集群和由至少一个第三服务器组成的外接接口微服务模块集群；通过所述第一服务器的第一微服务响应访问请求消息、所述第二服务器的第二微服务响应第一服务请求消息和所述第二服务器的第三微服务发送第二服务请求消息给所述第三服务器，以供第三服务器响应所述第二服务请求消息，从而实现了每一个应用功能区都是采用微服务完成的，同时也实现了将单一的服务分解为多个可管理的分支服务，解决了Monolithic架构系统存在的垂直方向切分不彻底和应用功能模块之间只是逻辑上的切分的问题。

本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

图3为本发明微服务架构系统实施例一的组成结构示意图，参照图3所示，本实施例的微服务架构系统包括：由至少一个第一服务器111组成的第三方接口微服务模块集群11、由至少一个第二服务器121组成的系统内微服务模块集群12和由至少一个第三服务器131组成的外接接口微服务模块集群13；其中，

所述第一服务器111，用于接收客户端发送的访问请求消息，并根据所述访问请求消息启动与所述访问请求消息对应的第一微服务的第一进程；所述第一进程用于发送第一服务请求消息给第二服务器121；

这里，所述第一服务器111为节点服务器，用于中转所述访问请求消息给第二服务器121；用户可以通过移动终端、电脑等用户设备向第三方接口微服务集群11中第一服务器111发送访问请求消息；具体地，用户设备安装有客户端软件，通过客户端软件的界面来提供用户输入访问请求消息的接口，将用户输入的访问请求消息通过网络协议发送给第三方接口微服务模块集群11中第一服务器111。

所述系统内微服务模块集群12包含多台第二服务器121，每台第二服务器121包含多个第二微服务，所述第一微服务与第二微服务采用轻量级的通信机制互相沟通；具体地，所述第三方接口微服务模块集群11中的第一服务器11中与所述访问请求消息对应的第一微服务可以基于HTTP协议的RESTful API，将第一服务请求消息发送给第二服务器121。

所述第二服务器121，用于根据所述第一服务请求消息，启动与所述第一服务请求消息对应的第二微服务的第二进程；并根据所述第一服务请求消息的预设类型确定是否启动与所述第一服务请求消息对应的第三微服务的第三进程；

其中，所述第二进程，用于根据所述第一服务请求消息，调用内部接口获取第一预设存储位置的数据，以响应所述第一服务请求消息，并生成第一响应结果；

这里，所述第一预设存储位置可以为数据库和第三方组件；

所述第三进程，用于在确定启动时，发送第二服务请求消息给第三服务器131，以供所述第三服务器131响应所述第二服务请求消息。

这里，所述第一服务请求消息的预设类型包括只需要内部微服务以及同时需要内部微服务和外部微服务；所述第二服务器同时还包含了第三微服务，所述第三微服务可远程调用及响应外接接口微服务模块集群13中第三服务器131的第四微服务；本实施例中，所述第三微服务可以基于HTTP协议的RESTfulAPI，将第二服务请求消息发送给外接接口微服务模块集群13中第三服务器131。

进一步地，所述第三服务器131，用于根据所述第二服务请求消息启动与所述第二服务请求消息对应的第四微服务的第四进程；其中，所述第四进程，用于根据所述第二服务请求消息，调用内部接口获取第二预设存储位置的数据，以响应所述第二服务请求消息，并生成第二响应结果反馈给所述第二服务器121，所述第二预设存储位置可以为数据库、第三方组件和第三方接口部件。

可以理解的是，所述微服务架构系统通过第一服务器111中的第一微服务、第二服务器121中的第二微服务和第三微服务以及第三服务器131中的第四微服务互相沟通，就能解决Monolithic架构系统存在的问题，是因为：第三方接口微服务模块集群11中第一服务器111的第一微服务、系统内微服务模块集群12中第二服务器121的第二微服务和第三微服务、以及外接接口微服务模块集群13中第三服务器131的第四微服务，实现的都是不同的应用功能，从而使每一个应用功能区都是使用微服务完成的；并且每个微服务运行在独立的进程中，微服务之间通过远程调用的方式互相沟通，实现了将单一的服务分解为多个可管理的分支服务；而且每个分支服务都围绕着具体业务进行构建，并能够被独立的部署，从而可以更容易地对将来应用于平台的不同用户、设备和特殊应用场景进行部署，因此，解决了Monolithic架构系统存在的垂直方向切分不彻底和应用功能模块之间只是逻辑上的切分的问题。

进一步地，图4为本发明微服务架构系统实施例二的组成结构示意图，参照图4所示，本实施例的微服务架构系统，是在实施例一的系统组成结构基础上还包括：负载均衡器14和接口性能参数采集器15；其中，

所述负载均衡器14，用于根据预设的负载均衡策略，确定所述第三方接口微服务模块集群11中用于接收所述访问请求消息的第一服务器111；并对所述访问请求消息的目标访问地址进行重定向，以将所述访问请求消息转发给所述第一服务器111。

通常，为有效解决数据流量过大和系统网络负荷过重的问题，充分利用现有设备，避免服务器单点故障造成数据流量的损失，采用负载均衡器14接收客户端发送的访问请求消息；通过API Gateway传递所述访问请求消息给第三方接口微服务模块集群11中第一服务器111，从而使应用不直接访问系统内微服务模块集群12和外接接口微服务模块集群13中的微服务，这样不仅能够解决数据流量过大以及系统网络负荷过重的问题，而且可以实现缓存、访问控制和API计费监控等任务；并且，由于所述负载均衡器14中有灵活多样的负载均衡策略把数据流量合理地分配给微服务集群内的服务器共同负担，因此，有负载平衡的第一服务器111能够同时响应不同客户端的访问请求消息，也可以分散负荷响应同一客户端的多个访问请求消息，从而提高了系统的业务处理能力；另外，增加了负载均衡器14的微服务架构系统，即使是给服务器扩充升级，也只是简单地增加一个新的服务器到微服务集群中，不需要改变现有系统网络的结构，停止现有的服务。

所述负载均衡器14可以通过高性能的HTTP和反向代理服务器(NGINX)来实现，所述预设的负载均衡策略可以是RR策略和hash策略；本实施例中，可以以RR策略为例进行详细说明，具体地，所述负载均衡器14根据各个第二服务器121中微服务的进程和各个第三服务器131中微服务的进程的接口性能参数，按照RR策略来确定用于接收所述访问请求消息的第三方接口微服务模块集群11中第一服务器111。

所述负载均衡器14通过所述接口性能参数采集器15来获取所述接口性能参数；具体地，在所述第一服务器111启动第一微服务的第一进程，所述第二服务器121启动第二微服务的第二进程和第三微服务的第三进程以及第三服务器131启动第四微服务的第四进程的同时，所述第一服务器111会根据所述访问请求消息，生成参数采集请求消息，并将所述参数采集请求消息发送给接口性能参数采集器15；

所述接口性能参数采集器15，用于根据所述参数采集请求消息，采集各个第二服务器121中微服务的进程和各个第三服务器131中微服务的进程的接口性能参数，并向所述负载均衡器14发送所述接口性能参数，以供所述负载均衡器14接收到客户端发送的下一个访问请求消息时，会根据所述接口性能参数，按照RR策略确定用于接收访问请求消息的第三方接口微服务模块集群11中第一服务器111，所述接口性能参数可以为CPU内存使用率。

进一步地，所述负载均衡器14可以利用Cucumber和JBehave等工具搭建测试框架对所述接口性能参数进行测试和结果统计，生成测试结果，以便在客户端发送下一个访问请求消息时，所述负载均衡器14会根据所述接口性能参数和测试结果，按照RR策略确定用于接收访问请求消息的第三方接口微服务模块集群11中第一服务器111，从而能够保障微服务架构系统中微服务所负责的业务逻辑以及与外部交互的稳定性和可靠性。

进一步地，为了使微服务应用的开发及部署访问流程的过程中有足够的控制方法和高度的自动化，本实施例的微服务架构系统还包括配置库16(SpringCloud)，用于对微服务架构系统构建时提供一些常用的解决方案的工具集以及一些常用的基础组件的构建服务。

在实际应用中，本发明微服务架构系统可以应用于目前主流的云计算技术领域或云平台建设项目。

本发明还提供了一种应用于上述微服务架构系统的访问方法，图5为本发明微服务架构系统的访问方法实施例一的实现流程示意图，参照图5所示，本实施例中的微服务架构系统的访问方法包括以下步骤：

步骤201，所述微服务架构系统中第三方接口微服务模块集群的第一服务器接收客户端发送的访问请求消息，并根据所述访问请求消息启动与所述访问请求消息对应的第一微服务的第一进程，发送第一服务请求消息给微服务架构系统中系统内微服务模块集群的第二服务器；

这里，所述第一服务器为节点服务器，用于中转所述访问请求消息给第二服务器；用户可以通过移动终端、电脑等用户设备向第三方接口微服务集群中第一服务器发送访问请求消息；具体地，用户设备安装有客户端软件，通过客户端软件的界面来提供用户输入访问请求消息的接口，将用户输入的访问请求消息通过网络协议发送给第三方接口微服务模块集群中第一服务器。

所述系统内微服务模块集群包含大量的第二服务器，每台第二服务器包含多个第二微服务，所述第一微服务与第二微服务采用轻量级的通信机制互相沟通；具体地，所述第三方接口微服务模块集群中的第一服务器中与所述访问请求消息对应的第一微服务可以基于HTTP协议的RESTful API，将第一服务请求消息发送给第二服务器。

步骤202，所述第二服务器根据所述第一服务请求消息启动与所述第一服务请求消息对应的第二微服务的第二进程，调用内部接口获取第一预设存储位置的数据，以响应所述第一服务请求消息，并生成第一响应结果；

这里，所述第一预设存储位置可以为数据库和第三方组件；

步骤203，所述第二服务器根据所述第一服务请求消息的预设类型确定是否启动与所述第一服务请求消息对应的第三微服务的第三进程；

这里，所述第一服务请求消息的预设类型包括只需要内部微服务以及同时需要内部微服务和外部微服务；所述第二服务器同时还包含了第三微服务，所述第三微服务可远程调用及响应外接接口微服务模块集群中第三服务器的第四微服务；

步骤204，当确定启动所述第三进程时，所述第二服务器启动所述第三进程，所述第三进程发送第二服务请求消息给所述微服务架构系统中外接接口微服务模块集群的第三服务器；

这里，所述第三微服务可以基于HTTP协议的RESTful API，将第二服务请求消息发送给外接接口微服务模块集群中第三服务器。

步骤205，所述第三服务器响应所述第二服务请求消息。

该步骤中，所述第三服务器响应所述第二服务请求消息包括：所述第三服务器根据所述第二服务请求消息启动与所述第二服务请求消息对应的第四微服务的第四进程，调用内部接口获取第二预设存储位置的数据，以响应所述第二服务请求消息，并生成第二响应结果反馈给所述第二服务器，所述第二预设存储位置可以为数据库、第三方组件以及第三方接口部件。

具体地，第三方接口微服务模块集群的第一服务器接收客户端发送的访问请求消息，并根据所述访问请求消息启动与所述访问请求消息对应的第一微服务的第一进程，基于HTTP协议的RESTful API将所述第一服务请求消息发送给系统内微服务模块集群中的第二服务器；

所述第二服务器根据所述第一服务请求消息启动与所述第一服务请求消息对应的第二微服务的第二进程，调用内部接口获取数据库和第三方组件中的数据，执行相应的微服务操作，并生成第一响应结果；

所述第二服务器根据所述第一服务请求消息的预设类型确定是否启动与所述第一服务请求消息对应的第三微服务的第三进程；

当还需要调用外接接口微服务模块集群中第三服务器的微服务时，所述第二服务器会启动与所述第一服务请求消息对应的第三微服务的第三进程，发送第二服务请求消息给外接接口微服务模块集群的第三服务器；

所述第三服务器根据所述第二服务请求消息启动与所述第二服务请求消息对应的第四微服务的第四进程，调用内部接口获取数据库、第三方组件以及第三方接口部件的数据，以响应所述第二服务请求消息，并生成第二响应结果反馈给所述第二服务器。

可以理解的是，所述微服务架构系统的访问方法通过访问微服务架构系统中第三方接口微服务模块集群的第一服务器、系统内微服务模块集群中的第二服务器以及外接接口微服务模块集群中的第三服务器就能实现微服务架构系统对服务的响应是因为：首先，通过所述第一服务器接收客户端发送的访问请求消息，根据所述访问请求消息启动与所述访问请求消息对应的第一微服务的第一进程，发送第一服务请求消息给第二服务器，从而实现对访问请求消息的响应；然后，所述第二服务器根据所述第一服务请求消息启动与所述第一服务请求消息对应的第二微服务的第二进程，从而实现对第一服务请求消息的响应；最后，根据所述第一服务请求消息的预设类型确定是否启动与所述第一服务请求消息对应的第三微服务的第三进程，发送第二服务请求消息给第三服务器，并由第三服务器响应所述第二服务请求消息，从而实现对第二服务请求消息的响应；因此，经过第一服务器中第一微服务对访问请求消息的响应、第二服务器中第二微服务对第一服务请求消息的响应、第二服务器中第三微服务对第二服务请求消息的调用以及第三服务器中第四微服务对第二服务请求消息的响应，实现了微服务架构系统对一个服务的完整响应。

进一步地，图6为本发明微服务架构系统的访问方法实施例二的实现流程示意图之一，参照图6所示，本实施例的微服务架构系统的访问方法，是在方法实施例一的步骤201之前还包括：

步骤200a，所述微服务架构系统中的负载均衡器根据预设的负载均衡策略，确定所述第三方接口微服务模块集群中用于接收所述访问请求消息的第一服务器；

所述负载均衡器可以通过高性能的HTTP和反向代理服务器(NGINX)来实现，所述预设的负载均衡策略可以是RR策略和hash策略；本实施例中，可以以RR策略为例进行详细说明，具体地，所述负载均衡器根据各个第二服务器中微服务的进程和各个第三服务器中微服务的进程的接口性能参数，按照RR策略来确定用于接收所述访问请求消息的第三方接口微服务模块集群中第一服务器。

所述负载均衡器通过接口性能参数采集器来获取所述接口性能参数；具体地，在所述第一服务器启动第一微服务的第一进程，所述第二服务器启动第二微服务的第二进程和第三微服务的第三进程以及第三服务器启动第四微服务的第四进程的同时，所述第一服务器会根据所述访问请求消息，生成参数采集请求消息，并将所述参数采集请求消息发送给微服务架构系统中的接口性能参数采集器；

所述接口性能参数采集器，根据所述参数采集请求消息，采集各个第二服务器中微服务的进程和各个第三服务器中微服务的进程的接口性能参数，并向所述负载均衡器发送所述接口性能参数，以供所述负载均衡器接收到客户端发送的下一个访问请求消息时，会根据所述接口性能参数，按照RR策略确定用于接收访问请求消息的第三方接口微服务模块集群中第一服务器，所述接口性能参数可以为CPU内存使用率。

进一步地，所述负载均衡器14可以利用Cucumber和JBehave等工具搭建测试框架对所述接口性能参数进行测试和结果统计，生成测试结果，以便在客户端发送下一个访问请求消息时，所述负载均衡器会根据所述接口性能参数和测试结果，按照RR策略确定用于接收访问请求消息的第三方接口微服务模块集群中第一服务器，从而能够保障微服务架构系统中微服务所负责的业务逻辑以及与外部交互的稳定性和可靠性。

步骤200b，所述负载均衡器对所述访问请求消息的目标访问地址进行重定向，以将所述访问请求消息转发给所述第一服务器。

基于方法实施例一的微服务架构系统的访问方法，在本实施例中，对本发明微服务架构系统的访问方法的具体实现举例进行详细说明；图7为本发明微服务架构系统的访问方法实施例二的实现流程示意图之二，参照图7所示，本实施例的微服务架构系统的访问方法的流程具体包括以下步骤：

第1步：客户端将访问请求消息发送给负载均衡器；

第2步：所述负载均衡器根据接口性能参数采集器采集的微服务的进程的CPU内存使用率，按照RR策略确定第三方接口微服务模块集群中用于接收所述访问请求消息的第一服务器；然后对所述访问请求消息的目标访问地址进行重定向，将所述访问请求消息转发给所述第一服务器；

第3步：所述第一服务器接收所述访问请求消息，并根据所述访问请求消息启动与所述访问请求消息对应的第一微服务的第一进程，基于HTTP协议的RESTful API将第一服务请求消息发送给系统内微服务模块集群的第二服务器；

第4步：所述第二服务器根据所述第一服务请求消息启动与所述第一服务请求消息对应的第二微服务的第二进程，调用内部接口获取第一预设存储位置的数据，以响应所述第一服务请求消息，并生成第一响应结果；同时，当需要调用外接接口微服务模块集群中的微服务时，所述第二服务器启动与所述第一服务请求消息对应的第三微服务的第三进程，基于HTTP协议的RESTful API将第二服务请求消息发送给外接接口微服务模块集群中的第三服务器；

第5步：所述第三服务器根据所述第二服务请求消息启动与所述第二服务请求消息对应的第四微服务的第四进程，调用内部接口获取数据库、第三方组件以及第三方接口部件的数据，以响应所述第二服务请求消息，并生成第二响应结果反馈给所述第二服务器。

第6步：所述第二服务器将响应结果作为服务请求响应消息反馈给所述第一服务器；

第7步：所述第一服务器将所述服务请求响应消息反馈给所述负载均衡器；

第8步：所述负载均衡器将所述服务请求响应消息反馈给客户端。

进一步地，在执行第3步至第5步的过程中将会触发执行第9步：所述第一服务器生成参数采集请求消息，并将所述参数采集请求消息发送给接口性能参数采集器；所述接口性能参数采集器采集各个第二服务器中微服务的进程和各个第三服务器中微服务的进程的接口性能参数，并将所述接口性能参数发送给所述负载均衡器。

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

Claims (10)

1.一种微服务架构系统，其特征在于，所述系统包括：由至少一个第一服务器组成的第三方接口微服务模块集群、由至少一个第二服务器组成的系统内微服务模块集群和由至少一个第三服务器组成的外接接口微服务模块集群；其中，

所述第一服务器，用于接收客户端发送的访问请求消息，并根据所述访问请求消息启动与所述访问请求消息对应的第一微服务的第一进程；所述第一进程用于发送第一服务请求消息给第二服务器；

所述第二服务器，用于根据所述第一服务请求消息启动与所述第一服务请求消息对应的第二微服务的第二进程；并根据所述第一服务请求消息的预设类型确定是否启动与所述第一服务请求消息对应的第三微服务的第三进程；

其中，所述第二进程，用于根据所述第一服务请求消息，调用内部接口获取第一预设存储位置的数据，以响应所述第一服务请求消息，并生成第一响应结果；

所述第三进程，用于在确定启动时，发送第二服务请求消息给第三服务器，供所述第三服务器响应所述第二服务请求消息。

2.根据权利要求1所述的系统，其特征在于，所述第三服务器，用于根据所述第二服务请求消息启动与所述第二服务请求消息对应的第四微服务的第四进程；

其中，所述第四进程，用于根据所述第二服务请求消息，调用内部接口获取第二预设存储位置的数据，以响应所述第二服务请求消息，并生成第二响应结果反馈给所述第二服务器。

3.根据权利要求2所述的系统，其特征在于，所述系统还包括：

负载均衡器，用于根据预设的负载均衡策略，确定所述第三方接口微服务模块集群中用于接收所述访问请求消息的第一服务器；并对所述访问请求消息的目标访问地址进行重定向，以将所述访问请求消息转发给所述第一服务器。

4.根据权利要求3所述的系统，其特征在于，所述系统还包括：接口性能参数采集器；其中，

所述第一服务器，还用于根据所述访问请求消息，生成参数采集请求消息，并将所述参数采集请求消息发送给接口性能参数采集器；

所述接口性能参数采集器，用于根据所述参数采集请求消息，采集各个第二服务器中微服务的进程和各个第三服务器中微服务的进程的接口性能参数，并向所述负载均衡器发送所述接口性能参数；

所述负载均衡器，具体用于根据所述接口性能参数，按照预设的负载均衡策略进行所述目标地址的重定向。

5.根据权利要求3所述的系统，其特征在于，所述第二服务器，还用于将所述响应结果作为服务请求响应消息反馈给所述第一服务器；

所述第一服务器，还用于将所述服务请求响应消息经所述负载均衡器反馈给客户端。

6.一种微服务架构系统的访问方法，其特征在于，所述访问方法包括：

所述微服务架构系统中第三方接口微服务模块集群的第一服务器接收客户端发送的访问请求消息，并根据所述访问请求消息启动与所述访问请求消息对应的第一微服务的第一进程，发送第一服务请求消息给微服务架构系统中系统内微服务模块集群的第二服务器；

所述第二服务器根据所述第一服务请求消息启动与所述第一服务请求消息对应的第二微服务的第二进程，调用内部接口获取第一预设存储位置的数据，以响应所述第一服务请求消息，并生成第一响应结果；

所述第二服务器根据所述第一服务请求消息的预设类型确定是否启动与所述第一服务请求消息对应的第三微服务的第三进程；

其中，所述第三进程在确定启动时，发送第二服务请求消息给所述微服务架构系统中外接接口微服务模块集群的第三服务器，供所述第三服务器响应所述第二服务请求消息。

7.根据权利要求6所述的访问方法，其特征在于，所述第三服务器响应所述第二服务请求消息包括：

所述第三服务器根据所述第二服务请求消息启动与所述第二服务请求消息对应的第四微服务的第四进程，调用内部接口获取第二预设存储位置的数据，以响应所述第二服务请求消息，并生成第二响应结果反馈给所述第二服务器。

8.根据权利要求7所述的访问方法，其特征在于，所述第一服务器接收客户端发送的访问请求消息之前，所述访问方法还包括：

所述微服务架构系统中的负载均衡器根据预设的负载均衡策略，确定所述第三方接口微服务模块集群中用于接收所述访问请求消息的第一服务器；

所述负载均衡器对所述访问请求消息的目标访问地址进行重定向，以将所述访问请求消息转发给所述第一服务器。

9.根据权利要求8所述的访问方法，其特征在于，所述第一服务器接收客户端发送的访问请求消息之后，所述访问方法还包括：

所述第一服务器根据所述访问请求消息，生成参数采集请求消息，并将所述参数采集请求消息发送给微服务架构系统中的接口性能参数采集器；

所述接口性能参数采集器根据所述参数采集请求消息，采集各个第二服务器中微服务的进程和各个第三服务器中微服务的进程的接口性能参数，并向所述负载均衡器发送所述接口性能参数，以供所述负载均衡器根据所述接口性能参数，按照预设的负载均衡策略进行所述目标地址的重定向。

10.根据权利要求8所述的访问方法，其特征在于，所述第三服务器响应所述第二服务请求消息之后，所述访问方法还包括：

所述第二服务器将所述响应结果作为服务请求响应消息反馈给所述第一服务器；

所述第一服务器将所述服务请求响应消息经所述负载均衡器反馈给客户端。