CN104994093B - 一种服务负载均衡方法及系统 - Google Patents

Abstract

本发明提供一种服务负载均衡方法及系统。服务负载均衡方法包括：服务端通过统一的代理端口号接收客户端的请求报文，请求报文包括连接请求报文或应用请求报文，根据连接请求报文建立服务端与客户端的连接，并为所建立的连接在内核中创建一个连接管理结构，连接管理结构中保存有与客户端的连接相关信息；当服务端接收到一个应用请求报文时，在内核空间为应用请求报文选择一个可用的端口号，根据发送应用请求报文的客户端对应的连接相关信息建立所选择的端口号与所述客户端的一个socket通道；端口号对应的应用服务实例根据应用请求报文提供相应的服务，并通过socket通道将服务结果反馈给客户端。本发明的技术方案能够大大提高系统效率。

Description

一种服务负载均衡方法及系统

技术领域

本发明涉及一种计算机技术，特别是涉及一种服务负载均衡方法及系统。

背景技术

在计算机网络连接中，需要使用操作系统内核协议栈，最常用的就是TCP协议。当网络通信繁重时，需要对网络通信产生的负载进行均衡。通常可以采用的负载均衡方法主要通过报文中有意义的应用层内容，根据前端负载均衡设置的服务端选择方式，选择一个最合适的服务端进行业务处理。传统的服务负载均衡架构有两种方式，一种是使用专门的负载均衡设备作为前端，进行负载均衡到后端服务端；另一种方式前端和后端在同一台设备上，前端应用层负载均衡进程按报文内容进行负载均衡之后，再传输给后端不同的服务端口。第一种方式弊端是，需要性能强劲昂贵前端负载设备，增加服务的硬件成本。第二种方式弊端是，虽然没有增加应用硬件成本，但一个七层会话报文需要多次进出内核空间，随着服务连接数的增长，大量内核资源，如sock、服务端口等无法避免地被占用消耗，造成服务容量和性能的大幅下降。现有技术采用的应用层均衡部署如图1所示，通过统一的端口的代理均衡服务模块接收客户端的连接请求并建立连接后，将接收到的应用请求通过均衡策略转交给端口B或端口C，建立代理均衡服务模块与端口B或端口C应用服务模块之间的连接，由端口B或端口C的应用服务模块提供相应的应用服务后转发给代理均衡服务模块的端口A，再由代理均衡服务模块端口转发给请求的客户端。其具体的流程如图2所示，其中端口A为接收客户端请求的统一端口。GET(1)和GET(2)代表两个应用请求报文。

鉴于此，如何找到一种同时兼顾成本与服务性能的网络均衡方法就成了本领域技术人员亟待解决的问题。

发明内容

鉴于以上所述现有技术的缺点，本发明的目的在于提供一种服务负载均衡方法及系统，用于解决现有技术中的服务负载均衡方案不能兼顾均衡成本与服务性能的问题。

为实现上述目的及其他相关目的，本发明提供一种服务负载均衡方法，所述服务负载均衡方法包括：服务端通过统一的代理端口号接收客户端的请求报文，所述请求报文包括连接请求报文或应用请求报文，根据所述连接请求报文建立服务端与所述客户端的连接，并为所建立的连接在内核中创建一个连接管理结构，所述连接管理结构中保存有与所述客户端的连接相关信息；当服务端接收到一个所述应用请求报文时，在内核空间为所述应用请求报文选择一个可用的端口号，根据发送所述应用请求报文的客户端对应的连接相关信息建立所选择的端口号与所述客户端的一个socket通道；所述端口号的应用服务实例根据所述应用请求报文提供相应的服务，并通过所述socket通道将所述服务结果反馈给所述客户端。

可选地，所述请求报文包括遵循HTTP协议的请求报文。

可选地，仅当关闭所有与所述客户端的socket通道后，方可关闭所述服务端与所述客户端的连接。

可选地，所述服务负载均衡方法还包括：在所述连接管理结构中对端口号进行管理，将建立了socket通道的端口号标识为已使用状态。

