CN110187972B - 一种基于api的软负载均衡实现方案 - Google Patents

Abstract

本发明提供了一种基于API的软负载均衡实现方案，该方案主要包括通讯和探测两个模块，作为整体嵌入到客户端中。总体上，客户端通过调用API的同步或异步接口来发起请求并接收响应，API与集群服务端之间采用TCP同步或异步短连接的通信模式。API能够定时探测集群服务端中各节点的存活状态并获取集群IP配置及其负载均衡策略。其优点表现在：无需硬件设备支持，有效降低成本；支持同步、异步通讯模式，通讯模块集成在API中，对客户端透明；支持负载均衡，满足个性化负载因子的负载要求；实现扩展或收缩客户端无感知，满足弹性扩展收缩功能。

Description

一种基于API的软负载均衡实现方案

技术领域

本发明涉及负载均衡技术领域，尤其是涉及一种基于API的软负载均衡实现方案。

背景技术

负载均衡是集群系统中非常重要的一个环节，通过负载均衡将请求派发到网络中的若干节点上进行处理，确保集群系统的高可用性。虽然如F5等硬件设备可很好的解决负载及扩展问题，但费用昂贵，并且F5自身存在单点隐患。而软负载以其低廉的成本、便捷的功能开发而深受用户青睐。

目前实现软负载的模式多种多样，既有开源框架的产品，如基于注册中心的ZOOKEEPER等，也有各种自主设计开发的负载均衡产品或策略。

基于注册中心的ZOOKEEPER负载均衡解决方案的缺点有：1)注册中心属于中心化的节点，与去中心化理念相违背；2)集群服务端在注册中心上进行注册，注册中心将集群服务端的注册信息下发给客户端，如注册中心异常，客户端可能无法及时获取集群服务端信息；3)客户端与集群服务端的负载、通讯等功能，均需客户端编码完成，对客户端的集成能力要求较高。

在客户端上安装探测模块(一般起探测进程)，对集群服务端进行探测，根据探测结果更新集群服务端地址列表状态，在使用时通过探测模块获取按负载比例分配的可用地址。缺点有：1)需要在客户端安装独立的模块，并需要启动相关的探测进程；2)如果探测进程故障，可用地址列表不是最新，会导致交易失败；3)无法动态感知集群服务端节点变化，需在客户端维护集群服务端地址列表。

发明内容

本发明的目的在于，解决在集群系统中，在不使用硬件负载设备(如F5)情况下，在客户端上集成负载均衡模块完成对请求在网络节点上的分配派发，实现负载均衡、故障隔离。同时支持客户端能主动捕获集群服务端节点动态调整，实现集群服务端扩展与收缩对客户端无感知的解决方案。

为了达到上述目的，本发明提供了一种基于API的软负载均衡实现方法，所述API具有通讯和探测模块，所述API嵌入到客户端中，所述软负载均衡实现方法包括以下步骤：

步骤①：客户端调用API通讯模块中的同步或异步接口发起服务请求，同步或异步等待响应；

步骤②：API通讯模块向探测模块申请可用的集群服务端节点的IP地址；

步骤③：API通讯模块获取到探测模块返回的IP地址；

步骤④：API通讯模块与返回的IP地址所对应的集群服务端节点建立TCP同步或异步短连接，发送服务请求并同步或异步等待响应；

步骤⑤：集群服务端转发送服务请求至该集群服务端对应的服务端；

步骤⑥：集群服务端接收其对应服务端原路返回的服务响应；

步骤⑦：API通讯模块接收集群服务端返回的服务响应；

步骤⑧：客户端接收服务响应。

可选的，API探测模块启动3个独立的线程：轮询探测线程、健康检测线程和检查配置更新线程。

可选的，所述轮询探测线程负责轮询探测：集群服务端节点的存活状态、集群服务端的横向扩展或收缩、集群服务端节点的负载因子更新、健康检测线程的存活状态。

可选的，所述轮询探测线程一旦发现健康检测线程死亡或被销毁，立即将其重新拉起。

可选的，所述健康检测线程负责定时检测：轮询探测线程的存活状态、检查配置更新线程的存活状态。

可选的，所述检查配置更新线程负责定时检查本地配置文件是否更新,如有更新,则重新加载。

可选的，客户端调用API的同步通讯接口发送请求并等待接收响应，API使用客户端的线程而不再创建新的线程。

可选的，客户端调用API的异步通讯接口发送请求，API使用客户端线程转发请求，API创建用于处理响应事件、IO操作以及任务调度的线程池。

可选的，当通讯模块来获取地址时，探测模块通过加权随机的负载策略计算出地址，响应给通讯模块。

