CN117793114A - 一种负载均衡方法、装置、计算机可读存储介质及设备 - Google Patents

Abstract

本申请公开了一种负载均衡方法、装置、计算机可读存储介质及设备。该方法应用于客户端，包括：应用层接收业务请求；将所述业务请求通过协议栈传输至数据链路层；所述数据链路层根据负载均衡策略对所述业务请求进行处理，将过滤后的业务请求发送至所述客户端的传输层；所述传输层将处理后的业务请求传输至所述目标服务器；其中所述传输层在所述应用层接收业务请求之前，确定目标服务器并与所述目标服务器建立连接；所述传输层将所述响应数据通过协议栈传输发送至所述数据链路层；所述数据链路层将所述响应数据还原后传输至所述应用层。

Description

一种负载均衡方法、装置、计算机可读存储介质及设备

技术领域

本申请涉及互联网通信技术领域，尤其涉及一种负载均衡方法、装置、计算机可读存储介质及设备。

背景技术

随着互联网的高速发展，服务器的负载越来越高，对此，通常将多台服务器组成一个集群对外提供服务。但是，如此并不能很好的解决所有负载问题。举例说明，网站对外提供的访问入口只有一个，例如：http://www.baidu.com，那么当用户在浏览器输入http://www.baidu.com的时候，如何将用户的请求分发至集群中不同的机器上，因此，出现了负载均衡问题。

现有传统负载均衡方案通常是采用服务端负载的方式，具体的，在服务器前架设负载均衡设备，作为统一流量入口接收用户请求，然后再将用户请求根据特定算法分发至各个原始的服务器。该方式非常依赖客户端侧参数，例如：请求已经分发到某负载节点的请求数量、某节点响应时间等。

客户端负载均衡技术则是每个发起服务调用的客户端都存有完整的目标服务地址列表，根据配置负载均衡策略，由客户端自己决定向那台服务器发起调用。与服务器端负载均衡相比，客户端负载均衡减轻了服务器的压力，减少了与服务器的交互次数，降低了网络流量，但是客户端和业务逻辑强相关，实用性不强，并且客户端通常需做较多的改动，例如：根据连接不同服务器的需求需在客户端创建不同的服务完成相关功能，增加了客户端的复杂性，因此，该方式未能兼顾负载端侧CPU使用率等运行情况，无法实现真正意义上的负载均衡。

发明内容

本申请实施例为了解决现有技术中存在的上述问题，提供一种负载均衡方法、装置、计算机可读存储介质及设备。

根据本申请第一方面，提供了一种负载均衡方法，应用于客户端，所述方法包括：应用层接收业务请求；将所述业务请求通过协议栈传输至数据链路层；所述数据链路层根据负载均衡策略对所述业务请求进行处理，将过滤后的业务请求发送至所述客户端的传输层；所述传输层将处理后的业务请求传输至所述目标服务器；其中所述传输层在所述应用层接收业务请求之前，确定目标服务器并与所述目标服务器建立连接；所述传输层将响应数据通过协议栈传输发送至所述数据链路层；所述数据链路层将所述响应数据还原后传输至所述应用层。

根据本申请一实施方式，所述传输层在所述应用层接收业务请求之前，确定目标服务器并与所述目标服务器建立连接，包括：通过所述传输层向服务器端发送查询请求，获取服务器端的多个服务器节点的负载均衡策略；获取所述服务器端的多个服务器节点的服务器核心参数和当前状态；根据所述负载均衡策略、所述服务器核心参数和所述当前状态，确定多个服务器节点中响应于所述查询请求的目标服务器；在数据链路层和传输层同时构建对所述业务请求的监听端口；通过所述监听接口监听业务请求。

根据本申请一实施方式，所述负载均衡策略包括以下至少之一：优先选择多个所述服务器节点中连接客户端数最少的一者作为目标服务器；优先选择多个所述服务器节点中响应时间小于设定时间的一者作为目标服务器；优先选择多个所述服务器节点中CPU使用率小于设定使用率的一者作为目标服务器；优先选择多个所述服务器节点中CPU参数符合预设CPU需求的一者作为目标服务器；优先选择多个所述服务器节点中内存大于设定内存的一者作为目标服务器。

