CN109842651A - 一种业务不间断的负载均衡方法和系统 - Google Patents

Abstract

本发明提供一种业务不间断的负载均衡方法和系统，所述方法包括：S1、负载均衡装置实时判断后端实例的服务是否可用，并将后端实例的服务状态更新至共享内存中存储的服务可用性列表；S2、共享内存实时将更新后的服务可用性列表写入各负载均衡装置的配置文件，对配置文件进行持久化保存；S3、负载均衡装置接收用户请求时，根据服务可用性列表选择一个可用后端实例处理用户请求。将后端实例的服务状态实时更新到共享内存中存储的服务可用性列表；共享内存采用异步的方式将服务可用性列表变更信息写入配置文件，并通知其他负载均衡装置更新相关配置文件；可以在不重启负载均衡装置的情况下动态的请求负载到配置文件中不存在的后端实例。

Description

一种业务不间断的负载均衡方法和系统

技术领域

本发明涉及通信技术领域，更具体地，涉及一种业务不间断的负载均衡方法和系统。

背景技术

负载均衡，是指按照事先配置的负载均衡算法，将访问同一个IP地址的用户流量分配到不同的服务器上，它通过虚拟服务技术、服务器健康检查技术和逐流转发技术将用户的流量分摊到多台阶的服务器上，间接提高了服务器的处理能力，也间接提高了服务器的稳定性和可扩展性。

随着第三代业务支撑的建设推进，业务支撑系统往着多中心化、多远化、复杂化的方向发展，主机数量成倍增加，系统复杂度也随之增加，如何在复杂的云环境下确保业务系统的连续性，以及在云环境下如何完成请求负载的介入管理是支撑网运营管理系统关注的重点。从目前技术上看，针对负载管理主要依赖于负载软件自身的功能实现：一是负载接入与卸载，主要依赖于软件自身的检测机制，如ping，telnet，健康检查；二是负载后端实例配置，存在配置文件中，通过对配置文件修改控制后端请求实例数的增加和删除。

现有负载管理主要依赖于负载软件自身的功能实现时，由于后端实例健康状况判断过于简单，没有实现面向业务的健康检查，会出现故障没有隔离的情况，对于故障的判断不准确。在增加或减少后端实例时，需要修改配置文件，并且需要通过重启才能加载新的配置，就算重启采用软件自带的sf参数，也有可能性导致新的业务请求被拒绝，业务受到影响。在云环境下经常需要根据系统的负载情况进行后端实例的弹性伸缩，故障隔离，可能需要频繁启停后端实例，还可能需要增加新的后端实例，而自带的健康检查的方式只能解决已经加入配置文件的后端实例动态伸缩，而无法解决新增的后端实例在不重启情况下动态伸缩与故障隔离，在配置文件之外新增的后端实例配置无法动态加载，无法使业务100％不受影响，且无法做到实时生效。

发明内容

本发明提供一种克服上述问题或者至少部分地解决上述问题的一种业务不间断的负载均衡方法和系统，解决了现有技术中后端实例在不重启情况下无法实现动态伸缩与故障隔离，且在配置文件之外新增的后端实例配置无法动态加载，无法使业务100％不受影响，且无法做到实时生效等问题。

根据本发明的一个方面，提供一种负载均衡方法，包括：

S1、负载均衡装置实时判断后端实例的服务是否可用，并将后端实例的服务状态更新至共享内存中存储的服务可用性列表；

S2、共享内存实时将更新后的服务可用性列表写入各负载均衡装置的配置文件，对配置文件进行持久化保存；

S3、接收用户请求时，根据服务可用性列表选择一个可用后端实例处理用户请求。

作为优选的，所述步骤S1具体包括：

读取用户故障判断配置信息，并结合负载均衡装置自身监控指标和第三方监控指标判断后端实例的服务是否可用；