可选地，在所述连接管理结构中采用位图方式管理端口号，所述位图中的每一位与一个端口号一一对应，根据位图中每一位的值确定该位对应着的端口号的使用状态，所述使用状态包括已使用状态或者未使用状态。

可选地，仅当所述连接管理结构中的管理的端口号都处于未使用状态时，方可关闭与所述服务端与客户端的连接。

本发明还提供一种服务负载均衡系统，所述服务负载均衡系统包括：请求报文管理模块，用于通过统一的代理端口号接收客户端的请求报文，请求报文包括连接请求报文或应用请求报文，根据所述连接请求报文建立服务端与所述客户端的连接，为所建立的连接在内核中创建一个连接管理结构，所述连接管理结构中保存有与所述客户端的连接相关信息；应用请求均衡模块，与所述连接请求管理模块相连，用于当接收到一个所述应用请求报文时，在内核空间为所述应用请求报文选择一个可用的端口号，根据发送所述应用请求报文的客户端对应的连接相关信息建立所选择的端口号与所述客户端的一个socket通道；应用请求服务模块，与所述应用请求均衡模块相连，用于根据所述应用请求报文提供相应的服务，并通过所述socket通道将所述服务结果反馈给所述客户端。

可选地，所述请求报文包括遵循HTTP协议的请求报文。

可选地，所述连接请求管理模块还用于关闭所述服务端与所述客户端的连接，仅当关闭所有与所述客户端的socket通道后，方可关闭所述服务端与所述客户端的连接。

可选地，所述应用请求均衡模块还用于：在所述连接管理结构中对端口号进行管理，将建立了socket通道的端口号标识为已使用状态，当所述socket通道关闭时，将所述socket通道对应的端口号标识为未使用状态。

可选地，在所述连接管理结构中采用位图方式管理端口号，所述位图中的每一位与一个端口号一一对应，根据位图中每一位的值确定该位对应着的端口号的使用状态，所述使用状态包括已使用状态或者未使用状态。

如上所述，本发明的一种服务负载均衡方法及系统，具有以下有益效果：能够解决针对使用专用负载均衡设备增加服务硬件成本的问题，以及使用应用层负载均衡将导致系统内核资源不可避免的消耗进而导致服务容量和性能下降的问题。通过本发明的技术方案，能够最大限度降低报文在内核和应用层之间的传递，节约cpu资源、节约端口资源，减少会话均衡的协议栈开销，从而大幅提高了单机容量和性能。

附图说明

图1显示为现有技术的负载均衡方法的一实施例中的系架构示意图。

图2显示为现有技术的负载均衡方法的一实施例中的流程示意图。

图3显示为本发明的服务负载均衡方法的一实施例中的流程示意图。

图4显示为本发明的服务负载均衡方法的一实施例中的架构示意图。

图5显示为本发明的服务负载均衡方法的另一实施例中的流程示意图。

图6显示为本发明的服务负载均衡方法的一实施例中的服务结构示意图。

图7显示为本发明的服务负载均衡方法的一实施例中的连接关闭的流程示意图。

图8显示为本发明的服务负载均衡系统的一实施例中的模块示意图。

元件标号说明

1 服务负载均衡系统

11 请求报文管理模块

12 应用请求均衡模块

13 应用请求服务模块

S1～S3 步骤

具体实施方式

以下通过特定的具体实例说明本发明的实施方式，本领域技术人员可由本说明书所揭露的内容轻易地了解本发明的其他优点与功效。本发明还可以通过另外不同的具体实施方式加以实施或应用，本说明书中的各项细节也可以基于不同观点与应用，在没有背离本发明的精神下进行各种修饰或改变。

需要说明的是，本实施例中所提供的图示仅以示意方式说明本发明的基本构想，遂图式中仅显示与本发明中有关的组件而非按照实际实施时的组件数目、形状及尺寸绘制，其实际实施时各组件的型态、数量及比例可为一种随意的改变，且其组件布局型态也可能更为复杂。

本发明提供一种服务负载均衡方法。在一个实施例中，如图3所示，所述服务负载均衡方法包括：

