CN101014045A - 服务承载网中服务管理的分布式方法 - Google Patents

Abstract

本发明属于服务承载网服务管理技术领域，其特征在于，该方法引入了多聚集节点间的服务管理，包含以下步骤：服务器注册，服务的本地维护，服务信息在聚集节点的更新，聚集节点间的信息动态交互及动态维护，以及客户端的请求和处理等步骤。本发明一方面优化了用户的服务响应时间，在服务选择时兼顾了网络延迟和服务器负载情况，另一方面摆脱了单聚集节点的瓶颈问题，有很好的扩展性，适用于大规模服务的环境。

Description

服务承载网中服务管理的分布式方法

技术领域

服务承载网中服务管理的分布式方法属于互联网技术领域，尤其涉及服务定位，服务质量路由领域。

背景技术

当前Internet上有很多应用分散在Internet中不同地理位置的多个服务器副本上，这些服务器的副本能够提供相同的服务，或者含有同一类资源。典型的如：分布式镜像***，内容分发网络，域名服务***，分布式文件***/数据库等等，之所以设置同一个服务的多个服务器副本是出于提高服务的质量，增强容错性和负载平衡的考虑。但这同时给选择服务的用户提出了一个难题。因此我们期望网络可以自己承担发现“最好”的服务这一任务，而不是由对网络没有太多认识的端***在一系列服务列表中去无意识的选择。

本发明基于服务承载网络的架构，(它位于传输层和应用层之间，向下和底层网络融合；向上可以为应用提供支持服务质量路由，流量负载均衡等服务的接口)。

本发明的关注点在于在将服务定位和服务质量路由引入服务承载网过程中，每类服务只有一个聚集节点管理服务器负载信息，在服务规模增大的时候而引发的瓶颈问题，从而提出服务管理的分布式方法，来减轻服务承载网聚集节点的负担。

发明内容

本发明的目的在于提供服务承载网中服务管理的分布式方法。

本发明的实施依次有如下步骤：

步骤1.初始化：

网络管理员在该服务承载网中部署多个节点，各节点通过运行服务承载网协议交互节点及链路信息形成一个传输网络和上层应用网络之间的服务承载网；

在和所述各节点相连的相应各服务器中，部署运行服务注册和更新的协议，而且各服务器和客户机各自已通过距离自己最近的本地服务承载网络节点接入该服务承载网；

步骤2.源服务器注册，依次含有以下步骤：

步骤2.1.源服务器向本地的服务承载网节点UNode_S，以(Service，Server_Load)的格式提出注册服务申请，其中Service为该源服务器所提供的服务名称，Server_Load是该源服务器的负载，同时提供该源服务器的IP地址Server_IP；

步骤2.2.该UNode_S节点把收到的与注册请求相应的源服务器的IP地址和Service字段(Server_IP，Service)放入本地的服务节点信息表中；

步骤2.3.该UNode_S节点对本地的服务信息表中的每一个注册表项产生一个能在服务承载网中唯一标识的注册消息，其格式为(Service_ID，Server_Load)，其中，Service_ID由所述本地服务信息表项中的Service字段，本地承载网节点的全局唯一的节点号UNode_S_ID和源服务器地址Server_IP共同构成，源服务器的负载Server_Load的值记作l，由服务承载网中该源服务器的接入节点UNode_S协助该源服务器来度量的，l的衡量标准为：实时测量得到的该源服务器到它的接入节点的已占用带宽B_used与该段链路的容量C之比，l的取值在[0，1]之间，该B_used＝C-B_available，该B_available为可用带宽；

步骤2.4.该UNode_S节点查询本身的服务聚集节点表，该表维护的是对该UNode_S节点的每种服务的所有默认聚集节点UNode_R，所述聚集节点的数量k＞＝2，若表中有对应该类服务的聚集节点UNode_R_ID，转步骤2.7；否则，执行下一步骤；

