CN106572132A - 分发建链方法、装置和系统 - Google Patents

Abstract

本发明公开了一种分发建链方法，该方法包括：接收发起端的建链请求报文；根据预置的动态分发表，从所述建链请求报文中获取目的地址和目的端口合法的建链请求报文；根据预置的负荷分担表，将所述合法的建链请求报文转发给负荷最小的服务节点进行建链。本发明还公开了一种分发建链装置和一种分发建链系统。本发明实现了对建链请求报文的均匀分发，从而使服务器集群各服务节点的负荷达到均衡，加快了服务器集群的响应速度，给用户带来了更好的业务体验。

Description

分发建链方法、装置和系统

技术领域

本发明涉及通信技术领域，尤其涉及一种分发建链方法、装置和系统。

背景技术

目前，移动、电信核心网通常使用服务器集群提供服务，例如HLR(HomeLocation Register，归属位置寄存器)、IMS(IP Multimedia Subsystem，IP多媒体子系统)，通过分布式的架构提高了数据处理效率。用户在获取HLR、IMS提供的服务时，首先需要和HLR、IMS建立TCP(Transmission Control Protocol，传输控制协议)链接，与服务器集群进行通信。

在分布式系统下，服务器集群根据用户的IP地址和端口号范围事先对接入的用户进行规划，能够将用户的服务需求均匀分配给集群中的各服务节点进行处理。当用户发起建链请求后，服务器集群根据用户的IP地址和端口号范围，按照事先的规划，将用户的建链请求转发给相应的服务节点，由服务节点提供服务。

然而，随着业务的不断拓展与发展，用户的服务需求也日益增长，当服务器集群无法提前获知用户的IP地址和端口号范围时，现有的分发建链方式无法快速接入用户请求，严重影响了用户体验。

例如，当用户的移动终端在向IMS请求触发类业务时，由于移动终端的IP地址和端口都是动态分配的，IMS服务器不能根据移动终端的IP地址事先分配服务节点，有可能造成移动终端无法接入IMS服务器，或移动终端成功接入后IMS服务器后，IMS服务器的各个服务节点处理服务请求的负载严重不均衡，产生有些服务节点满负荷运行、有些服务节点空置，浪费资源，降低了整个核心网的响应能力。

发明内容

本发明的主要目的在于提供一种分发建链方法、装置和系统，旨在解决现有技术中服务器集群负荷不均衡、响应慢的技术问题。

为实现上述目的，本发明提供一种分发建链方法，所述分发建链方法包括以下步骤：

接收发起端的建链请求报文；

根据预置的动态分发表，从所述建链请求报文中获取目的地址和目的端口合法的建链请求报文；

根据预置的负荷分担表，将所述合法的建链请求报文转发给负荷最小的服务节点进行建链。

优选的，所述接收发起端的建链请求报文的步骤之前，还包括：

部署所述动态分发表，所述动态分发表记录预设的合法建链目的地址和目的端口；

获取各服务节点的动态负荷参数，生成所述负荷分担表。

优选的，所述根据预置的负荷分担表，将所述合法的建链请求报文转发给负荷最小的服务节点进行建链的步骤之后，还包括：

存储本次分发建链信息，生成分发会话表，所述分发会话表用于所述发起端后续报文的分发。

优选的，所述根据预置的动态分发表，从所述建链请求报文中获取目的地址和目的端口合法的建链请求报文的步骤之后，还包括：

根据所述分发会话表，判断所述发起端是否进行过建链；

若所述发起端进行过建链，则根据所述会话分发表，获取已与所述发起端进行过建链的服务节点，并将所述合法的建链请求报文转发给所述获取的服务节点进行建链；

若所述发起端未进行过建链，则转入执行步骤：根据预置的负荷分担表，将所述合法的建链请求报文转发给负荷最小的服务节点进行建链。

此外，为实现上述目的，本发明还提供一种分发建链装置，所述分发建链装置包括：

接收模块，用于接收发起端的建链请求报文；

筛选模块，用于根据预置的动态分发表，从所述建链请求报文中获取目的地址和目的端口合法的建链请求报文；

转发模块，用于根据预置的负荷分担表，将所述合法的建链请求报文转发给负荷最小的服务节点进行建链。

优选的，所述分发建链装置还包括：

部署模块，用于部署所述动态分发表，所述动态分发表记录预设的合法建链目的地址和目的端口；

获取模块，用于获取各服务节点的动态负荷参数，生成所述负荷分担表。

优选的，所述分发建链装置还包括：

存储模块，用于存储本次分发建链信息，生成分发会话表，所述分发会话表用于所述发起端后续报文的分发。

优选的，所述分发建链装置还包括：

判定模块，用于根据所述分发会话表，判断所述发起端是否进行过建链；

所述转发模块还用于，若所述发起端进行过建链，则根据所述会话分发表，获取已与所述发起端进行过建链的服务节点，并将所述合法的建链请求报文转发给所述获取的服务节点进行建链；若所述发起端未进行过建链，则根据预置的负荷分担表，将所述合法的建链请求报文转发给负荷最小的服务节点进行建链。

此外，为实现上述目的，本发明还提供一种分发建链系统，所述分发建链系统包括发起端和服务器，其中：

所述发起端，用于发送建链请求报文；

所述服务器包括接入侧和服务侧；

所述接入侧包括接收模块、筛选模块、转发模块、部署模块、获取模块、存储模块和判定模块；

所述服务侧，用于接收所述建链请求报文，与所述发起端建链。

优选的，所述服务侧包括：

各服务节点，所述各服务节点用于将动态负荷参数发送给所述接入侧，接收所述接入侧转发的建链请求报文，并根据所述建链请求报文与所述发起端进行建链，接收所述接入侧转发的所述发起端的后续报文。