若服务可用，则结束该后端实例的判断过程；若服务不可用，则更新负载均衡装置共享内存中存储的服务可用性列表，移除服务不可用后端实例的IP和PORT。

作为优选的，所述步骤S1还包括：

根据需要增加后端实例的个数，提供接口接收增加后端实例的IP和PORT；

判断增加后端实例是否故障，将故障的增加后端实例更新至负载均衡装置的配置文件，且不更新共享内存中的服务可用性列表，将正常的增加后端实例更新至共享内存中存储的服务可用性列表。

作为优选的，所述步骤S2中，通过多进程模式进行共享内存，具体包括：

若判断为多进程模式，则进行共享内存的处理，进一步判断是否是父进程；

若判断为父进程，则创建父进程的共享内存，通过共享内存读取所有子进程的握手消息，并将所有子进程的pid合集发送给各个子进程；

若判断为子进程，则创建子进程的共享内存，等待父进程的共享内存创建完毕后，发送子进程的握手消息到共享内存中；收到父进程发送的所有子进程的pid合集后，连接到其他子进程的共享内存中。

作为优选的，将所有子进程的pid合集发送给各个子进程后还包括：

确认所有子进程的pid合集发送完毕后，销毁父进程的共享内存。

作为优选的，所述步骤S2具体还包括：

在收到增加后端实例的消息时，转发其他负载均衡装置；在收到减少后端实例的消息时，转发其他负载均衡装置；

在处理负载均衡装置配置信息的run_poll_loop的循环中，首先处理共享内存的消息；若收到了增加后端实例的消息，则进行增加后端实例的操作，且不转发给其他负载均衡装置；若收到了减少后端实例的消息，则进行减少后端实例的操作，且不转发给其他负载均衡装置。

作为优选的，所述步骤S3具体包括：

负载均衡装置接收用户请求时，判断服务可用性列表中是否存在可用后端实例，若存在可用后端实例，则根据负载算法选择一个可用后端实例接收用户请求；

若不存在可用后端实例，则重试过程判断，重试失败后将错误信息返回至用户。

一种负载均衡系统，包括：

可用服务获取模块，用于实时判断后端实例的服务是否可用，并将后端实例的服务状态更新至共享内存中存储的服务可用性列表；

服务共享模块，用于实时将共享内存中更新后的服务可用性列表写入各负载均衡装置的配置文件，对配置文件进行持久化保存；

服务处理模块，用于在接收用户请求时，根据服务可用性列表选择一个可用后端实例处理用户请求。

一种负载均衡设备，包括：

至少一个处理器；以及

与所述处理器通信连接的至少一个存储器，其中：

所述存储器存储有可被所述处理器执行的程序指令，所述处理器调用所述程序指令能够执行如上述负载均衡的方法。

一种计算机程序产品，所述计算机程序产品包括存储在非暂态计算机可读存储介质上的计算机程序，所述计算机程序包括程序指令，当所述程序指令被计算机执行时，使所述计算机执行如上述负载均衡的方法。

本发明提出一种负载均衡方法和系统，负载均衡装置实时根据自身的监控机制与第三方监控机制组合判断后端实例的可用性，并将服务的事实状态实时更新到共享内存中存储的服务可用性列表；共享内存采用异步的方式将服务可用性列表变更信息写入配置文件，动态增加或减少后端实例个数时通知其他负载装置进程更新相关配置文件；可以在不重启负载均衡装置的情况下动态的请求负载到配置文件中不存在的后端实例上，并动态的将新增的后端实例加入配置文件，无需人工干预，实现真正意义的弹性伸缩，确保用户无感知，100％不影响业务的处理；相比现有简单判断机制，故障判断更加准确，与现有方案相比出现故障不隔离的情况大大降低。

附图说明

图1为根据本发明实施例的负载均衡方法流程框图；

图2为根据本发明实施例的负载均衡方法具体流程示意图；

图3为根据本发明实施例的服务可用行列表更新流程示意图；