步骤S1，服务端通过统一的代理端口号接收客户端的请求报文，所述请求报文包括连接请求报文或应用请求报文，根据所述连接请求报文建立服务端与所述客户端的连接，并为所建立的连接在内核中创建一个连接管理结构，所述连接管理结构中保存有与所述客户端的连接相关信息。在本发明中，服务端虽然根据所述连接请求报文建立了服务端与所述客户端的连接，但并未建立客户端与服务端应用层(应用服务模块)的连接通道。客户端向服务端的统一代理端口A(内核均衡模块)发起syn连接请求，在接收到服务端的syn-ack后，返回ack报文完成3次握手的连接建立。在现有技术中，服务器端在接收到该客户端ack报文时，如图2中步骤4(简称图1:4)所示，request操作将连接请求入应用层服务端监听队列，通告应用层连接建立。但在本发明中，采用了连接请求延迟技术，当服务器端在接收到该客户端ack报文时，并不通过应用层连接的建立，但为所建立的连接在内核中创建一个连接管理结构，所述连接管理结构中保存有与所述客户端的连接相关信息。所述连接管理结构包括内核sock结构。所述请求报文包括遵循HTTP协议的请求报文。

步骤S2，当服务端接收到一个所述应用请求报文时，在内核空间为所述应用请求报文选择一个可用的端口号，根据发送所述应用请求报文的客户端对应的连接相关信息建立所选择的端口号与所述客户端的一个socket通道。如图4所示，在本发明中，对应用请求报文的均衡策略是在内核空间中处理的，其中的均衡管理，即为所述应用请求报文选择一个可用的端口号是由内核层的内核均衡模块来完成的。而在现有技术中，如图1所示，均衡策略是由应用层的代理均衡服务模块来完成的。当服务端与客户端通过三次握手建立连接后，在现有技术中，服务器端在接收到该客户端ack报文时，如图2中步骤4(简称图2:4)所示，request操作将连接请求入应用层服务端监听队列，通告应用层连接建立。但在本发明的一个实施例中，如图5所示，采用了连接请求延迟技术，将延迟一个报文进行该操作。在客户端发送带有实质内容的应用请求报文如GET(1)时，才根据报文中有意义的内容，由内核层内核均衡模块通过blnc(图5:8)操作按均衡策略选择服务端，再通过request(图5:9)将请求送入均衡目的服务端的监听队列中。因为该延迟动作实际上对客户端透明，不会影响客户端报文传输的节奏；而对于服务端，当客户端包含有效内容报文到达之前是没有实际的业务数据可处理，服务端是同步阻塞或异步等待的状态，因此该请求延迟并不会影响服务端对应用的响应时间。在内核均衡实现中通过delay-req(图5:5)操作创建均衡实例，保存请求信息，延迟向应用层的request(图5:9)发送。每个应用服务模块实例占用一个可用端口号，选择可用端口号的过程即是选择报文应用服务模块实例的过程。已使用的端口号与应用服务模块实例一一对应，根据所述端口号为对应的应用服务模块实例建立一个应用服务模块实例与客户端的socket通道。

步骤S3，所述端口号的应用服务实例根据所述应用请求报文提供相应的服务，并通过所述socket通道将所述服务结果反馈给所述客户端。具体地，所述端口号对应的应用服务模块实例根据应用请求报文提供相应的服务。