本发明提出的一种分发建链方法、装置和系统，通过服务器集群接入侧接收发起端的建链请求报文；根据预置的动态分发表，从建链请求报文中获取目的地址和目的端口合法的建链请求报文；然后，根据预置的负荷分担表，将合法的建链请求报文转发给负荷最小的服务节点进行建链，实现对接入的建链请求进行均匀的分发。本发明实现了对建链请求报文的均匀分发，从而使服务器集群各服务节点的负荷达到均衡，避免了负荷不均衡导致的资源浪费，减轻了服务器集群的负担，加快了服务器集群的响应速度，增强了服务器集群的整体性能，给用户带来了更好的业务体验。

附图说明

图1为本发明分发建链方法第一实施例的流程示意图；

图2为本发明分发建链方法第二实施例的流程示意图；

图3为本发明分发建链方法第三实施例的流程示意图；

图4为本发明分发建链方法第四实施例的流程示意图；

图5为本发明分发建链装置第一实施例的功能模块示意图；

图6为本发明分发建链装置第二实施例的功能模块示意图；

图7为本发明分发建链装置第三实施例的功能模块示意图；

图8为本发明分发建链装置第四实施例的功能模块示意图；

图9为本发明分发建链系统第一实施例的模块示意图；

图10为本发明实施例应用场景为手机客户端向IMS核心网请求服务的示意图；

图11为本发明分发建链系统第二实施例的模块示意图。

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

具体实施方式

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

本发明实施例的主要解决方案是：接收发起端的建链请求报文；根据预置的动态分发表，从所述建链请求报文中获取目的地址和目的端口合法的建链请求报文；根据预置的负荷分担表，将所述合法的建链请求报文转发给负荷最小的服务节点进行建链。

由于现有技术在发起端的地址和端口范围不确定时，服务器集群会产生无法接入或各服务节点负荷不均衡的情况，导致服务响应缓慢，影响用户体验。

本发明提供一种解决方案，使服务器集群接入侧在不需要知道发起端的地址和端口信息的情况下，将建链请求均匀分发给各服务节点，实现了服务器集群的各服务节点负荷均衡，提高了服务器整体的响应速度。

参照图1，本发明分发建链方法第一实施例提供一种分发建链方法，所述分发建链方法包括：

步骤S10、接收发起端的建链请求报文。

本发明实施例主要应用于分布式系统中，用户通过与服务器集群建链，接入服务集群。本发明应用场景可以是用户终端发起建链接入服务集群，可以是第三方服务器发起建链接入服务集群，也可以是服务集群内网的终端建链获取服务，可根据实际需要灵活应用。

本实施例以用户客户端与核心网建立PCT链接，接入核心网进行举例说明。当然，本发明应用场景不限定于PCT建链。

在客户端需要获取核心网的服务时，客户端作为发起端，首先需要和核心网的建立PCT链接。核心网服务器集群的接入侧接收建链请求报文，并将建链请求报文分发给服务节点进行建链和提供服务。

具体的，作为一种实施方式，首先，发起端发出建链请求报文TCP SYN(synchronous，握手信号)报文，发起建链。

其中，TCP SYN报文中携带有发起端的本端地址、本端端口，和本次建链的目的地址、目的端口，还可以携带其他信息例如本次服务请求，可根据实际需要灵活设定。

发起端可以通过WiMax(Worldwide Interoperability for Microwave Access,全球微波互联接入)、WLAN(Wireless Local Area Networks，无线局域网络)、HSPDA(High Speed Downlink Packet Access，高速下行分组接入)、网线、或3G等通信技术与核心网进行网络通信，接入核心网。

然后，接入侧接收发起端的TCP SYN报文。需要说明的是，接入侧可以是PC(personal computer，个人计算机)，也可以是接口板，也可以是其他具有网络报文转发能力的设备，可根据实际需要灵活设定。

步骤S20、根据预置的动态分发表，从所述建链请求报文中获取目的地址和目的端口合法的建链请求报文。

在接入侧收到发起端的TCP SYN报文后，接入侧解析发起端的TCP SYN，获取发起端本次建链的目的地址和目的端口，用于判断本次TCP SYN报文是否合法。

接入侧预置有动态分发表，动态分发表记录了核心网允许接入服务的目的地址和目的端口。

接入侧根据预先部署的动态分发表，查询本次TCP SYN报文的目的地址和目的端口是否在动态分发表中。

若本次TCP SYN报文的目的地址和目的端口不在动态分发表中，则本次TCP SYN报文不合法，做丢弃处理；

若本次TCP SYN报文的目的地址和目的端口在动态分发表中，则本次TCP SYN报文合法，可继续进行建链。

由此，接入侧获得目的地址和目的端口合法的建链请求报文。

步骤S30、根据预置的负荷分担表，将所述合法的建链请求报文转发给负荷最小的服务节点进行建链。

在接入侧获取合法的TCP SYN报文后，接入侧需要将TCP SYN报文转发给服务节点进行建链。

具体的，作为一种实施方式，首先，接入侧查询预置的负荷分担表。

其中，负荷分担表为动态生成的，记录了集群中各服务节点的负荷状况，实时动态更新。

接入侧选取当前负荷最小的服务节点。

然后，接入侧采用负荷分担策略，将本次TCP SYN报文转发给选取的服务节点，完成本次建链请求报文的分发，由选取的服务节点与发起端进行TCP协商。

若选取的服务节点与发起端TCP协商成功，则后续服务节点与发起端的非TCP报文，均由接入侧直接转发给当前服务节点。