步骤2.5.若表中没有对应该类服务的聚集节点UNode_R_ID，节点UNode_S根据hash(Service)算法得到一个32比特的散列值，节点UNode_S向节点号与散列值最接近的一个聚集节点发送一条查询信息，其中hash(Service)算法采用SHA-1散列算法，该算法使任意长度服务名称经哈希函数计算变换为一个32比特的散列值；

步骤2.6.收到步骤2.5所述查询信息的聚集节点查询查询聚集节点负载表，该负载表维护的是该类服务的所有聚集节点的负载信息，该节点UNode_R把当前负载最小的聚集节点的UNode_R(min)_ID返回发送查询信息的UNode_S，该负载最小的聚集节点把字段(UNode_R(min)_ID，UNode_S_ID)添加到负责节点表中，该表维护的是相应于该类服务的所有聚集节点所分别负责的服务承载网相应本地节点的列表；

步骤2.7.节点UNode_S向节点号为UNode_R_ID的聚集节点发送步骤2.3中产生的(Service_ID，Server_Load)注册消息，转步骤4.1；

步骤3.服务的本地维护，依次按以下步骤进行：

步骤3.1.服务器周期性地向本地UNode_S节点发送如步骤2.1中所述的注册消息，从而使本地节点得知接入服务器的活跃情况，若在连续的3个周期内没收到应答，则根据服务聚集节点表中维护的负责该服务的聚集节点的ID，向该聚集节点报告服务器不活跃，所述聚集节点的ID是指步骤2.4中的UNode_R_ID，或者是步骤2.6中的UNode_R(min)_ID；

步骤3.2.当源服务器检测到负载低于80％时，向服务承载网络的本地节点UNode_S报告自己的负载信息，此信息由本地节点UNode_S转发到服务聚集节点表中维护的负责该类服务的聚集节点维护，所述聚集节点的ID是指步骤2.4中的UNode_R_ID，或者是步骤2.6中的UNode_R(min)_ID；

步骤4.服务信息在聚集节点表中的更新，依次按以下步骤执行；

步骤4.1.若聚集节点收到(Service_ID，Server_Load)的注册消息后，向其维护的服务器副本信息表中添加这一条注册消息；

步骤4.2.若聚集节点收到服务器不活跃消息，则删除服务器副本信息表中的相应服务器IP地址的表项；

步骤4.3.若聚集节点收到负载变化消息，则更新服务器副本信息表中的相应负载表项；

步骤5.聚集节点间的信息交互，依次含有以下步骤；

步骤5.1在服务承载网的节点周期性维护路由信息的时候，聚集节点将自己维护的节点列表的变化情况和当前负载，附在路由协议的LSA后边，发送给相邻的该类服务的聚集节点；

步骤5.2.若某聚集节点收到步骤5.1所述的交互信息，先查看是否过时，如果过时，转步骤5.3，否则转步骤5.4；

步骤5.3.直接丢弃，不进行处理；

步骤5.4.修改负责节点表或聚集节点负载表，在下一次周期性维护路由信息的时候向相邻聚集节点转发；

步骤6.聚集节点按以下步骤进行动态维护：

步骤6.1.若某聚集节点的负载超过设定阈值，则选择距离它最近的一个非聚集节点，将它作为新的聚集节点；

步骤6.2.把原聚集节点维护的一半节点分给新的聚集节点，在新的聚集节点分别依照原聚集节点维护的表项重新建立服务器副本表，聚集节点负载表和负责节点表，同时修改原聚集节点的相应表项；

步骤6.3.新聚集节点给它们维护的服务承载网中的每个本地节点发送消息，通告聚集节点的变化，相应地，服务承载网中的本地节点修改服务聚集节点表，把表项中的原聚集节点UNode_R_ID替换成新的；

步骤6.4.新聚集节点向其他聚集节点发送动态维护消息，其他聚集节点修改聚集节点负载表或负责节点表；

步骤7.客户端的请求和处理：

步骤7.1.客户端首先向接入的服务承载网络节点提出服务请求消息，格式为(Service，QoS)；

步骤7.2.收到请求的服务承载网络节点(记作UNode_c)同样根据服务聚集节点表得出服务承载网中负责此类服务的聚集节点号，并向此聚集节点发送(Service，QoS)请求，此聚集节点再将请求转发给该类服务的其他聚集节点；

