CN112671882A - 一种基于微服务的同城双活系统和方法 - Google Patents

Abstract

本发明实施例提供了一种基于微服务的同城双活系统和方法，所述系统包括：两个数据中心，每个数据中心各自包括：负载均衡、微服务网关、多个容器集群；多个微服务部署到两个数据中心的每个容器集群中，所有微服务统一注册到Consul集群；多个容器集群用于为请求提供相应的微服务；微服务通过服务名实现对所在容器集群内其他微服务的调用；并通过调用目标微服务所在的目标容器集群对应的Ingress，由该Ingress将所述请求转发至目标微服务，实现跨集群的微服务访问。本发明提供的方法和系统，将两个数据中心内的微服务统一注册到Consul集群，以此作为服务访问的基础，利用负载均衡和Ingress配合进行调用，实现高可用双活。

Description

一种基于微服务的同城双活系统和方法

技术领域

本发明涉及信息技术领域，特别是涉及一种基于微服务的同城双活系统和一种基于微服务的同城双活方法。

背景技术

互联网的高度发展为人们的工作和生活带来了极大的便利，随之而来地，人们对服务端网络系统提供服务的稳定性也提出了更高的要求。但是服务端网络系统因为受到软硬件故障、网络攻击、人为操作失误等众多因素的影响，仍然难以避免存在系统迟响应甚至无响应的风险。

针对上述问题，人们基于“容灾”的思想提出建立容灾系统，为计算机信息系统提供的一个能应付各种灾难的环境，在主系统无法正常提供服务时，由备份系统“救场”。可以说，容灾系统有效地提高了网络系统提供服务的稳定性。

在“容灾思想”的基础上，人们还提出高可用和双活的概念，同样旨在提高网络系统运行的稳定性。其中，高可用是系统不能提供服务的时间越少越好，而双活是让主备份系统同时在线运行并互为备份。其中，为了满足主备份系统之间的通讯低延时等要求，同城双活，即将主备份系统的数据中心部署在同个城市，从部署难度、部署成本上来说，是更容易实现的一种双活方案。

显然，如何进行网络系统架构的设计，让网络系统中的众多组件彼此配合工作，极大程度地影响着系统的高可用性和双活性能，进而决定了系统运行的稳定性。当下的网络系统架构设计层出不穷，如何更进一步地提高网络系统的高可用性、双活性能，依然是令技术人员头疼的难题。

发明内容

为了解决上述问题，本发明实施例提出了一种基于微服务的同城双活系统和一种基于微服务的同城双活方法，旨在实现网络系统的高可用双活。

本发明实施例提供了一种基于微服务的同城双活系统，所述系统包括通过专线网络连接的两个数据中心，每个数据中心各自包括：负载均衡单元、微服务网关单元、多个容器集群单元，其中，每个容器集群单元预先部署Ingress单元和多个对应的微服务单元；两个数据中心的每个微服务单元统一注册到Consul集群；

所述负载均衡单元，用于将外部域名系统发送的请求转发至微服务网关单元；

所述微服务网关单元，用于对所述请求进行鉴权、限流，并根据所述请求携带的URL，转发至URL指向的容器集群单元相对应的微服务单元；

所述多个容器集群单元，用于为所述请求提供相应的微服务单元；所述微服务单元通过服务名实现对所在容器集群单元内其他微服务单元的调用；所述微服务单元通过调用目标微服务单元所在的目标容器集群单元对应的Ingress单元，由该Ingress单元将所述请求转发至目标微服务单元，实现跨容器集群单元的服务访问；

所述Ingress单元是所在容器集群单元最外层的、由Ingress规则集合组成的虚拟节点。

可选地，针对每个数据中心，所述负载均衡单元包括：

负载均衡第一接收单元，用于在外部域名系统解析到两个数据中心的负载均衡单元的IP地址、并将用户的请求发送至任意一个数据中心的负载均衡单元后，由该数据中心的负载均衡单元接收所述请求；

负载均衡分配单元，用于将该请求携带的外部IP地址转换为该数据中心的内部IP地址；

负载均衡第一转发单元，用于将携带内部IP地址的请求转发至该数据中心的微服务网关单元。

可选地，针对每个数据中心，所述负载均衡单元包括：