根据本申请一实施方式，在所述通过所述传输层向服务器端发送查询请求之前，所述方法还包括：对所述多个服务器节点进行数据同步。

根据本申请一实施方式，所述对所述多个服务器节点进行数据同步，包括以下之一：通过广播和远程过程调用方式实现数据同步；将其中一个服务器节点作为配置节点，实现数据同步。

根据本申请一实施方式，所述根据所述负载均衡策略、所述服务器核心参数和所述当前状态，确定多个服务器节点中响应于所述查询请求的目标服务器，包括：在所述服务器节点的数量为1时，将所述服务器节点确定为目标服务器；在所述服务器节点的数量大于1时，将所述多个服务器节点中服务器核心参数和当前状态均符合所述负载均衡策略的服务器节点确定为目标服务器。

根据本申请一实施方式，所述通过所述监听接口监听业务请求，包括：通过所述数据链路层所构建的监听端口监听所述业务请求；通过所述传输层构建的监听端口，监听所述数据链路层对所述业务请求进行处理后的请求数据。

根据本申请第二方面，还提供了一种负载均衡装置，所述装置包括：接收模块，用于应用层接收业务请求；第一传输模块，用于将所述业务请求通过协议栈传输至数据链路层；请求处理模块，用于所述数据链路层根据负载均衡策略对所述业务请求进行处理，将过滤后的业务请求发送至所述客户端的传输层；第二传输模块，用于所述传输层将处理后的业务请求传输至所述目标服务器；其中，所述传输层在所述应用层接收业务请求之前，确定目标服务器并与所述目标服务器建立连接；数据发送模块，用于所述传输层将所述响应数据通过协议栈传输发送至所述数据链路层；还原传输模块，用于所述数据链路层将所述响应数据还原后传输至所述应用层。

根据本申请第三方面，又提供了一种计算机可读存储介质，所述存储介质包括一组计算机可执行指令，当所述指令被执行时用于执行上述任意所述负载均衡方法。

根据本申请第四方面，又提供了一种设备，所述设备包括至少一个处理器、以及与所述处理器连接的至少一个存储器、总线；其中，所述处理器、所述存储器通过所述总线完成相互间的通信；所述处理器用于调用所述存储器中的程序指令，以执行本申请上述负载均衡方法。

本申请实施例负载均衡方法、装置、计算机可读存储介质及设备中，负载均衡方法应用于客户端，该方法包括：应用层接收业务请求；将所述业务请求通过协议栈传输至数据链路层；所述数据链路层根据负载均衡策略对所述业务请求进行处理，将过滤后的业务请求发送至所述客户端的传输层；所述传输层将处理后的业务请求传输至所述目标服务器；其中所述传输层在所述应用层接收业务请求之前，确定目标服务器并与所述目标服务器建立连接；所述传输层将所述响应数据通过协议栈传输发送至所述数据链路层；所述数据链路层将所述响应数据还原后传输至所述应用层。如此，整个处理过程对上层应用无感知，有效提升用户体验，并且本申请中客户端所有发起的链接均通过代理转发，使得客户端连接数可控，进一步的，客户端位于传输层之下，与具体业务实现了解耦，具备更广泛的实用性。

需要理解的是，本申请的教导并不需要实现上面所述的全部有益效果，而是特定的技术方案可以实现特定的技术效果，并且本申请的其他实施方式还能够实现上面未提到的有益效果。

附图说明

通过参考附图阅读下文的详细描述，本申请示例性实施方式的上述以及其他目的、特征和优点将变得易于理解。在附图中，以示例性而非限制性的方式示出了本申请的若干实施方式，其中：

在附图中，相同或对应的标号表示相同或对应的部分。

图1示出了常规技术中的负载均衡方案应用场景示意图；

图2示出了本申请实施例负载均衡方法的具体应用场景示意图；

图3示出了本申请实施例负载均衡方法的实现流程示意图；

图4示出了本申请实施例OSI网络模型数据发送端和数据接收端进行数据传输过程中的数据封装过程示意图；

图5示出了本申请实施例的应用场景OSI(Open Systems Interconnectionmodel，计算机网络的一种概念模型)网络的示意图；

图6示出了本申请实施例负载均衡方法的又一具体应用场景示意图；

图7示出了本申请实施例的监听原理示意图；