当然，本发明不限定于用户终端与服务器集群的建链，也可以应用于服务器集群内部的分发建链。

以服务器集群内部的分发建链进行举例说明，具体的，作为一种实施方式，首先，将需要获取服务的终端作为发起端，发起端发出建链请求报文。

在服务器集群内部，各终端均有唯一可识别的标识，例如虚拟IP地址和端口，使接入侧可以根据此标识识别不同的终端。

接入侧接收发起端的建链请求报文，然后根据预置的动态分发表，查找发起端本次建链请求的目的IP地址和端口。

若未成功找到发起端本次建链请求的目的IP地址和端口，则丢弃本次建链请求报文；

若成功找到发起端本次建链请求的目的IP地址和端口，则接入侧根据预置的负荷分担表，选取负荷最小的服务节点，并将本次建链请求报文转发给选取的服务节点。

然后，由该选取的服务节点与发起端进行建链，并提供相应服务。

在本实施例中，通过服务器集群接入侧接收发起端的建链请求报文；根据预置的动态分发表，从建链请求报文中获取目的地址和目的端口合法的建链请求报文；然后，根据预置的负荷分担表，将合法的建链请求报文转发给负荷最小的服务节点进行建链，对接入的建链请求进行均匀的分发。本实施例实现了对建链请求报文的均匀分发，从而使服务器集群各服务节点的负荷达到均衡，避免了负荷不均衡导致的资源浪费，减轻了服务器集群的负担，加快了服务器集群的响应速度，增强了服务器集群的整体性能，给用户带来了更好的业务体验。

进一步的，参照图2，本发明分发建链方法第二实施例提供一种分发建链方法，基于上述图1所示的实施例，所述步骤S10之前，还包括：

步骤S40、部署所述动态分发表，所述动态分发表记录预设的合法建链目的地址和目的端口。

在本实施例中，服务器集群预设有允许接入服务的服务器地址和端口。

接入侧将本端允许接入服务的服务器地址和端口记录为动态分发表，作为提供服务的地址和端口，部署在接入侧。

其中，动态分发表可以包括服务器集群对外网提供服务的IP地址和端口，用于外网用户终端获取服务；动态分发表也可以包括服务器集群内各终端的虚拟IP地址和端口，用于集群内的终端获取服务；动态分发表也可以包括其他标识信息，用于标识、查找提供服务的服务器，可根据实际需要灵活设定。

当发起端向服务器集群发起建链请求，接入侧查询动态分发表，查找本次建链请求报文携带的目的地址和目的端口。

若接入侧在动态分发表中查找到发起端的本次建链请求报文携带的目的地址和目的端口，则发起端本次建链请求报文携带的目的地址和目的端口是服务器集群允许接入的地址和端口，接入侧判定发起端本次建链请求报文合法。

若接入侧在动态分发表中未查找到发起端的本次建链请求报文携带的目的地址和目的端口，则发起端的本次建链请求报文目的地址和目的端口，与当前服务器集群能够提供服务的地址和端口不符，因此，服务器集群不能与发起端建链。接入侧将发起端的本次建链请求报文视为非法报文，做丢弃处理。

步骤S50、获取各服务节点的动态负荷参数，生成所述负荷分担表。

在本实施例中，接入侧获取集群中各服务节点的负荷参数，生成负荷分担表。

在集群服务器中，各服务节点的负荷状况根据实时处理状态都会产生变动。因此，各服务节点实时主动向接入侧上报各服务节点的负荷参数，用于接入侧生成负荷分担表。

其中，各服务节点的负荷参数包括各服务节点的负荷状况，各服务节点的负荷状况可以是各服务节点上的TCP链接数，也可以是各服务节点上的CPU使用率、内存占用率等技术参数，也可以是其他标识各服务节点负荷状况的参数，可根据实际需要灵活设定。

各服务节点的负荷参数还包括各服务节点能够处理的服务请求。

由此，接入侧得到实时更新的负荷分担表。其中，负荷分担表记录了集群中各服务节点的负荷参数，用于选取负荷最小的服务节点。

由此，在接入侧根据预置的负荷分担表，分发建链请求报文时，首先，选取能够处理发起端的服务请求的服务节点；然后，接入侧在能够处理发起端的服务请求的服务节点中，选取负荷最小的服务节点，转发本次建链请求报文。

在本实施例中，接入侧部署动态分发表，记录预设的合法建链目的地址和目的端口；接入侧获取各服务节点的动态负荷参数，生成负荷分担表，用于根据各服务节点的负荷参数均与分发建链请求报文。本实施例中接入侧通过动态分发表筛选获取合法的建链请求报文，通过负荷分担表选取负荷最小的服务节点，均匀分发建链请求报文，实现了服务器集群的负荷均衡，减轻了服务器集群的负担，加快了服务器集群的响应速度，增强了服务器集群的整体性能，给用户带来了更好的业务体验。

进一步的，参照图3，本发明分发建链方法第三实施例提供一种分发建链方法，基于上述图1或图2所示的实施例(本发明以图1为例)，所述步骤S30之后，还包括：

步骤S60、存储本次分发建链信息，生成分发会话表，所述分发会话表用于所述发起端后续报文的分发。

在接入侧转发本次建链请求报文给相应的服务节点后，接入侧存储本次分发建链的信息，生成分发会话表。

具体的，作为一种实施方式，接入侧转发本次建链请求报文后，将本次建链的相关信息进行存储。

接入侧可以将建链请求报文携带的本端地址、本端端口、目的地址、目的端口和报文转发的目的服务节点标识信息，作为本次分发建链信息进行存储，生成分发会话表。

在获取本次建链的相关信息后，接入侧生成会话分发表，并动态更新，实时记录建链信息用于会话分发表的动态生成。

