CN110995656B - 负载均衡方法、装置、设备及存储介质 - Google Patents

Abstract

本发明属于通信技术领域，公开了一种负载均衡方法、装置、设备及存储介质。该方法通过利用应用层中的脚本引擎对接收到的请求消息报文进行解析，获得能够标识请求消息报文唯一性的请求标识信息，在确定处理不同请求消息报文的目标服务节点时，只关注请求消息报文的请求标识信息，不关注接收请求消息报文的TCP连接，从而可以将不同的请求消息报文分配给不同的服务节点处理，在保证负载均衡效果的同时，也大大提升了处理效率。

Description

负载均衡方法、装置、设备及存储介质

技术领域

本发明涉及通信技术领域，尤其涉及一种负载均衡方法、装置、设备及存储介质。

背景技术

所谓负载均衡是指将负载(工作任务)进行平衡、分摊到多个操作单元，如文件传输协议服务器、网页服务器、企业核心应用服务器和其他主要任务服务器上进行运行，从而协同完成工作任务。

但是，由于目前的负载均衡方案，在实现前端用户集群与后端服务器集群之间的负载均衡时，通常是以传输控制协议(Transmission Control Protocol，TCP)为单位做负载均衡调度，根本无法将客户端通过一个TCP连接发出的多个请求消息报文分发给后端服务集群中不同的服务节点(服务器)进行处理。这样不仅会影响负载均衡效果，同时在处理该TCP连接的服务节点发生故障时，由于无法将请求消息报文快速切换到正常的服务节点，即无法实现故障转移，也会严重影响任务的处理效率。

上述内容仅用于辅助理解本发明的技术方案，并不代表承认上述内容是现有技术。

发明内容

本发明的主要目的在于提供一种负载均衡方法、装置、设备及存储介质，旨在解决上述技术问题。

为实现上述目的，本发明提供了一种负载均衡方法，所述方法包括以下步骤：

通过物理接口层接收前端用户集群中客户端发送的请求消息报文，并将各请求消息报文缓存在TCP协议栈中；

通过应用层中的脚本引擎从所述TCP协议栈中读取请求消息报文，对读取到的请求消息报文进行解析，确定各请求消息报文的请求标识信息，并根据确定的请求标识信息生成请求标识信息集合；

通过所述应用层中的反向代理对所述请求标识信息集合进行遍历，根据遍历到的当前请求标识信息从所述请求消息报文中确定需要处理的目标请求消息报文；

通过所述应用层中的会话保持或反向代理从后端服务集群中选取一个服务节点作为目标服务节点，并将所述目标请求消息报文发送至所述目标服务节点。

优选地，所述请求标识信息包括请求消息报文长度和请求消息报文标识号；

所述通过所述应用层中的会话保持或反向代理从后端服务集群中选取一个服务节点作为目标服务节点，并将所述目标请求消息报文发送至所述目标服务节点的步骤，包括：

通过所述应用层中的会话保持对预先构建的会话保持标识信息集合进行遍历，确定所述会话保持标识信息集合中是否存在所述目标请求消息报文的请求消息报文标识号，所述会话保持标识信息集合用于记载请求消息报文标识号和目标服务节点的服务节点信息之间的对应关系；

若所述会话保持标识信息集合中不存在所述目标请求消息报文的请求消息报文标识号，则通过所述应用层中的反向代理从后端服务集群中选取一个服务节点作为目标服务节点，并将所述目标请求消息报文发送至所述目标服务节点；

若所述会话保持标识信息集合中存在所述目标请求消息报文的请求消息报文标识号，则通过所述应用层中的会话保持从后端服务集群中选取一个服务节点作为目标服务节点，并将所述目标请求消息报文发送至所述目标服务节点。

优选地，所述通过所述应用层中的反向代理从后端服务集群中选取一个服务节点作为目标服务节点，并将所述目标请求消息报文发送至所述目标服务节点的步骤，包括：

通过所述应用层中的反向代理获取所述后端服务集群中各服务节点的负载状态，根据各服务节点的负载状态和预设的服务节点负载均衡标准从所述后端服务集群中选取一个服务节点作为处理所述目标请求消息报文的目标服务节点，并根据所述请求标识信息集合中记载的所述请求消息报文标识号对应的请求消息报文长度，从所述TCP协议栈中提取出所述目标请求消息报文，将所述目标请求消息报文发送至所述目标服务节点；

相应地，所述通过所述应用层中的会话保持从后端服务集群中选取一个服务节点作为目标服务节点，并将所述目标请求消息报文发送至所述目标服务节点的步骤，包括：

通过所述应用层中的会话保持从所述会话保持标识信息集合中获取所述请求消息报文标识对应的服务节点信息，将所述后端服务集群中所述服务节点信息对应的服务节点作为所述目标服务节点，通过所述应用层中的反向代理根据所述请求标识信息集合中记载的所述请求消息报文标识号对应的请求消息报文长度，从所述TCP协议栈中提取出所述目标请求消息报文，通过所述应用层中的会话保持将所述目标请求消息报文发送至所述目标服务节点。

优选地，所述将所述目标请求消息报文发送至所述目标服务节点的步骤之后，所述方法还包括：

通过所述物理接口层接收各目标服务节点返回的针对各目标请求消息报文作出的应答消息报文，并将各应答消息报文缓存在所述TCP协议栈中；

通过所述应用层中的脚本引擎从所述TCP协议栈中读取应答消息报文，对读取到的应答消息报文进行解析，确定各应答消息报文的应答标识信息，并根据确定的应答标识信息生成应答标识信息集合；

通过所述应用层中的反向代理对所述应答标识信息集合进行遍历，根据遍历到的当前应答标识信息确定目标应答消息报文；

通过所述应用层中的会话保持或反向代理从所述前端用户集群中选取一个客户端作为接收所述目标应答消息报文的目标客户端，并将所述目标应答消息发送至所述目标客户端。

优选地，所述应答标识信息包括应答消息报文长度和应答消息报文标识号；

所述通过所述应用层中的会话保持或反向代理从所述前端用户集群中选取一个客户端作为接收所述目标应答消息报文的目标客户端，并将所述目标应答消息发送至所述目标客户端的步骤，包括：

通过所述应用层中的会话保持对所述会话保持标识信息集合进行遍历，确定所述会话保持标识信息集合中是否存在所述目标应答消息报文的应答消息报文标识号，所述会话保持标识信息集合还用于记载应答消息报文标识号和目标客户端的客户端信息之间的对应关系；

若所述会话保持标识信息集合中不存在所述目标应答消息报文的应答消息报文标识号，则通过所述应用层中的反向代理从所述前端用户集群中选取一个客户端作为接收所述目标应答消息报文的目标客户端，并将所述目标应答消息发送至所述目标客户端；

若所述会话保持标识信息集合中存在所述目标应答消息报文的应答消息报文标识号，则通过所述应用层中的会话保持从所述前端用户集群中选取一个客户端作为接收所述目标应答消息报文的目标客户端，并将所述目标应答消息发送至所述目标客户端。

优选地，所述将所述目标请求消息报文发送至所述目标服务节点的步骤，包括：

确定与所述目标服务节点之间可用的请求消息传输通道；

根据预设的请求传输通道负载均衡标准，从所述可用的请求消息传输通道中确定目标请求消息传输通道，并采用所述目标请求消息传输通道将所述目标请求消息发送至所述目标服务节点；

相应地，所述将所述目标应答消息发送至所述目标客户端的步骤，包括：

确定与所述目标客户端之间可用的应答消息传输通道；

根据预设的应答传输通道负载均衡标准，从所述可用的应答消息传输通道中确定目标应答消息传输通道，并采用所述目标应答消息传输通道将所述目标应答消息发送至所述目标客户端。