图4为根据本发明实施例的增加与删除服务实例的方法示意图；

图5为根据本发明实施例的处理增减后端实例消息示意图；

图6为根据本发明实施例的多个负载均衡模块共享内存流程示意图；

图7为根据本发明实施例的单个负载均衡模块共享内存流程示意图。

具体实施方式

下面结合附图和实施例，对本发明的具体实施方式作进一步详细描述。以下实施例用于说明本发明，但不用来限制本发明的范围。

如图1和图2所示，图中示出了一种负载均衡方法，包括：

S1、实时判断后端实例的服务是否可用，并将后端实例的服务状态更新至共享内存中存储的服务可用性列表；

S2、实时将更新后的服务可用性列表写入各负载均衡装置的配置文件，对配置文件进行持久化保存；

S3、接收用户请求时，根据服务可用性列表选择一个可用后端实例处理用户请求。

在本实施例中，如图3所示，所述步骤S1具体包括：

负载均衡装置读取用户故障判断配置信息，并结合自身监控指标和第三方监控指标判断后端实例的服务是否可用；

若服务可用，则结束该后端实例的判断过程；若服务不可用，则更新负载均衡装置共享内存中存储的服务可用性列表，移除服务不可用后端实例的IP和PORT。

通过本实施例的步骤S1，通过多维度指标，同时结合指标见的逻辑运算最终判断后端实例的服务可用状态，后端实例的健康状况进行准确判断，故障判断结果准确，避免业务出现中断。具体的，后端实例的故障判断标准支持配置，支持与、或、非等逻辑运算综合判断，实现面向用户体验的故障判断，判断更为精确；判定为故障后通过调度引擎可以设置故障联动动作，对故障实例进行隔离操作或其他联动操作。

在本实施例中，发现故障后端实例后实时更新服务可用性列表，服务可用性列表不仅仅保存在负载均衡装置的配置文件中，还在共享内存中存储，实时读取共享内存配置，速度更快，实时生效。

通过以上方式解决了负载装置故障判断不准确，将用户请求转发到故障实例，业务受影响，产生中断的问题。同时加入共享内存存储服务可用性列表，确保配置高效读取更新与动态生效，后端异步更新配置文件，持久化到配置文件，整个过程确保业务不间断。

如图4和图5所示，在本实施例中，所述步骤S1还包括：

负载均衡装置根据需要增加后端实例的个数，提供接口接收增加后端实例的IP和PORT；

判断增加后端实例是否故障，将故障的增加后端实例更新至负载均衡装置的配置文件，且不更新共享内存中的服务可用性列表，将正常的增加后端实例更新至共享内存中存储的服务可用性列表。

具体的，在本实施例中，云环境下根据指标判断系统负载过高需要增加后端实例个数，提高系统的处理能力，触发增加后端实例的操作。

负载均衡装置提供接口接收增加服务主机服务的IP和端口信息。

负载均衡装置根据配置的故障判断综合指标判断后端实例是否正常。如果为故障实例不更新共享内存中的服务可用性列表，只更新负载均衡装置持久化配置文件，加入新增主机的IP和端口，如果为正常实例，首先更新负载均衡装置共享内存中的服务可用性列表，增加新增后端实例的IP和端口，确保负载配置动态生效，及时将客户请求分担到新增的后端实例上面，实现动态增加系统的处理能力，整个过程负载均衡装置无需重启，确保业务不间断。

具体的，为负载装置增加两条增减后端实例的命令server add和server delete。

增加后端实例命令，这个命令的格式是server add后端/服务名称，例如在后端be1增加服务名称为server172_2的服务命令如下：

server add be1/server172_2server server172_2 192.168.0.172:11258cookie server172_2

如果后端实例已经存在，那么只是把后端实例设置为启动状态，不存在时，才真正增加这个后端实例。

步骤如下：

(1)在负载装置中增加”server”命令的解析；