会话分发表可以用于后续发起端非建链请求报文的转发。具体的，在发起端与服务节点进行会话时，首先，接入侧接收到同一发起端的非建链请求报文时，查询会话分发表，获取已与发起端建链的服务节点。

然后，接入侧将本次报文转发给获取的服务节点。

服务节点收到报文后，进行相应的处理，向发起端提供服务。

在本实施例中，接入侧通过存储本次分发建链信息，生成分发会话表，用于后续同一发起端报文的分发。本实施例实现了当发起端与服务节点建链时，接入侧再接收到发起端后续的非建链请求报文时，可直接根据分发会话表转发至相应的服务节点，减轻了服务器集群的负担，加快了服务器集群的响应速度，增强了服务器集群的整体性能，给用户带来了更好的业务体验。

进一步的，参照图4，本发明分发建链方法第四实施例提供一种分发建链方法，基于上述图3所示的实施例，所述步骤S20之后，还包括：

步骤S70、根据所述分发会话表，判断所述发起端是否进行过建链。

在接入侧获取合法的建链请求报文后，根据动态生成的分发会话表，查找发起端是否已和服务器集群建立过建链。

具体的，作为一种实施方式，接入侧根据当前发起端的本端地址、本端端口查找分发会话表是否记录了当前发起端建链报文转发的目的服务节点标识信息。

若接入侧在分发会话表中成功查找到当前发起端建链报文转发的目的服务节点标识信息，则判定发起端已与服务器集群进行过建链；

若接入侧在分发会话表中未成功查找到当前发起端建链报文转发的目的服务节点标识信息，则判定发起端未与服务器集群进行过建链。

由此，接入侧得到判定结果。

步骤S80、若所述发起端进行过建链，则根据所述会话分发表，获取已与所述发起端进行过建链的服务节点，并将所述合法的建链请求报文转发给所述获取的服务节点进行建链；若所述发起端未进行过建链，则转入执行步骤S30。

若发起端和服务器集群进行过建链，则接入侧根据会话分发表，获取已和当前发起端进行过建链的服务节点标识信息，并根据标识信息将建链请求报文转发给获取的服务节点，由获取的服务节点与发起端进行建链。

若发起端和服务器集群未进行过建链，则接入侧根据预置的负荷分担表，将本次建链请求报文转发给负荷最小的服务节点，完成本次建链请求报文的分发，由选取的服务节点与发起端进行TCP协商。

在本实施例中，接入侧根据分发会话表，判断发起端是否进行过建链；若发起端进行过建链，则接入侧根据预置的负荷分担表，将本次建链请求报文转发给已和发起端进行过建链的服务节点进行建链；若发起端未进行过建链，则接入侧根据预置的负荷分担表，将本次建链请求报文转发给负荷最小的服务节点进行建链。本实施例通过会话分发表的判定，将已进行过建链的发起端建链请求分发给已和发起端进行过建链的服务节点进行处理，减轻了集群中其他服务节点的处理负担，均衡了集群中各服务节点的负荷，从而避免报文重复分发造成资源浪费，加快了服务器集群的响应速度，增强了服务器集群的整体性能，给用户带来了更好的业务体验。

参照图5，本发明分发建链装置第一实施例提供一种分发建链装置，所述分发建链装置包括：

接收模块100，用于接收发起端的建链请求报文。

本发明实施例主要应用于分布式系统中，用户通过与服务器集群建链，接入服务集群。本发明应用场景可以是用户终端发起建链接入服务集群，可以是第三方服务器发起建链接入服务集群，也可以是服务集群内网的终端建链获取服务，可根据实际需要灵活应用。

本实施例以用户客户端与核心网建立PCT链接，接入核心网进行举例说明。当然，本发明应用场景不限定于PCT建链。

在客户端需要获取核心网的服务时，客户端作为发起端，首先需要和核心网的建立PCT链接。核心网服务器集群的接入侧接收建链请求报文，并将建链请求报文分发给服务节点进行建链和提供服务。

具体的，作为一种实施方式，首先，发起端发出建链请求报文TCP SYN(synchronous，握手信号)报文，发起建链。

其中，TCP SYN报文中携带有发起端的本端地址、本端端口，和本次建链的目的地址、目的端口，还可以携带其他信息例如本次服务请求，可根据实际需要灵活设定。

发起端可以通过WiMax(Worldwide Interoperability for Microwave Access,全球微波互联接入)、WLAN(Wireless Local Area Networks，无线局域网络)、HSPDA(High Speed Downlink Packet Access，高速下行分组接入)、网线、或3G等通信技术与核心网进行网络通信，接入核心网。

然后，接收模块100接收发起端的TCP SYN报文。需要说明的是，本发明分发建链装置可以位于PC(personal computer，个人计算机)上，也可以位于接口板上，也可以位于其他具有网络报文转发能力的设备上，可根据实际需要灵活设定。

筛选模块200，用于根据预置的动态分发表，从所述建链请求报文中获取目的地址和目的端口合法的建链请求报文。

在接收模块100收到发起端的TCP SYN报文后，筛选模块200解析发起端的TCP SYN，获取发起端本次建链的目的地址和目的端口，用于判断本次TCP SYN报文是否合法。

筛选模块200预先部署有动态分发表，动态分发表记录了核心网允许接入服务的目的地址和目的端口。

筛选模块200根据预先部署的动态分发表，查询本次TCP SYN报文的目的地址和目的端口是否在动态分发表中。

若本次TCP SYN报文的目的地址和目的端口不在动态分发表中，则本次TCP SYN报文不合法，做丢弃处理；