优选地，所述通过应用层中的脚本引擎从所述TCP协议栈中读取请求消息报文，对读取到的请求消息报文进行解析，确定各请求消息报文的请求标识信息，并根据确定的请求标识信息生成请求标识信息集合的步骤，包括：

判断所述TCP协议栈中缓存的请求消息报文是否是加密版请求消息报文；

若所述TCP协议栈中缓存的请求消息报文是加密版请求消息报文，则将所述TCP协议栈中的请求消息报文传输至预先部署的安全套接层SSL协议栈，由所述SSL协议栈对各请求消息报文进行解密，得到解密版请求消息报文；

通过应用层中的脚本引擎从所述SSL协议栈中读取解密版请求消息报文，对读取到的解密版请求消息报文进行解析，确定各请求消息报文的请求标识信息，并根据确定的请求标识信息生成请求标识信息集合。

此外，为实现上述目的，本发明还提出一种负载均衡装置，所述装置包括：物理接口层和应用层；

所述应用层部署有脚本引擎、反向代理和会话保持；

所述物理接口层，用于接收前端用户集群中客户端发送的请求消息报文，并将各请求消息报文缓存在TCP协议栈中；

所述脚本引擎，用于从所述TCP协议栈中读取请求消息报文，对读取到的请求消息报文进行解析，确定各请求消息报文的请求标识信息，并根据确定的请求标识信息生成请求标识信息集合；

所述反向代理，用于对所述请求标识信息集合进行遍历，根据遍历到的当前请求标识信息从所述请求消息报文中确定需要处理的目标请求消息报文；

所述应用层中的会话保持或反向代理，还用于从后端服务集群中选取一个服务节点作为目标服务节点，并将所述目标请求消息报文发送至所述目标服务节点。

此外，为实现上述目的，本发明还提出一种负载均衡设备，所述设备包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的负载均衡程序，所述负载均衡程序配置为实现如上文所述的负载均衡方法的步骤。

此外，为实现上述目的，本发明还提出一种计算机可读存储介质，所述计算机可读存储介质上存储有负载均衡程序，所述负载均衡程序被处理器执行时实现如上文所述的负载均衡方法的步骤。

本发明提供的负载均衡方案，通过利用应用层中的脚本引擎对接收到的请求消息报文进行解析，获得能够标识请求消息报文唯一性的请求标识信息，在确定处理不同请求消息报文的目标服务节点时，只关注请求消息报文的请求标识信息，不关注接收请求消息报文的TCP连接，从而可以将不同的请求消息报文分配给不同的服务节点处理，在保证负载均衡效果的同时，也大大提升了处理效率。

附图说明

图1是本发明实施例方案涉及的硬件运行环境的负载均衡设备的结构示意图；

图2为本发明负载均衡方法第一实施例的流程示意图；

图3为本发明负载均衡方法第二实施例的流程示意图；

图4为本发明负载均衡装置第一实施例的结构框图。

本发明目的的实现、功能特点及优点将集合实施例，参照附图做进一步说明。

具体实施方式

应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。

参照图1，图1为本发明实施例方案涉及的硬件运行环境的负载均衡设备结构示意图。

如图1所示，该负载均衡设备可以包括：处理器1001，例如中央处理器(CentralProcessing Unit，CPU)，通信总线1002、用户接口1003，网络接口1004，存储器1005。其中，通信总线1002用于实现这些组件之间的连接通信。用户接口1003可以包括显示屏(Display)、输入单元比如键盘(Keyboard)，可选用户接口1003还可以包括标准的有线接口、无线接口。网络接口1004可选的可以包括标准的有线接口、无线接口(如无线保真(WIreless-FIdelity，WI-FI)接口)。存储器1005可以是高速的随机存取存储器(RandomAccess Memory，RAM)存储器，也可以是稳定的非易失性存储器(Non-Volatile Memory，NVM)，例如磁盘存储器。存储器1005可选的还可以是独立于前述处理器1001的存储装置。

本领域技术人员可以理解，图1中示出的结构并不构成对负载均衡设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

如图1所示，作为一种存储介质的存储器1005中可以包括操作系统、网络通信模块、用户接口模块以及负载均衡程序。

在图1所示的负载均衡设备中，网络接口1004主要用于与网络服务器进行数据通信；用户接口1003主要用于与用户进行数据交互；本发明负载均衡设备中的处理器1001、存储器1005可以设置在负载均衡设备中，所述负载均衡设备通过处理器1001调用存储器1005中存储的负载均衡程序，并执行本发明实施例提供的负载均衡方法。

本发明实施例提供了一种负载均衡方法，参照图2，图2为本发明一种负载均衡方法第一实施例的流程示意图。

本实施例中，所述负载均衡方法包括以下步骤：

步骤S10，通过物理接口层接收前端用户集群中客户端发送的请求消息报文，并将各请求消息报文缓存在TCP协议栈中。

具体的说，在实际应用中用于执行本实施例中所说的负载均衡方法的执行主体实质为用于连通前端用户集群中的客户端与后端服务集群中的服务节点的代理服务器，该代理服务器可以是传统的占用实际物理空间的物理服务器，也可以是目前较为普及的部署于云端的云服务器，为了便于后续说明，本实施例将所述代理服务器称为负载均衡设备。

相应地，上述所说的客户端和服务节点也可以是与代理服务器类似的设备，本实施例对此不做限制。

为了便于理解本实施例提供的负载均衡方法的实现流程，以下先对负载均衡设备的在网络通信过程中涉及的分层进行简要说明。

具体的，在本实施例中，所述负载均衡设备在网络通信过程中主要依赖的是开放式系统互联(Open System Interconnection，OSI)。OSI是国际标准组织制定，用于定义不同计算机互联的标准，是设计和描述计算机网络通信的基本框架。在具体应用中，OSI从底层到用户层的结构上主要分为位于最下层的物理接口层(Physical，也称物理层，主要用于与其他计算机设备通信)、依次叠加设置的数据链路层(Date Link)、网络层(Network)、传输层(Transport)、会话层(Session)、表示层(Presetation)和位于最上层能够与用户进行交互的应用层(Application)。

而上述所说的TCP协议栈在本实施例中具体是位于传输层的，故而结合上述对负载均衡设备中OSI框架的介绍可知，上述步骤S10中的操作实质为：

所述负载均衡设备在通过物理接口层接收到与其预先建立通信连接的前端用户集群中任意客户端发送的请求消息报文时，先与数据链路层进行交互，将接收到的请求消息报文传输给数据链路层，然后数据链路层与网络层进行交互，将所述请求消息报文传输给网络层，最后网络数据层与传输层进行交互，将所述请求消息报文传输给传输层中的TCP协议栈，通过这种方式便可以实现将物理接口层接收到的各请求消息报文缓存在TCP协议栈中。

关于上述所说的预先建立的负载均衡设备与客户端之间的通信连接，在本实施例中具体为TCP长连接。

相应地，为了保障上述操作的顺利执行，建立负载均衡设备与前端用户集群中各客户端之间的TCP长连接的操作需要在执行上述步骤S10之前完成。

值得一提的是，由于在实际应用中，TCP长连接可以分为单工、双工、半双工等形式，故而在建立TCP长连接时，具体可以分为如下三种：

(1)基于单工原理，分别与所述前端用户集群中的各客户端建立TCP长连接，即建立的各TCP长连接为单工工作模式；

(2)基于双工原理，分别与所述前端用户集群中的各客户端建立TCP长连接，即建立的各TCP长连接为双工工作模式；

(3)基于半双工原理，分别与所述前端用户集群中的各客户端建立TCP长连接，即建立的各TCP长连接为半双工工作模式。

为了便于理解，以下对“单工”、“双工”、“半双工”这三种模式进行简要说明：

所谓“单工”，实质是指一个客户端与一个负载均衡设备之间建立的一条TCP长连接，要么用于接收数据包，要么用于发送数据包，不能既用来发送数据包，又用来接收数据包。