负载均衡第二接收单元，用于在微服务网关单元检测到该数据中心内与请求相对应的微服务单元的实例运行状况不大于预设健康阈值、并返回所述请求时，接收微服务网关单元返回的请求；

负载均衡第二转发单元，用于将微服务网关单元返回的请求通过专线网络转发至另一个数据中心的微服务网关单元。

可选地，针对每个数据中心，所述微服务网关单元包括：

微服务网关检查单元，用于执行健康检查，检查该数据中心内与请求相对应的微服务单元的实例运行状况是否大于预设健康阈值；若是，将所述请求转发至微服务网关第一转发单元；若否，将所述请求转发至微服务网关返回单元；

微服务网关第一转发单元，用于经过鉴权、限流后，将从负载均衡单元接收的请求转发到该数据中心内与请求相对应的微服务单元；

微服务网关返回单元，用于将所述请求返回至该数据中心的负载均衡单元。

可选地，所述微服务单元包括：

针对每个数据中心，所述微服务单元包括：

微服务第一调用单元，用于默认按路由就近的原则访问同集群内的微服务单元，通过服务名实现对下一级微服务单元的调用；

微服务第一返回单元，用于当微服务单元异常时，若该微服务单元是直接被微服务网关单元所调用，将请求返回该微服务网关单元。

可选地，针对每个数据中心，所述微服务网关单元包括：

微服务网关第二转发单元，用于将异常微服务单元返回的请求转发至该容器集群单元内的其他微服务单元，包括：默认按路由就近的原则，按照服务名将请求转发至该容器集群单元内、除异常微服务单元以外的其他微服务单元；

微服务网关第三转发单元，用于将异常微服务单元返回的请求转发至该异常微服务单元所在的容器集群单元以外的其他容器集群单元，包括：默认按路由就近的原则，按照服务名将请求转发至其他容器集群单元内、与异常微服务单元对应的微服务单元。

可选地，所述微服务单元包括：

微服务第二返回单元，用于当微服务单元异常时，若该微服务单元是直接被上一级微服务单元所调用，则将请求返回上一级微服务单元。

可选地，所述微服务单元还包括：

微服务第一转发单元，用于将异常微服务单元返回的请求转发至该容器集群单元内的其他微服务单元，包括：默认按路由就近的原则，按照服务名将请求转发至该容器集群单元内、除异常微服务单元以外的其他微服务单元；

微服务第二转发单元，用于将异常微服务单元返回的请求转发至该数据中心的、其他容器集群单元内与该异常微服务单元相对应的目标微服务单元，包括：利用目标容器集群单元对应的Ingress单元对外暴露的节点IP地址和端口号，将所述请求转发至该数据中心内、其他容器集群单元内与该异常微服务单元相对应的微服务单元。

可选地，所述微服务单元包括：

微服务第三转发单元，用于将异常微服务单元返回的请求转发至另一数据中心的容器集群单元内与该异常微服务单元相对应的目标微服务单元，包括：利用目标容器集群单元对应的Ingress单元对外暴露的节点IP地址和端口号，将所述请求转发至另一数据中心的容器集群单元内与该异常微服务单元相对应的微服务单元。

本发明实施例还提供了一种基于微服务的同城双活方法，应用于上述任一项所述的系统，所述方法包括：

由负载均衡将域名系统发送的请求转发至微服务网关；

由微服务网关对所述请求进行鉴权、限流，并根据所述请求携带的URL，转发至URL指向的容器集群单元相对应的微服务单元；

由容器集群为所述请求提供相应的微服务；所述微服务通过服务名实现对所在容器集群内其他微服务的调用；所述微服务通过调用目标微服务所在的目标容器集群对应的Ingress，由该Ingress将所述请求转发至目标微服务，实现跨容器集群的服务访问；所述Ingress是所在容器集群最外层的、由Ingress规则集合组成的虚拟节点。

从上述技术方案可以看出，本发明实施例提供了一种基于微服务的同城双活系统和方法，本发明基于微服务架构建立同城双数据中心，每个数据中心部署多个跨容器集群的微服务，且两个数据中心的微服务均统一注册到Consul集群，每个容器集群还部署Ingress层，其中，每个数据中心的负载均衡都能够实现请求任务的分配和再分配，而微服务还能够在满足系统安全要求的同时，通过Ingress实现跨数据中心和跨集群的服务访问和调用，避免了服务之间出现调用异常、跨集群网络限制的问题，进而实现网络系统的高可用双活。