若本次TCP SYN报文的目的地址和目的端口在动态分发表中，则本次TCP SYN报文合法，可继续进行建链。

由此，筛选模块200获得目的地址和目的端口合法的建链请求报文。

转发模块300，用于根据预置的负荷分担表，将所述合法的建链请求报文转发给负荷最小的服务节点进行建链。

在筛选模块200获取合法的TCP SYN报文后，转发模块300需要将TCPSYN报文转发给服务节点进行建链。

具体的，作为一种实施方式，首先，转发模块300查询预置的负荷分担表。

其中，负荷分担表为动态生成的，记录了集群中各服务节点的负荷状况，实时动态更新。

转发模块300选取当前负荷最小的服务节点。

然后，转发模块300采用负荷分担策略，将本次TCP SYN报文转发给选取的服务节点，完成本次建链请求报文的分发，由选取的服务节点与发起端进行TCP协商。

若选取的服务节点与发起端TCP协商成功，则后续服务节点与发起端的非TCP报文，均由转发模块300直接转发给当前服务节点。

当然，本发明分发建链装置不限定于用户终端与服务器集群的建链，也可以应用于服务器集群内部的分发建链。

以服务器集群内部的分发建链进行举例说明，具体的，作为一种实施方式，首先，将需要获取服务的终端作为发起端，发起端发出建链请求报文。

在服务器集群内部，各终端均有唯一可识别的标识，例如虚拟IP地址和端口，使本发明分发建链装置可以根据此标识识别不同的终端。

接收模块100接收发起端的建链请求报文，然后筛选模块200根据预置的动态分发表，查找发起端本次建链请求的目的IP地址和端口。

若未成功找到发起端本次建链请求的目的IP地址和端口，则筛选模块200丢弃本次建链请求报文；

若成功找到发起端本次建链请求的目的IP地址和端口，则转发模块300根据预置的负荷分担表，选取负荷最小的服务节点，并将本次建链请求报文转发给选取的服务节点。

然后，由该选取的服务节点与发起端进行建链，并提供相应服务。

在本实施例中，通过服务器集群接收模块100接收发起端的建链请求报文；筛选模块200根据预置的动态分发表，从建链请求报文中获取目的地址和目的端口合法的建链请求报文；然后，转发模块300根据预置的负荷分担表，将合法的建链请求报文转发给负荷最小的服务节点进行建链，实现对接入的建链请求进行均匀的分发。本实施例实现了对建链请求报文的均匀分发，从而使服务器集群各服务节点的负荷达到均衡，避免了负荷不均衡导致的资源浪费，减轻了服务器集群的负担，加快了服务器集群的响应速度，增强了服务器集群的整体性能，给用户带来了更好的业务体验。

进一步的，参照图6，本发明分发建链装置第二实施例提供一种分发建链装置，基于上述图5所示的实施例，所述分发建链装置还包括：

部署模块400，用于部署所述动态分发表，所述动态分发表记录预设的合法建链目的地址和目的端口。

在本实施例中，服务器集群预设有允许接入服务的服务器地址和端口。

部署模块400将本端允许接入服务的服务器地址和端口记录为动态分发表，作为提供服务的地址和端口，部署在筛选模块200。

其中，动态分发表可以包括服务器集群对外网提供服务的IP地址和端口，用于外网用户终端获取服务；动态分发表也可以包括服务器集群内各终端的虚拟IP地址和端口，用于集群内的终端获取服务；动态分发表也可以包括其他标识信息，用于标识、查找提供服务的服务器，可根据实际需要灵活设定。

当发起端向服务器集群发起建链请求，筛选模块200查询动态分发表，查找本次建链请求报文携带的目的地址和目的端口。

若筛选模块200在动态分发表中查找到发起端的本次建链请求报文携带的目的地址和目的端口，则发起端本次建链请求报文携带的目的地址和目的端口是服务器集群允许接入的地址和端口，筛选模块200判定发起端本次建链请求报文合法。

若筛选模块200在动态分发表中未查找到发起端的本次建链请求报文携带的目的地址和目的端口，则发起端的本次建链请求报文目的地址和目的端口，与当前服务器集群能够提供服务的地址和端口不符，因此，服务器集群不能与发起端建链。筛选模块200将发起端的本次建链请求报文视为非法报文，做丢弃处理。

获取模块500，用于获取各服务节点的动态负荷参数，生成所述负荷分担表。

在本实施例中，获取模块500获取集群中各服务节点的负荷参数，生成负荷分担表。

在集群服务器中，各服务节点的负荷状况根据实时处理状态都会产生变动。因此，各服务节点实时主动向接入侧上报各服务节点的负荷参数，用于接入侧生成负荷分担表。

其中，各服务节点的负荷参数包括各服务节点的负荷状况，各服务节点的负荷状况可以是各服务节点上的TCP链接数，也可以是各服务节点上的CPU使用率、内存占用率等技术参数，也可以是其他标识各服务节点负荷状况的参数，可根据实际需要灵活设定。

各服务节点的负荷参数还包括各服务节点能够处理的服务请求。

由此，获取模块500得到实时更新的负荷分担表。其中，负荷分担表记录了集群中各服务节点的负荷参数，用于选取负荷最小的服务节点。

由此，在转发模块300根据预置的负荷分担表，分发建链请求报文时，首先，选取能够处理发起端的服务请求的服务节点；然后，转发模块300在能够处理发起端的服务请求的服务节点中，选取负荷最小的服务节点，转发本次建链请求报文。