也就是说，在基于单工原理建立负载均衡设备与前端用户集群中各客户端之间的TCP长连接时，为了保证客户端既可以向负载均衡设备发送数据包(请求消息报文)，又可以接收负载均衡设备返回的数据包(应答消息报文)，任意一个客户端与负载均衡设备之间至少需要建立两条TCP长连接，一条用来发送数据包，一条用来接收数据包。

所谓“双工”，实质是指一个客户端与一个负载均衡设备之间建立的一条TCP长连接，既可以用来发送数据包，又可以用来接收数据包。

也就是说，在基于双工原理建立负载均衡设备与前端用户集群中各客户端之间的TCP长连接时，一个客户端与一个负载均衡设备之间只需建立一条TCP长连接就可以实现客户端既可以向负载均衡设备发送数据包(请求消息报文)，又可以接收负载均衡设备返回的数据包(应答消息报文)的操作。

所谓“半双工”，实质是指一个客户端与一个负载均衡设备之间建立的一条TCP长连接，既可以用来发送数据包，又可以用来接收数据包，但是同一时刻不能既用来发送数据包，又用来接收数据包，即不可以同时进行发送数据包和接收数据包的工作，需要分时进行。

也就是说，在基于半双工原理建立负载均衡设备与前端用户集群中各客户端之间的TCP长连接时，一个客户端与一个负载均衡设备之间可以只建立一条TCP长连接，只要设置好分时工作状态就可以既实现客户端向负载均衡设备发送数据包(请求消息报文)，又可以接收负载均衡设备返回的数据包(应答消息报文)的操作。

基于上述描述可知，在实际应用中，为了保证负载均衡设备与客户端之间的通信，本领域技术人员可以根据需要选择合适的方式建立负载均衡设备与客户端之间的TCP长连接，本实施例对此不做限制。

此外，由于TCP长连接的使用以及相当成熟，本实施例对于如何建立负载均衡设备与客户端之间的TCP长连接不再赘述，本领域技术人员可以自行查找相关文档实现。

步骤S20，通过应用层中的脚本引擎从所述TCP协议栈中读取请求消息报文，对读取到的请求消息报文进行解析，确定各请求消息报文的请求标识信息，并根据确定的请求标识信息生成请求标识信息集合。

具体的说，本实施例中所说的脚本引擎是在应用层中新增的一个功能。在实际应用中，可以是以虚拟功能模块(可以称为脚本引擎模块)来实现，也可以是以一个任务、线程、程序来实现，本实例对此不做限制。

关于上述所说的通过应用层中的脚本引擎从所述TCP协议栈中读取请求消息报文，对读取到的请求消息报文进行解析的操作，在本实施例中具体是通过预设的请求消息报文处理脚本代码实现的，即所述脚本引擎在从所述TCP协议栈中读取出请求消息报文后，触发运行在其上的请求消息报文处理脚本，执行请求消息报文处理脚本中的代码，由请求消息报文处理脚本对读取到的请求消息报文进行解析，进而得到请求消息报文对应的请求标识信息。

此外，关于上述所说的将得到的请求标识信息集合添加到所述应用层中的反向代理的操作，在实际应用中可以是通过预设的应用程序编程接口(Application ProgrammingInterface，API)将所述请求标识信息集合中的请求标识信息传输给所述反向代理进行保存的。

此外，值得一提的是，关于上述所说解析得到的请求标识信息，在本实施例中主要包括请求消息报文长度和请求消息报文标识号两种，但在实际应用中，本领域技术人员可以根据需要编译合适的请求消息报文处理脚本，进而提取其他类型的请求标识信息，本实施例对此不做限制。

所谓请求消息报文长度，在本实施例中是指解析的请求消息报文对应的长度。

相应地，上述所说的请求消息报文标识号，在本实施例中是指能够标识解析的请求消息报文唯一性的标识号，该标识号是在用户通过客户端触发请求消息报文时，由客户端根据预设的程序自动为其分配的。

此外，值得一提的是，在实际应用中，上述通过脚本引擎上的请求消息报文处理脚本解析得到的各请求消息报文的请求标识信息生成的请求标识信息集合可以添加到所述反向代理中预设的存储区域进行存现，以便反向代理对其进行遍历和管理。

步骤S30，通过所述应用层中的反向代理对所述请求标识信息集合进行遍历，根据遍历到的当前请求标识信息从所述请求消息报文中确定需要处理的目标请求消息报文。

具体的说，由于本实施例提供的负载均衡方法在确定处理各个请求消息报文的目标服务节点时，是根据各个请求消息报文的请求标识信息确定。因此不会限制负载均衡设备在接收到一个客户端通过一个TCL长连接发送的请求消息报文后，必需等到接收到后端反馈的针对当前请求消息报文作出的应答消息报文，然后将接收到的应答消息报文反馈给作出该请求消息报文的客户端，故而可以批量接收客户端通过同一TCP长连接发送的不同请求消息报文。

相应地，由于接收到的请求消息报文不仅仅是一个，故而通过脚本引擎中预设的请求消息报文处理脚本解析后得到的请求标识信息也不只一个，即所述请求标识集合中可能会存在多个请求消息报文的请求标识信息。因此，需要通过步骤S30中所说的操作，依次确定需要处理的目标请求消息报文。

步骤S40，通过所述应用层中的会话保持或反向代理从后端服务集群中选取一个服务节点作为目标服务节点，并将所述目标请求消息报文发送至所述目标服务节点。

具体的说，在本实施例中，确定所述目标服务节点时，需要先由所述应用层中的会话保持对预先构建的会话保持标识信息集合进行遍历，确定所述会话保持标识信息集合中是否存在所述目标请求消息报文的请求消息报文标识号；然后根据遍历结果决定确定目标服务节点，以及发送目标请求消息报文的操作由谁完成。

关于上述所说的会话保持标识信息集合，在本实施例中主要是用于记载请求消息报文标识号和目标服务节点的服务节点信息之间的对应关系的。

由于在实际应用中，会话保持标识信息集合中要么存在目标请求消息报文的请求消息报文标识，要么不存在。

因此，针对上述两种情况，在本实施例中确定目标服务节点，以及发送目标请求消息报文的操作也会有所区别。

具体的，若所述会话保持标识信息集合中不存在所述目标请求消息报文的请求消息报文标识号，则后续操作(确定目标服务节点和发送目标请求消息报文的操作)需要通过所述应用层中的反向代理来完成，关于所述应用层中的反向代理进行的操作，大致如下：

首先，通过所述应用层中的反向代理获取所述后端服务集群中各服务节点的负载状态；

然后，根据各服务节点的负载状态和预设的服务节点负载均衡标准从所述后端服务集群中选取一个服务节点作为处理所述目标请求消息报文的目标服务节点；

接着，根据所述请求标识信息集合中记载的所述请求消息报文标识号对应的请求消息报文长度，并从所述TCP协议栈中提取出所述目标请求消息报文；

最后，将所述目标请求消息报文发送至所述目标服务节点。

也就是说，在所述会话保持标识信息集合中不存在所述目标请求消息报文的请求消息报文标识号，确定目标服务节点、提取目前请求消息报文以及发送目标请求消息报文至确定的目标服务节点的操作，均是由应用层中的反向代理完成的。

进一步地，若所述会话保持标识信息集合中存在所述目标请求消息报文的请求消息报文标识号，则确定目标服务节点和发送目标请求消息报文的操作需要通过所述应用层中的会话保持完成，提取目标请求消息报文的操作则由所述应用层中的反向代理完成，关于后续所述应用层中的反向代理和会话保持进行的操作大致如下：

首先，通过所述应用层中的会话保持从所述会话保持标识信息集合中获取所述请求消息报文标识对应的服务节点信息，将所述后端服务集群中所述服务节点信息对应的服务节点作为所述目标服务节点；