步骤7.3.收到步骤7.2所述服务请求的聚集节点依次执行以下操作：

步骤7.3.1.查询服务器副本信息表中各个表项的UNode_S节点及其对应的Server_Load信息，把Server_Load信息记作l；

步骤7.3.2.查询服务承载网的虚链路度量数据库，得到服务器副本信息表中各个表项中的UNode_S节点到UNode_c节点的延迟，记作d；

步骤7.3.3.计算各UNode_s节点的值1/(d+l)，它综合反映了服务器与客户端距离以及服务器处理能力，并得到按此值从大到小排列的UNode_S节点号的序列；

步骤7.4.各聚集节点将序列中前30％的UNode_S的(UNode_S_ID，1/(d+l))返回给步骤7.2中所述最初请求的聚集节点，该聚集节点再对汇总的UNode_S进行再排序

步骤7.5.计算步骤7.4中所述新序列中第一个UNode_S节点到UNode_c节点，满足请求中QoS约束的一条可行路径；

步骤7.6.若存在可行路径，则最初请求的聚集节点向UNode_c节点发送请求成功的消息，并后续转发给客户端；并向该序列中第一个UNode_S节点发送可行路径消息，后续服务器的服务数据沿此路径发送给客户端；

步骤7.7.若计算失败，则继续对该序列中的后续节点执行步骤7.5中的计算；

步骤7.8.若该序列的所有后续节点都没有可行路径，则向UNode_c节点发送请求失败的消息，并后续转发给客户端。

本发明的特点在于：不需要对物理网络的现有设备作更改，可同时支持多种服务，客户端只需简单提出所需服务和服务质量需求即可，以优化用户的服务响应时间为目的，服务选择时兼顾网络延迟和服务器负载。

本发明相对于单聚集节点的方法，实现起来较为复杂，且要承担聚集节点间的信息交互，聚集节点动态维护以及分布式计算的开销，但是摆脱了单聚集节点的瓶颈问题，有良好的可扩展性，适合于服务规模较大的情况。

本发明的贡献在于提出了聚集节点间的信息交互方法，聚集节点的动态维护方法以及分布式情况下的QoS路径计算方法。

附图说明

图1.服务承载网络模型；

图2.***流程图；

图3.服务器注册流程图；

图4.分布式管理流程图；

图5.单聚集节点与多聚集节点性能比较。

具体实施方式

在本发明所述***中，除了服务承载网络的每个节点都需要运行同一套基本的服务承载网协议之外，服务器还需要运行服务注册和更新协议；客户端无需运行任何额外的协议，只需通过Web方式向服务承载网的接入节点提出服务申请即可。

服务承载网络中的服务大体上分成两种：“数据提供型”和“服务提供型”，其中对于前者，从服务器到客户端的数据传输量较大，对应于下载和在线播放等服务；后者的数据传输量较轻，对应于DNS解析等服务。不论对于这两大类服务中的哪种具体服务，服务的提供者可通过网站，电子邮件等方式使用户得知服务名称，以便用户提出服务请求。

维护表项：

本地的服务承载网节点维护了两张表，服务信息表(Server_IP，Service)和服务聚集节点表(Service，UNode_R_ID)。

聚集节点额外维护服务器副本表(Service_ID，Service_Load)和聚集节点负载表(UNode_R_ID，UNode_Load)和负责节点表(UNode_R_ID，UNode_S_ID)。

服务承载网对每一类服务设置有多个聚集节点进行服务器的选择和服务路由的计算。一个服务器副本只要注册到该类服务的任一聚集节点上，就可在服务承载网络中提供服务，具体有以下步骤：

本地注册：

在此步骤中，服务承载网络的服务接入节点需要维护所有服务器(与服务类型无关)的接入信息，保存在下面的表中。

服务器本地的服务信息表中各列的含义：

名称	含义
		Server_IPService	服务器的IP地址。该服务器所能提供的服务名称。