附图说明

图1是本发明实施例提供的一种基于微服务的同城双活系统的结构框图；

图2是本实施例提供的一种基于微服务的同城双活系统负载切换示意图；

图3是本实施例提供的一种容器集群单元的结构框图；

图4是本发明提供的一种负载均衡单元的结构框图；

图5是本实施例提供的一种负载均衡单元的结构框图；

图6是本实施例提供的一种微服务网关单元的结构框图；

图7是本实施例提供的一种微服务单元的结构框图；

图8是本实施例提供的一种微服务网关单元的结构框图。

具体实施方式

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

同城双活是指在同个城市部署两个数据中心，让两个数据中心同时承担用户的业务，此时，两个数据中心互为备份，并且进行实时备份，保证了当其中一边发生故障时，不至于造成业务无法处理的情况。而微服务架构是一种将单体程序作为一套小型服务开发方法，每种应用程序都在其自己的进程中运行，以轻量级机制进行通信，可以简单理解为将单个的服务系统拆成多个彼此分工合作的服务组件。

Consul是一个服务管理软件。支持多数据中心下分布式高可用，服务发现和配置共享。采用Raft算法，用来保证服务的高可用。相关技术将Consul运用至微服务同城双活方案，双数据中心共用Consul集群，这种网络系统架构在出现调用延迟问题、跨数据中心网络波动时，由于共用集群，可能会引发Consul集群的紊乱，从而引发某Consul节点疯狂地消息广播导致专线带宽急剧上升，服务之间的调用出现异常。

同时，随着企业、个体对网络安全的要求越来越高，网络系统的安全限制也相应加强，在一些服务端网络系统中，跨容器集群只允许开放特定的端口互通，在新增微服务时无法在两个数据中心同步为对应的容器集群开放对应的IP端口，存在跨集群的网络限制。

由此可见，相关技术的微服务同城双活系统仍然存在无法保证业务连续性的问题。针对上述问题，本申请发明人考虑将双数据中心的每个微服务集群统一注册为Consul集群，提供集群彼此独立互相通信的条件，并通过在每个集群外层添加Ingress虚拟节点，利用Ingress可以只暴露一个对应IP地址和端口的特性，在满足网络安全要求的前提下，实现跨数据中心和跨集群中对应微服务之间的服务访问，配合负载均衡进行任务的分配和调用。由此，使得在微服务单组件故障时，可以调用所在容器集群的其他微服务或利用Ingress调用跨容器集群对应的微服务；在数据中心大规模故障时，可以利用负载均衡调用另一个数据中心的微服务或利用Ingress调用跨数据中心对应的微服务，有效地提高了网络系统的高可用性和双活性能。

参照图1，图1是本发明实施例提供的一种基于微服务的同城双活系统的结构框图。如图1所示，所述系统具体包括：

通过专线网络连接的两个数据中心，每个数据中心各自包括：负载均衡单元301、微服务网关单元302、多个容器集群单元303，其中，每个容器集群单元303预先部署Ingress单元3032和多个对应的微服务单元3031；两个数据中心的每个微服务单元统一注册到Consul集群。

需要注意的是，为使结构框图易于理解，图1并未详细绘制数量冗余的部分结构，但是应当理解的是：两个数据中心的架构应一致，即，数据中心2中部署着与数据中心1相同或相似的单元。

同时，两个数据中心除基本架构以外也可以实现不同的部署，包括：根据特定的需求，针对服务调用原则、集群数量、微服务内容等服务参数进行非对称式的部署。例如，根据企业或个体用户不同的安全性要求，针对安全性设置不同的服务安全原则；或者，根据两个数据中心所在机房的条件，针对安全性原则和进行非对称式的部署。

参照图2，图2是本发明实施例提供的一种基于微服务的同城双活系统负载切换示意图。如图2所示，在本实施例中，在双数据中心系统中，负载均衡可以在例如网关健康检查不符合要求时，通过专线可以将任务请求(流量)转发至另一数据中心微服务网关，实现跨数据中心的一种负载切换。同时，在请求进入数据中心容器集群内部后，在同一个数据中心内，微服务能够对另一微服务进行调用，在微服务异常时，可以由上一级微服务利用Ingress将其转发至该数据中心其他容器集群的微服务，实现同数据中心跨容器集群的负载切换，也可以由上一级微服务利用Ingress将其转发至另一数据中心其他容器集群的微服务，实现跨数据中心跨容器集群的负载切换。