(2)在”server”命令的解析逻辑内部，增加”add”的解析；

(3)查找服务；

(4)如果(3)找到服务，启动服务检测，并设置服务为运行状态；

(5)如果(3)没有找到服务，查找后端；

(6)如果(5)找到后端，把服务添加到后端，分配服务id，启动服务检测，并设置服务为运行状态，然后根据均衡策略重新计算服务负载状态；

(7)如果(5)没有找到后端，返回无可用服务。

减少后端实例命令server delete，这个命令的格式是server delete后端/服务名称例如在后端be1删除服务名称为server172_2的服务，命令如下：

server delete be1/server172_2

减少后端实例并不是真正的删除，只是把后端实例置为停止状态。

步骤如下：

(1)”server”命令的解析逻辑内部，增加”delete”的解析；

(2)查找服务；

(3)如果(2)找到服务，设置服务为停止状态。

在步骤S2中，共享内存采用异步的方式将服务可用性列表变更信息写入配置文件，动态增加或减少服务实例个数时通知其他负载均衡装置进程更新相关配置文件，确保负载均衡装置进程间相互通信，信息一致。

具体的，负载均衡装置采用多进程模式，负载均衡装置与配置信息通过共享内存实现，原有负载均衡装置各进程间并没有有效的交互渠道，为了达到动态增加后端实例的个数，提出了负载均衡装置间通过共享内存增加交互的支持的新方法。

本实施例中采用共享内存进行通信，当其中一个负载均衡装置进程收到增加或减少后端实例时，通过共享内存通知其他负载均衡装置进程在多个负载均衡装置之间，其他负载均衡装置接收到信息后执行相关的指令，并将新的后端实例配置写入配置文件，进行持久化保存。

具体的，如图6所示，3台主机组成一个集群，主机1为Master(主)，主机2，3为slave(备)确保负载均衡器的高可用，本身单台主机多个子进程的方式也具备一定高可用性。这两种方法都是通过共享内存与各主机间的通讯握手确保3台主机的配置一致性，主要流程如下：

每台主机可以配置主机内负载均衡器启动子进程的数量，主机内的进程使用同一共享内存。启动子进程后，父进程可以选择退出或作为守护进程。作为守护进程将会监视子进程的状态，一旦子进程异常退出。作为守护进程的父进程会自动拉起一个子进程。确保子进程的数量与配置值一样，真正有负载均衡功能的是子进程。

当通过检测发现需要增减后端实例信息更新配置时，Master主机中会更新自己本机的共享内存并更新负载均衡设备配置文件，同时通知集群内的其他主机2，3更新共享内存信息并更新对应主机的负载均衡配置文件。确保集群内的负载均衡设备配置及共享内存信息一致。

当master主机出现故障时。集群内的其他主机会按照选举机制重新选择一台主机2或主机3作为master，自动接管主机1的负载均衡工作，确保业务不间断。

具体的，如图7所示，下面为单台主机内负载装置处理流程，即所述步骤S2中具体包括：

在负载均衡装置的主函数中，若判断为多进程模式，则进行共享内存的处理；

判断是否是父进程；

若判断为父进程，则创建父进程的共享内存，通过共享内存读取子进程的握手消息，在所有子进程的握手消息都读取到后，发送所有子进程的pid合集给各个子进程，确认消息发送完毕后，销毁父进程的共享内存，然后父进程自身会正常退出。

若判断为子进程，则创建子进程的共享内存，等待父进程的共享内存创建完毕后，发送子进程的握手消息到父进程的共享内存中，接着收到父进程所有子进程的pid合集后，连接到其他子进程的共享内存中。

具体的，所述步骤S2具体还包括：

在收到增加后端实例的消息时，转发其他负载均衡装置；在收到减少后端实例的消息时，转发其他负载均衡装置；