本地节点不保存服务器的负载信息，而将此信息转发给聚集节点维护。因此承载网络中，服务的接入节点只需维护本地有那些服务器，各自能提供什么服务即可。在本地注册后，本地节点需要继续将信息注册到聚集节点，为了提高效率需要维护服务聚集节点表

服务器本地的服务聚集节点表中各列的含义：

名称	含义
		UNodeR_IDService	对于该类服务负责该本地节点的聚集节点ID服务名称。

因为在服务承载网内部的通信是以每个服务承载网络节点的全局唯一的节点号为标识的，本地节点须将自己的节点号信息附加在注册信息中，发至聚集节点；又考虑到本地可能存在多个能提供相同服务的服务器同时接入，因此还需要服务器的IP来标识；因此最终产生的在服务承载网络中标识服务的Service_ID由服务名称，提供此服务接入的服务承载网络的节点号UNode_S和服务器的IP地址共同构成。

特定服务聚集节点所维护的服务器副本信息表中各列的含义：

名称	含义
		Service_IDServer_Load	在服务承载网络中唯一标识一个服务的ID号，由服务名称，提供此服务接入的服务承载网络的节点号UNodeS和服务器的IP地址构成。是服务器的负载。

在本地节点和服务器的交互中，仅区分服务名称和服务器IP地址即可；而在本地节点和聚集节点的交互中，仅区分服务名称和UNode_S节点号即可。

向聚集节点的注册：

在此步骤中，一类服务的一组聚集节点维护此类服务所有服务器副本的信息，根据服务承载网络自身提供的节点间的虚链路度量信息以及下表中的各个服务器副本的性能，来综合决定服务器副本的选择。这样作的目的是对用户请求服务的响应时间的综合考虑。如步骤6.3.3中，d刻画了服务承载网络内部的通信延迟；l刻画了服务器的处理延迟及其到接入节点之间的延迟，(这里认为客户端的接入节点到客户端的下行带宽不成为***的瓶颈)，如果仅以服务器的负载为依据，那么可能最终会选择一个负载较轻但是实际上距客户端很远的服务器，这不是我们想看到的。

上面提到选择服务器时综合考虑了延迟和服务器负载的因素，在本***中，服务器的负载是由服务承载网络中服务器的接入节点协助服务器来度量的，具体方法是将实时测量的服务器到其接入节点的已占用带宽B_used与此段链路的容量C相比，作为服务器的负载的衡量标准，取值在[0，1]之间。C是定值，而B_used＝C-B_Available得到，B_Available是可用带宽，可通过PathChirp等工具测量得出。

聚集节点的选择：

如果服务聚集节点表中有相应服务的聚集节点表项，则查表就可以；如果服务聚集节点中没有表项，采取SHA-1散列算法，任意长度的服务名称经哈希函数计算得到固定长度(32比特)的散列值，向节点号与这个散列值最接近的聚集节点发送查询消息，该聚集节点查询聚集节点负载表，找出负载最轻的聚集节点返回给本地节点。

聚集节点负载信息表中各列的含义：

名称	含义
		UNodeR_IDUNode_load	聚集节点的ID该聚集节点的负载

用户请求的QoS：

作为本发明背景的服务承载网支持延迟，可用带宽，丢包率这三种度量的虚链路测量，因此这里限定用户的提出的服务质量约束限制在这三种以内，多约束的路由由聚集节点计算，本***采用源路由的策略，由聚集节点根据本地维护的全网虚链路信息，计算一条从服务器接入节点到客户端接入节点的路径；并计算所得路径发送给服务器接入节点，按照此路径发送服务数据。

聚集节点间的信息交互：

在服务承载网节点周期性维护路由信息的时候，聚集节点将自己维护的节点列表的变化情况和当前负载，附在路由协议的LSA后边，发送给相邻的聚集节点，只交互自己维护节点的变化情况和负载是为了减少交互信息的数量，增强***的可扩展性，而附在路由协议LSA后面周期性发送，进一步减少了聚集节点信息维护带来的额外开销。

负责节点表中各列的含义：

名称	含义
		UNodeS_ID	聚集节点维护的本地节点列表