所述负载均衡单元301，用于将外部域名系统发送的请求转发至微服务网关单元。

如图1和图2所示，由于两个数据中心通过专线网络连接，每个数据中心的负载均衡都可以通过专线网络将任务请求转发至另一个数据中心的微服务网关。

所述微服务网关单元302，用于对所述请求进行鉴权、限流，并根据所述请求携带的URL，转发至URL指向的容器集群单元相对应的微服务单元。

其中，每个数据中心包含的微服务网关可以设置一个或多个，具体数量可根据该数据中心处理的流量决定。

同时，每个微服务网关可以用户的任务请求转发至URL地址指向的任意一个或多个容器集群，也可以根据URL请求参数中的服务名将请求转发至任意一个或多个微服务。

所述多个容器集群单元303，用于为所述请求提供相应的微服务单元。

具体地，在每个数据中心内存在多个并列关系的容器集群，每个容器集群部署的微服务相同，功能和作用也相同，微服务网关能够对所在数据中心每个容器集群内的微服务进行调用。

所述微服务单元3031通过服务名实现对所在容器集群单元内其他微服务单元的调用；所述微服务单元通过调用目标微服务单元所在的目标容器集群单元对应的Ingress单元，由该Ingress单元将所述请求转发至目标微服务单元，实现跨容器集群单元的服务访问。

所述Ingress单元3032为所在容器集群单元最外层的、由Ingress规则集合组成的虚拟节点。

参照图3，图3是本实施例提供的一种容器集群单元的结构框图。如图3所示，在每个容器集群内，每一个微服务都是单独的组件，彼此之间能够互相调用，每个微服务处理的任务类型、处理任务的能力也可能是不同的。

每个微服务都是一个独立的节点，在数据中心内部拥有独一无二的IP地址(和端口号)。而Ingress是一个虚拟的节点，以独立单元或者集群的形式提供端口服务，同样地，可以为Ingress分配虚拟IP(和端口号)。出于容器边界和安全原则的限制，每个微服务都可以调用该微服务所在容器集群的其他微服务，优选地，默认按路由就近的原则进行服务访问和调用。

由于所有微服务统一在Consul注册中心完成了注册，且两个数据中心通过专线网络实现了互联，而Ingress处于容器集群的最外层，则每个微服务也可以调用其他所有容器集群的Ingress节点。

如图3所示，Ingress处于容器集群单元的最外层，能实现对容器集群单元内任一微服务的调用。Ingress是管理外部网络访问容器集群中微服务的API对象，能够授权将请求转发至集群微服务，同时具备七层负载均衡的能力，Ingress节点会根据该微服务所转发的请求的属性，将请求转发到与该微服务相对应的目标微服务。

如图2所示，示例性地，若原本处理任务请求的是微服务B1，且将该请求发送至微服务B1的是微服务A1，在微服务B1出现异常时，微服务A1会将返回的请求发送至容器集群2的Ingress，Ingress节点会将请求发送至该Ingress所在容器集群(容器集群2)的微服务B2，由微服务B2执行该请求。其中，图2中的实线表达了在各个微服务的实例正常运行时，各个组件之间的部分调用关系；虚线则表示了在微服务发生故障时，微服务之间的部分调用关系。

参照图4，图4是本发明提供的一种负载均衡单元的结构框图。考虑到双数据中心并非镜像关系，因此两个数据中心的负载均衡的外部IP地址可以不同，在域名系统向服务系统发送请求时，会携带一个或多个外部IP地址，根据外部IP寻址至负载均衡，负载均衡再为请求分配对应微服务的内部IP地址。因此，如图4所示，在本实施例中，针对每个数据中心，所述负载均衡单元301包括：

负载均衡第一接收单元3011，用于在外部域名系统解析到两个数据中心的负载均衡单元的IP地址、并将用户的请求发送至任意一个数据中心的负载均衡单元后，由该数据中心的负载均衡单元接收所述请求；

负载均衡分配单元3012，用于将该请求携带的外部IP地址转换为该数据中心的内部IP地址；

