CN114827277B - 基于多机房容器部署的微服务系统及方法 - Google Patents

Abstract

本发明涉及微服务技术领域，公开了一种基于多机房容器部署的微服务系统，包括多个机房、管理端和注册中心；每个机房部署一套容器集群，所述容器集群中的每个容器集成有API组件；所述管理端用于配置微服务的服务注册信息；所述容器集群中的网关和/或微服务通过所述API组件从所述管理端获取匹配的服务注册信息，并自动注册到所述注册中心。本发明具有服务高可用自动化注册能力，可以支持按机房扩展，保证系统的高可用能力；使用方无需调整代码及配置，通过管理端一次性配置即可满足某微服务的高可用能力。可以灵活控制多种部署结构或网络结构的场景下的系统高可用能力，可以随意选择容灾或多活方案，避免系统因不可抗力因素带来的损失。

Description

基于多机房容器部署的微服务系统及方法

技术领域

本发明涉及微服务技术领域，尤其涉及一种基于多机房容器部署的微服务系统及方法。

背景技术

微服务架构通常采取容器的部署方式，针对电信行业大部分采用两地三中心的高可用部署策略，避免业务系统因各种情况造成无法运行的风险。部署方式通常为一地点两中心部署双活，用于高可用；另外一地点一中心部署容灾，用于不可抗力因素进行容灾切换。

上述部署策略中两个地点距离较远，如果三机房部署一套容器集群（k8s）会存在网络抖动或延迟的问题，会出现整个集群不稳定，整个生产系统受三个机房整体网络影响，使生产系统的高可用能力无法保障。

如果采取机房独立部署容器云的方式，即每个机房部署一套容器集群（k8s），然后管理多套容器集群（k8s），这样单机房故障不会影响另一个机房容器集群（k8s），但这种部署方式的部署模式都是写好规范，然后按照规范接入，如果某个微服务没有按照规范将机房、租户信息注册到注册中心，将不具备高可用能力，还会对生产运行带来影响；如果要进行扩充机房或者新增一个系统，那么不但整体架构的路由规则需要调整，所有的按此规则业务中心注册信息都需要配合调整，改造成本将是巨大的。

发明内容

本发明所要解决的技术问题是针对现有技术存在的问题，提供一种基于多机房容器部署的微服务系统及方法。

为解决上述技术问题，本发明提供一种基于多机房容器部署的微服务系统，包括多个机房、管理端和注册中心；每个机房部署一套容器集群，所述容器集群中的每个容器集成有API组件；所述管理端用于配置微服务的服务注册信息；所述容器集群中的网关和/或微服务通过所述API组件从所述管理端获取匹配的服务注册信息，并自动注册到所述注册中心。

为解决上述技术问题，本发明还提供一种基于多机房容器部署的微服务方法，该方法利用上述技术方案提供的基于多机房容器部署的微服务系统实现，方法包括如下步骤：所述容器集群中的网关和/或微服务通过所述API组件从所述管理端获取匹配的服务注册信息，并自动注册到所述注册中心；其中，所述管理端配置有微服务的服务注册信息。

本发明的有益效果是：本发明通过管理端配置微服务的服务注册信息，每个容器上都集成有API组件，API组件可以从管理端获取与微服务匹配的服务注册信息，并自动化注册到注册中心；如需要新增异地机房部署，可以直接部署，无需考虑高可用问题，满足直接部署高可用能力；即本发明具有服务高可用自动化注册能力，可以支持按机房扩展，保证系统的高可用能力；使用方无需调整代码及配置，通过管理端一次性配置即可满足某微服务的高可用能力。可以灵活控制多种部署结构或网络结构的场景下的系统高可用能力，可以随意选择容灾或多活方案，避免系统因不可抗力因素带来的损失。

本发明附加的方面及其优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本发明实践了解到。

附图说明

图1为本发明实施例提供的基于多机房容器部署的微服务系统框图；

图2为本发明实施例提供的基于多机房容器部署的微服务系统单元结构示意图；

图3为本发明实施例提供的WEB系统分层图；

图4为本发明实施例提供的基于多机房容器部署的微服务方法中自动化注册过程的信令交互图；

图5为本发明实施例提供的基于多机房容器部署的微服务方法中服务调用过程的信令交互图。

