CN109413209A - 一种基于双队列及注册中心的动态负载均衡方法和系统 - Google Patents

Abstract

本发明公开了一种基于双队列及注册中心的动态负载均衡方法和系统，保证当有可用服务的时候一定能够拿到可用的服务地址。其技术方案为：本发明通过引入可用队列和不可用队列的双队列、注册中心和定时机制保证了返回消费端地址的可用性。

Description

一种基于双队列及注册中心的动态负载均衡方法和系统

技术领域

本发明涉及动态负载均衡技术，具体涉及基于双队列和注册中心的架构实现的对动态负载均衡进行改良的方法和系统。

背景技术

在传统的IT行业软件大多都是各种独立系统的堆砌，这些系统的问题总结来说就是扩展性差、可靠性不高、维护成本高。到后面引入了SOA(企业数据总线进行服务间通信)服务化，但是，由于SOA早期均使用了总线模式，这种总线模式是与某种技术栈强绑定的，比如：J2EE。这会导致很多企业的遗留系统很难对接，切换时间太长，成本太高，新系统稳定性的收敛也需要一些时间。最终SOA看起来很美，但却成为了企业级奢侈品，中小公司都望而生畏。

微服务的关键其实不仅仅是微服务本身，而是系统要提供一套基础的架构，这种架构使得微服务可以独立的部署、运行、升级，不仅如此，这个系统架构还让微服务与微服务之间在结构上“松耦合”，而在功能上则表现为一个统一的整体。这种所谓的“统一的整体”表现出来的是统一风格的界面，统一的权限管理，统一的安全策略，统一的上线过程，统一的日志和审计方法，统一的调度方式，和统一的访问入口等等。

微服务的目的是有效的拆分应用，实现敏捷开发和部署。

微服务提倡的理念团队间是inter-operate,not integrate。inter-operate是定义好系统的边界和接口，在一个团队内全栈，让团队自治，原因就是因为如果团队按照这样的方式组建，将沟通的成本维持在系统内部，每个子系统就会更加内聚，彼此的依赖耦合能变弱，跨系统的沟通成本也就能降低。

在微服务架构中，一般每一个服务都是有多个拷贝，来做负载均衡。一个服务随时可能下线，也可能应对临时访问压力增加新的服务节点。服务之间如何相互感知，服务如何管理，这就是使用注册中心服务发现的问题了。一般有两类做法，也各有优缺点。基本都是通过zookeeper(分布式，开源的应用程序协调服务)等类似技术做服务注册信息的分布式管理。当服务上线时，服务提供者将自己的服务信息注册到zookeeper或类似框架，并通过心跳维持长链接，实时更新链接信息。服务调用者通过zookeeper寻址，根据可定制算法找到一个服务，还可以将服务信息缓存在本地以提高性能。当服务下线时，zookeeper会发通知给服务客户端(消费端)。

在客户端(消费端)处理的方案的优点是架构简单，扩展灵活，只对服务注册器依赖。但其缺点是客户端(消费端)要维护所有调用服务的地址，有技术难度，一般大公司都有成熟的内部框架支持，比如Dubbo(阿里巴巴开源的一个服务框架)。

在服务端处理的方案的优点是简单，所有服务对于前台调用方透明，一般在小公司在云服务上部署的应用采用的比较多。

随着业务系统越来越复杂，微服务变的越来越普遍，然而其基础组件只能满足大部分通用的功能，有些细分领域并不能够满足。

市面上存在服务注册中心的需求，解耦消费端和服务端，也是微服务体系的基础组件。

基于zookeeper作为服务注册中心，我们在客户端(消费端)封装了框架，可以方便的获取远端服务的地址，业务开发人员不用关心这些。开源的客户端(消费端)算法是当某个服务节点宕机需要要过十多秒才能通知到客户端(消费端)，这个时候消费端可能拿到不可用的服务地址，导致整个链路调用出现问题。拿到不可用的服务地址会导致调用失败，这对于某些场景是不可接受的。

发明内容