然后，通过所述应用层中的反向代理根据所述请求标识信息集合中记载的所述请求消息报文标识号对应的请求消息报文长度，从所述TCP协议栈中提取出所述目标请求消息报文；

最后，通过所述应用层中的会话保持将所述目标请求消息报文发送至所述目标服务节点。

也就是说，在所述会话保持标识信息集合中存在所述目标请求消息报文的请求消息报文标识号时，确定目标服务节点以及发送目标请求消息报文至确定的目标服务节点的操作，均是由应用层中的会话保持完成的，提取目标请求消息报文的操作仍是由应用层中的反向代理完成的。

进一步地，为了实现异步模式下，后续后端服务集群中各目标服务节点返回的应答消息报文能够精准的返回给前端用户集群中对应的客户端。在所述会话保持标识信息集合中不存在所述目标请求消息报文的请求消息报文标识号，由所述应用层中的反向代理完成确定目标服务节点、提取目前请求消息报文以及发送目标请求消息报文至确定的目标服务节点的操作后，还可以设置所述应用层中的会话保持将所述目标请求消息报文的请求消息报文标识号作为关键字，记录发起该目标请求消息报文的客户端的网际互连协议(Internet Protocol，IP)地址、客户端的端口号、确定的目标服务节点的IP地址，以及目标服务器的端口号，从而在后续反馈应答消息报文时，能够根据记录的上述信息解决应答消息报文的溯源问题。

相应地，由于在所述会话保持标识信息集合中不存在所述目标请求消息报文的请求消息报文标识号时，已经完成了上述记录发起该目标请求消息报文的客户端的网际互连协议(Internet Protocol，IP)地址、客户端的端口号、确定的目标服务节点的IP地址，以及目标服务器的端口号的操作，故而在确定所述会话保持标识信息集合中存在所述目标请求消息报文的请求消息报文标识号时，所述应用层中的会话保持在确定目标服务节点时，只需以所述目标请求消息报文对应的请求消息报文标识号作为关键字，然后从记录上述信息的数据表中提取出之前已经确定的用于处理所述目标请求消息报文的目标服务节点的IP地址和端口号，然后将通过所述应用层中的反向代理提取出的所述目标请求消息报文发送至所述IP地址和端口号对应的目标服务节点即可。

此外，在通过所述应用层中的会话保持或反向代理将所述目标请求消息报文发送至所述目标服务节点时，为了更好的实现负载均衡，可以通过如下几个步骤实现：

首先，确定对象确定与所述目标服务节点之间可用的请求消息传输通道；

然后，根据预设的请求传输通道负载均衡标准，从所述可用的请求消息传输通道中确定目标请求消息传输通道，并采用所述目标请求消息传输通道将所述目标请求消息发送至所述目标服务节点。

应当理解的是，上述确定可用请求消息传输通道，以及通过确定的目标请求消息传输通道将所述目标请求消息发送至所述目标服务节点的操作，具体是由上述步骤S40中确定的反向代理或会话保持完成的。

即，如果用确定目标服务节点和发送目标请求消息报文的是反向代理，则上述确定可用请求消息传输通道，以及通过确定的目标请求消息传输通道将所述目标请求消息发送至所述目标服务节点的就是反向代理；反之，则为会话保持。

此外，需要说明的是，关于上述所说的请求消息传输通道即为预先构建的负载均衡设备与服务节点之间的通信链路，即为了保证能将目标请求消息报文发送至目标服务节点，同时能够从目标服务节点接收到反馈的应答消息报文，在执行上述步骤S40之前，同样需要先建立负载均衡设备与服务节点之间的通信连接。

具体的说，在本实施例中，负载均衡设备与服务节点之间的通信连接同样为TCP长连接。

同理，本实施例中建立的负载均衡设备与后端服务集群中各服务节点之间的TCP长连接可以分为单工、双工、半双工等形式，故而在建立TCP长连接时，具体可以分为如下三种：

(1)基于单工原理，分别与所述后端服务集群中的各服务节点建立TCP长连接；

(2)基于双工原理，分别与所述后端服务集群中的各服务节点端建立TCP长连接；

(3)基于半双工原理，分别与所述后端服务集群中的各服务节点建立TCP长连接。

由于在步骤S10中已经对“单工”、“双工”、“半双工”进行了介绍，此处不再进行赘述。

进一步地，在通过所述应用层中的会话保持或反向代理将所述目标请求消息报文发送至所述目标服务节点之后，所述负载均衡设备还会接收目标服务节点返回的针对各目标请求消息报文作出的应答消息报文，并将接收到的应答消息报文反馈给对应的客户端。

为了便于理解这一流程，以下进行简要说明：

首先，通过所述物理接口层接收各目标服务节点返回的针对各目标请求消息报文作出的应答消息报文，并将各应答消息报文缓存在所述TCP协议栈中；

然后，通过所述应用层中的脚本引擎从所述TCP协议栈中读取应答消息报文，对读取到的应答消息报文进行解析，确定各应答消息报文的应答标识信息，并根据确定的应答标识信息生成应答标识信息集合；

接着，通过所述应用层中的反向代理对所述应答标识信息集合进行遍历，根据遍历到的当前应答标识信息确定目标应答消息报文；

最后，通过所述应用层中的会话保持或反向代理从所述前端用户集群中选取一个客户端作为接收所述目标应答消息报文的目标客户端，并将所述目标应答消息发送至所述目标客户端。

具体的说，上述所说的应答标识信息与请求标识信息类似，主要包括应答消息报文长度和应答消息报文标识号。

相应地，与上述步骤S40的操作类似，在本实施例中，确定所述目标客户端时，同样需要先由所述应用层中的会话保持对所述会话保持标识信息集合进行遍历，确定所述会话保持标识信息集合中是否存在所述目标应答消息报文的应答消息报文标识号；然后根据遍历结果决定确定目标客户端，以及发送目标应答消息报文的操作由谁完成。

关于上述所说的会话保持标识信息集合，在本实施例中还用于记载应答消息报文标识号和目标客户端的客户端信息之间的对应关系。

由于在实际应用中，会话保持标识信息集合中要么存在目标应答消息报文的应答消息报文标识，要么不存在。

因此，针对上述两种情况，在本实施例中确定目标客户端，以及发送目标应答消息报文的操作也会有所区别。

具体的，若所述会话保持标识信息集合中不存在所述目标应答消息报文的应答消息报文标识号，则后续操作需要通过所述应用层中的反向代理来完成，关于所述应用层中的反向代理进行的操作，大致如下：

首先，通过所述应用层中的反向代理获取所述前端用户集群中各客户端的负载状态；

然后，根据各客户端的负载状态和预设的客户端负载均衡标准从所述前端用户集群中选取一个客户端作为接收所述目标应答消息报文的目标客户端；

接着，根据所述应答标识信息集合中记载的所述应答消息报文标识号对应的应答消息报文长度，从所述TCP协议栈中提取出所述目标应答消息报文；

最后，将所述目标应答消息报文发送至所述目标客户端。

也就是说，在所述会话保持标识信息集合中不存在所述目标应答消息报文的应答消息报文标识号，即所述目标客户端确定对象为反向代理时，确定目标客户端、提取目前应答消息报文以及发送目标应答消息报文至确定的目标客户端的操作，均是由应用层中的反向代理完成的。

进一步地，若所述应用层中的会话保持对预先构建的会话保持标识信息集合进行遍历后，确定所述会话保持标识信息集合中存在所述目标应答消息报文的应答消息报文标识号，则后续操作需要通过所述应用层中的反向代理和会话保持共同完成，关于后续所述应用层中的反向代理和会话保持进行的操作大致如下：

首先，通过所述应用层中的会话保持从所述会话保持标识信息集合中获取所述应答消息报文标识对应的客户端信息，将所述前端用户集群中所述客户端信息对应的客户端作为所述目标客户端；