具体实施方式

以下通过特定的具体实例说明本公开的实施方式，本领域技术人员可由本说明书所揭露的内容轻易地了解本公开的其他优点与功效。显然，所描述的实施例仅仅是本公开的一部分实施例，而不是全部的实施例。本公开还可以通过另外不同的具体实施方式加以实施或应用，本说明书中的各项细节也可以基于不同观点与应用，在没有背离本公开的精神下进行各种修饰或改变。需说明的是，在不冲突的情况下，以下实施例及实施例中的特征可以相互组合。基于本公开中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本公开保护的范围。

需要说明的是，下文描述在所附权利要求书的范围内的实施例的各种方面。应显而易见，本文中所描述的方面可体现于广泛多种形式中，且本文中所描述的任何特定结构及/或功能仅为说明性的。基于本公开，所属领域的技术人员应了解，本文中所描述的一个方面可与任何其它方面独立地实施，且可以各种方式组合这些方面中的两者或两者以上。举例来说，可使用本文中所阐述的任何数目个方面来实施设备及/或实践方法。另外，可使用除了本文中所阐述的方面中的一或多者之外的其它结构及/或功能性实施此设备及/或实践此方法。

图1为本发明实施例提供的基于多机房容器部署的微服务系统框图。如图1所示，该系统包括：多个机房、管理端和注册中心；每个机房部署一套容器集群，所述容器集群中的每个容器集成有API组件。

所述管理端用于配置微服务的服务注册信息；即管理端包括注册信息配置单元，注册信息配置单元用于根据微服务属性配置微服务的服务注册信息，服务注册信息可以包括机房信息、租户信息和外部访问地址等。

所述容器集群中的网关和/或微服务通过所述API组件从所述管理端获取匹配的服务注册信息，并自动注册到所述注册中心。即API组件包括自动化注册单元，自动化注册单元用于根据微服务名从管理端获取匹配的服务注册信息，并自动注册到注册中心。

上述实施例中，理端配置有微服务的服务注册信息，每个容器上都集成有API（即应用程序接口，Application Program Interface）组件，API组件可以从管理端获取与微服务匹配的服务注册信息，并自动化注册到注册中心。本发明如需要新增异地机房部署，可以直接部署，无需考虑高可用问题，满足直接部署高可用能力，即本发明具有服务高可用自动化注册能力，可以支持按机房扩展，保证系统的高可用能力；使用方无需调整代码及配置，通过管理端一次性配置即可满足某微服务的高可用能力。可以灵活控制多种部署结构或网络结构的场景下的系统高可用能力，可以随意选择容灾或多活方案，避免系统因不可抗力因素带来的损失。

可选地，在上述实施例的基础上，管理端还用于配置微服务路由规则，并将微服务路由规则推送至注册中心。即管理端还包括路由规则配置单元和路由规则推送单元。路由规则推送单元用于配置微服务路由规则，路由规则推送单元用于将微服务路由规则推送至注册中心。

所述容器集群中的网关和/或微服务接收到服务调用请求时，通过所述API组件从所述注册中心获取所有满足服务调用请求的微服务的服务注册信息及路由规则，并根据服务注册信息及路由规则进行路由计算，并根据计算结果调用对应的微服务，将服务调用结果反馈给用户。即API组件还包括服务调用路由计算单元，该单元用于实现上述功能。

上述实施例中，管理端除了配置服务注册信息外，还配置微服务路由规则，并将微服务路由规则推送至注册中心；网关或微服务接收到服务调用请求时，通过API组件从注册中心获取所有满足服务调用请求的微服务的服务注册信息及路由规则，并根据服务注册信息及路由规则进行路由计算，根据计算结果调用对应的微服务，将服务调用结果反馈给用户。本发明可统一管理路由调用规则，保证系统的高可用能力；使用方无需调整代码及配置，通过管理端一次性配置即可满足某微服务的高可用能力，并可以个性化调整路由策略；且本发明跨机房路由方式统一，只要涉及通过注册中心选举服务列表，均使用该API组件进行提供者选举，保证服务路由规则一致性。可以灵活控制多种部署结构或网络结构的场景下的系统高可用能力，可以随意选择容灾或多活方案，避免系统因不可抗力因素带来的损失。