负载均衡第一转发单元3013，用于将携带内部IP地址的请求转发至该数据中心的微服务网关单元。

其中，负载均衡的IP地址即外部IP地址。负载均衡对请求的内容进行解析，为请求分配对应的内部IP地址，并保留URL中的原始请求参数，内部IP地址可以包括微服务的IP地址和端口号，具体根据数据中心内部地址的划分方式决定。

所述负载均衡分配单元3012，可以根据容器集群中已在运行或已在等待队列中的负载情况，对任务请求预计的负载进行平衡，分摊到多个容器集群、微服务运行，协同完成工作任务，提高网络系统的业务连续性和高可用性。由于负载均衡技术目前已较为成熟，且种类繁多，在此不再赘述。

参照图5，图5是本实施例提供的一种负载均衡单元的结构框图。本发明除了根据上述单元实现所在数据中心内部微服务的负载分配，还可以在该数据中心内部大规模故障时，根据网关返回的请求，将请求通过专线网络转发至另一数据中心的微服务网关。因此，本实施例还提供能够接收微服务网关返回的请求的单元，以及，能够将该请求转发至另一数据中心的单元，具体地，如图5所示，在本实施例中，针对每个数据中心，所述负载均衡单元301包括：

负载均衡第二接收单元3014，用于在微服务网关单元检测到该数据中心内与请求相对应的微服务单元的实例运行状况不大于预设健康阈值、并返回所述请求时，接收微服务网关单元返回的请求；

负载均衡第二转发单元3015，用于将微服务网关单元返回的请求通过专线网络转发至另一个数据中心的微服务网关单元。

其中，所述预设健康阈值可以根据系统的实际运行状况进行预先设置，具体可以是该数据中心内该请求可用的微服务数量，也可以是该数据中心内微服务处理的平均等待队列长度。

例如，在服务端压力较小的时间段，系统理应能够实时处理所述请求，则某一个任务请求来说，需要超过5个对应的微服务才能够正常满足处理需求，则可以将健康阈值预设为<该请求可用的微服务数量，5>，进而能够在一方数据中心大规模故障时，将该请求交由另一数据中心执行，以满足任务的处理需求，并尽快将结果返回给用户。

又例如，在服务端压力较大的时间段，两个数据中心的微服务可能均处理满负荷运行的状态，任务请求处理等待队列中，则此时有的微服务上，还需等待处理的任务数量为4个，有的是2个，该数据中心内整体平均等待队列长度是3，则可以将健康阈值预设为<平均等待队列长度，3>，以在该数据中心负载过高，无法按时完成任务时，将该请求交由另一数据中心执行，以实现任务的处理需求，并尽快将结果返回给用户。

参照图6，图6是本实施例提供的一种微服务网关单元的结构框图。在本实施例中，由微服务网关来执行健康检查的功能，因此，如图6所示，针对每个数据中心，所述微服务网关单元302包括：

微服务网关检查单元3021，用于执行健康检查，检查该数据中心内与请求相对应的微服务单元的实例运行状况是否大于预设健康阈值；若是，将所述请求转发至微服务网关第一转发单元；若否，将所述请求转发至微服务网关返回单元；

微服务网关第一转发单元3022，用于经过鉴权、限流后，将从负载均衡单元接收的请求转发到该数据中心内与请求相对应的微服务单元；

微服务网关返回单元3023，用于将所述请求返回至该数据中心的负载均衡单元。

其中，由于同一数据中心内的所有容器集群均为并列关系，微服务网关能够具备将请求直接转发至任意容器集群的能力，因此，在本实施例中，微服务网关根据请求携带的内部IP地址(和端口号)，默认按路由就近的原则，将请求转发到该数据中心内与请求相对应的微服务单元。

通过本实施例，可以在请求未进入数据中心内部时，若检查到大规模故障，由负载均衡和微服务网关的组合实现跨数据中心之间负载的切换。

参照图7，图7是本实施例提供的一种微服务单元的结构框图。由于同集群内各个微服务之间是协作的关系，各自负责请求对应的一部分工作，因此，往往需要调用一个容器集群内的多个微服务，才能够完成任务，考虑到网关同时将请求分发至同集群内的各个微服务，存在任务重复、整体逻辑距离过长、网关压力过大等弊端，本申请中由微服务就近调用同集群内的其他微服务。因此，如图7所示，在本实施例中，针对每个数据中心，所述微服务单元3031包括：