图8示出了在传输层构建对所述业务请求的监听端口之后传输层的监听原理示意图；

图9示出了本申请实施例负载均衡方法的一具体应用示例的实现流程示意图；

图10示出了本申请实施例提供的负载均衡装置的组成结构示意图。

具体实施方式

下面将参考若干示例性实施方式来描述本申请的原理和精神。应当理解，给出这些实施方式仅仅是为使本领域技术人员能够更好地理解进而实现本申请，而并非以任何方式限制本申请的范围。相反，提供这些实施方式是为使本申请更加透彻和完整，并能够将本申请的范围完整地传达给本领域的技术人员。

下面结合附图和具体实施例对本申请的技术方案进一步详细阐述。

这里，为了更好的对本申请的技术方案进行描述，首先对本申请的具体应用场景进行简单说明，图1示出了常规技术中的负载均衡方案应用场景示意图；

图2示出了本申请实施例负载均衡方法的具体应用场景示意图。参考图1和图2，本申请实施例负载均衡方法的具体应用场景与常规技术中的负载均衡方案应用场景的最大区别就在于本申请实施例中不再配置集中的负载均衡设备。

图3示出了本申请实施例负载均衡方法的实现流程示意图。

参考图3，本申请实施例负载均衡方法，应用于客户端，至少包括如下操作流程：操作301，应用层接收业务请求；操作302，将业务请求通过协议栈传输至数据链路层；操作303，数据链路层根据负载均衡策略对业务请求进行处理，将过滤后的业务请求发送至客户端的传输层；操作304，传输层将处理后的业务请求传输至目标服务器；其中传输层在应用层接收业务请求之前，确定目标服务器并与目标服务器建立连接；操作305，传输层将响应数据通过协议栈传输发送至数据链路层；操作306，数据链路层将响应数据还原后传输至应用层。

在操作301中，应用层接收业务请求。

在本申请这一实施例中，用户通过客户端的即时聊天窗口、网页窗口等具体应用输入或点击需要打开的内容，即认为客户端的应用层接收到业务请求。

在操作302中，将业务请求通过协议栈传输至数据链路层。

在本申请这一实施例中，将业务请求通过协议栈自顶向下封包，在数据传输过程中，数据接收端和数据发送端的同一个的各个进程或程序均是独立的。参考图4所示，客户端可以是数据接收端或者数据发送端。这里，将图4中将右侧数据接收端简称R，右侧数据接收端简称为R，当S需要通过TCP(Transmission Control Protocol，传输控制协议)等协议向R发送数据时，将协议栈自顶向下封包，直至传输至数据链路层。

在操作303中，数据链路层根据负载均衡策略对业务请求进行处理，将过滤后的业务请求发送至客户端的传输层。

在本申请这一实施方式中，负载均衡策略可以包括以下至少之一：优先选择多个服务器节点中连接客户端数最少的一者作为目标服务器；优先选择多个服务器节点中响应时间小于设定时间的一者作为目标服务器；优先选择多个服务器节点中CPU使用率小于设定使用率的一者作为目标服务器；优先选择多个服务器节点中CPU参数符合预设CPU需求的一者作为目标服务器；以及优先选择多个服务器节点中内存大于设定内存的一者作为目标服务器。

在本申请这一实施方式中，在通过传输层向服务器端发送查询请求之前，方法还包括：对多个服务器节点进行数据同步。

在本申请这一实施方式中，可以通过广播和远程过程调用方式实现数据同步，或者将其中一个服务器节点作为配置节点实现数据同步，由此实现对多个服务器节点进行数据同步。

在本申请这一实施方式中，在服务器节点的数量为1时，将服务器节点确定为目标服务器；在服务器节点的数量大于1时，将多个服务器节点中服务器核心参数和当前状态均符合负载均衡策略的服务器节点确定为目标服务器。以此实现根据负载均衡策略、服务器核心参数和当前状态，确定多个服务器节点中响应于查询请求的目标服务器。

在本申请这一实施方式中，通过数据链路层所构建的监听端口监听业务请求，并通过传输层构建的监听端口，监听数据链路层对业务请求进行处理后的请求数据。以此实现通过监听接口监听业务请求。