可选地，在上述实施例的基础上，所述管理端还用于定期向所有API组件发送探测请求，并根据API组件反馈的请求响应信息分析网关和/或微服务的运行状态，并根据分析结果更新管理端的微服务路由规则，将更新的微服务路由规则推送至注册中心。

即管理端包括服务监控单元，用于定期向所有API组件发送探测请求，并根据API组件反馈的请求响应信息分析网关和/或微服务的运行状态，并根据分析结果更新管理端的微服务路由规则，将更新的微服务路由规则推送至注册中心。

API组件还包括探测服务单元，用于提供探测服务地址，根据服务监控单元发送的探测请求反馈请求响应信息。

现有技术中，存在因网络问题造成的局部异常，定位问题将面临异常困难，现有技术没有服务路由的监控手段，只是架构底层的能力实现，无法保障系统真正的高可用能力运行的监控。

本发明述实施例中通过监控手段对微服务进行监控，可根据探测结果更改微服务提供者权重，比如调用时按照调用微服务在三个机房的探测响应耗时最小的优先调用，实现动态路由规则，在多机房部署的场景下提升系统响应速度及高可用。另外，通过监控的手段可以看到哪些微服务的路由规则异常，便于定位系统问题，如某个机房的微服务探测总是超时，则判断机房出现故障或业务升级出现BUG。

可选地，在上述实施例的基础上，微服务路由规则可以包括：默认计算规则、机房内优先规则、地理区域配置优先规则以及网络延时优先规则等。

所述默认计算规则包括：获取所有满足服务调用请求的服务提供者列表，然后利用轮询方式进行服务调用；其中，跨机房使用外部IP和端口进行访问，内部机房采样内部IP和端口进行访问。

所述机房优先规则包括：将同机房服务提供者的优先级设置为高于跨机房服务提供者的优先级，再针对同机房服务提供者采用轮询方式进行服务调用。即如果是同机房服务提供者，则优先级高于跨机房的服务提供者，再针对高优先级的服务提供者进行轮询方式调用。

所述地理区域配置优先规则包括：根据访问请求的业务数据，按照机房所属地理区域进行高优先级路由调用。即根据业务请求的客户端地理位置 匹配服务端所在最近的机房位置。如运营商中根据工号信息得出归属地市，默认此地市优先访问机房1，机房1如果服务提供不可用在访问其他机房。

所述网络延时优先规则包括：根据管理端定时探测微服务的调用耗时，确定微服务提供者的权重，根据所述微服务提供者权重进行服务调用。

下面是本发明的具体实施例：

本实施例采用如图2所示的基于多机房容器部署的微服务系统，其中，微服务系统包括：多个机房、管理端和注册中心；每个机房部署一套容器集群，所述容器集群中的每个容器集成有API组件。

API组件用于提供自动化注册、服务路由计算及服务探测提供等功能；管理端用于提供注册信息配置、路由规则配置、自动化切换配置、路由监控及路由手工切换等功能。

API组件：

1、自动化注册，根据微服务应用名与管理端通信，拉取到服务注册信息，如机房、租户信息、跨机房调用IP、端口，集成API组件的微服务应用启动时将这些属性注册到注册中心。

2、服务调用路由计算，根据注册中心发现的微服务注册信息，得到服务的机房、租户、提供者IP、端口和调用优先级等信息，进行服务计算调用。

3、提供服务探测访问能力，用于根据管理端发送的探测请求反馈响应信息。

管理端：

1、注册信息配置，针对主机IP定义机房；针对微服务名定义跨机房访问IP、端口（IP、端口可以通过容器之间约定自定义变量，以达到减少配置的目的）。

2、微服务路由规则配置，可以多种配置组合。

微服务路由规则可以包括如下几种：

A.默认计算规则，针对微服务名得到全部服务提供者列表，然后采取轮询方式调用规则，针对跨机房使用外部IP、端口访问，内部机房采取内部IP、端口访问。

B.机房内优先规则，如果是同机房服务提供者，则优先级高于跨机房的服务提供者，再针对高优先级的服务提供者进行轮询方式调用。

C.地理区域配置优先规则，根据访问请求的业务数据，按照机房所属地理区域进行高优先级路由调用。