聚集节点的动态维护：

若某聚集节点的负载超过设定阈值，例如80％，则选择距离它最近的一个非聚集节点，将它作为新的聚集节点；将原聚集节点维护的一半节点分给新的聚集节点，在新的聚集节点分别依照原聚集节点维护的表项重新建立服务器副本表，聚集节点负载表和负责节点表，同时修改原聚集节点的相应表项；新聚集节点给它维护的每个本地节点发送消息，通告聚集节点的变化，本地节点修改服务聚集节点表，即将表项中的原聚集节点UNode_R_ID替换成新的；新聚集节点向其他聚集节点发送动态维护消息，其他聚集节点修改聚集节点负载表和负责节点表；

要注意的是每类服务的聚集节点数最小值为2，这是为了不产生瓶颈。

协议设计

聚集节点信息交互协议设计

0-7		8-15
			协议类型		总长度
发出通告节点号
			序列号
UNode_Load
			类型
UNodeS_ID
			类型
UNodeS_ID
			。。。。。。。。。。。。

协议类型8位，1表示聚集节点间信息交互协议，

总长度8位，表示信息交互协议的总长度，

发出通告节点号32位，表示发出消息的聚集节点的UNode_R_ID，

序列号：32位无符号整数，用来检验是否过时，

UNode_Load16位：表示该聚集节点的负载，

类型：1表示添加一个本地节点，2表示删除一个本地节点，

UNode_S_ID，本地节点序号。

聚集节点动态维护协议设计

0-7	8-15
		协议类型	总长度
发出通告节点号
		序列号
UNodeS_ID
		UNodeS_ID
。。。。。。。。。。。。

协议类型8位，2表示聚集节点间动态维护协议，

总长度8位，表示动态维护协议的总长度，

发出通告节点号32位，表示发出消息的聚集节点的UNode_R_ID，

序列号：32位无符号整数，用来检验是否过时，

UNode_S_ID，表示新聚集节点维护的本地节点序号。

本地节点查询协议设计

0-7	8-15
		协议类型	总长度
发出通告节点号

序列号

协议类型8位，3表示本地节点查询协议，

总长度8位，表示本地节点查询协议的总长度，

发出通告节点号32位，表示发出消息的本地节点的UNode_S_ID，

序列号：32位无符号整数，用来检验是否过时。

返回查询结果协议设计

0-7	8-15
		协议类型	总长度
发出通告节点号
		序列号
UNodeR_ID

协议类型8位，4表示返回查询结果协议，

总长度8位，表示查询结果返回协议的总长度，

发出通告节点号32位，表示发出消息的聚集节点的UNode_R_ID，

序列号：32位无符号整数，用来检验是否过时，

UNode_R_ID：返回的负载最轻的聚集节点ID

分布式QoS计算请求协议

0-7	8-15
		协议类型	总长度
发出通告节点号
		序列号
UNodeC_ID

协议类型8位，5表示分布式QoS计算请求协议，

总长度8位，表示分布式QoS计算请求协议的总长度，

发出通告节点号32位，表示发出消息的聚集节点的UNode_R_ID

序列号：32位无符号整数，用来检验是否过时，

UNode_C_ID：收到请求的节点ID。

分布式QoS计算结果返回协议

0-7	8-15
		协议类型	总长度
发出通告节点号
		序列号
UNodeS_ID
		1/(d+1)
UNodeS_ID

1/(d+1)
	。。。。。。。。。。。。

协议类型8位，6表示分布式QoS计算结果返回协议，

总长度8位，表示协议的总长度，

发出通告节点号32位，表示发出消息的聚集节点的UNode_R_ID

序列号：32位无符号整数，用来检验是否过时，

UNode_S_ID：按照1/(d+l)排序在前30％的UNode_S_ID。

实验：

假定服务承载网每个聚集节点能承受的最大负载相同且为10Mb/s，聚集节点数随实际平均负载而变化，即超过某阈值，例如70％，增加一个聚集节点，但最少也要有2个聚集节点，假定网络流量由1Mb/s，以1Mb/s速度递增到30Mb/s，则分别绘出单个聚集节点和多个聚集节点负载随流量变化的图，可见采用多个聚集节点时每个聚集节点的负载情况明显优于单聚集节点的情况。