可选的，集群负载因子支持个性化配置，满足不同客户端对负载比例的要求。

本发明的软负载均衡实现方案，是一种不依赖于注册中心，API内集合通讯、探测、负载均衡、扩展等功能于一体，能有效降低客户端与集群服务端的集成难度。

主要包括：

1、同步、异步调用机制

API内部集成了TCP的同步、异步通讯模块，无需客户端再开发通讯，直接调用API的发送方法即可。

2、负载均衡

API通过加权随机的方式实现负载均衡策略，对集群服务端可用地址列表进行筛选，可根据实际运行情况动态调整各节点的负载比率。

3、动态扩展与收缩

集群服务端节点变化时，客户端通过API的探测模块，能实时获取到集群服务端节点变化信息，更新本地配置，并加载到集群服务端节点列表中。集群服务端节点扩展或收缩时，做到客户端无感知，该方案特别适合企业服务总线这种对接很多客户端的集群系统中。

综上所述，由于采用了上述技术方案，本发明与现有技术相比，具备如下有益效果：

1、无需硬件设备支持，通过软件负载实现，有效降低成本。

2、支持同步、异步通讯模式，并且通讯模块已集成在API中，对客户端透明。

3、负载均衡，通过探测能实时隔离故障节点，同时支持按节点维度的负载因子配置，满足对负载比例的要求。

4、动态扩展与收缩，通过探测能主动捕获集群服务端节点变化，实现客户端无感知，满足弹性扩展收缩功能。

5、客户端上直接集成API，客户端和服务端直接交互，同时探测非独立进程，确保了探测状态与实际状态的一致性。

附图说明

图1为基于API的软负载均衡实现方案总体结构框图。

图2为同步-同步模式下，API通讯模块和集群服务端交互时序图。

图3为异步-异步模式下，API通讯模块和集群服务端交互时序图。

图4为API探测模块和集群服务端交互时序图。

具体实施方式

下面将结合示意图对本发明的具体实施方式进行更详细的描述。根据下列描述，本发明的优点和特征将更清楚。需说明的是，附图均采用非常简化的形式且均使用非精准的比例，仅用以方便、明晰地辅助说明本发明实施例的目的。

名词说明：

API(Application Programming Interface)：应用程序编程接口。

软负载均衡：通过在服务器上安装特定的负载均衡软件或是自带负载均衡模块完成对请求的分配派发。

硬件负载均衡：在服务器节点之间安装专门的硬件进行负载均衡的工作。

实施例：

如图1所示：API主要包括通讯和探测两个模块，作为整体嵌入到客户端中。总体上，客户端通过调用API的同步或异步接口来发起请求并接收响应，API与集群服务端之间采用TCP同步或异步短连接的通信模式。API能够定时探测集群服务端中各节点的存活状态并获取集群IP配置及其负载均衡策略。

步骤①：客户端调用API通讯模块中的同步或异步接口发起服务请求，同步或异步等待响应。

步骤②：API通讯模块向探测模块申请可用的集群服务端节点的IP地址。

步骤③：API通讯模块获取到探测模块返回的IP地址。

步骤④：API通讯模块与返回的IP地址所对应的集群服务端节点建立TCP同步或异步短连接，发送服务请求并同步或异步等待响应。

步骤⑤：集群服务端转发送服务请求至该集群服务端对应的服务端。

步骤⑥：集群服务端接收其对应服务端原路返回的服务响应。

步骤⑦：API通讯模块接收集群服务端返回的服务响应。

步骤⑧：客户端接收服务响应。

重要模块主要功能如下：

如图2所示：同步-同步模式下，由于客户端调用API的同步接口，API与集群服务端之间的通信交互采用同步模式，所以API通讯模块不再创建新的线程用来发送请求报文，直接使用客户端的线程(user-thread)即可。

如图3所示：异步-异步模式下，客户端调用API的异步接口，API与集群服务端之间的通信交互采用异步模式，故API通讯模块也不再创建新的线程用来发送请求报文，直接使用客户端的线程(user-thread)即可。但需要分别创建专门用于处理响应事件、IO操作以及任务调度的线程池。

无论同步或异步模式，API通讯模块均需获取可用集群服务端节点的IP地址以发送请求报文。在API中，可用集群服务端节点列表和负载均衡策略均保存在共享内存中，并由探测模块负责维护。通讯模块直接从该共享内存中获取可用节点地址即可。

如图4所示：API探测模块启动3个独立的线程：轮询探测线程(round-robinthread)、健康检测线程(health-monitor thread)以及检查配置更新线程(config-updatethread)。探测模块不涉及线程池的创建和使用，它和集群服务端交互时序如下：