D.网络延时优先规则，根据管理端定时探测微服务的调用耗时，确定微服务提供者的权重，根据所述微服务提供者权重进行服务调用。

下面对API组件和管理端进行详细介绍。

管理端包括注册信息配置单元、路由规则配置单元、路由规则推送单元和服务监控单元。

注册信息配置单元用于根据微服务属性配置微服务的服务注册信息，服务注册信息可以包括机房信息、租户信息和外部访问地址等。

路由规则配置单元用于配置微服务路由规则。路由规则推送单元用于将微服务路由规则推送至注册中心。

服务监控单元用于定期向所有API组件发送探测请求，并根据API组件反馈的请求响应信息分析网关和/或微服务的运行状态。路由规则配置单元还用于根据探测分析结果更新微服务路由规则，将更新的微服务路由规则推送至注册中心。

API组件包括自动化注册单元、服务路由计算单元和探测服务单元。

自动化注册单元用于根据微服务名从管理端获取匹配的服务注册信息，并自动注册到注册中心。

服务路由计算单元用于在接收到服务调用请求时，从注册中心获取所有满足服务调用请求的微服务的服务注册信息及路由规则，并根据服务注册信息及路由规则进行路由计算，并根据计算结果调用对应的微服务，将服务调用结果反馈给用户。

探测服务单元用于提供探测服务地址，根据服务监控单元发送的探测请求反馈请求响应信息。

本发明实施例提供的基于多机房容器部署的微服务系统可实现如下功能：

1、自动化注册配置。

各业务中心的微服务通过集成上述API组件，无需新增任何配置，统一由该API组件调用管理端查询注册配置信息，进行该微服务对应机房、租户的信息注册，便于统一管理、变更及扩展。

2、服务路由规则统一管理。

各微服务统一集成上述API组件，API组件自动根据管理端配置规则进行跨机房、租户服务发现路由调用，并支持电信运营商个性调用，如营业厅地址位置规则优先调用。

3、服务路由监控。

监控路由策略，动态调整路由规则，以满足系统高可用能力，服务路由自动化切换，针对网络分析，调整服务路由的选举优先级。

本发明实施例的实验环境：准备两套k8s集群分别部署在两个机房，两个微服务应用分别部署在两个机房。

图1中，CDN的全称是Content Delivery Network，即内容分发网络。机房1和机房2中的CUST-A、CUST-B、PROD-A、PROD-B和BASE分别代表客户服务提供A、客户服务提供B、产品服务提供者A、产品服务提供者B、基础能力提供者。注册中心中，CUST、PROD和BASE分别代表客户服务注册信息、产品服务注册信息、基础能力注册信息。INST代表信息。

测试默认路由规则：

通过注册中心，可以看到两个微服务应用各注册了四个IP，每个应用一个内部调用IP，一个外部IP（跨机房调用）；通过网关调用，看到服务提供IP在4个IP中轮询响应。

测试服务层互相调用路由规则：

通过服务A内部调用服务B，通过网关测试调用时，服务A优先调用同机房的服务B；通过将服务B在服务A同机房的应用停止，服务A会跨机房访问服务B；如果此时服务B再次访问服务A时，会再次优先访问服务B同机房的服务A。

测试网络延时优先规则：

模拟服务A某个提供者IP因探测发现网络延迟较高，调整了该提供者的选举值为0.1，通过网关多次调用，发现大部分请求在其他IP，极少的情况会分发到此IP中。

上文结合图1至图2，详细描述了根据本发明实施例提供的基于多机房容器部署的微服务系统。下面结合图3和5，详细描述本发明实施例提供的基于多机房容器部署的微服务方法。

本发明实施例提供一种基于多机房容器部署的微服务方法，该方法利用上述实施例提供的基于多机房容器部署的微服务系统实现，方法包括如下步骤：所述容器集群中的网关和/或微服务通过所述API组件从所述管理端获取匹配的服务注册信息，并自动注册到所述注册中心；其中，所述管理端配置有微服务的服务注册信息。