图5示出了本申请实施例的应用场景OSI(Open Systems Interconnectionmodel，计算机网络的一种概念模型)网络的示意图，参考图5所示，OSI模型包括Application(应用层)、Presentation(表示层)、Session(会话层)、Transport(传输层)、Network(网络层)、Data Link(数据链路层)、Physical(物理层)，其中数据发送端和数据接收端可以通过物理层的铜缆、光纤、无线信号等Physical Medium(物理介质)进行数据传输。在本申请这一实施例中，在OSI网络模型的数据链路层配置Filter(过滤器)。

这里首先对如何为业务请求配置最佳的服务器节点进行说明。客户端通过加密协议(https)向服务器发起查询请求，获取负载均衡策略，负载均衡策略通过以下操作预先配置：当服务器节点加入集群后，服务器端集群节点之间通过组播和远程过程调用的方式定时同步数据，保证集群中各个节点数据一致。其中，集群中各个服务器节点的负载均衡数据同步实现的可以通过UDP(User Datagram Protocol，用户数据报协议)等方式适宜的方式进行广播。例如：所有加入集群的服务器节点监听一个组播地址，集群中任一服务器节点均定时广播该服务器节点负载均衡数据，以保证各节点之间一致性。由此，在客户端通过加密http协议向服务器节点发起查询请求时，即可在查询到负载均衡数据后，根据节点算法、各节点当前状态选择最佳节点做业务，以实现负载分流。

具体的，可以在数据链路层最终向服务器群节点发出业务请求之前，先遍历GatewayLoadList(网关负载列表)向量，根据指定指标项计算出最优的负载端服务器节点。其中，服务器节点的选择过程可以默认根据节点最小用户数判断当前节点是否为最优节点，同时还可以指定CPU、内存、网络连接、在线用户数等信息等其他指标作为选择指标。此外，用户还可以根据业务场景需要赋予不同参数相应权重，做进一步细粒度精准负载均衡。由此，数据链路层获取集群服务器节点状态，综合集群中多个服务器节点的资源，确定最优的服务器节点。从而将常见的集中式服务端负载功能分布于各个客户端实现，同时在服务器端设置了通过UDP广播同步服务器节点的负载状态信息广播，客户端和服务器通讯一次即可获取集群内所有服务器节点状态，有效避免客户端需要与每个服务器进行一次通讯获取服务器状态，显著减少客户端和服务器通讯次数。进一步的，数据链路层除了基于业务请求信息对服务器节点进行选择和配置之外，还充分考虑集群中多个服务器节点的负载状态信息，有效解决了常规的负载状体信息不对称导致的负载策略不够合理等问题。例如：通过上述操作，有效避免“节点Node1在集群节点中请求连接数和响应时间均为最优，但是CPU使用率已经达到99％，此时Node1已经不再适合接收请求，但是若仅根据业务请求信息进行服务器节点选择和配置时，仍旧选择服务器节点Node1作为负载端服务器节点带来的响应速度慢等问题”。

此外，基于上述操作集群中多个服务器节点之间为对等关系，服务器节点之间通过广播和远程过程调用的方式实现数据同步，对网络带宽有一定占用。这里还可以如图6所示将其中一个服务器节点作为专门的配置服务器节点，存储本集群中其他的服务器节点的负载状态信息，集群中其他的服务器节点固定向专门的配置服务器节点定时发送负载信息数据，客户端发送业务请求时，无需访问集群列表多个服务器中的任意服务器节点，而是定向访问专门的配置服务器节点即可。客户端的其他处理逻辑同上述操作，此处不再赘述。

在操作304中，传输层将处理后的业务请求传输至目标服务器；其中传输层在应用层接收业务请求之前，确定目标服务器并与目标服务器建立连接。

在本申请这一实施方式中，可以通过传输层向服务器端发送查询请求，获取服务器端的多个服务器节点的负载均衡策略以及服务器端的多个服务器节点的服务器核心参数和当前状态，并根据负载均衡策略、服务器核心参数和当前状态，确定多个服务器节点中响应于查询请求的目标服务器。进一步的，在数据链路层和传输层同时构建对业务请求的监听端口，并通过监听接口监听业务请求。由此，传输层在应用层接收业务请求之前，确定目标服务器并与目标服务器建立连接。