然后，通过所述应用层中的反向代理根据所述应答标识信息集合中记载的所述应答消息报文标识号对应的应答消息报文长度，从所述TCP协议栈中提取出所述目标应答消息报文；

最后，通过所述应用层中的会话保持将所述目标应答消息报文发送至所述目标客户端。

也就是说，在所述会话保持标识信息集合中存在所述目标应答消息报文的应答消息报文标识号，即所述目标客户端确定对象为会话保持时，确定目标客户端以及发送目标应答消息报文至确定的目标客户端的操作，均是由应用层中的会话保持完成的，提取目标应答消息报文的操作仍是由应用层中的反向代理完成的。

进一步地，由于为了实现异步模式下，保证后续后端服务集群中各目标服务节点返回的应答消息报文能够精准的返回给前端用户集群中对应的客户端。在所述会话保持标识信息集合中不存在所述目标请求消息报文的请求消息报文标识号，由所述应用层中的反向代理完成确定目标服务节点、提取目前请求消息报文以及发送目标请求消息报文至确定的目标服务节点的操作后，会设置所述应用层中的会话保持将所述目标请求消息报文的请求消息报文标识号作为关键字，记录发起该目标请求消息报文的客户端的网际互连协议(Internet Protocol，IP)地址、客户端的端口号、确定的目标服务节点的IP地址，以及目标服务器的端口号。同理，为了实现异步模式下，在会话保持标识信息集合中不存在目标应答消息报文的应答消息报文标识号，将确定的目标应答消息报文发送给确定的目标客户端后，后端服务集群中的服务节点能够继续接收到该目标客户端发送的请求消息报文，在会话保持标识信息集合中不存在目标应答消息报文的应答消息报文标识号，将确定的目标应答消息报文发送给确定的目标客户端后，同样可以设置所述应用层中的会话保持将所述目标应答消息报文的应答消息报文标识号作为关键字，记录作出该目标应答消息报文的目标服务节点的IP地址、端口号，以及接收该目标应答消息报文的目标客户端的IP地址、端口号。

相应地，由于在所述会话保持标识信息集合中不存在所述目标应答消息报文的应答消息报文标识号时，已经完成了上述记录作出该目标应答消息报文的服务节点的IP地址、端口号、确定的目标客户端的IP地址，以及目标客户端的端口号的操作，故而在确定所述会话保持标识信息集合中存在所述目标应答消息报文的应答消息报文标识号时，所述应用层中的会话保持在确定目标客户端时，只需以所述目标应答消息报文对应的应答消息报文标识号作为关键字，然后从记录上述信息的数据表中提取出之前已经确定的目标客户端的IP地址和端口号，然后将通过所述应用层中的反向代理提取出的所述目标应答消息报文发送至所述IP地址和端口号对应的目标客户端即可。

此外，在过所述应用层中的会话保持或反向代理将所述目标应答消息发送至所述目标客户端时，为了更好的实现负载均衡，可以通过如下几个步骤实现：

首先，确定与所述目标客户端之间可用的应答消息传输通道；

然后，根据预设的应答传输通道负载均衡标准，从所述可用的应答消息传输通道中确定目标应答消息传输通道，并采用所述目标应答消息传输通道将所述目标应答消息发送至所述目标客户端。

应当理解的是，以上给出的仅为一种具体的实现方式，对本发明的技术方案并不构成任何限定，在具体应用中，本领域的技术人员可以根据需要进行设置，本发明对此不做限制。

此外，关于上述所说的各项负载均衡标准，如请求传输通道负载均衡标准、客户端负载均衡标准、应答传输通道负载均衡标准，在实际应用中，本领域技术人员均可以实际需要进行设置，本实施例对此不做任何限制。

通过上述描述不难发现，本实施例提供的负载均衡方法，通过利用应用层中的脚本引擎对接收到的请求消息报文进行解析，获得能够标识请求消息报文唯一性的请求标识信息，在确定处理不同请求消息报文的目标服务节点时，只关注请求消息报文的请求标识信息，不关注接收请求消息报文的TCP连接，从而可以将不同的请求消息报文分配给不同的服务节点处理，在保证负载均衡效果的同时，也大大提升了处理效率。

此外，值得一提的是，在实际应用中，为了尽可能方便操作前端用户集群中的客户端的用户，可以为负载均衡设备分配一个固定的虚拟IP地址，后续客户端无论何时发起请求消息报文，都只需向这个固定的虚拟IP地址发送即可，这样即便后期修改了负载均衡设备的实际IP地址，也不影响用户的使用，即用户无需记住负载均衡设备的实际IP地址，只需记住这个固定的虚拟IP地址即可。

相应地，为了便于对后端服务集群中服务节点的修改和替换，也可以为后端服务集群中的每一个服务节点分配一个固定的虚拟IP地址，这样无论后端服务集群中的服务节点发送怎样的变化，都不会影响负载均衡设备与后端服务集群中服务节点的交互。

关于如何为负载均衡设备分配虚拟IP地址、建立前端用户集群中各个客户端与负载均衡设备之间的通信连接，以及如何为后端服务集群中各个服务节点分配虚拟IP地址，并建立各个服务节点与负载均衡设备之间的通信连接，本领域技术人员可以根据需要设置，本实施例对此不做任何限制。

参考图3，图3为本发明一种负载均衡方法第二实施例的流程示意图。

基于上述第一实施例，本实施例负载均衡方法提供了一种对请求消息报文进行解密的具体处理方式，详见步骤S20中包括的子步骤S201至子步骤S204。

子步骤S201，判断所述TCP协议栈中缓存的请求消息报文是否是加密版请求消息报文。

具体的说，在实际应用中，为了尽可能保证通信过程的安全性，前端用户集群中的客户端发起的请求消息报文可能存在加密的情况。故而为了更好的保证本实施例提供的负载均衡方法的实现，所述应用层中的脚本引擎在对客户端发起的请求消息报文进行解析之前，所述负载均衡设备可以先判断一下缓存在所述TCP协议栈中的请求消息报文是否是加密版本请求消息报文。

相应地，若通过判断，确定所述TCP协议栈中缓存的请求消息报文是加密版请求消息报文，则进入子步骤S202，执行其内的操作；否则，直接进入子步骤S204，执行其内的操作。

子步骤S202，将所述TCP协议栈中的请求消息报文传输至预先部署的安全套接层SSL协议栈，由所述SSL协议栈对各请求消息报文进行解密，得到解密版请求消息报文。

具体的说，为了保证解密操作的顺利进行，在实际应用中，可以预先约定客户端发起的请求消息报文的加密规则，与负载均衡设备需要进行的解密规则，具体的实现，本实施例不做限制。

子步骤S203，通过应用层中的脚本引擎从所述SSL协议栈中读取解密版请求消息报文，对读取到的解密版请求消息报文进行解析，确定各请求消息报文的请求标识信息，并根据确定的请求标识信息生成请求标识信息集合。

子步骤S204，通过应用层中的脚本引擎从所述TCP协议栈中读取请求消息报文，对读取到的请求消息报文进行解析，确定各请求消息报文的请求标识信息，并根据确定的请求标识信息生成请求标识信息集合。

应当理解的是，以上给出的仅为一种具体的实现方式，对本发明的技术方案并不构成任何限定，在具体应用中，本领域的技术人员可以根据需要进行设置，本发明对此不做限制。

通过上述描述不难发现，本实施例提供的负载均衡方法，通过在应用层中设置SSL协议栈，从而在利用应用层中的脚本引擎对TCP协议栈中缓存的请求消息报文进行解析时，通过判断读取到的请求消息报文是否是加密版本的请求消息报文，在确定读取到的请求消息报文是加密版本的请求消息报文时，通过SSL协议栈对加密版本的请求消息报文进行解密获得解密版本请求消息报文，再由脚本引擎对解密版请求消息报文进行解析，从而在保证请求消息安全性的同时，也可以实现针对加密和非加密不同形式的请求消息报文的处理，使得负载均衡设备能够更好的应用于各种形式的任务处理。