可见本发明可以解决单个聚集节点造成的瓶颈问题。

Claims (1)

1服务承载网中服务管理的分布式方法，其特征在于，所述的方法是在服务承载网中，依次按以下步骤实现的：

步骤1.初始化：

网络管理员在该服务承载网中部署多个节点，各节点通过运行服务承载网协议交互节点及链路信息形成一个传输网络和上层应用网络之间的服务承载网；

在和所述各节点相连的相应各服务器中，部署运行服务注册和更新的协议，而且各服务器和客户机各自己通过距离自己最近的本地服务承载网络节点接入该服务承载网；

步骤2.源服务器注册，依次含有以下步骤：

步骤2.1.源服务器向本地的服务承载网节点UNode_S，以(Service，Server_Load)的格式提出注册服务申请，其中Service为该源服务器所提供的服务名称，Server_Load是该源服务器的负载，同时提供该源服务器的IP地址Server_IP；

步骤2.2.该UNode_S节点把收到的与注册请求相应的源服务器的IP地址和Service字段(Server_IP，Service)放入本地的服务节点信息表中；

步骤2.3.该UNode_S节点对本地的服务信息表中的每一个注册表项产生一个能在服务承载网中唯一标识的注册消息，其格式为(Service_ID，Server_Load)，其中，Service_ID由所述本地服务信息表项中的Service字段，本地承载网节点的全局唯一的节点号UNode_S_ID和源服务器地址Server_IP共同构成，源服务器的负载Server_Load的值记作l，由服务承载网中该源服务器的接入节点UNode_S协助该源服务器来度量的，l的衡量标准为：实时测量得到的该源服务器到它的接入节点的已占用带宽B_used与该段链路的容量C之比，l的取值在[0，1]之间，该B_used＝C-B_available，该B_available为可用带宽；

步骤2.4.该UNode_S节点查询本身的服务聚集节点表，该表维护的是对该UNode_S节点的每种服务的所有默认聚集节点UNode_R，所述聚集节点的数量k＞＝2，若表中有对应该类服务的聚集节点UNode_R_ID，转步骤2.7；否则，执行下一步骤；

步骤2.4.若表中没有对应该类服务的聚集节点UNode_R_ID，节点UNode_S根据hash(Service)算法得到一个32比特的散列值，节点UNode_S向节点号与散列值最接近的一个聚集节点发送一条查询信息，其中hash(Service)算法采用SHA-1散列算法，该算法使任意长度服务名称经哈希函数计算变换为一个32比特的散列值；

步骤2.6.收到步骤2.5所述查询信息的聚集节点查询查询聚集节点负载表，该负载表维护的是该类服务的所有聚集节点的负载信息，该节点UNode_R把当前负载最小的聚集节点的UNode_R(min)_ID返回发送查询信息的UNode_S，该负载最小的聚集节点把字段(UNode_R(min)_ID，UNode_S_ID)添加到负责节点表中，该表维护的是相应于该类服务的所有聚集节点所分别负责的服务承载网相应本地节点的列表；

步骤2.7.节点UNode_S向节点号为UNode_R_ID的聚集节点发送步骤2.3中产生的(Service_ID，Server_Load)注册消息，转步骤4.1；

步骤3.服务的本地维护，依次按以下步骤进行：

步骤3.1.服务器周期性地向本地UNode_S节点发送如步骤2.1中所述的注册消息，从而使本地节点得知接入服务器的活跃情况，若在连续的3个周期内没收到应答，则根据服务聚集节点表中维护的负责该服务的聚集节点的ID，向该聚集节点报告服务器不活跃，所述聚集节点的ID是指步骤2.4中的UNode_R_ID，或者是步骤2.6中的UNode_R(min)_ID；