在处理负载均衡装置配置信息的run_poll_loop的循环中，首先处理共享内存的消息；若收到了增加后端实例的消息，则进行增加后端实例的操作，且不转发给其他负载均衡装置；若收到了减少后端实例的消息，则进行减少后端实例的操作，且不转发给其他负载均衡装置。

在本实施例中，通过多进程模式，利用共享内存在多个负载均衡装置之间传递指令和更新配置文件。确保了在不重启负载装置的情况下，配置能够动态生效。同时实现了故障服务判断与配置更新、操作联动，从而实现在云环境下可靠且不间断的弹性伸缩与故障实例的动态隔离。

所述步骤S3具体包括：

负载均衡装置接收用户请求时，将请求发送到负载均衡装置，负载均衡装置判断服务可用性列表中是否存在可用后端实例，若存在可用后端实例，则根据负载算法选择一个可用后端实例接收用户请求；

若不存在可用后端实例，则重试过程判断，重试失败后将错误信息返回至用户。

若步骤S1判断出需要增加后端实例则触发增加后端实例的具体操作，待新增实例检测正常后再将配置信息写入到共享内存中并异步存到配置文件中并通知其他负载装置进程。若步骤S1判断需要减少后端实例个数则更新共享内存中的信息并异步修改配置文件信息，但实际不删除后端实例。

本实施例中还提供了一种负载均衡系统，包括：

可用服务获取模块，用于实时判断后端实例的服务是否可用，并将后端实例的服务状态更新至共享内存中存储的服务可用性列表；

服务共享模块，用于实时将共享内存中更新后的服务可用性列表写入各负载均衡装置的配置文件，对配置文件进行持久化保存；

服务处理模块，用于在接收用户请求时，根据服务可用性列表选择一个可用后端实例处理用户请求。

本实施例中还提供了一种负载均衡设备，包括：处理器(processor)、存储器(memory)、通信接口(Communications Interface)和总线；

其中，

所述处理器、存储器、通信接口通过所述总线完成相互间的通信；

所述通信接口用于该测试设备与显示装置的通信设备之间的信息传输；

所述处理器用于调用所述存储器中的程序指令，以执行上述负载均衡方法实施例所提供的方法，例如包括：

S1、负载均衡装置实时判断后端实例的服务是否可用，并将后端实例的服务状态更新至共享内存中存储的服务可用性列表；

S2、共享内存实时将更新后的服务可用性列表写入各负载均衡装置的配置文件，对配置文件进行持久化保存；

S3、负载均衡装置接收用户请求时，根据服务可用性列表选择一个可用后端实例处理用户请求。

本实施例还公开一种计算机程序产品，所述计算机程序产品包括存储在非暂态计算机可读存储介质上的计算机程序，所述计算机程序包括程序指令，当所述程序指令被计算机执行时，计算机能够执行上述负载均衡方法实施例所提供的方法，例如包括：

S1、负载均衡装置实时判断后端实例的服务是否可用，并将后端实例的服务状态更新至共享内存中存储的服务可用性列表；

S2、共享内存实时将更新后的服务可用性列表写入各负载均衡装置的配置文件，对配置文件进行持久化保存；

S3、负载均衡装置接收用户请求时，根据服务可用性列表选择一个可用后端实例处理用户请求。

本实施例提供一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储计算机指令，所述计算机指令使所述计算机执行上述负载均衡方法实施例所提供的方法，例如包括：

S1、负载均衡装置实时判断后端实例的服务是否可用，并将后端实例的服务状态更新至共享内存中存储的服务可用性列表；

S2、共享内存实时将更新后的服务可用性列表写入各负载均衡装置的配置文件，对配置文件进行持久化保存；

S3、负载均衡装置接收用户请求时，根据服务可用性列表选择一个可用后端实例处理用户请求。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

以上所描述的显示装置的测试设备等实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。

最后，本发明的方法仅为较佳的实施方案，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种负载均衡方法，其特征在于，包括：