在一个实施例中个，通过图2与图5对现有技术与本发明的处理流程进行比较。在现有技术中，客户端与服务端应用层(端口A)的代理均衡服务模块建立了一个socket通道，当接收到应用请求报文如GET(1)时，由服务器应用层的代理均衡服务模块(端口A)确定GET(1)由应用层的服务提供模块B(端口B)处理，然后由服务器应用层的代理均衡服务(端口A)与应用层的服务提供模块B(端口B)建立一个socket通道，应用层的服务提供模块B处理服务请求，将服务结果返回给服务器应用层的均衡模块(端口A)，由服务器应用层的均衡模块(端口A)将服务结果给客户端。而在本发明中，当服务端与客户端建立连接时，并不立刻建立socket通道。仅当接收到应用请求报文如GET(1)时，由内核均衡模块根据应用请求报文中应用层的应用信息，确定GET(1)由应用层的服务提供模块B(端口B)处理，然后，内核均衡模块根据发送所述应用请求报文的客户端对应的连接相关信息(包括与客户端相应的内核sock结构)，建立应用层的服务提供模块B(端口B)与所述客户端的一个socket通道。应用层的服务提供模块B处理服务请求，将服务结果直接返回给服客户端。对同一客户端的不同应用请求报文如GET(2)，则与GET(1)的处理过程相类似。内核均衡模块以内核模块的形态存在，不同的均衡模块可以实现不同的均衡策略。

如图5所示，在本发明的方法中，客户端完成握手建立连接后，向服务器端发送带第一个关键字为1的Get的报文，内核均衡实现中，将Get报文交予均衡模块做blnc(图5:8)操作：该动作根据策略解析出关键字1，从均衡服务端中，选择监听在B端口上的应用服务模块；连接重定向：将目的端口为A的报文重定向到监听在端口B的应用服务模块:通过将被延迟的请求，由request(图5:9)发往端口B的应用服务模块的接收队列，在应用服务模块B完成accept(图5：10)动作之后，到应用层连接打通，完成连接重定向；会话服务：应用服务模块完成针对接收到的Get请求关键字1，准备响应内容于Get-ok(图5：13)报文内，返回内核，传递给客户端；请求复用：客户端完成第一次会话之后，发出第二个会话启动的Get报文携带关键字为2，当根据策略均衡到另一个端口C的应用服务模块C的时候，该Get报文的seq序号将被记录到连接均衡实例对应存储空间中。从当前Get请求报文起，需被传输到端口C的应用服务模块C，此时3次握手被保存的req信息将被复用，通过request(图5:19)将连接请求发往应用服务模块C，在应用服务模块C完成accpet操作之后，一条新的socket通道被建立。如图6所示，内核sock结构被多次复用，在建立应用层端口(B、C、D等)的socket时都需要使用该应用请求报文客户端对应的内核sock结构。即单个TCP连接sock将可对接多个不同端口的应用socket，且对应用层编程实现透明。

在一个实施例中，所述服务负载均衡方法还包括：对所述内核接收到所述客户端一个新的应用请求报文的处理要高于所述端口号的处理。具体地，当服务器在通过现有的socket通道对应用请求报文处理时，如果接收到新的应用请求报文，则优先为新的应用请求报文分配端口号，建立新的socket通道。在一个实施例中，如图5所示，对socket上下文切换使用被动切换方式，当端口B的应用服务模块B持续接收处理报文，当遇到seq为Get(2)的报文，通过sock_switch(图5:22)操作，通道主动进入空闲状态，上下文切换至应用服务模块C，完成切换之后进行异步通告data_ready(图5:23)，即可触发应用服务模块C启动报文接收，接管通道。

在一个实施例中，仅当关闭所有与所述客户端的socket通道后，方可关闭所述服务端与所述客户端的连接。具体地，关闭所述服务端与所述客户端的连接是指完全关闭所述服务端与所述客户端的连接，即通过4次挥手关闭连接。在一个实施例中，所述服务负载均衡方法还包括：在所述连接管理结构中对端口号进行管理，将建立了socket通道的端口号标识为已使用状态。可以下述方法进行管理：在所述连接管理结构中采用位图方式管理端口号，所述位图中的每一位与一个端口号一一对应，根据位图中每一位的值确定该位对应着的端口号的使用状态，所述使用状态包括已使用状态或者未使用状态。仅当所述连接管理结构中的管理的端口号都处于未使用状态时，方可关闭与所述服务端与客户端的连接。均衡实例与内核sock对应，与内核sock建立连接的应用层socket在均衡实例中对应索引位置保留指针，并根据索引设置位图对应位，当应用层socket关闭时，对应索引所指向的指针清空，并复位相应位图，只有位图所有位为空时，才真正的调用底层接口进行连接的关闭。均衡连接其他关闭方式，设置内核sock状态，通告所有相连的应用socket状态变迁。在一个实施例中，如图7所示，当需要主动关闭客户端与服务端的连接时，必须先行关闭所有服务端的应用端口与客户端建立的socket通道，并清空sock中的位图(bitmap)，然后才能真正关闭客户端与服务端的连接。