步骤3.2.当源服务器检测到负载低于80％时，向服务承载网络的本地节点UNode_S报告自己的负载信息，此信息由本地节点UNode_S转发到服务聚集节点表中维护的负责该类服务的聚集节点维护，所述聚集节点的ID是指步骤2.4中的UNode_R_ID，或者是步骤2.6中的UNode_R(min)_ID；

步骤4.服务信息在聚集节点表中的更新，依次按以下步骤执行：

步骤4.1.若聚集节点收到(Service_ID，Server_Load)的注册消息后，向其维护的服务器副本信息表中添加这一条注册消息；

步骤4.2.若聚集节点收到服务器不活跃消息，则删除服务器副本信息表中的相应服务器IP地址的表项；

步骤4.3.若聚集节点收到负载变化消息，则更新服务器副本信息表中的相应负载表项；

步骤5.聚集节点间的信息交互，依次含有以下步骤：

步骤5.1在服务承载网的节点周期性维护路由信息的时候，聚集节点将自己维护的节点列表的变化情况和当前负载，附在路由协议的LSA后边，发送给相邻的该类服务的聚集节点；

步骤5.2.若某聚集节点收到步骤5.1所述的交互信息，先查看是否过时，如果过时，转步骤5.3，否则转步骤5.4；

步骤5.3.直接丢弃，不进行处理；

步骤5.4.修改负责节点表或聚集节点负载表，在下一次周期性维护路由信息的时候向相邻聚集节点转发；

步骤6.聚集节点按以下步骤进行动态维护：

步骤6.1.若某聚集节点的负载超过设定阈值，则选择距离它最近的一个非聚集节点，将它作为新的聚集节点；

步骤6.2.把原聚集节点维护的一半节点分给新的聚集节点，在新的聚集节点分别依照原聚集节点维护的表项重新建立服务器副本表，聚集节点负载表和负责节点表，同时修改原聚集节点的相应表项；

步骤6.3.新聚集节点给它们维护的服务承载网中的每个本地节点发送消息，通告聚集节点的变化，相应地，服务承载网中的本地节点修改服务聚集节点表，把表项中的原聚集节点UNode_R_ID替换成新的；

步骤6.4.新聚集节点向其他聚集节点发送动态维护消息，其他聚集节点修改聚集节点负载表或负责节点表；

步骤7.客户端的请求和处理：

步骤7.1.客户端首先向接入的服务承载网络节点提出服务请求消息，格式为(Service，QoS)；

步骤7.2.收到请求的服务承载网络节点(记作UNode_c)同样根据服务聚集节点表得出服务承载网中负责此类服务的聚集节点号，并向此聚集节点发送(Service，QoS)请求，此聚集节点再将请求转发给该类服务的其他聚集节点；

步骤7.3.收到步骤7.2所述服务请求的聚集节点依次执行以下操作：

步骤7.3.1.查询服务器副本信息表中各个表项的UNode_S节点及其对应的Server_Load信息，把Server_Load信息记作l；

步骤7.3.2.查询服务承载网的虚链路度量数据库，得到服务器副本信息表中各个表项中的UNode_S节点到UNode_c节点的延迟，记作d；

步骤7.3.3.计算各UNode_s节点的值1/(d+l)，它综合反映了服务器与客户端距离以及服务器处理能力，并得到按此值从大到小排列的UNode_S节点号的序列；

步骤7.4.各聚集节点将序列中前30％的UNode_S的(UNode_S_ID，1/(d+l))返回给步骤7.2中所述最初请求的聚集节点，该聚集节点再对汇总的UNode_S进行再排序

步骤7.5.计算步骤7.4中所述新序列中第一个UNode_S节点到UNode_c节点，满足请求中QoS约束的一条可行路径；

步骤7.6.若存在可行路径，则最初请求的聚集节点向UNode_c节点发送请求成功的消息，并后续转发给客户端；并向该序列中第一个UNode_S节点发送可行路径消息，后续服务器的服务数据沿此路径发送给客户端；

步骤7.7.若计算失败，则继续对该序列中的后续节点执行步骤7.5中的计算；

步骤7.8.若该序列的所有后续节点都没有可行路径，则向UNode_c节点发送请求失败的消息，并后续转发给客户端。

Images