在本实施例中，部署模块400动态分发表，记录预设的合法建链目的地址和目的端口；获取模块500获取各服务节点的动态负荷参数，生成负荷分担表，用于根据各服务节点的负荷参数均与分发建链请求报文。本实施例中分发建链装置通过动态分发表筛选获取合法的建链请求报文，通过负荷分担表选取负荷最小的服务节点，均匀分发建链请求报文，实现了服务器集群的负荷均衡，减轻了服务器集群的负担，加快了服务器集群的响应速度，增强了服务器集群的整体性能，给用户带来了更好的业务体验。

进一步的，参照图7，本发明分发建链装置第三实施例提供一种分发建链装置，基于上述图5或图6所示的实施例(本发明以图5为例)，所述分发建链装置还包括：

存储模块600，用于存储本次分发建链信息，生成分发会话表，所述分发会话表用于所述发起端后续报文的分发。

在转发模块300转发本次建链请求报文给相应的服务节点后，存储模块600存储本次分发建链的信息，生成分发会话表。

具体的，作为一种实施方式，转发模块300转发本次建链请求报文后，存储模块600将本次建链的相关信息进行存储。

存储模块600可以将建链请求报文携带的本端地址、本端端口、目的地址、目的端口和报文转发的目的服务节点标识信息，作为本次分发建链信息进行存储，生成分发会话表。

在获取本次建链的相关信息后，存储模块600生成会话分发表，并动态更新，实时记录建链信息用于会话分发表的动态生成。

会话分发表可以用于后续发起端非建链请求报文的转发。具体的，在发起端与服务节点进行会话时，首先，接收模块100接收到同一发起端的非建链请求报文时，转发模块300查询会话分发表，获取已与发起端建链的服务节点。

然后，转发模块300将本次报文转发给获取的服务节点。

服务节点收到报文后，进行相应的处理，向发起端提供服务。

在本实施例中，存储模块600通过存储本次分发建链信息，生成分发会话表，用于后续同一发起端报文的分发。本实施例实现了当发起端与服务节点建链时，接收模块100再接收到发起端后续的非建链请求报文时，可直接根据分发会话表由转发模块300转发至相应的服务节点，减轻了服务器集群的负担，加快了服务器集群的响应速度，增强了服务器集群的整体性能，给用户带来了更好的业务体验。

进一步的，参照图8，本发明分发建链装置第四实施例提供一种分发建链装置，基于上述图7所示的实施例，所述分发建链装置还包括：

判定模块700，用于根据所述分发会话表，判断所述发起端是否进行过建链。

在筛选模块200获取合法的建链请求报文后，判定模块700根据动态生成的分发会话表，查找发起端是否已和服务器集群建立过建链。

具体的，作为一种实施方式，判定模块700根据当前发起端的本端地址、本端端口查找分发会话表是否记录了当前发起端建链报文转发的目的服务节点标识信息。

若判定模块700在分发会话表中成功查找到当前发起端建链报文转发的目的服务节点标识信息，则判定发起端已与服务器集群进行过建链；

若判定模块700在分发会话表中未成功查找到当前发起端建链报文转发的目的服务节点标识信息，则判定发起端未与服务器集群进行过建链。

由此，判定模块700得到判定结果。

所述转发模块300还用于，若所述发起端进行过建链，则根据所述会话分发表，获取已与所述发起端进行过建链的服务节点，并将所述合法的建链请求报文转发给所述获取的服务节点进行建链；若所述发起端未进行过建链，则根据预置的负荷分担表，将所述合法的建链请求报文转发给负荷最小的服务节点进行建链。

若发起端和服务器集群进行过建链，则转发模块300根据会话分发表，获取已和当前发起端进行过建链的服务节点标识信息，并根据标识信息将建链请求报文转发给获取的服务节点，由获取的服务节点与发起端进行建链。

若发起端和服务器集群未进行过建链，则转发模块300根据预置的负荷分担表，将本次建链请求报文转发给负荷最小的服务节点，完成本次建链请求报文的分发，由选取的服务节点与发起端进行TCP协商。

在本实施例中，判定模块700根据分发会话表，判断发起端是否进行过建链；若发起端进行过建链，则转发模块300接入侧根据预置的负荷分担表，将本次建链请求报文转发给已和发起端进行过建链的服务节点进行建链；若发起端未进行过建链，则转发模块300根据预置的负荷分担表，将本次建链请求报文转发给负荷最小的服务节点进行建链。本实施例通过会话分发表的判定，将已进行过建链的发起端建链请求分发给已和发起端进行过建链的服务节点进行处理，减轻了集群中其他服务节点的处理负担，均衡了集群中各服务节点的负荷，从而避免报文重复分发造成资源浪费，加快了服务器集群的响应速度，增强了服务器集群的整体性能，给用户带来了更好的业务体验。

参照图9，本发明分发建链系统第一实施例提供一种分发建链系统，所述分发建链系统包括发起端A和服务器B，其中：

所述发起端A，用于发送建链请求报文。

在本实施例中，以向服务器集群发起建链请求、获取服务的终端作为发起端。

根据本发明应用场景，发起端A可以分为外网终端和内网终端。

其中，外网终端为服务器集群外的、获取服务器集群服务的移动终端或服务器等终端。外网终端可以通过WiMax(Worldwide Interoperability forMicrowave Access,全球微波互联接入)、WLAN(Wireless Local Area Networks，无线局域网络)、HSPDA(High Speed Downlink Packet Access，高速下行分组接入)、网线、或3G等通信技术与服务器集群进行通信。例如，宽带移动终端均可能通过宽带网络，使用TCP协议向核心网网元获取服务。

内网终端为服务器集群内获取服务的终端或节点。例如，核心网内的节点需要向UDS请求目录服务，UDS服务器提供本端的IP和端口。当该节点请求服务的时候，服务器B将会根据负荷分担在相应的UDS服务器节点建立链接，并提供相关服务。