本发明还提供一种服务负载均衡系统。所述服务负载均衡系统可以采用如上所述的服务负载均衡方法。在一个实施例中，如图8所示，所述服务负载均衡系统1包括请求服务管理模块11、应用请求均衡模块12以及应用请求服务模块13。其中：

请求报文管理模块11用于通过统一的代理端口号接收客户端的请求报文，请求报文包括连接请求报文或应用请求报文，根据所述连接请求报文建立服务端与所述客户端的连接，为所建立的连接在内核中创建一个连接管理结构，所述连接管理结构中保存有与所述客户端的连接相关信息。具体地，请求报文管理模块11根据所述连接请求报文建立了服务端与所述客户端的连接，但并未建立客户端与服务端应用层的连接通道。客户端向服务端的统一代理端口A发起syn连接请求，在接收到服务端的syn-ack后，返回ack报文完成3次握手的连接建立。而在现有技术中，服务器端在接收到该客户端ack报文时，如图2中步骤4(简称图2:4)所示，request操作将连接请求入应用层服务端监听队列，通告应用层连接建立。但在本发明中，采用了连接请求延迟技术，当服务器端在接收到该客户端ack报文时，并不通过应用层连接的建立，但为所建立的连接在内核中创建一个连接管理结构，所述连接管理结构中保存有与所述客户端的连接相关信息。所述连接管理结构包括内核sock结构。所述请求报文包括遵循HTTP协议的请求报文

应用请求均衡模块12与所述连接请求管理模块11相连，用于当接收到一个所述应用请求报文时，在内核空间为所述应用请求报文选择一个可用的端口号，根据发送所述应用请求报文的客户端对应的连接相关信息建立所选择的端口号与所述客户端的一个socket通道。在一个实施例中，如图4所示，应用请求均衡模块12对应用请求报文的均衡策略是在内核空间中处理的，其中的均衡管理，即为所述应用请求报文选择一个可用的端口号是由内核均衡模块来完成的。而在现有技术中，如图1所示，均衡策略是由应用层的代理均衡服务模块来完成的。当服务端与客户端通过三次握手建立连接后，在现有技术中，服务器端在接收到该客户端ack报文时，如图2中步骤4(简称图2:4)所示，request操作将连接请求入应用层服务端监听队列，通告应用层连接建立。但在本发明的一个实施例中，如图5所示，采用了连接请求延迟技术，将延迟一个报文进行该操作。在客户端发送带有实质内容的应用请求报文如GET(1)时，才根据报文中有意义的内容，由内核均衡模块通过blnc(图5:8)操作按均衡策略选择服务端，再通过request(图5:9)将请求送入均衡目的服务端的监听队列中。因为该延迟动作实际上对客户端透明，不会影响客户端报文传输的节奏；而对于服务端，当客户端包含有效内容报文到达之前是没有实际的业务数据可处理，服务端是同步阻塞或异步等待的状态，因此该请求延迟并不会影响服务端对应用的响应时间。在内核均衡实现中通过delay-req(图5:5)操作创建均衡实例，保存请求信息，延迟向应用层的request(图5:9)发送。每个应用服务模块实例占用一个可用端口号，选择可用端口号的过程即是选择报文应用服务模块实例的过程。已使用的端口号与应用服务模块实例一一对应，根据所述端口号为对应的应用服务模块实例建立一个应用服务模块实例与客户端的socket通道。

应用请求服务模块13与所述应用请求均衡模块12相连，用于根据所述应用请求报文提供相应的服务，并通过所述socket通道将所述服务结果反馈给所述客户端。