以下给出一个或多个方面的简要概述以提供对这些方面的基本理解。此概述不是所有构想到的方面的详尽综览，并且既非旨在指认出所有方面的关键性或决定性要素亦非试图界定任何或所有方面的范围。其唯一的目的是要以简化形式给出一个或多个方面的一些概念以为稍后给出的更加详细的描述之序。

本发明的目的在于解决上述问题，提供了一种基于双队列及注册中心的动态负载均衡方法和系统，保证当有可用服务的时候一定能够拿到可用的服务地址。

本发明的技术方案为：本发明揭示了一种基于双队列及注册中心的动态负载均衡方法，包括：

消费端从自身存储的可用队列中，通过配置的负载均衡算法查找可用的服务地址；

如果查找到可用的服务地址则获取服务对应的IP地址，如果没有查找到可用的服务地址则返回地址不可用；

在获取到服务对应的IP地址后，根据获取到的IP地址发起连接请求进行访问，如果连接异常则将获取到的IP地址从可用队列移除并放入到不可用队列，返回从消费端的可用队列中通过负载均衡算法查找可用的服务地址的步骤中继续处理，如果连接正常则返回连接正常的IP地址。

根据本发明的基于双队列及注册中心的动态负载均衡方法的一实施例，配置的负载均衡算法包括但不限于随机、随机检查、轮询权重、根据当前负载来分发、哈希算法在内的多种模式。

根据本发明的基于双队列及注册中心的动态负载均衡方法的一实施例，配置的负载均衡算法是可扩展的。

根据本发明的基于双队列及注册中心的动态负载均衡方法的一实施例，可用队列和不可用队列均存储在消费端上，消费端启动后通过可用队列监听注册中心以获取注册中心上的所有地址。

根据本发明的基于双队列及注册中心的动态负载均衡方法的一实施例，方法还包括在消费端上运行一个检查线程以用于检查不可用队列中的地址是否可用，检查线程执行以下的步骤：

检查线程每隔一定周期轮询不可用队列中的地址，针对每一个地址发送心跳请求，如果不可用队列中的一个地址变成可用则将其放到可用队列中，如果还不可用则待监听到zookeeper上面有节点消失的消息后再将其删除。

本发明还揭示了一种基于双队列及注册中心的动态负载均衡系统，包括消费端、注册中心以及一运行于消费端的计算机程序，消费端上存储有可用队列和不可用队列，所述计算机程序运行后执行以下的步骤：

消费端从自身存储的可用队列中，通过配置的负载均衡算法查找可用的服务地址；

如果查找到可用的服务地址则获取服务对应的IP地址，如果没有查找到可用的服务地址则返回地址不可用；

在获取到服务对应的IP地址后，根据获取到的IP地址发起连接请求进行访问，如果连接异常则将获取到的IP地址从可用队列移除并放入到不可用队列，返回从消费端的可用队列中通过负载均衡算法查找可用的服务地址的步骤中继续处理，如果连接正常则返回连接正常的IP地址。

根据本发明的基于双队列及注册中心的动态负载均衡系统的一实施例，配置的负载均衡算法包括但不限于随机、随机检查、轮询权重、根据当前负载来分发、哈希算法在内的多种模式。

根据本发明的基于双队列及注册中心的动态负载均衡系统的一实施例，配置的负载均衡算法是可扩展的。

根据本发明的基于双队列及注册中心的动态负载均衡系统的一实施例，消费端配置为启动后通过可用队列监听注册中心以获取注册中心上的所有地址。

根据本发明的基于双队列及注册中心的动态负载均衡系统的一实施例，系统还包括在消费端上运行的一检查线程以用于检查不可用队列中的地址是否可用，检查线程运行后执行以下的步骤：

检查线程每隔一定周期轮询不可用队列中的地址，针对每一个地址发送心跳请求，如果不可用队列中的一个地址变成可用则将其放到可用队列中，如果还不可用则待监听到zookeeper上面有节点消失的消息后再将其删除。