所述服务器B包括接入侧B1和服务侧B2；

所述接入侧B1包括接收模块100、筛选模块200、转发模块300、部署模块400、获取模块500、存储模块600和判定模块700；

所述服务侧B2，用于接收所述建链请求报文，与所述发起端A建链。

服务器B包括接入侧B1和服务侧B2。其中，接入侧B1用于接收发起端A的建链请求报文并分发给服务侧B2，接收服务侧B2的应答并转发给发起端A.

服务侧B2用于接收接入侧B1分发的报文并应答，向发起端A提供相应的服务。

需要说明的是，接入侧的接收报文功能和转发报文功能可由同一物理硬件实现，也可由不同的物理硬件组合实现。

参照图10，以本发明应用场景为手机客户端向IMS核心网请求服务，进行举例说明。

在本应用场景中，发起端A包括有多个手机客户端，手机客户端请求获取呼叫限制限制功能的服务业务。

手机客户端通过TCP链接接入IMS核心网，接口板作为接入侧B1接收手机客户端的建链请求报文并进行分发。接口板基于SIP-I(Session InitiationProtocol，会话初始协议)进行会话管理。本实施例中包括有备用接口板SIP-I，用于处理突发情况。

IMS核心网中的BSF/AP网元作为服务侧B2，为手机客户端提供触发业务。

具体的，使用Client-1、Client-2……Client-N表征各请求服务的手机客户端。

Client-1、Client-2……Client-N向IMS核心网请求开启呼叫限制功能的开启服务，该功能需要通过HTTP协议向BSF/AP网元发起请求。在HTTP请求发起前，Client-1、Client-2……Client-N需要和BSF/AP网元建立TCP链接。

作为一种实施方式，首先，Client-1、Client-2……Client-N向IMS核心网发出TCP SYN建链请求报文。

接口板收到手机客户端发出的SYN报文以后，解析报文中的目的IP地址和端口，根据预置的动态分发表依次检查Client-1、Client-2……Client-N是否是本端允许接入的地址和端口。

如果不是本端允许接入的地址和端口，接口板将丢弃SYN报文；

如果是本端允许接入的地址和端口，则接口板根据预置的负荷分担表查找BSF/AP网元中服务处理节点SMP(Symmetric Multi Processing，对称多处理系统)，得到各服务处理结点SMP-1、SMP-2……SMP-N。

然后，接口板依次为Client-1、Client-2……Client-N的建链，根据负荷分担表选取相应的负荷最小的服务处理节点SMP。需要说明的是，接口板为Client-1、Client-2……Client-N建链所选取的服务处理节点SMP可以是相同的，也可以是不同的。

然后，接口板分别将Client-1、Client-2……Client-N的SYN报文转发给相应的已选取的服务处理节点SMP。

然后，由选取的服务处理节点SMP分别与发起端Client-1、Client-2……Client-N进行TCP三次握手，完成TCP建链，接口板记录下每个手机客户端的会话，生成会话分发表。

此后，接口板收到Client-1、Client-2……Client-N发起的开启呼叫限制请求报文，根据各个手机客户端的IP地址和端口，在建立好的会话中，根据会话分发表获取已和手机客户端建立过链接的服务处理节点SMP，并将请求报文转发到获取的服务处理节点SMP。

各服务处理节点SMP收到开启呼叫限制请求后，处理手机客户端请求，并把处理结果发送回手机客户端。

在本实施例中，分发建链系统包括发起端A和服务器B。发起端A发起建链请求，服务器B通过接入侧B1均匀分发建链请求报文，使得服务侧B2能够均衡处理发起端A的建链请求和服务请求。本实施例实现了服务器集群的负荷均衡，减轻了服务器集群的负担，加快了服务器集群的响应速度，增强了服务器集群的整体性能，给用户带来了更好的业务体验。

进一步的，参照图11，本发明分发建链系统第二实施例提供一种分发建链系统，基于上述图9所示的实施例，所述服务侧B2包括：

各服务节点B21，所述各服务节点B21用于将动态负荷参数发送给所述接入侧B1，接收所述接入侧转发的建链请求报文，并根据所述建链请求报文与所述发起端A进行建链，接收所述接入侧转发的所述发起端的后续报文。

在本实施例中，服务侧B2包括提供服务的各服务节点B21。

各服务节点B21实时更新负荷参数，并实时上报给接入侧B1，用于接入侧B1负荷分担表的生成。

其中，各服务节点B21的负荷参数包括各服务节点的负荷状况，各服务节点的负荷状况可以是各服务节点上的TCP链接数，也可以是各服务节点上的CPU使用率、内存占用率等技术参数，也可以是其他标识各服务节点负荷状况的参数，可根据实际需要灵活设定。

各服务节点B21侦听接入侧B1，向接入侧B1提供各服务节点B21能够处理的服务信息，和各服务节点B21的标识信息，如IP地址和端口。接入侧B1可以获取各服务节点B21的侦听信息，得到各服务节点B21能够处理的服务信息和表示信息。

由此，接入侧B1可以根据建链请求报文的服务请求和各服务节点B21的侦听信息，获取能够处理发起端服务请求的服务节点。

然后，从能够处理发起端服务请求的服务节点中选取负荷最小的服务节点，并根据各服务节点B21的标识信息转发报文。

各服务节点B21接收接入侧B1转发的建链请求报文后，根据建链请求报文通过接入侧B1与发起端A进行建链，接收接入侧B1转发的后续报文并向发起端A提供相应的服务。

以本发明应用场景为第三方应用服务器向核心网获取服务，进行举例说明。

