一种全局负载均衡中的重定向方法和装置 【技术领域】
本发明涉及通信技术领域， 特别是涉及一种全局负载均衡中的重定向方法和装置。 背景技术
随着网络业务量的提高， 以及网络访问量和数据流量的快速增长， 现有网络的各 个核心部分的处理能力和计算强度也相应地增大， 使得单一的服务器设备根本无法承担全 部的网络任务。针对上述情况， 网络技术领域提出了负载均衡 (Load Balance， 以下简称 ： LB) 技术， 以扩展现有网络设备和服务器的带宽、 增加吞吐量、 加强网络数据处理能力、 提高 网络的灵活性和可用性。
按照负载均衡设备的网络部署的不同， 负载均衡技术可以包括局域负载均衡 (Local Load Balance， 以下简称 ： LLB) 和全局负载均衡 (Global Load Balance， 以下简称 ： GLB)。 如图 1 所示， 为现有技术中的局域负载均衡示意图。服务器集群集中在一个物理 位置， 负载均衡设备位于服务器集群外侧， 对客户端向服务器集群发起的服务访问进行分 发处理。
如图 2 所示， 为现有技术中的全局负载均衡示意图。服务器集群分布在不同地理 位置， 每个服务器集群的前端均部署一台 GLB 设备， 各个 GLB 设备之间协同工作， 对来自客 户端的服务访问进行分发。全局负载均衡能够为用户提供完全透明的服务， 使用户无需关 心服务器集群的物理分布， 能够有效避免服务器集群的单点失效， 通过就近访问的方式提 高服务器集群的响应速度。 相对于局域负载均衡而言， 全局负载均衡更加可靠， 能够向访问 用户提供更好的服务体验。
全局负载均衡使用的策略包括 HTTP(Hyper Text Transfer Protocol， 超文本传 输协议 ) 重定向技术， 该技术可以通过基于 HTTP 协议的重定向报文将用户流量引导到最优 的站点。如图 3 所示， 为现有技术中的全局负载均衡的 HTTP 重定向示意图。客户端向服务 器集群 I 发送 get( 获取 ) 请求 ； LB 设备 I 接收到 get 请求后， 发现本地服务器全部故障， 需 要将 get 请求重定向到服务器集群 II 上， 于是向客户端返回 HTTP 重定向报文 ( 如图 3 中 的实线流程所示 ) ； 客户端收到重定向报文后， 向重定向目的地址发起新的 HTTP 请求 ( 如 图 3 中的虚线流程所示 )。
然而， 在上述全局负载均衡的 HTTP 重定向过程中， 会出现在多个站点间重复重定 向的问题。例如， 当服务器集群 I 与服务器集群 II 都发生故障时， 可能会出现 get 请求从 服务器集群 I 重定向到服务器集群 II， 又从服务器集群 II 重定向回服务器集群 I， 导致业 务不可用。
为解决上述问题， 现有系统通过在站点之间增加私有协议交互的方式， 以规避重 复重定向的问题。例如， 全局负载均衡系统中存在三个服务器集群， 分别为服务器集群 I、 服务器集群 II 和服务器集群 III。三个服务器集群之间进行私有协议进行通信， 分别报告
各自的可用服务器个数。当服务器集群 I 中的所有服务器发生故障， 需要选择重定向站点 时， 会在存在可用服务器的站点中选择一个最优的站点， 如果服务器集群 II 中没有可用服 务器， 服务器集群 III 中存在可用服务器， 则将 get 请求直接重定向到服务器集群 III。
在实现本发明的过程中， 发明人发现现有技术至少存在如下问题 ：
由于站点之间的私有协议通信需要一定的通信时间， 而在该通信时间内会发生短 时间的重定向选择错误。 而在访问高峰时期， 对于需要提供高可靠性的服务商， 短时间的选 择错误也是无法接受的。 因此， 现有技术无法解决全局负载均衡中的重复重定向问题， 无法 保证全局负载均衡业务的可靠性。 发明内容 本发明提供一种全局负载均衡中的重定向方法和装置， 用以解决全局负载均衡中 的重复重定向问题。
本发明提出一种全局负载均衡中的重定向方法， 包括 ：
负载均衡设备接收来自客户端的超文本传输协议 HTTP 请求， 获取所述 HTTP 请求 中携带的向所述客户端发送过重定向报文的站点的信息 ；
所述负载均衡设备从站点列表选择除所述发送过重定向报文的站点之外的站点， 作为本次的重定向站点 ；
所述负载均衡设备根据选择出的重定向站点生成重定向报文， 其中， 所述负载均 衡设备将其所在站点的信息和获取到的发送过重定向报文的站点的信息作为发送过重定 向报文的站点的信息添加到所述重定向报文中 ；
所述负载均衡设备将所述重定向报文发送到所述客户端。
其中， 所述客户端通过以下方式生成 HTTP 请求 ：
所述客户端接收重定向报文， 获取所述重定向报文中携带的统一资源定位符 URL 信息， 所述 URL 信息中的查询 query 部分记录有向所述客户端发送过重定向报文的站点的 信息 ；
所述客户端生成包含所述 URL 信息的 HTTP 请求。
其中， 当所述 HTTP 请求中没有携带向所述客户端发送过重定向报文的站点的信 息时， 所述负载均衡设备从所述站点列表中选择本次的重定向站点 ；
所述负载均衡设备根据选择出的重定向站点生成重定向报文， 其中， 所述负载均 衡设备将其所在站点的信息作为向所述客户端发送过重定向报文的站点的信息添加到所 述重定向报文中 ；
所述负载均衡设备将所述重定向报文发送到所述客户端。
其中， 所述负载均衡设备将其所在站点的信息和获取到的发送过重定向报文的站 点的信息作为发送过重定向报文的站点的信息添加到所述重定向报文中， 具体为 ：
所述负载均衡设备从接收到的客户端的 HTTP 请求中获取 URL 信息， 并将该负载均 衡设备所在站点的信息添加到该 URL 信息中用于记录向所述客户端发送过重定向报文的 站点的信息的 query 部分 ；
所述负载均衡设备根据该添加了站点信息的 URL 信息生成所述重定向报文的 URL 信息。
其中， 所述站点的信息包括所述站点的 IP 地址、 站点标识和根据 IP 地址生成的用 于唯一标识所述站点的标识参数中的至少一种。
本发明还提出一种负载均衡设备， 包括 ：
获取模块， 用于接收来自客户端的 HTTP 请求， 获取所述 HTTP 请求中携带的向所述 客户端发送过重定向报文的站点的信息 ；
选择模块， 用于从站点列表选择除所述发送过重定向报文的站点之外的站点， 作 为本次的重定向站点 ；
生成模块， 用于根据所述选择模块选择出的重定向站点生成重定向报文， 其中， 所 述生成模块将所述负载均衡设备所在站点的信息和获取到的发送过重定向报文的站点的 信息作为发送过重定向报文的站点的信息添加到所述重定向报文中 ；
发送模块， 用于将所述生成模块生成的重定向报文发送到所述客户端。
其中， 所述选择模块， 还用于在所述 HTTP 请求中没有携带向所述客户端发送过重 定向报文的站点的信息时， 从所述站点列表中选择本次的重定向站点 ；
所述生成模块， 还用于根据所述选择模块选择出的重定向站点生成重定向报文， 其中， 所述生成模块将所述负载均衡设备所在站点的信息作为向所述客户端发送过重定向 报文的站点的信息添加到所述重定向报文中。 其中， 所述生成模块， 具体用于从接收到的客户端的 HTTP 请求中获取 URL 信息， 并 将所述负载均衡设备所在站点的信息添加到该 URL 信息中用于记录向所述客户端发送过 重定向报文的站点的信息的 query 部分 ； 根据该添加了站点信息的 URL 信息生成所述重定 向报文的 URL 信息。
其中， 所述站点的信息包括所述站点的 IP 地址、 站点标识和根据 IP 地址生成的用 于唯一标识所述站点的标识参数中的至少一种。
与现有技术相比， 本发明具有以下优点 ： 根据客户端的 HTTP 请求得到向客户端发 送过重定向报文的站点的信息， 并根据该站点的信息选择重定向站点， 避免了全局负载均 衡的重定向过程中出现的不同服务器集群间的重复重定向， 提高全局负载均衡业务的可用 性和可靠性。
附图说明
图 1 为现有技术中的局域负载均衡示意图 ； 图 2 为现有技术中的全局负载均衡示意图 ； 图 3 为现有技术中的全局负载均衡的 HTTP 重定向示意图 ； 图 4 为本发明实施例中的全局负载均衡的 HTTP 重定向示意图 ； 图 5 为本发明实施例中的全局负载均衡中的重定向方法流程图 ； 图 6 为本发明实施例中的负载均衡设备的结构示意图。具体实施方式
本发明实施例提供的技术方案中， 负载均衡设备接收来自客户端的超文本传输协 议 HTTP 请求， 获取该 HTTP 请求中携带的向客户端发送过重定向报文的站点的信息 ； 负载均 衡设备从站点列表选择除发送过重定向报文的站点之外的站点， 作为本次的重定向站点 ；负载均衡设备根据选择出的重定向站点生成重定向报文， 其中， 负载均衡设备将其所在站 点的信息和获取到的发送过重定向报文的站点的信息作为发送过重定向报文的站点的信 息添加到重定向报文中， 并将该重定向报文发送到客户端， 从而避免全局负载均衡中的重 复重定向。
下面将结合本发明中的附图， 对本发明中的技术方案进行清楚、 完整的描述， 显 然， 所描述的实施例是本发明的一部分实施例， 而不是全部的实施例。 基于本发明中的实施 例， 本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例， 都属 于本发明保护的范围。
如图 4 所示， 为本发明实施例中的全局负载均衡的 HTTP 重定向示意图， 包括客户 端、 服务器集群 I、 与服务器集群 I 连接的 LB 设备 I、 服务器集群 II、 与服务器集群 II 连接 的 LB 设备 II、 服务器集群 III， 以及与服务器集群 III 连接的 LB 设备 III。通常， 各个 LB 设备中维护有站点列表， 该站点列表中包含各站点的信息， 即可供选择作为重定向站点的 LB 设备的信息。LB 设备对接收到的 get 请求进行重定向时， 可以从该站点列表中选择重定 向站点。
在上述架构中， 客户端向 LB 设备 I 发送 get 请求， 该 get 请求中携带 LB 设备 I 的 IP 地址作为该 get 请求的目的地址， 即该 get 请求中的 URL 表示为 ： http://1.1.1.1。当 与 LB 设备 I 连接的服务器集群 I 中没有可用的服务器 ( 即 LB 设备 I 所在站点无法响应该 get 请求 ) 时， LB 设备 I 根据站点列表选择 LB 设备 II 作为重定向站点， 并根据 LB 设备 II 的信息生成重定向报文， 并将该重定向报文发送到客户端， 该重定向报文的 URL(Universal Resource Locator， 统一资源定位符 ) 信息中携带 LB 设备 II 的 IP 地址作为重定向站点地 址， 上述 URL 信息中还携带向客户端发送过重定向报文的站点的信息， 即 LB 设备 I 的标识 参数， 其中， LB 设备 I 的标识参数可设置在 URL 信息中， 如重定向报文的 URL 信息表示为 ： http://2.2.2.2 ？ SrvKey ＝ 01010101， 其中， http 为 URL 信息中的 scheme( 通信协议 ) 部分的内容， 表示该 URL 信息使用 HTTP 协议 ； 2.2.2.2 为 URL 信息中的 host( 主机 ) 部分 的内容， 表示重定向站点地址， 即 LB 设备 II 的地址 ； SrvKey ＝ 01010101 为 URL 信息中的 query( 查询 ) 部分的内容， 表示 LB 设备 I 向客户端发送过重定向报文 (01010101 是 LB 设 备 I 的标识参数 )。
客户端接收来自 LB 设备 I 的重定向报文， 获取该重定向报文中携带的 URL 信息， 生成包含该 URL 信息的 get 请求， 并向 LB 设备 II 发送该 get 请求， 该 get 请求中的 URL 信 息包括 LB 设备 II 的 IP 地址作为该 get 请求的目的地址， 该 URL 信息的 query 部分记录有 向客户端发送过重定向报文的站点的信息， 例如， LB 设备 I 的标识参数。在具体实现中， 根 据现有协议， 客户端可以直接将重定向报文的 URL 信息作为生成的 get 请求的 URL 信息， 即： http://2.2.2.2 ？ SrvKey ＝ 01010101， 其中， 2.2.2.2 是目标站点 ( 即 LB 设备 II) 的 地址， SrvKey ＝ 01010101 表示向客户端发送过重定向报文的站点的信息， 此处为 LB 设备 I 的标识参数。如果与 LB 设备 II 连接的服务器集群 II 中也没有可用的服务器， LB 设备 II 对接收到的 get 请求进行重定向处理， 该重定向处理流程如图 5 所示， 包括以下步骤 ：
步骤 501， LB 设备 II 解析来自客户端的 get 请求。
该步骤中， 客户端接收到 LB 设备 I 发送的重定向报文后， 通过解析该报文中的 URL 信息获知重定向站点为 LB 设备 II 所在站点， 并向 LB 设备 II 发送包含上述 URL 信息的 get请求， 该 URL 信息中携带在本次全局负载均衡过程中向该客户端发送过重定向报文的站点 的信息， 这里是 LB 设备 I 所在站点的信息。在本发明实施例中， 该 get 请求消息中的 URL 信息可表示为 ： http://2.2.2.2 ？ SrvKey ＝ 01010101。
步骤 502， LB 设备 II 根据解析结果判断该 get 请求中是否携带有向客户端发送过 重定向报文的站点的信息。如果判断结果为是， 则执行步骤 503 ； 否则， 执行步骤 504。
其中， 向客户端发送过重定向报文的站点的信息可以是标识参数。该标识参数可 以为 SrvKey 参数， 该参数与站点的 IP 地址相对应， 可以根据 IP 地址生成。例如， 本实施例 中， 发送过重定向报文的站点为 LB 设备 I， LB 设备 I 的 IP 地址为 1.1.1.1， 可以将该 IP 地 址的每段转换成两位的十进制数， 并将每段转换得到的十进制数进行合并， 相应的 SrvKey 参数可以为 “SrvKey ＝ 01010101” 。需要说明的是， 由于 IP 地址的每段所能表示的十进制 数最大不超过 255， 也可以将 IP 地址的每段转换成三位的十进制整数， 并将转换的结果进 行合并， 得到相应的 SrvKey 参数， 这样可以保证标识参数与 IP 地址的一一对应关系。
步骤 503， LB 设备 II 从站点列表中选择除该发送过重定向报文的站点以外的其他 站点作为本次重定向站点。
具体地， 在 get 请求中包含的发送过重定向报文的站点信息表示为站点标识参数 的情况下， 例如发送过重定向报文的站点的标识参数 “SrvKey ＝ 01010101” 时， LB 设备可 以通过解析该标识参数， 得到发送过重定向报文的站点的 IP 地址， 即 1.1.1.1。 由于站点列 表中包含可供选择作为重定向站点的 LB 设备的 IP 地址 (LB 设备的 IP 地址即为该设备所 在站点的 IP 地址 )， LB 设备 II 从该站点列表中选择不同于 1.1.1.1 的 IP 地址作为重定向 地址， 与重定向地址对应的 LB 设备即为重定向站点。LB 设备 II 可针对该客户端复制一份 站点列表副本， 并将发送过重定向报文的站点的 IP 地址从该站点列表副本中删除或标记 为不可用， 以避免选择发送过重定向报文的站点作为重定向站点。
需要说明的是， 在执行完步骤后， 继续执行步骤 505。
步骤 504， LB 设备 II 从站点列表中选择重定向站点。
具体地， 当 LB 设备 II 判断 get 请求中没有携带向客户端发送过重定向报文的站 点的信息时， LB 设备 II 从站点列表中选择重定向站点。
步骤 505， LB 设备 II 生成重定向报文， 并将重定向报文发送到客户端。
LB 设备 II 在生成重定向报文时， 将其自身所在站点的信息作为向客户端发送过 重定向报文的站点信息添加到该重定向报文中。具体地， 在 get 请求中携带的发送过重 定向报文的站点信息表示为站点标识参数的情况下， LB 设备 II 可以根据自身的 IP 地址 计算得到相应的标识参数， 并将该标识参数添加到从 get 请求中获得的 URL 信息的 query 部分中。本实施例中， LB 设备 II 的 IP 地址为 2.2.2.2 时， 相应的 SrvKey 参数可以为 “02020202” ， LB 设备 II 所接收到的 get 请求中的 URL 表示为 ： “http://2.2.2.2/ ？ SrvKey ＝ 01010101” ， 其中， 标识参数 “SrvKey ＝ 01010101” 表示向客户端发送过重定向报文的站 点， 此时， LB 设备 II 将其自身的标识参数 “02020202” 添加到该 URL 信息中， 得到添加了站 点信息的 URL 信息 ： http://2.2.2.2/ ？ SrvKey ＝ 0101010102020202， 即表示向客户端发 送过重定向报文的站点为 LB 设备 I 和 LB 设备 II 所在的站点。
当 LB 设备 II 从 get 请求中解析得到的用于表示向客户端发送过重定向报文的站 点的 URL 信息为 http://2.2.2.2/ 时， 表明目前还没有向客户端发送过重定向报文的站点，LB 设备 II 将其自身的标识参数添加到该 URL 信息的 query 部分后， 该 URL 信息可以表示为 http://2.2.2.2/ ？ SrvKey ＝ 02020202， 表明当前向客户端发送过重定向报文的站点为 LB 设备 II 所在的站点。
LB 设备 II 在生成重定向报文时， 根据添加了站点信息的 URL 信息生成重定向报 文的 URL 信息， 即保留该添加了站点信息的 URL 信息的 query 部分， 将该添加了站点信息的 URL 信息中的 host 部分替换为选择出的重定向站点的信息， 重定向站点的信息可以为重定 向站点的 IP 地址。
LB 设备 II 生成的重定向报文的 URL 信息可以表示为 Location( 位置 ) 信息的 形式， 该 Location 信息中携带重定向站点的 IP 地址， 以及向客户端发送过重定向报文的 站点的信息， 如采用 URL 方式表示的站点标识参数。例如， 当重定向站点为 LB 设备 III， LB 设备 III 的 IP 地址为 3.3.3.3， 向客户端发送过重定向报文的站点为 LB 设备 I 和 LB 设备 II 所在的站点时， LB 设备 II 生成的重定向报文中的 Location 信息为 ： “Location ： http://3.3.3.3/ ？ SrvKey ＝ 0101010102020202” 。
需要说明的是， 在本发明的其他实施方式中， 客户端向 LB 设备发送的 get 请求中， 也可以携带发送过重定向报文的站点的 IP 地址或站点标识等信息， 以代替发送过重定向 报文的站点的标识参数。LB 设备向客户端发送的重定向报文中， 也可以携带该发送过重定 向报文的站点的 IP 地址或站点标识等信息， 以代替发送过重定向报文的站点的标识参数。
在本发明的其他实施方式中， 向客户端发送过重定向报文的站点的信息还可以携 带在除 get 请求之外的其他 HTTP 请求中发送给 LB 设备， 例如， 携带在 post 请求中。
根据以上描述可以看出， 通过在重定向报文和 HTTP 请求中添加向客户端发送过 重定向报文的站点的信息， 从而协助后续站点选择重定向站点， 避免了全局负载均衡的重 定向过程中出现的不同服务器集群间的重复重定向， 提高了全局负载均衡业务的可用性和 可靠性。当然， 实施本发明的实施例的任一产品并不一定需要同时达到以上所述的所有优 点。
根据上述实施方式中提供的全局负载均衡中的重定向方法， 本发明实施例还提供 了应用上述重定向方法的装置。
如图 6 所示， 为本发明实施例中的负载均衡设备的结构示意图， 包括 ：
获取模块 610， 用于接收来自客户端的 HTTP 请求， 获取所述 HTTP 请求中携带的向 客户端发送过重定向报文的站点的信息。
其中， 站点的信息包括站点的 IP 地址、 站点标识和根据 IP 地址生成的用于唯一标 识该站点的标识参数中的至少一种。
选择模块 620， 用于从站点列表选择除发送过重定向报文的站点之外的站点， 作为 本次的重定向站点。
具体地， 选择模块 620 可以将发送过重定向报文的站点作为不可用站点， 并从排 除该不可用站点的站点列表中选择重定向站点。
生成模块 630， 用于根据选择模块 620 选择出的重定向站点的信息生成重定向报 文， 其中， 生成模块 630 将负载均衡设备所在站点的信息和获取到的发送过重定向报文的 站点的信息作为发送过重定向报文的站点的信息添加到重定向报文中。
具体地， 生成模块 630 可以从接收到的客户端的 HTTP 请求中获取 URL 信息， 并将负载均衡设备所在站点的信息添加到该 URL 信息中用于记录向客户端发送过重定向报文 的站点的信息的 query 部分 ； 根据该添加了站点信息的 URL 信息生成重定向报文的 URL 信 息。
发送模块 640， 用于将生成模块 630 生成的重定向报文发送到客户端。
此外， 当获取模块 610 接收到的 HTTP 请求中没有携带向客户端发送过重定向报文 的站点的信息时， 上述选择模块 620 还用于在从站点列表中选择本次的重定向站点 ； 相应 地， 上述生成模块 630， 还用于根据选择模块 620 选择出的重定向站点生成重定向报文， 其 中， 生成模块 630 将负载均衡设备所在站点的信息作为向客户端发送过重定向报文的站点 的信息添加到重定向报文中。
本发明的实施例包括以下优点， 通过在重定向报文和 HTTP 请求中添加向客户端 发送过重定向报文的站点的信息， 协助后续站点选择重定向站点， 避免了全局负载均衡的 重定向过程中出现的不同服务器集群间的重复重定向， 提高全局负载均衡业务的可用性和 可靠性。当然， 实施本发明的实施例的任一产品并不一定需要同时达到以上所述的所有优 点。
本领域技术人员可以理解实施例中的装置中的模块可以按照实施例描述进行分 布于实施例的装置中， 也可以进行相应变化位于不同于本实施例的一个或多个装置中。上 述实施例的模块可以合并为一个模块， 也可以进一步拆分成多个子模块。 通过以上的实施方式的描述， 本领域的技术人员可以清楚地了解到本发明可借助 软件加必需的通用硬件平台的方式来实现， 当然也可以通过硬件， 但很多情况下前者是更 佳的实施方式。基于这样的理解， 本发明的技术方案本质上或者说对现有技术做出贡献的 部分可以以软件产品的形式体现出来， 该计算机软件产品存储在一个存储介质中， 包括若 干指令用以使得一台终端设备 ( 可以是手机， 个人计算机， 服务器， 或者网络设备等 ) 执行 本发明各个实施例所述的方法。
以上所述仅是本发明的优选实施方式， 应当指出， 对于本技术领域的普通技术人 员来说， 在不脱离本发明原理的前提下， 还可以做出若干改进和润饰， 这些改进和润饰也应 视本发明的保护范围。