本发明对比现有技术有如下的有益效果：本发明的方法通过在消费端设计双队列以及在系统中增加注册中心，在此基础上实现动态负载均衡。本发明的方法应用在金融服务领域，而金融服务领域对服务的可用性有严格的要求，尤其是对于应该是可用的状态而返回不一致的这种情况有非常严格的要求。例如，当出现网络瞬断，而zookeeper由于有固定超时时间且一般不会太短(出于性能考虑，一般为3秒以上)是感知不到这种异常的，这种情况下就会出现zookeeper认为节点是好的，但是应用请求失败的情况。本发明的方法则能够以更快的频率(可以是半秒)对这种由于网络瞬断引起的问题进行纠错。相较于现有技术，本发明解决了开源软件存在的可用性问题(某些时刻拿到的服务地址是不可用的)，极大的降低了产生这种可用性问题的可能性，通过引入不可用队列和定时机制保证了返回消费端地址的可用性。使用本发明的方案后，用户几乎无需对现有程序进行修改，只需要在spring(一个轻量级开源的java开发框架)中配置registry(注册)相关的bean(spring实例化的对象)，然后在配置中心加上本机IP和端口，从而降低了成本。

附图说明

在结合以下附图阅读本公开的实施例的详细描述之后，能够更好地理解本发明的上述特征和优点。在附图中，各组件不一定是按比例绘制，并且具有类似的相关特性或特征的组件可能具有相同或相近的附图标记。

图1示出了本发明的基于双队列及注册中心的动态负载均衡方法的一实施例的流程图。

图2示出了本发明的消费端上的检查线程的流程图。

图3示出了本发明的基于双队列及注册中心的动态负载均衡系统的一实施的原理图。

具体实施方式

以下结合附图和具体实施例对本发明作详细描述。注意，以下结合附图和具体实施例描述的诸方面仅是示例性的，而不应被理解为对本发明的保护范围进行任何限制。

图1示出了本发明的基于双队列及注册中心的动态负载均衡方法的一实施例的消费端的处理流程。

步骤S11：消费端从自身的内存的可用队列中，通过配置的负载均衡算法查找可用的服务地址。如果查找到可用的服务地址则进行步骤S12，如果没有查找到可用的服务地址则进行步骤S13。

开源的注册中心消费端只维护了可用队列，刷新会有一段时间的延迟，在某些情况下zookeeper客户端(消费端)心跳还存在但是服务已经不可用，它的地址会一直存在，就会造成消费者拿到不可用地址。

当在可用队列查找可用地址时，负载均衡算法提供多种，包括随机、随机检查、轮询权重、根据当前负载来分发等多种模式，根据用户在配置文件中的配置来选择，任何负载均衡策略都可以使用，具体如何做负载均衡并不是本发明的发明点。本发明在负载均衡算法的实现上提供了一种很好的扩展性，如果需要对某一种负载均衡算法修改的话只需要修改那个算法的实现类就可以，如果有一种新的负载均衡算法需要添加，对原来的代码不用修改，新加一个实现类就可以，很好的支持了开闭原则。

使用负载均衡算法的效果是可以保证高可用，当服务端注册了多个地址的时候，消费端可以动态的发现，也实现了消费端和服务端解耦。现有的负载均衡算法有：随机算法、权重轮询算法，哈希算法。

如图2和图3所示，消费端上存储了可用队列和不可用队列，消费端启动后通过可用队列监听注册中心，即通过可用队列获取注册中心上的所有地址。

此外，消费端上还执行一个检查线程以用于检查不可用队列中的地址是否可用，与图1所示的方法步骤是并行的。消费端的检查线程每隔1秒(可配置)轮询不可用队列中的地址，然后针对每一个地址发送心跳请求，如果地址变成可用则放到可用队列中，如果还不可用则什么都不做，当监听到zookeeper上面有节点消失的消息后再把它删除。

步骤S12：获取服务对应的IP地址。然后执行步骤S14。

步骤S13：返回地址不可用(即返回空值，null)。

步骤S14：根据步骤S12获取到的IP地址发起连接请求，进行访问。如果连接异常则执行步骤S15，如果连接正常则执行步骤S16。

步骤S15：将获取到的IP地址从可用队列移除，放入到不可用队列，然后执行步骤S11中继续从可用队列中通过负载均衡算法查找可用的服务地址。

步骤S16：返回连接正常的IP地址。