在一个实施例中，所述服务负载均衡系统中，对所述应用请求均衡模块11的处理要优先于对应用请求服务模块13的处理。具体地，当服务器在通过现有的socket通道对应用请求报文处理时，如果接收到新的应用请求报文，则优先为新的应用请求报文分配端口号，建立新的socket通道。在一个实施例中，如图5所示，对socket上下文切换使用被动切换方式，当应用服务模块B持续接收处理报文，当遇到seq为Get(2)的报文，通过sock_switch(图5:22)操作，通道主动进入空闲状态，上下文切换至应用服务模块C，完成切换之后进行异步通告data_ready(图5:23)，即可触发应用服务模块C启动报文接收，接管通道。

在一个实施例中，所述连接请求管理模块12还用于关闭所述服务端与所述客户端的连接，仅当关闭所有与所述客户端的socket通道后，方可关闭所述服务端与所述客户端的连接。具体地，关闭所述服务端与所述客户端的连接是指完全关闭所述服务端与所述客户端的连接，即通过4次挥手关闭连接。在一个实施例中，所述应用请求均衡模块12还用于：在所述连接管理结构中对端口号进行管理，将建立了socket通道的端口号标识为已使用状态，当所述socket通道关闭时，将所述socket通道对应的端口号标识为未使用状态。具体地，在所述连接管理结构中采用位图方式管理端口号，所述位图中的每一位与一个端口号一一对应，根据位图中每一位的值确定该位对应着的端口号的使用状态，所述使用状态包括已使用状态或者未使用状态。仅当所述连接管理结构中的管理的端口号都处于未使用状态时，方可关闭与所述服务端与客户端的连接。所管理的端口号与根据端口号建立的应用层socket一一对应。均衡实例与内核sock对应，与内核sock建立连接的应用层socket在均衡实例中对应索引位置保留指针，并根据索引设置位图对应位，当应用层socket关闭时，对应索引所指向的指针清空，并复位相应位图，只有位图所有位为空时，才真正的调用底层接口进行连接的关闭。均衡连接其他关闭方式，设置内核sock状态，通告所有相连的应用socket状态变迁。在一个实施例中，如图7所示，当需要主动关闭客户端与服务端的连接时，必须先行关闭所有服务端的应用端口与客户端建立的socket通道，并清空sock中的位图(bitmap)，然后才能真正关闭客户端与服务端的连接。

与现有的均衡方案相比较，本发明的技术方案从应用空间进入内核空间；通过安装具有均衡功能的内核；均衡代理端口A，作为客户端可见端口，是客户端发起对服务器连接时的目的端口，通过内核对用户空间开发的控制接口进行配置；均衡服务端口范围(如B、C)，是业务监听端口，通过内核对用户空间开放的接口进行配置，通告内核均衡模块；应用服务模块启动时，如监听端口在配置的均衡服务端口范围内，内核均衡模块将对应的监听socket录为可用服务端，在报文到来后，根据策略均衡，重定向到可用服务端后可达应用服务模块。在一个实施例中，在相同的硬件条件下对现有技术采用的应用均衡方案与本发明的内核均衡方案进行性能测试，测试结果表明，采用应用均衡方案时，当新建连接数达到10000/s的时候，将有大量的新建连接不能成功建立。而当采用本发明的内核均衡方案时，即使当新建在19000/s时，仍然可以很好的完成均衡和业务处理，且单连接的响应时间始终保持平稳较低。显然，相比于现有技术，本发明的技术方案对性能和容量有明显的大幅度提升。

综上所述，本发明的一种服务负载均衡方法及系统采用了具有均衡策略的内核，将对客户端的服务请求在内核空间进行均衡管理。与现有的在应用层空间进行均衡管理相比，能够最大限度降低报文在内核和应用层之间的传递，节约cpu资源、节约端口资源，减少会话均衡的协议栈开销，从而大幅提高了单机容量和性能。所以，本发明有效克服了现有技术中的种种缺点而具高度产业利用价值。