图7示出了本申请实施例的监听原理示意图。参考图7，客户端的数据链路层从服务器端获取到服务器负载状态信息，并确定最佳的服务器节点之后，将通过“ProtocolBinding(协议绑定)→Filter Module(过滤器模块)→Virtual Miniport IntermediateDriver(虚拟微型端口中间驱动程序)→Protocol Edge(协议边缘)→Filter Module(过滤器模块)→Miniport Adapter(微型端口适配器)”在本地数据链路层和传输层同时启动监听，执行监听操作，同时将服务器节点的负载状态信息下发给监听进程。用户通过客户端发送业务请求至服务器节点时，监听进程拦截到业务请求的数据包，根据预设的规则对业务请求进行过滤，并将过滤之后的请求转发至目标服务器。

传输层监听的目的是为了不违背分层理念(每一层只做每一层该干的事)的情况下实现无感知负载，即流量的定向分发。图8示出了在传输层构建对业务请求的监听端口之后传输层的监听原理示意图，参考图8，传输层监听可以理解为本地代理，数据链路层拦截到目标消息后将信息发送到本地代理，本地代理最终将数据发往目标服务器。例如：数据发送端的IP地址是192.168.1.1，数据接收端的IP地址为192.168.1.4，即时对话应用的端口是80，即时对话应用有2个服务器节点，IP分别为192.168.1.2和192.168.1.3。此时IP为192.168.1.1的数据发送端向IP为192.168.1.4的数据接收端发送消息，消息实际上通过即时对话应用的服务器转发给数据接收端。本方案为了实现即时对话应用的信息负载均衡，本质上是捕获了目的地址为192.168.1.4端口为80的信息，然后通过选择最佳服服务器节点之后发送至IP为192.168.1.2的服务器节点或者IP为192.168.1.3的服务器节点。

在操作305中，传输层将响应数据通过协议栈传输发送至数据链路层。

在本申请这一实施例中，传输层将处理后的业务请求传输至目标服务器之后，目标服务器将对业务请求进行响应，确定响应数据，并通过目标服务器的传输层传输至客户端的传输层，目标客户端的传输层将响应数据通过协议栈传输发送至客户端数据链路层。

在操作306中，数据链路层将响应数据还原后传输至应用层。

在本申请这一实施例中，目标客户端的传输层将响应数据通过协议栈传输发送至客户端数据链路层之后，数据链路层将响应数据还原后传输至应用层。这里操作306和操作307的数据传输过程也可以参考图4所示本申请实施例OSI网络模型数据发送端和数据接收端进行数据传输过程中的数据封装过程示意图，此处不再赘述。

如此，客户端完成认证登录后，通过应用层接收业务请求，该业务请求将沿协议栈依次向下传递直到数据链路层。数据链路层根据负载均衡策略动态的控制和过滤业务请求，数据链路层检测到业务请求时，将从客户端的应用层、表示层、会话层、传输层和网络层依次发送至数据链路层的目标数据包重定向至传输层预先构建的监听接口，这里业务请求携带目标数据包。客户端的传输层在服务器端和目标服务器相连，对目标数据包进行数据过滤、压缩、加密等处理后传输至目标服务器。目标服务器对业务请求的响应数据传输至客户端的传输层通道接收后，经由协议栈向下发送给数据链路层，并通过物理层将数据层传输至客户端，客户端的数据链路层从物理层接收响应数据后，对响应数据进行还原并转发至客户端的应用层，例如：业务请求的发起者web浏览器等。由此，本申请结合驱动层技术，解决了客户端和业务请求的逻辑强相关问题，通过数据链路层驱动拦截技术，将用户通过应用层等TCP(传输控制协议)层以上发起的业务请求以及相应的目标数据包，统一转发至目标服务端，对业务请求等负载的传输和对业务请求的响应数据的传输，对于客户端的应用层均是拥挤透明无感知的，显著提升了用户体验。

图9示出了本申请实施例负载均衡方法的一具体应用示例的实现流程示意图。

参考图9，本申请实施例这一具体应用示例提供的负载均衡方法，至少包括如下操作流程：

操作901，输入任意网关节点地址。

这里输入网关节点地址即为“客户端通过加密协议(https)向服务器发起查询请求”，可以理解为客户端有业务查询请求。需要在接下来的操作中输入业务请求。需要基于该业务查询请求确定目标服务器。