此外，本发明实施例还提出一种计算机可读存储介质，所述计算机可读存储介质上存储有负载均衡程序，所述负载均衡程序被处理器执行时实现如上文所述的负载均衡方法的步骤。

参照图4，图4为本发明负载均衡装置第一实施例的结构框图。

如图4所示，本发明实施例提出的负载均衡装置包括：物理接口层和应用层。

进一步地，在本实施例中，所述应用层中预先部署有脚本引擎、反向代理和会话保持。

具体的，所述物理接口层，用于接收前端用户集群中客户端发送的请求消息报文，并将各请求消息报文缓存在TCP协议栈中；所述脚本引擎，用于从所述TCP协议栈中读取请求消息报文，对读取到的请求消息报文进行解析，确定各请求消息报文的请求标识信息，并根据确定的请求标识信息生成请求标识信息集合；所述反向代理，用于对所述请求标识信息集合进行遍历，根据遍历到的当前请求标识信息从所述请求消息报文中确定需要处理的目标请求消息报文；所述应用层还用于选取会话保持或反向代理作为目标服务节点确定对象；所述应用层中的会话保持或反向代理，还用于从后端服务集群中选取一个服务节点作为目标服务节点，并将所述目标请求消息报文发送至所述目标服务节点。

此外，值得一提的是，在实际应用中，上述所说的请求标识信息包括请求消息报文长度和请求消息报文标识号。

相应地，所述应用层中的会话保持或反向代理从后端服务集群中选取一个服务节点作为目标服务节点，并将所述目标请求消息报文发送至所述目标服务节点的操作，具体为：

通过所述应用层中的会话保持对预先构建的会话保持标识信息集合进行遍历，确定所述会话保持标识信息集合中是否存在所述目标请求消息报文的请求消息报文标识号，所述会话保持标识信息集合用于记载请求消息报文标识号和目标服务节点的服务节点信息之间的对应关系；

相应地，若所述会话保持标识信息集合中不存在所述目标请求消息报文的请求消息报文标识号，则通过所述应用层中的反向代理从后端服务集群中选取一个服务节点作为目标服务节点，并将所述目标请求消息报文发送至所述目标服务节点；若所述会话保持标识信息集合中存在所述目标请求消息报文的请求消息报文标识号，则通过所述应用层中的会话保持从后端服务集群中选取一个服务节点作为目标服务节点，并将所述目标请求消息报文发送至所述目标服务节点。

进一步地，在确定目标服务节点以及将目标请求消息报文发送至确定的目标服务节点的操作为所述应用层中的反向代理时，该确定目标服务节点和发送目标请求消息报文的操作具体为：

通过所述应用层中的会话保持从后端服务集群中选取一个服务节点作为目标服务节点，并将所述目标请求消息报文发送至所述目标服务节点。

相应地，在确定目标服务节点以及将目标请求消息报文发送至确定的目标服务节点的操作为所述应用层中的会话保持时，该确定目标服务节点和发送目标请求消息报文的操作具体为：

通过所述应用层中的会话保持从所述会话保持标识信息集合中获取所述请求消息报文标识对应的服务节点信息，将所述后端服务集群中所述服务节点信息对应的服务节点作为所述目标服务节点，通过所述应用层中的反向代理根据所述请求标识信息集合中记载的所述请求消息报文标识号对应的请求消息报文长度，从所述TCP协议栈中提取出所述目标请求消息报文，通过所述应用层中的会话保持将所述目标请求消息报文发送至所述目标服务节点。

进一步地，在实际应用中，在通过所述应用层中的会话保持或反向代理将所述目标请求消息报文发送至所述目标服务节点之后，还会涉及到接收后端服务集群中各服务节点返回的针对各目标请求消息报文作出的应答消息报文，故而为了能够将接收到的应答消息报文准确的反馈给前端用户集群中的客户端，在实际应用中所述负载均衡装置还会进行如下操作：

首先，通过所述物理接口层接收各目标服务节点返回的针对各目标请求消息报文作出的应答消息报文，并将各应答消息报文缓存在所述TCP协议栈中；

然后，通过所述应用层中的脚本引擎从所述TCP协议栈中读取应答消息报文，对读取到的应答消息报文进行解析，确定各应答消息报文的应答标识信息，并根据确定的应答标识信息生成应答标识信息集合；

接着，通过所述应用层中的反向代理对所述应答标识信息集合进行遍历，根据遍历到的当前应答标识信息确定目标应答消息报文；

最后，通过所述应用层中的会话保持或反向代理从所述前端用户集群中选取一个客户端作为接收所述目标应答消息报文的目标客户端，并将所述目标应答消息发送至所述目标客户端。

相应地，上述所说的应答标识信息与请求标识信息类似，主要包括应答消息报文长度和应答消息报文标识号。

相应地，所述通过所述应用层中的会话保持或反向代理从所述前端用户集群中选取一个客户端作为接收所述目标应答消息报文的目标客户端，并将所述目标应答消息发送至所述目标客户端的操作，具体为：

通过所述应用层中的会话保持对所述会话保持标识信息集合进行遍历，确定所述会话保持标识信息集合中是否存在所述目标应答消息报文的应答消息报文标识号，所述会话保持标识信息集合还用于记载应答消息报文标识号和目标客户端的客户端信息之间的对应关系；

相应地，若所述会话保持标识信息集合中不存在所述目标应答消息报文的应答消息报文标识号，则通过所述应用层中的反向代理从前端用户集群中选取一个客户端作为目标客户端，并将所述目标应答消息发送至所述目标客户端；若所述会话保持标识信息集合中存在所述目标应答消息报文的应答消息报文标识号，则通过所述应用层中的会话保持从前端用户集群中选取一个客户端作为目标客户端，并将所述目标应答消息发送至所述目标客户端。

进一步地，在确定目标客户端以及将目标应答消息报文发送至确定的目标客户端的操作为所述应用层中的反向代理时，该确定目标客户端和发送目标应答消息报文的操作具体为：

通过所述应用层中的反向代理获取所述前端用户集群中各客户端的负载状态，根据各客户端的负载状态和预设的客户端负载均衡标准从所述前端用户集群中选取一个客户端作为接收所述目标应答消息报文的目标客户端，并根据所述应答标识信息集合中记载的所述应答消息报文标识号对应的应答消息报文长度，从所述TCP协议栈中提取出所述目标应答消息报文，将所述目标应答消息报文发送至所述目标客户端；

相应地，在确定目标客户端以及将目标应答消息报文发送至确定的目标客户端的操作为所述应用层中的会话保持时，该确定目标客户端和发送目标应答消息报文的操作具体为：

通过所述应用层中的会话保持从所述会话保持标识信息集合中获取所述应答消息报文标识对应的客户端信息，将所述前端用户集群中所述客户端信息对应的客户端作为所述目标客户端，通过所述应用层中的反向代理根据所述应答标识信息集合中记载的所述应答消息报文标识号对应的应答消息报文长度，从所述TCP协议栈中提取出所述目标应答消息报文，通过所述应用层中的会话保持将所述目标应答消息报文发送至所述目标客户端。

此外，在通过所述应用层中的会话保持或反向代理将所述目标请求消息报文发送至所述目标服务节点时，为了更好的实现负载均衡，可以通过如下几个步骤实现：

首先，通过所述应用层中的会话保持或反向代理确定与所述目标服务节点之间可用的请求消息传输通道；

然后，通过所述应用层中的会话保持或反向代理根据预设的请求传输通道负载均衡标准，从所述可用的请求消息传输通道中确定目标请求消息传输通道，并采用所述目标请求消息传输通道将所述目标请求消息发送至所述目标服务节。