(一)轮询探测线程负责轮询探测：

1)集群服务端节点的存活状态；

2)集群服务端的横向扩展或收缩；

3)集群服务端节点的负载因子更新；

4)健康检测线程的存活状态，一旦发现异常，如线程死亡或被销毁，立即将其重新拉起。

实现原理：

①客户端上API初始化时，首先加载本地配置文件，将集群服务端节点信息加载到内存中。

②随后API启动轮询探测线程，该线程按顺序尝试与集群服务端某一节点建立TCP短连接，一旦连接成功且集群服务端节点可用，则会收到集群服务端返回的最新全量节点表，并将其更新至内存中，然后终止后续的连接尝试。此时，轮询探测线程启动并初始化完成。

③API根据内存中的节点表，轮询探测线程开始有序探测各节点，如果探测成功，该线程会比较内存中的节点表和收到的响应报文是否相同，若不同，则更新节点表并覆盖本地配置文件；如果探测失败，证明该节点不可用，将其从内存中的可用节点表中移除。

④轮询探测线程和随后启动的健康检测线程能够相互检测彼此的存活状态，一旦发现对方异常，立即将其重新拉起。

⑤轮询探测线程在完成上述探测过程后，进入休眠状态，等待下一探测周期的到来。如果此时集群服务端节点突发异常并不可用，造成通讯模块的交易失败，通讯模块会立刻唤醒轮询探测线程，后者马上轮询探测各节点，确保在最短的时间内将异常节点从可用节点表中移除。

(二)健康检测线程负责定时检测：

1)轮询探测线程的存活状态；

2)检查配置更新线程的存活状态，一旦发现线程异常，立即将其重新拉起。

(三)检查配置更新线程

该线程负责定时检查本地配置文件是否更新，如有更新，则重新加载。

上述仅为本发明的优选实施例而已，并不对本发明起到任何限制作用。任何所属技术领域的技术人员，在不脱离本发明的技术方案的范围内，对本发明揭露的技术方案和技术内容做任何形式的等同替换或修改等变动，均属未脱离本发明的技术方案的内容，仍属于本发明的保护范围之内。

Claims (9)

1.一种基于API的软负载均衡实现方法，其特征在于，所述API具有通讯和探测模块，所述API嵌入到客户端中，所述软负载均衡实现方法包括以下步骤：

步骤①：客户端调用API通讯模块中的同步或异步接口发起服务请求，同步或异步等待响应；

步骤②：API通讯模块向探测模块申请可用的集群服务端节点的IP地址，当API通讯模块来获取地址时，探测模块通过加权随机的负载策略计算出地址，响应给通讯模块；

步骤③：API通讯模块获取到探测模块返回的IP地址；

步骤④：API通讯模块与返回的IP地址所对应的集群服务端节点建立TCP同步或异步短连接，发送服务请求并同步或异步等待响应；

步骤⑤：集群服务端转发送服务请求至该集群服务端对应的服务端；

步骤⑥：集群服务端接收其对应服务端原路返回的服务响应；

步骤⑦：API通讯模块接收集群服务端返回的服务响应；

步骤⑧：客户端接收服务响应。

2.根据权利要求1所述的软负载均衡实现方法，其特征在于，API探测模块启动3个独立的线程：轮询探测线程、健康检测线程和检查配置更新线程。

3.根据权利要求2所述的软负载均衡实现方法，其特征在于，所述轮询探测线程负责轮询探测：集群服务端节点的存活状态、集群服务端的横向扩展或收缩、集群服务端节点的负载因子更新、健康检测线程的存活状态。

4.根据权利要求3所述的软负载均衡实现方法，其特征在于，所述轮询探测线程一旦发现健康检测线程死亡或被销毁，立即将其重新拉起。

5.根据权利要求2所述的软负载均衡实现方法，其特征在于，所述健康检测线程负责定时检测：轮询探测线程的存活状态、检查配置更新线程的存活状态。

6.根据权利要求2所述的软负载均衡实现方法，其特征在于，所述检查配置更新线程负责定时检查本地配置文件是否更新,如有更新,则重新加载。

7.根据权利要求1所述的软负载均衡实现方法，其特征在于，客户端调用API的同步通讯接口发送请求并等待接收响应，API使用客户端的线程而不再创建新的线程。

8.根据权利要求1所述的软负载均衡实现方法，其特征在于，客户端调用API的异步通讯接口发送请求，API使用客户端线程转发请求，API创建用于处理响应事件、IO操作以及任务调度的线程池。

9.根据权利要求1所述的软负载均衡实现方法，其特征在于，集群负载因子支持个性化配置，满足不同客户端对负载比例的要求。