操作902，拉取服务端集群中多个服务器节点的负载状态信息。

这里，客户端，获取负载均衡策略。

操作903，判断各个服务器节点是否支持负载。

若是，则执行操作904。若否，则停止操作，此时可以返回操作901再次输入网关节点地址，也可以直接停止处理，可以根据实际需求进行设定。

操作904，解析服务端各个服务器节点的负载状态信息。

操作905，确定最合适的服务器节点作为目标服务器。

这里，操作904和操作905中，根据预先获取的集群各节点服务器核心参数、各节点当前状态选择最佳节点建立连接，同时启动监听端口。

操作906，切换至目标服务器执行后续操作。

在检测到业务请求时，客户端数据链路层对业务请求进行拦截甄别，然后监听端口监听并将业务请求发送至目标服务器。

其中，图9所示具体应用示例的其他具体实现过程与图1所示实施例的具体实现过程相类似，这里不再赘述。

本申请实施例负载均衡方法、装置、计算机可读存储介质及设备中，负载均衡方法应用于客户端，该方法包括：应用层接收业务请求；将业务请求通过协议栈传输至数据链路层；数据链路层根据负载均衡策略对业务请求进行处理，将过滤后的业务请求发送至客户端的传输层；传输层将处理后的业务请求传输至目标服务器；其中传输层在应用层接收业务请求之前，确定目标服务器并与目标服务器建立连接；传输层将响应数据通过协议栈传输发送至数据链路层；数据链路层将响应数据还原后传输至应用层。如此，整个处理过程对上层应用无感知，有效提升用户体验，并且本申请中客户端所有发起的链接均通过代理转发，使得客户端连接数可控，进一步的，客户端位于传输层之下，与具体业务实现了解耦，具备更广泛的实用性。

同理，基于上文负载均衡方法，本申请实施例还提供一种计算机可读存储介质，计算机可读存储介质存储有程序，当程序被处理器执行时，使得处理器至少执行如下的操作步骤：操作301，应用层接收业务请求；操作302，将业务请求通过协议栈传输至数据链路层；操作303，数据链路层根据负载均衡策略对业务请求进行处理，将过滤后的业务请求发送至客户端的传输层；操作304，传输层将处理后的业务请求传输至目标服务器；其中传输层在应用层接收业务请求之前，确定目标服务器并与目标服务器建立连接；操作305，传输层将响应数据通过协议栈传输发送至数据链路层；操作306，数据链路层将响应数据还原后传输至应用层。

进一步，基于如上文负载均衡方法，本申请实施例还提供了一种负载均衡装置，如图10，该装置100包括：接收模块1001，用于应用层接收业务请求；第一传输模块1002，用于将业务请求通过协议栈传输至数据链路层；请求处理模块1003，用于数据链路层根据负载均衡策略对业务请求进行处理，将过滤后的业务请求发送至客户端的传输层；第二传输模块1004，用于传输层将处理后的业务请求传输至目标服务器；其中，传输层在应用层接收业务请求之前，确定目标服务器并与目标服务器建立连接；数据发送模块1005，用于传输层将响应数据通过协议栈传输发送至数据链路层；还原传输模块1006，用于数据链路层将响应数据还原后传输至应用层。

更进一步，基于如上文负载均衡方法，本申请实施例还提供了一种设备(图中未示出)，该设备包括至少一个处理器、以及与处理器连接的至少一个存储器、总线；其中，处理器、存储器通过总线完成相互间的通信；处理器用于调用存储器中的程序指令，以执行本申请上述负载均衡方法。

这里需要指出的是：以上对针对负载均衡装置及设备实施例的描述，与前述图1至9所示的方法实施例的描述是类似的，具有同前述图1至9所示的方法实施例相似的有益效果，因此不做赘述。对于本申请负载均衡装置及设备实施例中未披露的技术细节，请参照本申请前述图1至9所示的方法实施例的描述而理解，为节约篇幅，因此不再赘述。

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

在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。

上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显示的部件可以是、或也可以不是物理单元；既可以位于一个地方，也可以分布到多个网络单元上；可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。

另外，在本申请各实施例中的各功能单元可以全部集成在一个处理单元中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

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

或者，本申请上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本申请各个实施例方法的全部或部分。而前述的存储介质包括：移动存储设备、ROM、磁碟或者光盘等各种可以存储程序代码的介质。