相应地，在通过所述应用层中的会话保持或反向代理将所述目标应答消息发送至所述目标客户端时，为了更好的实现负载均衡，可以通过如下几个步骤实现：

首先，通过所述应用层中的会话保持或反向代理确定与所述目标客户端之间可用的应答消息传输通道；

然后，通过所述应用层中的会话保持或反向代理根据预设的应答传输通道负载均衡标准，从所述可用的应答消息传输通道中确定目标应答消息传输通道，并采用所述目标应答消息传输通道将所述目标应答消息发送至所述目标客户端。

此外，值得一提的是，在实际应用中，为了能够保证述通过物理接口层接收前端用户集群中客户端发送的请求消息报文，同时保证能够通过所述应用层中的会话保持和反向代理从后端服务集群中选取一个服务节点作为目标服务节点，在执行上述两个操作之前，需要先建立负载均设备与前端用户集群中各客户端之间的通信连接，以及与后端服务集群中各服务节点之间的通信连接。

关于上述所说的负载均设备与前端用户集群中各客户端之间的通信连接，在本实施例中具体为TCP长连接。

具体的，关于建立所述负载均设备与前端用户集群中各客户端之间的TCP长连接的操作，可以大致分为如下三种：

基于单工原理，分别与所述前端用户集群中的各客户端建立TCP长连接；

或者，基于双工原理，分别与所述前端用户集群中的各客户端建立TCP长连接；

或者，基于半双工原理，分别与所述前端用户集群中的各客户端建立TCP长连接。

相应地，关于上述所说的负载均设备与后端服务集群中各服务节点之间的通信连接，在本实施例中同样可以为TCP长连接。

具体的，关于建立所述负载均设备与后端服务集群中各服务节点之间的TCP长连接的操作，同样可以大致分为如下三种：

基于单工原理，分别与所述后端服务集群中的各服务节点建立TCP长连接；

或者，基于双工原理，分别与所述后端服务集群中的各服务节点端建立TCP长连接；

或者，基于半双工原理，分别与所述后端服务集群中的各服务节点建立TCP长连接。

应当理解的是，以上给出的仅为一种具体的实现方式，对本发明的技术方案并不构成任何限定，在具体应用中，本领域的技术人员可以根据需要进行设置，本发明对此不做限制。

此外，本实施例中所涉及到的各模块均为逻辑模块，在实际应用中，一个逻辑单元可以是一个物理单元，也可以是一个物理单元的一部分，还可以以多个物理单元的组合实现。此外，为了突出本发明的创新部分，本实施例中并没有将与解决本发明所提出的技术问题关系不太密切的单元引入，但这并不表明本实施方式中不存在其它的单元。

通过上述描述不难发现，本实施例提供的负载均衡装置，通过利用应用层中的脚本引擎对接收到的请求消息报文进行解析，获得能够标识请求消息报文唯一性的请求标识信息，在确定处理不同请求消息报文的目标服务节点时，只关注请求消息报文的请求标识信息，不关注接收请求消息报文的TCP连接，从而可以将不同的请求消息报文分配给不同的服务节点处理，在保证负载均衡效果的同时，也大大提升了处理效率。

此外，值得一提的是，在实际应用中，为了尽可能方便操作前端用户集群中的客户端的用户，可以为负载均衡设备分配一个固定的虚拟IP地址，后续客户端无论何时发起请求消息报文，都只需向这个固定的虚拟IP地址发送即可，这样即便后期修改了负载均衡设备的实际IP地址，也不影响用户的使用，即用户无需记住负载均衡设备的实际IP地址，只需记住这个固定的虚拟IP地址即可。

相应地，为了便于对后端服务集群中服务节点的修改和替换，也可以为后端服务集群中的每一个服务节点分配一个固定的虚拟IP地址，这样无论后端服务集群中的服务节点发送怎样的变化，都不会影响负载均衡设备与后端服务集群中服务节点的交互。

关于如何为负载均衡设备分配虚拟IP地址、建立前端用户集群中各个客户端与负载均衡设备之间的通信连接，以及如何为后端服务集群中各个服务节点分配虚拟IP地址，并建立各个服务节点与负载均衡设备之间的通信连接，本领域技术人员可以根据需要设置，本实施例对此不做任何限制。

需要说明的是，以上所描述的工作流程仅仅是示意性的，并不对本发明的保护范围构成限定，在实际应用中，本领域的技术人员可以根据实际的需要选择其中的部分或者全部来实现本实施例方案的目的，此处不做限制。

另外，未在本实施例中详尽描述的技术细节，可参见本发明任意实施例所提供的负载均衡方法，此处不再赘述。

基于上述负载均衡装置的第一实施例，提出本发明负载均衡装置第二实施例。

在本实施例中，所述负载均衡装置还包括SSL协议栈。

具体的，所述SSL协议栈，用于在判定所述TCP协议栈中缓存的请求消息报文是加密版请求消息报文时，从所述TCP协议栈中读取缓存的请求消息报文，并对读取到的请求消息报文进行解密，进而获得解密版请求消息报文。

相应地，在判定所述TCP协议栈中缓存的请求消息报文是加密版请求消息报文时，所述脚本引擎会改变之前的从TCP协议栈中直接读取请求消息报文的方式，而是改为从SSL协议栈中读取解密版请求消息报文，然后对读取到的解密版请求消息报文进行解析，确定各请求消息报文的请求标识信息，得到请求标识信息集合。

应当理解的是，以上仅为举例说明，对本发明的技术方案并不构成任何限定，在具体应用中，本领域的技术人员可以根据需要进行设置，本发明对此不做限制。

此外，本实施例中所涉及到的各模块均为逻辑模块，在实际应用中，一个逻辑单元可以是一个物理单元，也可以是一个物理单元的一部分，还可以以多个物理单元的组合实现。此外，为了突出本发明的创新部分，本实施例中并没有将与解决本发明所提出的技术问题关系不太密切的单元引入，但这并不表明本实施方式中不存在其它的单元。

通过上述描述不难发现，本实施例提供的负载均衡装置，通过在应用层中设置SSL协议栈，从而在利用应用层中的脚本引擎对TCP协议栈中缓存的请求消息报文进行解析时，通过判断读取到的请求消息报文是否是加密版本的请求消息报文，在确定读取到的请求消息报文是加密版本的请求消息报文时，通过SSL协议栈对加密版本的请求消息报文进行解密获得解密版本请求消息报文，再由脚本引擎对解密版请求消息报文进行解析，从而在保证请求消息安全性的同时，也可以实现针对加密和非加密不同形式的请求消息报文的处理，使得负载均衡设备能够更好的应用于各种形式的任务处理。

需要说明的是，以上所描述的工作流程仅仅是示意性的，并不对本发明的保护范围构成限定，在实际应用中，本领域的技术人员可以根据实际的需要选择其中的部分或者全部来实现本实施例方案的目的，此处不做限制。

另外，未在本实施例中详尽描述的技术细节，可参见本发明任意实施例所提供的负载均衡方法，此处不再赘述。

此外，需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者系统中还存在另外的相同要素。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

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

以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (10)

1.一种负载均衡方法，其特征在于，所述方法包括以下步骤：

通过物理接口层接收前端用户集群中客户端发送的请求消息报文，并将各请求消息报文缓存在TCP协议栈中；

通过应用层中的脚本引擎从所述TCP协议栈中读取请求消息报文，对读取到的请求消息报文进行解析，确定各请求消息报文的请求标识信息，并根据确定的请求标识信息生成请求标识信息集合；

通过所述应用层中的反向代理对所述请求标识信息集合进行遍历，根据遍历到的当前请求标识信息从所述请求消息报文中确定需要处理的目标请求消息报文，所述请求标识信息包括请求消息报文长度和请求消息报文标识号；