上述实施例仅例示性说明本发明的原理及其功效，而非用于限制本发明。任何熟悉此技术的人士皆可在不违背本发明的精神及范畴下，对上述实施例进行修饰或改变。因此，举凡所属技术领域中具有通常知识者在未脱离本发明所揭示的精神与技术思想下所完成的一切等效修饰或改变，仍应由本发明的权利要求所涵盖。

Claims (10)

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

服务端通过统一的代理端口号接收客户端的请求报文，所述请求报文包括连接请求报文或应用请求报文，根据所述连接请求报文建立服务端与所述客户端的连接，对所述连接请求进行延迟，并不通过服务端应用层建立连接，而是为所建立的连接在具有均衡策略的内核中创建一个连接管理结构，所述连接管理结构中保存有与所述客户端的连接相关信息；

当服务端接收到一个所述应用请求报文时，在内核空间由内核均衡模块为所述应用请求报文选择一个可用的应用服务模块端口号，将所述应用请求报文送入均衡目的服务端的监听队列中，根据发送所述应用请求报文的客户端对应的连接相关信息建立所选择的端口号与所述客户端的一个socket通道；

所述端口号的应用服务实例根据所述应用请求报文提供相应的服务，并通过所述socket通道将所述服务结果反馈给所述客户端。

2.根据权利要求1所述的服务负载均衡方法，其特征在于：仅当关闭所有与所述客户端的socket通道后，方可关闭所述服务端与所述客户端的连接。

3.根据权利要求1所述的服务负载均衡方法，其特征在于：所述请求报文包括遵循HTTP协议的请求报文。

4.根据权利要求1所述的服务负载均衡方法，其特征在于：所述服务负载均衡方法还包括：在所述连接管理结构中对端口号进行管理，将建立了socket通道的端口号标识为已使用状态。

5.根据权利要求4所述的服务负载均衡方法，其特征在于：在所述连接管理结构中采用位图方式管理端口号，所述位图中的每一位与一个端口号一一对应，根据位图中每一位的值确定该位对应着的端口号的使用状态，所述使用状态包括已使用状态或者未使用状态。

6.一种服务负载均衡系统，其特征在于：所述服务负载均衡系统包括：

请求报文管理模块，用于通过统一的代理端口号接收客户端的请求报文，请求报文包括连接请求报文或应用请求报文，根据所述连接请求报文建立服务端与所述客户端的连接，对所述连接请求进行延迟，不通过服务端应用层建立连接，而是为所建立的连接在具有均衡策略的内核中创建一个连接管理结构，所述连接管理结构中保存有与所述客户端的连接相关信息；

应用请求均衡模块，与所述连接请求管理模块相连，用于当接收到一个所述应用请求报文时，在内核空间由内核均衡模块为所述应用请求报文选择一个可用的应用服务模块端口号，将所述应用请求报文送入均衡目的服务端的监听队列中，根据发送所述应用请求报文的客户端对应的连接相关信息建立所选择的端口号与所述客户端的一个socket通道；

应用请求服务模块，与所述应用请求均衡模块相连，用于根据所述应用请求报文提供相应的服务，并通过所述socket通道将所述服务结果反馈给所述客户端。

7.根据权利要求6所述的服务负载均衡系统，其特征在于：所述连接请求管理模块还用于关闭所述服务端与所述客户端的连接，仅当关闭所有与所述客户端的socket通道后，方可关闭所述服务端与所述客户端的连接。

8.根据权利要求6所述的服务负载均衡系统，其特征在于：所述请求报文包括遵循HTTP协议的请求报文。

9.根据权利要求6所述的服务负载均衡系统，其特征在于：所述应用请求均衡模块还用于：在所述连接管理结构中对端口号进行管理，将建立了socket通道的端口号标识为已使用状态，当所述socket通道关闭时，将所述socket通道对应的端口号标识为未使用状态。

10.根据权利要求9所述的服务负载均衡系统，其特征在于：在所述连接管理结构中采用位图方式管理端口号，所述位图中的每一位与一个端口号一一对应，根据位图中每一位的值确定该位对应着的端口号的使用状态，所述使用状态包括已使用状态或者未使用状态。