以上，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。

Claims (10)

1.一种负载均衡方法，应用于客户端，其特征在于，所述方法包括：

应用层接收业务请求；

将所述业务请求通过协议栈传输至数据链路层；

所述数据链路层根据负载均衡策略对所述业务请求进行处理，将过滤后的业务请求发送至所述客户端的传输层；

所述传输层将处理后的业务请求传输至所述目标服务器；其中所述传输层在所述应用层接收业务请求之前，确定目标服务器并与所述目标服务器建立连接；

所述传输层将响应数据通过协议栈传输发送至所述数据链路层；

所述数据链路层将所述响应数据还原后传输至所述应用层。

2.根据权利要求1所述的方法，其特征在于，所述传输层在所述应用层接收业务请求之前，确定目标服务器并与所述目标服务器建立连接，包括：

通过所述传输层向服务器端发送查询请求，获取服务器端的多个服务器节点的负载均衡策略；

获取所述服务器端的多个服务器节点的服务器核心参数和当前状态；

根据所述负载均衡策略、所述服务器核心参数和所述当前状态，确定多个服务器节点中响应于所述查询请求的目标服务器；

在数据链路层和传输层同时构建对所述业务请求的监听端口；

通过所述监听接口监听业务请求。

3.根据权利要求1所述的方法，其特征在于，所述负载均衡策略包括以下至少之一：

优先选择多个所述服务器节点中连接客户端数最少的一者作为目标服务器；

优先选择多个所述服务器节点中响应时间小于设定时间的一者作为目标服务器；

优先选择多个所述服务器节点中CPU使用率小于设定使用率的一者作为目标服务器；

优先选择多个所述服务器节点中CPU参数符合预设CPU需求的一者作为目标服务器；

优先选择多个所述服务器节点中内存大于设定内存的一者作为目标服务器。

4.根据权利要求2所述的方法，其特征在于，在所述通过所述传输层向服务器端发送查询请求之前，所述方法还包括：

对所述多个服务器节点进行数据同步。

5.根据权利要求4所述的方法，其特征在于，所述对所述多个服务器节点进行数据同步，包括以下之一：

通过广播和远程过程调用方式实现数据同步；

将其中一个服务器节点作为配置节点，实现数据同步。

6.根据权利要求2所述的方法，其特征在于，所述根据所述负载均衡策略、所述服务器核心参数和所述当前状态，确定多个服务器节点中响应于所述查询请求的目标服务器，包括：

在所述服务器节点的数量为1时，将所述服务器节点确定为目标服务器；

在所述服务器节点的数量大于1时，将所述多个服务器节点中服务器核心参数和当前状态均符合所述负载均衡策略的服务器节点确定为目标服务器。

7.根据权利要求2所述的方法，其特征在于，所述通过所述监听接口监听业务请求，包括：

通过所述数据链路层所构建的监听端口监听所述业务请求；

通过所述传输层构建的监听端口，监听所述数据链路层对所述业务请求进行处理后的请求数据。

8.一种负载均衡装置，其特征在于，所述装置包括：

接收模块，用于应用层接收业务请求；

第一传输模块，用于将所述业务请求通过协议栈传输至数据链路层；

请求处理模块，用于所述数据链路层根据负载均衡策略对所述业务请求进行处理，将过滤后的业务请求发送至所述客户端的传输层；

第二传输模块，用于所述传输层将处理后的业务请求传输至所述目标服务器；其中，所述传输层在所述应用层接收业务请求之前，确定目标服务器并与所述目标服务器建立连接；

数据发送模块，用于所述传输层将响应数据通过协议栈传输发送至所述数据链路层；

还原传输模块，用于所述数据链路层将所述响应数据还原后传输至所述应用层。

9.一种计算机可读存储介质，其特征在于，所述存储介质包括一组计算机可执行指令，当所述指令被执行时用于执行权利要求1-7中任一项所述的负载均衡方法。

10.一种设备，所述设备包括至少一个处理器、以及与所述处理器连接的至少一个存储器、总线；其中，所述处理器、所述存储器通过所述总线完成相互间的通信；所述处理器用于调用所述存储器中的程序指令，以执行权利要求1-7中任一项所述的负载均衡方法。