微服务第一调用单元30311，用于默认按路由就近的原则访问同集群内的微服务单元，通过服务名实现对下一级微服务单元的调用。

在本实施例中，将调用和被调用的两者组件，分别称为上级和下级。

此外，微服务异常时，需要能够将请求返回至上一级组件，重新调用其他微服务进行处理，因此，如图7所示，在一种实施方式中，针对每个数据中心，所述微服务单元还包括：

微服务第一返回单元30312，用于当该微服务单元异常时，若该微服务单元是直接被微服务网关单元所调用，将请求返回该微服务网关单元。

在大多数时候，网络系统的故障都是单组件故障，即，某一个微服务出现异常，在这种情况下，如果该异常微服务是直接被网关调用的，可以直接将微服务返回网关，由网关将请求发送至该数据中心的其他容器集群中对应的微服务处理。

参照图8，图8是本实施例提供的一种微服务网关单元的结构框图。考虑到该异常微服务所在容器集群的其他微服务，有可能也能对该请求进行处理，因此，微服务网关可以将返回的请求转发至同容器集群的其他微服务进行处理，相应地，如图8所示，在本实施例中，针对每个数据中心，所述微服务网关单元302包括：

微服务网关第二转发单元3024，用于将异常微服务单元返回的请求转发至该容器集群单元内的其他微服务单元，包括：默认按路由就近的原则，按照服务名将请求转发至该容器集群单元内、除异常微服务单元以外的其他微服务单元。

同容器集群的其他微服务如果无法处理该请求，则微服务网关可以将返回的请求转发至该数据中心的其他容器集群的微服务进行处理，如图8所示，结合以上实施例，在一种实施方式中，针对每个数据中心，所述微服务网关单元302还包括：

微服务网关第三转发单元3025，用于将异常微服务单元返回的请求转发至该异常微服务单元所在的容器集群单元以外的其他容器集群单元，包括：默认按路由就近的原则，按照服务名将请求转发至该数据中心的其他容器集群单元、与异常微服务单元对应的微服务单元。

通过本实施例，使得同一数据中心内的单个或少数几个微服务异常时，能够通过微服务网关，访问同容器集群和/或同数据中心跨容器集群对应的微服务，实现同容器集群和同数据中心跨容器集群的负载切换。

由于同一容器集群中的微服务数量众多，在大多数场景下，调用微服务的更多是其他微服务，而非网关。因此，异常微服务在更多情况下，将请求返回到的上一级是微服务，基于此，本发明提供了一种微服务单元，用于在微服务异常时将接收的请求返回上一级微服务，具体地，如图7所示，所述微服务单元3031包括：

微服务第二返回单元30313，用于当微服务单元异常时，若该微服务单元是直接被上一级微服务单元所调用，则将请求返回上一级微服务单元。

相应地，由于上一级微服务正常情况下无法直接替代异常微服务的功能对请求进行处理，因此，微服务也需要具备转发因微服务异常返回的请求的能力。

具体地，异常微服务所在容器集群的其他微服务，有可能也能对该请求进行处理，如图7所示，结合上述实施例，在一种实施方式中，所述微服务单元包括：

微服务第一转发单元30314，用于将异常微服务单元返回的请求转发至该容器集群单元内的其他微服务单元，包括：默认按路由就近的原则，按照服务名将请求转发至该容器集群单元内、除异常微服务单元以外的其他微服务单元。

同容器集群的其他微服务如果无法处理该请求，则上一级微服务可以利用Ingress将返回的请求转发至该数据中心的其他容器集群的微服务进行处理，因此，如图7所示，在一种实施方式中，所述微服务单元3031还包括：

微服务第二转发单元30315，用于将异常微服务单元返回的请求转发至该数据中心的、其他容器集群单元内与该异常微服务单元相对应的目标微服务单元，包括：利用目标容器集群单元对应的Ingress单元对外暴露的节点IP地址和端口号，将所述请求转发至该数据中心内、其他容器集群单元内与该异常微服务单元相对应的微服务单元。

通过本实施例，使得同一数据中心内的单个或少数几个微服务异常时，能够通过Ingress转发请求，通过Ingress暴露的IP和端口，访问同数据中心跨容器集群对应的微服务，实现跨容器集群的负载切换。