在本应用场景中，服务侧B2是核心网HLR(Home Location Register，归属位置寄存器)网元的UDS分布式数据库系统，接入侧B1为UDS接口板，而发起端A是第三方应用服务器，如AS服务器。

UDS为AS服务器提供基于TCP的目录查询服务，AS服务器通过标准的LDAP(Lightweight Directory Access Protocol，轻量目录访问协议)接口访问UDS。

作为一种实施方式，首先，AS服务器在向UDS获取目录服务的时候，已知道UDS服务器的服务IP地址和端口号。AS服务器在查询目录之前，需要先建立TCP链接。

UDS接口板在收到AS服务器的TCP链接请求后，首先，根据预置的动态分发表判断AS服务器的TCP建链请求报文是否合法。

若AS服务器的TCP建链请求报文合法，则UDS接口板根据分发会话表查询AS服务器是否已和UDS服务器进行过建链。

若AS服务器未和UDS服务器进行过过建链，UDS接口板将根据预置的负荷分担表查询各个UDS服务节点的链接负荷，选取负荷最小的服务节点，将AS服务器的建链请求转发到选取的服务节点，由该服务节点和AS服务器通过接口板转发报文完成TCP三次握手建链过程。

链接建立成功以后，AS服务器会通过TCP链接发送查询目录数据请求报文给服务器UDS，UDS接口板收到查询目录数据请求报文后，根据TCP链接的服务节点IP地址和端口号，查询到具体的服务节点，将请求转发给相应的服务节点。

由该服务节点接收接入侧B1转发的发起端A的后续报文，提供目录查询服务，并将查询结果应答给AS服务器。

在本实施例中，服务侧B2包括提供服务的各服务节点B21，各服务节点B21将动态负荷参数发送给接入侧B1，用于接入侧B1负荷分担表的生成；各服务节点B21接收接入侧B1转发的建链请求报文，并根据建链请求报文与发起端A进行建链。本实施例实现了服务器集群中各服务节点的负荷均衡，减轻了服务器集群的负担，加快了服务器集群的响应速度，增强了服务器集群的整体性能，给用户带来了更好的业务体验。

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

Claims (10)

1.一种分发建链方法，其特征在于，所述分发建链方法包括以下步骤：

接收发起端的建链请求报文；

根据预置的动态分发表，从所述建链请求报文中获取目的地址和目的端口合法的建链请求报文；

根据预置的负荷分担表，将所述合法的建链请求报文转发给负荷最小的服务节点进行建链。

2.如权利要求1所述的分发建链方法，其特征在于，所述接收发起端的建链请求报文的步骤之前，还包括：

部署所述动态分发表，所述动态分发表记录预设的合法建链目的地址和目的端口；

获取各服务节点的动态负荷参数，生成所述负荷分担表。

3.如权利要求1或2所述的分发建链方法，其特征在于，所述根据预置的负荷分担表，将所述合法的建链请求报文转发给负荷最小的服务节点进行建链的步骤之后，还包括：

存储本次分发建链信息，生成分发会话表，所述分发会话表用于所述发起端后续报文的分发。

4.如权利要求3所述的分发建链方法，其特征在于，所述根据预置的动态分发表，从所述建链请求报文中获取目的地址和目的端口合法的建链请求报文的步骤之后，还包括：

根据所述分发会话表，判断所述发起端是否进行过建链；

若所述发起端进行过建链，则根据所述会话分发表，获取已与所述发起端进行过建链的服务节点，并将所述合法的建链请求报文转发给所述获取的服务节点进行建链；

若所述发起端未进行过建链，则转入执行步骤：根据预置的负荷分担表，将所述合法的建链请求报文转发给负荷最小的服务节点进行建链。

5.一种分发建链装置，其特征在于，所述分发建链装置包括：

接收模块，用于接收发起端的建链请求报文；

筛选模块，用于根据预置的动态分发表，从所述建链请求报文中获取目的地址和目的端口合法的建链请求报文；

转发模块，用于根据预置的负荷分担表，将所述合法的建链请求报文转发给负荷最小的服务节点进行建链。

6.如权利要求5所述的分发建链装置，其特征在于，所述分发建链装置还包括：

部署模块，用于部署所述动态分发表，所述动态分发表记录预设的合法建链目的地址和目的端口；

获取模块，用于获取各服务节点的动态负荷参数，生成所述负荷分担表。

7.如权利要求5或6所述的分发建链装置，其特征在于，所述分发建链装置还包括：

存储模块，用于存储本次分发建链信息，生成分发会话表，所述分发会话表用于所述发起端后续报文的分发。

8.如权利要求7所述的分发建链装置，其特征在于，所述分发建链装置还包括：

判定模块，用于根据所述分发会话表，判断所述发起端是否进行过建链；

所述转发模块还用于，若所述发起端进行过建链，则根据所述会话分发表，获取已与所述发起端进行过建链的服务节点，并将所述合法的建链请求报文转发给所述获取的服务节点进行建链；若所述发起端未进行过建链，则根据预置的负荷分担表，将所述合法的建链请求报文转发给负荷最小的服务节点进行建链。

9.一种分发建链系统，其特征在于，所述分发建链系统包括发起端和服务器，其中：

所述发起端，用于发送建链请求报文；

所述服务器包括接入侧和服务侧；

所述接入侧包括如权利要求5-8所述的任一项分发建链装置；

所述服务侧，用于接收所述建链请求报文，与所述发起端建链。

10.如权利要求9所述的分发建链系统，其特征在于，所述服务侧包括：

各服务节点，所述各服务节点用于将动态负荷参数发送给所述接入侧，接收所述接入侧转发的建链请求报文，并根据所述建链请求报文与所述发起端进行建链，接收所述接入侧转发的所述发起端的后续报文。