S1、实时判断后端实例的服务是否可用，并将后端实例的服务状态更新至共享内存中存储的服务可用性列表；

S2、实时将更新后的服务可用性列表写入各负载均衡装置的配置文件，对配置文件进行持久化保存；

S3、接收用户请求时，根据服务可用性列表选择一个可用后端实例处理用户请求。

2.根据权利要求1所述的负载均衡方法，其特征在于，所述步骤S1具体包括：

读取用户故障判断配置信息，并结合负载均衡装置自身监控指标和第三方监控指标判断后端实例的服务是否可用；

若服务可用，则结束该后端实例的判断过程；若服务不可用，则更新负载均衡装置共享内存中存储的服务可用性列表，移除服务不可用后端实例的IP和PORT。

3.根据权利要求2所述的负载均衡方法，其特征在于，所述步骤S1还包括：

根据需要增加后端实例的个数，提供接口接收增加后端实例的网络协议IP和端口PORT；

判断增加后端实例是否故障，将故障的增加后端实例更新至负载均衡装置的配置文件，且不更新共享内存中的服务可用性列表，将正常的增加后端实例更新至共享内存中存储的服务可用性列表。

4.根据权利要求1所述的负载均衡方法，其特征在于，所述步骤S2中，通过多进程模式进行共享内存，具体包括：

若判断为多进程模式，则进行共享内存的处理，进一步判断是否是父进程；

若判断为父进程，则创建父进程的共享内存，通过共享内存读取所有子进程的握手消息，并将所有子进程的pid合集发送给各个子进程；

若判断为子进程，则创建子进程的共享内存，等待父进程的共享内存创建完毕后，发送子进程的握手消息到共享内存中；收到父进程发送的所有子进程的pid合集后，连接到其他子进程的共享内存中。

5.根据权利要求4所述的负载均衡方法，其特征在于，将所有子进程的pid合集发送给各个子进程后还包括：

确认所有子进程的pid合集发送完毕后，销毁父进程的共享内存。

6.根据权利要求3所述的负载均衡方法，其特征在于，所述步骤S2具体还包括：

在收到增加后端实例的消息时，转发其他负载均衡装置；在收到减少后端实例的消息时，转发其他负载均衡装置；

在处理负载均衡装置配置信息的run_poll_loop的循环中，首先处理共享内存的消息；若收到了增加后端实例的消息，则进行增加后端实例的操作，且不转发给其他负载均衡装置；若收到了减少后端实例的消息，则进行减少后端实例的操作，且不转发给其他负载均衡装置。

7.根据权利要求1所述的负载均衡方法，其特征在于，所述步骤S3具体包括：

接收用户请求时，判断服务可用性列表中是否存在可用后端实例，若存在可用后端实例，则根据负载算法选择一个可用后端实例接收用户请求；

若不存在可用后端实例，则重试过程判断，重试失败后将错误信息返回至用户。

8.一种负载均衡系统，其特征在于，包括：

可用服务获取模块，用于实时判断后端实例的服务是否可用，并将后端实例的服务状态更新至共享内存中存储的服务可用性列表；

服务共享模块，用于实时将共享内存中更新后的服务可用性列表写入各负载均衡装置的配置文件，对配置文件进行持久化保存；

服务处理模块，用于在接收用户请求时，根据服务可用性列表选择一个可用后端实例处理用户请求。

9.一种负载均衡设备，其特征在于，包括：

至少一个处理器；以及

与所述处理器通信连接的至少一个存储器，其中：

所述存储器存储有可被所述处理器执行的程序指令，所述处理器调用所述程序指令能够执行如权利要求1至7任一所述的方法。

10.一种计算机程序产品，其特征在于，所述计算机程序产品包括存储在非暂态计算机可读存储介质上的计算机程序，所述计算机程序包括程序指令，当所述程序指令被计算机执行时，使所述计算机执行如权利要求1至7任一所述的方法。