除此之外，在一些其他类型的数据中心大规模故障场景下，还需要由微服务将请求转发至另一个数据中心，完成跨数据中心容器集群中间的服务访问和调用。例如，在经过负载均衡和微服务网关时，数据中心内部微服务的实例运行正常，则微服务网关会将请求交由该数据中心处理，但是，请求在处理的过程中，数据中心同样可能存在大规模故障风险，同数据中心的容器集群无法满足任务的处理需求，为避免任务中断和丢失，需要由微服务将请求发送至另一数据中心容器集群内对应的微服务。

有鉴于此，如图7所示，结合上述实施例，本实施例还提供了一种微服务单元，所述微服务单元3031包括：

微服务第三转发单元30316，用于将异常微服务单元返回的请求转发至另一数据中心的容器集群单元内与该异常微服务单元相对应的目标微服务单元，包括：利用目标容器集群单元对应的Ingress单元对外暴露的节点IP地址和端口号，将所述请求转发至另一数据中心的容器集群单元内与该异常微服务单元相对应的微服务单元。

通过本实施例，某一数据中心内的微服务处理任务请求大规模故障异常时，能够通过Ingress转发请求，通过Ingress暴露的IP和端口，访问跨数据中心容器集群对应的微服务，实现跨数据中心跨容器集群的负载切换。

本发明提供的基于微服务的同城双活系统和方法，以微服务统一注册Consul集群和Ingress调用为基础，在满足安全需求的前提下，解决了跨容器集群服务互访的问题，实现了多层负载切换方法的配合，以此提高系统的高可用性和双活性能。

基于同一发明构思，本发明实施例还提供了一种基于微服务的同城双活方法，应用于上述任一项所述的系统，所述方法包括：

由负载均衡将域名系统发送的请求转发至微服务网关；

由微服务网关对所述请求进行鉴权、限流，并根据所述请求携带的URL，转发至URL指向的容器集群相对应的微服务；

由容器集群为所述请求提供相应的微服务；所述微服务通过服务名实现对所在容器集群内其他微服务的调用；所述微服务通过调用目标微服务所在的目标容器集群对应的Ingress，由该Ingress将所述请求转发至目标微服务，实现跨容器集群的服务访问；所述Ingress是所在容器集群最外层的、由Ingress规则集合组成的虚拟节点。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

本领域内的技术人员应明白，本发明实施例的实施例可提供为方法、装置、或计算机程序产品。因此，本发明实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明实施例是参照根据本发明实施例的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本发明实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明实施例范围的所有变更和修改。

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

以上对本发明所提供的一种基于微服务的同城双活系统和一种基于微服务的同城双活方法，进行了详细介绍，本实施例中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims (10)

1.一种基于微服务的同城双活系统，其特征在于，所述系统包括通过专线网络连接的两个数据中心，每个数据中心各自包括：负载均衡单元、微服务网关单元、多个容器集群单元，其中，每个容器集群单元预先部署Ingress单元和多个对应的微服务单元；两个数据中心的每个微服务单元统一注册到Consul集群；

所述负载均衡单元，用于将外部域名系统发送的请求转发至微服务网关单元；

所述微服务网关单元，用于对所述请求进行鉴权、限流，并根据所述请求携带的URL，转发至URL指向的容器集群单元相对应的微服务单元；

所述多个容器集群单元，用于为所述请求提供相应的微服务单元；

所述微服务单元通过服务名实现对所在容器集群单元内其他微服务单元的调用；所述微服务单元通过调用目标微服务单元所在的目标容器集群单元对应的Ingress单元，由该Ingress单元将所述请求转发至目标微服务单元，实现跨容器集群单元的服务访问；

所述Ingress单元是所在容器集群单元最外层的、由Ingress规则集合组成的虚拟节点。

2.根据权利要求1所述的系统，其特征在于，针对每个数据中心，所述负载均衡单元包括：

负载均衡第一接收单元，用于在外部域名系统解析到两个数据中心的负载均衡单元的IP地址、并将用户的请求发送至任意一个数据中心的负载均衡单元后，由该数据中心的负载均衡单元接收所述请求；

负载均衡分配单元，用于将该请求携带的外部IP地址转换为该数据中心的内部IP地址；