可选地，在上述实施例的基础上，基于多机房容器部署的微服务方法还包括：当所述容器集群中的网关和/或微服务接收到服务调用请求时，通过所述API组件从所述注册中心获取所有满足服务调用请求的微服务的服务注册信息及路由规则，并根据服务注册信息及路由规则进行路由计算，并根据计算结果调用对应的微服务，将服务调用结果反馈给用户；其中，管理端还配置有微服务路由规则，并将微服务路由规则推送至注册中心。

可选地，在上述实施例的基础上，基于多机房容器部署的微服务方法还包括：所述管理端定期向所有API组件发送探测请求，并根据API组件反馈的请求响应信息分析网关和/或微服务的运行状态，并根据分析结果更新管理端的微服务路由规则，将更新的微服务路由规则推送至注册中心。

场景举例：例如一个WEB系统如图3所示分层，包括访问层、接口层和服务层。访问层可以包括loT设备、移动设备和PC设备等；接口层包括网关，网关中集成有API组件，服务层包括多个应用服务，如应用服务A、应用服务B和应用服务C，各应用服务中集成有API组件。

图3中的网关和各微服务可以实现自动化注册，注册过程信令交互图如图4所示。包括如下步骤：

1.网关/微服务启动；

2.通过API组件向管理端发送服务注册信息获取请求；

3.管理端向网关/微服务返回服务注册信息；

4.网关/微服务根据返回的服务注册信息注册到注册中心。

上述实施例中，通过管理端配置微服务的服务注册信息，每个容器上都集成有API组件，API组件可以从管理端获取与微服务匹配的服务注册信息，并自动化注册到注册中心。本发明如需要新增异地机房部署，可以直接部署，无需考虑高可用问题，满足直接部署高可用能力，即本发明具有服务高可用自动化注册能力，可以支持按机房扩展，保证系统的高可用能力；使用方无需调整代码及配置，通过管理端一次性配置即可满足某微服务的高可用能力。可以灵活控制多种部署结构或网络结构的场景下的系统高可用能力，可以随意选择容灾或多活方案，避免系统因不可抗力因素带来的损失。

图3中的网关和各微服务可以实现微服务调用，以网关调用微服务为例（微服务之间调用与网关调用微服务过程类似），网关调用微服务过程的信令交互图如图5所示。包括如下步骤：

1.用户向网关发送调用请求；

2.网关根据调用的微服务名称调用注册中心；

3.注册中心向网关反馈所有满足服务调用请求的微服务的服务注册信息及路由规则；

4.网关的API组件根据服务注册信息及路由规则（可以为路由规则A、B、C或D）进行路由计算，并根据计算结果调用对应的微服务；

路由规则A：采用注册信信息轮询的方式调用，均衡调用量；

路由规则B：微服务之间调用（Spring Cloud），因微服务之间调用存在连续调用的情况，利用机房内部调用，将减少跨机房网络消耗；

路由规则C，根据调用请求的参数得到运营商的归属营业厅，分配到固定机房；

路由规则D：可以通过API组件提供的探测服务，通过管理端的探测结果更改注册中心中各微服务的调用权重。

以上路由规则可以组合使用，以满足实际高可用场景，保证每次请求都是满足以上的规则得到的最佳服务提供者给予响应。

5.微服务将服务调用结果反馈给网关；

6.网关将服务调用结果反馈给用户。

上述实施例中，管理端除了配置服务注册信息外，还配置微服务路由规则，并将微服务路由规则推送至注册中心；网关或微服务接收到服务调用请求时，通过API组件从注册中心获取所有满足服务调用请求的微服务的服务注册信息及路由规则，并根据服务注册信息及路由规则进行路由计算，并根据计算结果调用对应的微服务，将服务调用结果反馈给用户。本发明可统一管理路由调用规则，保证系统的高可用能力；使用方无需调整代码及配置，通过管理端一次性配置即可满足某微服务的高可用能力，并可以个性化调整路由策略；且本发明跨机房路由方式统一，只要涉及通过注册中心选举服务列表，均使用该API组件进行提供者选举，保证服务路由规则一致性。可以灵活控制多种部署结构或网络结构的场景下的系统高可用能力，可以随意选择容灾或多活方案，避免系统因不可抗力因素带来的损失。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。

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

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以是两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分，或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）执行本发明各个实施例方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器（ROM，Read-Only Memory）、随机存取存储器（RAM，Random Access Memory）、磁碟或者光盘等各种可以存储程序代码的介质。

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