图3示出了本发明的基于双队列及注册中心的动态负载均衡系统的一实施的原理。请参见图3，本实施例的系统包括：消费端、注册中心以及一运行于消费端的计算机程序，消费端上存储有可用队列和不可用队列。

计算机程序运行后执行如图1所示的各个步骤，在此不再赘述。

此外，消费端配置为启动后通过可用队列监听注册中心以获取注册中心上的所有地址。

系统还包括在消费端上运行的一检查线程以用于检查不可用队列中的地址是否可用，检查线程运行后执行以下的如图2所示的步骤：检查线程每隔一定周期轮询不可用队列中的地址，针对每一个地址发送心跳请求，如果不可用队列中的一个地址变成可用则将其放到可用队列中，如果还不可用则待监听到zookeeper上面有节点消失的消息后再将其删除。

尽管为使解释简单化将上述方法图示并描述为一系列动作，但是应理解并领会，这些方法不受动作的次序所限，因为根据一个或多个实施例，一些动作可按不同次序发生和/或与来自本文中图示和描述或本文中未图示和描述但本领域技术人员可以理解的其他动作并发地发生。

本领域技术人员将进一步领会，结合本文中所公开的实施例来描述的各种解说性逻辑板块、模块、电路、和算法步骤可实现为电子硬件、计算机软件、或这两者的组合。为清楚地解说硬件与软件的这一可互换性，各种解说性组件、框、模块、电路、和步骤在上面是以其功能性的形式作一般化描述的。此类功能性是被实现为硬件还是软件取决于具体应用和施加于整体系统的设计约束。技术人员对于每种特定应用可用不同的方式来实现所描述的功能性，但这样的实现决策不应被解读成导致脱离了本发明的范围。

结合本文所公开的实施例描述的各种解说性逻辑板块、模块、和电路可用通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或其它可编程逻辑器件、分立的门或晶体管逻辑、分立的硬件组件、或其设计成执行本文所描述功能的任何组合来实现或执行。通用处理器可以是微处理器，但在替换方案中，该处理器可以是任何常规的处理器、控制器、微控制器、或状态机。处理器还可以被实现为计算设备的组合，例如DSP与微处理器的组合、多个微处理器、与DSP核心协作的一个或多个微处理器、或任何其他此类配置。

结合本文中公开的实施例描述的方法或算法的步骤可直接在硬件中、在由处理器执行的软件模块中、或在这两者的组合中体现。软件模块可驻留在RAM存储器、闪存、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、可移动盘、CD-ROM、或本领域中所知的任何其他形式的存储介质中。示例性存储介质耦合到处理器以使得该处理器能从/向该存储介质读取和写入信息。在替换方案中，存储介质可以被整合到处理器。处理器和存储介质可驻留在ASIC中。ASIC可驻留在用户终端中。在替换方案中，处理器和存储介质可作为分立组件驻留在用户终端中。

在一个或多个示例性实施例中，所描述的功能可在硬件、软件、固件或其任何组合中实现。如果在软件中实现为计算机程序产品，则各功能可以作为一条或更多条指令或代码存储在计算机可读介质上或藉其进行传送。计算机可读介质包括计算机存储介质和通信介质两者，其包括促成计算机程序从一地向另一地转移的任何介质。存储介质可以是能被计算机访问的任何可用介质。作为示例而非限定，这样的计算机可读介质可包括RAM、ROM、EEPROM、CD-ROM或其它光盘存储、磁盘存储或其它磁存储设备、或能被用来携带或存储指令或数据结构形式的合意程序代码且能被计算机访问的任何其它介质。任何连接也被正当地称为计算机可读介质。例如，如果软件是使用同轴电缆、光纤电缆、双绞线、数字订户线(DSL)、或诸如红外、无线电、以及微波之类的无线技术从web网站、服务器、或其它远程源传送而来，则该同轴电缆、光纤电缆、双绞线、DSL、或诸如红外、无线电、以及微波之类的无线技术就被包括在介质的定义之中。如本文中所使用的盘(disk)和碟(disc)包括压缩碟(CD)、激光碟、光碟、数字多用碟(DVD)、软盘和蓝光碟，其中盘(disk)往往以磁的方式再现数据，而碟(disc)用激光以光学方式再现数据。上述的组合也应被包括在计算机可读介质的范围内。