负载均衡第一转发单元，用于将携带内部IP地址的请求转发至该数据中心的微服务网关单元。

3.根据权利要求1所述的系统，其特征在于，针对每个数据中心，所述负载均衡单元包括：

负载均衡第二接收单元，用于在微服务网关单元检测到该数据中心内与请求相对应的微服务单元的实例运行状况不大于预设健康阈值、并返回所述请求时，接收微服务网关单元返回的请求；

负载均衡第二转发单元，用于将微服务网关单元返回的请求通过专线网络转发至另一个数据中心的微服务网关单元。

4.根据权利要求1所述的系统，其特征在于，针对每个数据中心，所述微服务网关单元包括：

微服务网关检查单元，用于执行健康检查，检查该数据中心内与请求相对应的微服务单元的实例运行状况是否大于预设健康阈值；若是，将所述请求转发至微服务网关第一转发单元；若否，将所述请求转发至微服务网关返回单元；

微服务网关第一转发单元，用于经过鉴权、限流后，将从负载均衡单元接收的请求转发到该数据中心内与请求相对应的微服务单元；

微服务网关返回单元，用于将所述请求返回至该数据中心的负载均衡单元。

5.根据权利要求1所述的系统，其特征在于，针对每个数据中心，所述微服务单元包括：

微服务第一调用单元，用于默认按路由就近的原则访问同集群内的微服务单元，通过服务名实现对下一级微服务单元的调用；

微服务第一返回单元，用于当微服务单元异常时，若该微服务单元是直接被微服务网关单元所调用，将请求返回该微服务网关单元。

6.根据权利要求5所述的系统，其特征在于，针对每个数据中心，所述微服务网关单元包括：

微服务网关第二转发单元，用于将异常微服务单元返回的请求转发至该容器集群单元内的其他微服务单元，包括：默认按路由就近的原则，按照服务名将请求转发至该容器集群单元内、除异常微服务单元以外的其他微服务单元；

微服务网关第三转发单元，用于将异常微服务单元返回的请求转发至该异常微服务单元所在的容器集群单元以外的其他容器集群单元，包括：默认按路由就近的原则，按照服务名将请求转发至其他容器集群单元内、与异常微服务单元对应的微服务单元。

7.根据权利要求1所述的系统，其特征在于，所述微服务单元包括：

微服务第二返回单元，用于当微服务单元异常时，若该微服务单元是直接被上一级微服务单元所调用，则将请求返回上一级微服务单元。

8.根据权利要求7所述的系统，其特征在于，所述微服务单元还包括：

微服务第一转发单元，用于将异常微服务单元返回的请求转发至该容器集群单元内的其他微服务单元，包括：默认按路由就近的原则，按照服务名将请求转发至该容器集群单元内、除异常微服务单元以外的其他微服务单元；

微服务第二转发单元，用于将异常微服务单元返回的请求转发至该数据中心的、其他容器集群单元内与该异常微服务单元相对应的目标微服务单元，包括：利用目标容器集群单元对应的Ingress单元对外暴露的节点IP地址和端口号，将所述请求转发至该数据中心内、其他容器集群单元内与该异常微服务单元相对应的微服务单元。

9.根据权利要求1-8任一项所述的系统，其特征在于，所述微服务单元包括：

微服务第三转发单元，用于将异常微服务单元返回的请求转发至另一数据中心的容器集群单元内与该异常微服务单元相对应的目标微服务单元，包括：利用目标容器集群单元对应的Ingress单元对外暴露的节点IP地址和端口号，将所述请求转发至另一数据中心的容器集群单元内与该异常微服务单元相对应的微服务单元。

10.一种基于微服务的同城双活方法，其特征在于，应用于如权利要求1-9任一项所述的系统，所述方法包括：

由负载均衡将域名系统发送的请求转发至微服务网关；

由微服务网关对所述请求进行鉴权、限流，并根据所述请求携带的URL，转发至URL指向的容器集群相对应的微服务；

由容器集群为所述请求提供相应的微服务；所述微服务通过服务名实现对所在容器集群内其他微服务的调用；所述微服务通过调用目标微服务所在的目标容器集群对应的Ingress，由该Ingress将所述请求转发至目标微服务，实现跨容器集群的服务访问；所述Ingress是所在容器集群最外层的、由Ingress规则集合组成的虚拟节点。

Images