Claims (8)

1.一种基于多机房容器部署的微服务系统，其特征在于，包括多个机房、管理端和注册中心；每个机房部署一套容器集群，所述容器集群中的每个容器集成有API组件；

所述管理端用于配置微服务的服务注册信息；

所述容器集群中的网关和/或微服务通过所述API组件从所述管理端获取匹配的服务注册信息，并自动注册到所述注册中心；

所述管理端还用于配置微服务路由规则，并将微服务路由规则推送至注册中心；

所述容器集群中的网关和/或微服务接收到服务调用请求时，通过所述API组件从所述注册中心获取所有满足服务调用请求的微服务的服务注册信息及路由规则，并根据服务注册信息及路由规则进行路由计算，并根据计算结果调用对应的微服务，将服务调用结果反馈给用户。

2.根据权利要求1所述的系统，其特征在于，所述管理端还用于定期向所有API组件发送探测请求，并根据API组件反馈的请求响应信息分析网关和/或微服务的运行状态，并根据分析结果更新管理端的微服务路由规则，将更新的微服务路由规则推送至注册中心。

3.根据权利要求1所述的系统，其特征在于，所述微服务路由规则包括：默认计算规则、机房内优先规则、地理区域配置优先规则以及网络延时优先规则；

所述默认计算规则包括：获取所有满足服务调用请求的服务提供者列表，然后利用轮询方式进行服务调用；其中，跨机房使用外部IP和端口进行访问，内部机房采样内部IP和端口进行访问；

所述机房优先规则包括：将同机房服务提供者的优先级设置为高于跨机房服务提供者的优先级，再针对同机房服务提供者采用轮询方式进行服务调用；

所述地理区域配置优先规则包括：根据访问请求的业务数据，按照机房所属地理区域进行高优先级路由调用；

所述网络延时优先规则包括：根据管理端定时探测微服务的调用耗时，确定微服务提供者的权重，根据所述微服务提供者权重进行服务调用。

4.根据权利要求1至3任一项所述的系统，其特征在于，所述服务注册信息包括机房信息、租户信息和外部访问地址。

5.一种基于多机房容器部署的微服务方法，其特征在于，该方法利用权利要求1至4任一项所述的基于多机房容器部署的微服务系统实现，方法包括如下步骤：

容器集群中的网关和/或微服务通过所述API组件从管理端获取匹配的服务注册信息，并自动注册到所述注册中心；其中，所述管理端配置有微服务的服务注册信息，

还包括：当所述容器集群中的网关和/或微服务接收到服务调用请求时，通过所述API组件从所述注册中心获取所有满足服务调用请求的微服务的服务注册信息及路由规则，并根据服务注册信息及路由规则进行路由计算，并根据计算结果调用对应的微服务，将服务调用结果反馈给用户；其中，管理端还配置有微服务路由规则，并将微服务路由规则推送至注册中心。

6.根据权利要求5所述的方法，其特征在于，还包括：所述管理端定期向所有API组件发送探测请求，并根据API组件反馈的请求响应信息分析网关和/或微服务的运行状态，并根据分析结果更新管理端的微服务路由规则，将更新的微服务路由规则推送至注册中心。

7.根据权利要求5所述的方法，其特征在于，所述微服务路由规则包括：默认计算规则、机房内优先规则、地理区域配置优先规则以及网络延时优先规则；

所述默认计算规则包括：获取所有满足服务调用请求的服务提供者列表，然后利用轮询方式进行服务调用；其中，跨机房使用外部IP和端口进行访问，内部机房采样内部IP和端口进行访问；

所述机房优先规则包括：将同机房服务提供者的优先级设置为高于跨机房服务提供者的优先级，再针对同机房服务提供者采用轮询方式进行服务调用；

所述地理区域配置优先规则包括：根据访问请求的业务数据，按照机房所属地理区域进行高优先级路由调用；

所述网络延时优先规则包括：根据管理端定时探测微服务的调用耗时，确定微服务提供者的权重，根据所述微服务提供者权重进行服务调用。

8.根据权利要求5至7任一项所述的方法，其特征在于，所述服务注册信息包括机房信息、租户信息和外部访问地址。