提供对本公开的先前描述是为使得本领域任何技术人员皆能够制作或使用本公开。对本公开的各种修改对本领域技术人员来说都将是显而易见的，且本文中所定义的普适原理可被应用到其他变体而不会脱离本公开的精神或范围。由此，本公开并非旨在被限定于本文中所描述的示例和设计，而是应被授予与本文中所公开的原理和新颖性特征相一致的最广范围。

Claims (10)

1.一种基于双队列及注册中心的动态负载均衡方法，其特征在于，包括：

消费端从自身存储的可用队列中，通过配置的负载均衡算法查找可用的服务地址；

如果查找到可用的服务地址则获取服务对应的IP地址，如果没有查找到可用的服务地址则返回地址不可用；

在获取到服务对应的IP地址后，根据获取到的IP地址发起连接请求进行访问，如果连接异常则将获取到的IP地址从可用队列移除并放入到不可用队列，返回从消费端的可用队列中通过负载均衡算法查找可用的服务地址的步骤中继续处理，如果连接正常则返回连接正常的IP地址。

2.根据权利要求1所述的基于双队列及注册中心的动态负载均衡方法，其特征在于，配置的负载均衡算法包括但不限于随机、随机检查、轮询权重、根据当前负载来分发、哈希算法在内的多种模式。

3.根据权利要求1所述的基于双队列及注册中心的动态负载均衡方法，其特征在于，配置的负载均衡算法是可扩展的。

4.根据权利要求1所述的基于双队列及注册中心的动态负载均衡方法，其特征在于，可用队列和不可用队列均存储在消费端上，消费端启动后通过可用队列监听注册中心以获取注册中心上的所有地址。

5.根据权利要求1所述的基于双队列及注册中心的动态负载均衡方法，其特征在于，方法还包括在消费端上运行一个检查线程以用于检查不可用队列中的地址是否可用，检查线程执行以下的步骤：

检查线程每隔一定周期轮询不可用队列中的地址，针对每一个地址发送心跳请求，如果不可用队列中的一个地址变成可用则将其放到可用队列中，如果还不可用则待监听到zookeeper上面有节点消失的消息后再将其删除。

6.一种基于双队列及注册中心的动态负载均衡系统，其特征在于，包括消费端、注册中心以及一运行于消费端的计算机程序，消费端上存储有可用队列和不可用队列，所述计算机程序运行后执行以下的步骤：

消费端从自身存储的可用队列中，通过配置的负载均衡算法查找可用的服务地址；

如果查找到可用的服务地址则获取服务对应的IP地址，如果没有查找到可用的服务地址则返回地址不可用；

在获取到服务对应的IP地址后，根据获取到的IP地址发起连接请求进行访问，如果连接异常则将获取到的IP地址从可用队列移除并放入到不可用队列，返回从消费端的可用队列中通过负载均衡算法查找可用的服务地址的步骤中继续处理，如果连接正常则返回连接正常的IP地址。

7.根据权利要求6所述的基于双队列及注册中心的动态负载均衡系统，其特征在于，配置的负载均衡算法包括但不限于随机、随机检查、轮询权重、根据当前负载来分发、哈希算法在内的多种模式。

8.根据权利要求6所述的基于双队列及注册中心的动态负载均衡系统，其特征在于，配置的负载均衡算法是可扩展的。

9.根据权利要求6所述的基于双队列及注册中心的动态负载均衡系统，其特征在于，消费端配置为启动后通过可用队列监听注册中心以获取注册中心上的所有地址。

10.根据权利要求6所述的基于双队列及注册中心的动态负载均衡系统，其特征在于，系统还包括在消费端上运行的一检查线程以用于检查不可用队列中的地址是否可用，检查线程运行后执行以下的步骤：

检查线程每隔一定周期轮询不可用队列中的地址，针对每一个地址发送心跳请求，如果不可用队列中的一个地址变成可用则将其放到可用队列中，如果还不可用则待监听到zookeeper上面有节点消失的消息后再将其删除。