通过所述应用层中的会话保持或反向代理从后端服务集群中选取一个服务节点作为目标服务节点，具体包括以下步骤：通过所述应用层中的会话保持对预先构建的会话保持标识信息集合进行遍历，确定所述会话保持标识信息集合中是否存在所述目标请求消息报文的请求消息报文标识号，所述会话保持标识信息集合用于记载请求消息报文标识号和目标服务节点的服务节点信息之间的对应关系，以及，根据所确定的结果，通过所述应用层中的会话保持或反向代理从后端服务集群中选取一个服务节点作为目标服务节点；

将所述目标请求消息报文发送至所述目标服务节点。

2.如权利要求1所述的方法，其特征在于，所述根据所确定的结果，通过所述应用层中的会话保持或反向代理从后端服务集群中选取一个服务节点作为目标服务节点，具体包括：

若所述会话保持标识信息集合中不存在所述目标请求消息报文的请求消息报文标识号，则通过所述应用层中的反向代理从后端服务集群中选取一个服务节点作为目标服务节点；

若所述会话保持标识信息集合中存在所述目标请求消息报文的请求消息报文标识号，则通过所述应用层中的会话保持从后端服务集群中选取一个服务节点作为目标服务节点。

3.如权利要求2所述的方法，其特征在于，所述通过所述应用层中的反向代理从后端服务集群中选取一个服务节点作为目标服务节点，并将所述目标请求消息报文发送至所述目标服务节点的步骤，包括：

通过所述应用层中的反向代理获取所述后端服务集群中各服务节点的负载状态，根据各服务节点的负载状态和预设的服务节点负载均衡标准从所述后端服务集群中选取一个服务节点作为处理所述目标请求消息报文的目标服务节点，并根据所述请求标识信息集合中记载的所述请求消息报文标识号对应的请求消息报文长度，从所述TCP协议栈中提取出所述目标请求消息报文，将所述目标请求消息报文发送至所述目标服务节点；

相应地，所述通过所述应用层中的会话保持从后端服务集群中选取一个服务节点作为目标服务节点，并将所述目标请求消息报文发送至所述目标服务节点的步骤，包括：

通过所述应用层中的会话保持从所述会话保持标识信息集合中获取所述请求消息报文标识对应的服务节点信息，将所述后端服务集群中所述服务节点信息对应的服务节点作为所述目标服务节点，通过所述应用层中的反向代理根据所述请求标识信息集合中记载的所述请求消息报文标识号对应的请求消息报文长度，从所述TCP协议栈中提取出所述目标请求消息报文，通过所述应用层中的会话保持将所述目标请求消息报文发送至所述目标服务节点。

4.如权利要求3所述的方法，其特征在于，所述将所述目标请求消息报文发送至所述目标服务节点的步骤之后，所述方法还包括：

通过所述物理接口层接收各目标服务节点返回的针对各目标请求消息报文作出的应答消息报文，并将各应答消息报文缓存在所述TCP协议栈中；

通过所述应用层中的脚本引擎从所述TCP协议栈中读取应答消息报文，对读取到的应答消息报文进行解析，确定各应答消息报文的应答标识信息，并根据确定的应答标识信息生成应答标识信息集合；

通过所述应用层中的反向代理对所述应答标识信息集合进行遍历，根据遍历到的当前应答标识信息确定目标应答消息报文；

通过所述应用层中的会话保持或反向代理从所述前端用户集群中选取一个客户端作为接收所述目标应答消息报文的目标客户端，并将所述目标应答消息发送至所述目标客户端。

5.如权利要求4所述的方法，其特征在于，所述应答标识信息包括应答消息报文长度和应答消息报文标识号；

所述通过所述应用层中的会话保持或反向代理从所述前端用户集群中选取一个客户端作为接收所述目标应答消息报文的目标客户端，并将所述目标应答消息发送至所述目标客户端的步骤，包括：

通过所述应用层中的会话保持对所述会话保持标识信息集合进行遍历，确定所述会话保持标识信息集合中是否存在所述目标应答消息报文的应答消息报文标识号，所述会话保持标识信息集合还用于记载应答消息报文标识号和目标客户端的客户端信息之间的对应关系；

若所述会话保持标识信息集合中不存在所述目标应答消息报文的应答消息报文标识号，则通过所述应用层中的反向代理从所述前端用户集群中选取一个客户端作为接收所述目标应答消息报文的目标客户端，并将所述目标应答消息发送至所述目标客户端；

若所述会话保持标识信息集合中存在所述目标应答消息报文的应答消息报文标识号，则通过所述应用层中的会话保持从所述前端用户集群中选取一个客户端作为接收所述目标应答消息报文的目标客户端，并将所述目标应答消息发送至所述目标客户端。

6.如权利要求5所述的方法，其特征在于，所述将所述目标请求消息报文发送至所述目标服务节点的步骤，包括：

确定与所述目标服务节点之间可用的请求消息传输通道；

根据预设的请求传输通道负载均衡标准，从所述可用的请求消息传输通道中确定目标请求消息传输通道，并采用所述目标请求消息传输通道将所述目标请求消息发送至所述目标服务节点；

相应地，所述将所述目标应答消息发送至所述目标客户端的步骤，包括：

确定与所述目标客户端之间可用的应答消息传输通道；

根据预设的应答传输通道负载均衡标准，从所述可用的应答消息传输通道中确定目标应答消息传输通道，并采用所述目标应答消息传输通道将所述目标应答消息发送至所述目标客户端。

7.如权利要求1至6任一项所述的方法，其特征在于，所述通过应用层中的脚本引擎从所述TCP协议栈中读取请求消息报文，对读取到的请求消息报文进行解析，确定各请求消息报文的请求标识信息，并根据确定的请求标识信息生成请求标识信息集合的步骤，包括：

判断所述TCP协议栈中缓存的请求消息报文是否是加密版请求消息报文；

若所述TCP协议栈中缓存的请求消息报文是加密版请求消息报文，则将所述TCP协议栈中的请求消息报文传输至预先部署的安全套接层SSL协议栈，由所述SSL协议栈对各请求消息报文进行解密，得到解密版请求消息报文；

通过应用层中的脚本引擎从所述SSL协议栈中读取解密版请求消息报文，对读取到的解密版请求消息报文进行解析，确定各请求消息报文的请求标识信息，并根据确定的请求标识信息生成请求标识信息集合。

8.一种负载均衡装置，其特征在于，所述装置包括：物理接口层和应用层；

所述应用层部署有脚本引擎、反向代理和会话保持；

所述物理接口层，用于接收前端用户集群中客户端发送的请求消息报文，并将各请求消息报文缓存在TCP协议栈中；

所述脚本引擎，用于从所述TCP协议栈中读取请求消息报文，对读取到的请求消息报文进行解析，确定各请求消息报文的请求标识信息，并根据确定的请求标识信息生成请求标识信息集合；

所述反向代理，用于对所述请求标识信息集合进行遍历，根据遍历到的当前请求标识信息从所述请求消息报文中确定需要处理的目标请求消息报文，所述请求标识信息包括请求消息报文长度和请求消息报文标识号；

所述应用层中的会话保持，用于对预先构建的会话保持标识信息集合进行遍历，确定所述会话保持标识信息集合中是否存在所述目标请求消息报文的请求消息报文标识号，所述会话保持标识信息集合用于记载请求消息报文标识号和目标服务节点的服务节点信息之间的对应关系；

所述应用层中的会话保持或反向代理，还用于根据所确定的结果从后端服务集群中选取一个服务节点作为目标服务节点，将所述目标请求消息报文发送至所述目标服务节点。

9.一种负载均衡设备，其特征在于，所述设备包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的负载均衡程序，所述负载均衡程序配置为实现如权利要求1至7中任一项所述的负载均衡方法的步骤。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有负载均衡程序，所述负载均衡程序被处理器执行时实现如权利要求1至7任一项所述的负载均衡方法的步骤。

Images