分享 | eBay流量管理之负载均衡及应用交付

摘要：eBay FE Team通过在硬件负载均衡器上添加元素、应用负载均衡算法并绑定七层规则，智能地将应用中的请求和网络流量分发到不同的Machine和Pool，实现负载均衡和应用交付，完成流量管理。eBay FE Team应用多数据中心多层部署的硬件负载均衡器，基于负载均衡算法将流量转发到不同Machine，基于七层规则将流量转发到不同Pool，应用自动化工具实现了高可用的流量分发与管理，确保了用户业务应用能够快速、安全、可靠地交付。

供稿 | Yuting Cao

审稿 | Victor Yang

编辑 | Yang Liu

本文5159字，预计阅读时间13分钟

更多干货请关注“eBay技术荟”公众号

导读

eBay FE Team通过在硬件负载均衡器上添加元素、应用负载均衡算法并绑定七层规则，智能地将应用中的请求和网络流量分发到不同的Machine和Pool，实现负载均衡和应用交付，完成流量管理。希望能给同业人员相应的借鉴与启发。

1. HLB基本介绍

在网络安装中，硬件负载均衡器（HLB）一般安装在服务器前面，作为客户端和服务器之间的透明代理，在请求转发到服务器前进行流量管理。

一般而言，在基于TCP代理的负载均衡技术实现中，客户端与服务器的请求通信过程如下：

1）客户端向负载均衡器提供的虚拟IP地址VIP发送请求（CIP → VIP）；
2）负载均衡器从提前配置的多个子网IP地址中选择一个，替代客户端请求的源IP，并依据负载均衡算法，选择一个服务器IP作为目的IP，发送请求 (SNIP → SIP)；
3）服务器处理后将响应结果发回负载均衡器（SIP → SNIP）；
4）负载均衡器将最终结果返回给客户端（VIP → CIP）。

如下图所示：

图1.1 （点击可查看大

图

）

这样一来，HLB与客户端、服务器之间实际上是两个相互独立的TCP连接， 服务器并不知道真正的客户端IP ，但CIP可作为附加字段插入HTTP Header以告知服务器。

当然，除了TCP代理，负载均衡常用的实现机制还包括： DSR模式、Tunnel模式等。

2. 流量管理

在eBay有极其庞大数目的机器（Machine）提供各样的服务，而一组提供类似功能的机器可以简单理解为属于一个Pool，那么FE Team 如何借助负载均衡器将流量分发到不同的Machine和Pool呢？这里以常用的负载均衡器之一NetScaler为例介绍该过程。

2.1

NetScaler负载均衡器

NetScaler是Citrix公司提供的应用交付的硬件负载均衡器，其基本配置元素包括：虚拟服务器（Virtual Server）、服务（Service）、监控程序（Monitor）等。

虚拟服务器由名称、VIP、端口、协议等表示， 其端口和协议决定代表的具体服务器；
一般而言，虚拟服务器和服务协同工作，服务作为LB上的逻辑抽象，绑定到虚拟服务器上，可以是服务器的IP:Port，也可以是下一层LB的虚拟服务器；
LB对服务对象进行定时（比如每 5 秒）的健康探测，若探测失败，则将服务标记为DOWN，否则为UP。LB分发请求时，DOWN的服务将被排除在外， 流量只分发给UP的服务 。

2.2

负载均衡

那么， NetScaler如何将流量分发到不同机器上实现负载均衡流量管理呢？

举个例子，如下图所示，客户端Client1和Client2均能通过NetScaler上的虚拟服务器VS_HTTP和VS_SSL连接服务，服务S1、 S2、S3和S4绑定到虚拟服务器，分别表示安装在不同服务器上的应用程序。其中，VS_HTTP和VS_SSL具有相同的IP地址， 但端口和协议均不同； 服务S1和S2是服务器Server1和Server2上的HTTP应用程序，绑定到VS_HTTP，服务S3和S4是Server2和Server3上的SSL应用程序，绑定到VS_SSL。

图2.1 （点击可查看大图）

当NetScaler通过10.10.10.10:80收到HTTP请求时，根据VS_HTTP上虚拟服务器和服务的绑定情况、相应的负载均衡算法选择向Server1或Server2发送请求；同样，当通过10.10.10.10:443收到HTTPS请求时，根据VS_SSL上的配置绑定将请求发送给Server2或Server3。由此实现了流量的分配与转发。

2.3

负载均衡算法

NetScaler作为业内领先的硬件负载均衡器，具有极其强大的、多元化的负载均衡算法， 用于决定将客户端请求转发到哪一服务器 。最新版本的NetScaler支持十余种负载均衡算法，能够适应众多应用场景。常用的算法如：

最少连接算法（Least Connection），优先选择连接数最少的后端节点，是默认的负载均衡算法，在大多数情况下提供了最佳性能；
轮询算法（Round Robin），将用户请求依次轮流分配给内部服务器；
最少响应时间算法（Least Response Time），优先选择具有最少活跃连接和最低平均响应时间的服务器，可扩展为基于监控程序的最小响应时间算法（LRTM）；
最小带宽算法（Least Bandwidth），优先选择当前流量吞吐最小的服务器；

还有令牌算法（Token）、基于URL的Hash算法、域名Hash算法等，不作详述。

如果考虑不同服务器的处理能力不同，还可以给每个服务器分配不同权值，通过设置比率调整调度机率。

2.4

应用交付之七层规则

NetScaler是以软件为中心的应用程序交付解决方案，可以通过特定的负载均衡算法将应用中的流量分发到不同机器上，那 如果应用要求分发到指定Pool， 又该怎么做呢？

这就涉及到 七层规则 啦。NetScaler常用的七层规则包括：

Content Switching Policy ，将请求路由到指定的下游Pool；
Responder Policy ，针对特定的HTTP请求实现重定向（HTTP Redirect）、丢弃（TCP DROP）、重置（TCP RESET）等；
Rewrite Policy ，改写请求后转发给后端服务，“改写”包括：改写URL、添加/修改/删除Header。

一个VIP可以根据应用要求同时支持多种规则。

若用户要求将流量分发到指定Pool，则 添加Content Switching Policy ，将符合要求的请求路由到相应Pool，并绑定到VIP对应的虚拟服务器上。

3. 高可用性

了解了如何将流量分发到不同的Machine和Pool后，eBay FE Team又是如何 部署硬件负载均衡器确保其高可用性 呢？

一般而言，FE Team为每个负载均衡器同时部署两台设备。

图3.1 （点击可查看大图）

其中，主设备（Primary Node）主动连接并管理服务器，辅助设备（Secondary Node）与主设备配置始终保持同步，若主设备发生故障，则辅助设备成为主设备。主设备和辅助设备相互定时发送检测信号和运行状况检查请求，从而监控彼此，以提供高可用性。

当然为了不同场景的需要，我们还提供了BGP等方式，这里不作详述。

4. 多数据中心多层部署

鉴于eBay拥有多个数据中心，数万Pool及上百万服务单元（VM/BM/Pod等），需要 同时部署多层负载均衡器 以确保流量的正确转发，每个Pool在不同数据中心的各层负载均衡器上都有配置。

如下图所示，假设有3个数据中心， 最上层GSLB/GTM 作为DNS Resolver实现DNS解析，返回给用户不同数据中心最合适的IP列表；GSLB/GTM下面 绑定两层硬件负载均衡器 ，一层主要用于配置七层规则和SSL，另一层主要用于负载均衡的流量转发。每一层中均有不同类型的硬件负载均衡器，包括常用的NetScaler和F5。

图4.1 （点击可查看大图）

一般而言，将来自相同数据中心的客户端访问的大部分流量（如： 99% ）分发到本数据中心，少部分流量（如： 1% ）转到其他数据中心，实现跨数据中心访问。若一个数据中心出现问题，流量会自动转发到其他数据中心。

5.自动化管理方案

5. 自动化管理方案

流量管理是一个复杂的过程，FE Team结合多年实战经验，基于Python Django框架，利用eBay内部的LBMS等接口，开发出LB的控制面（Control Plane）工具： EasyLB ，实现了流量管理的自动化。其功能包括：七层规则的快速准确部署，配置的标准化管理，VIP的无缝迁移，多方位的性能监控等，为ATB（Availability to Business）提供了坚实保障。自动化方案不仅降低了人为失误，同时也提升了应用的交付效率。

6. 小试牛刀

介绍到这里，小伙伴们可能会想：“这些系统都不便宜，咱也不知道，咱也不敢问呀”。其实作为普通用户，我们完全有办法 零成本使用负载均衡器 。

以 NetScaler 为例，Citrix公司提供了一个容器化的应用交付控制器NetScaler CPX，方便用户体验。我们应用NetScaler CPX做了 2个小实验，深入理解负载均衡流量管理和七层规则，有兴趣的小伙伴可以试试。

选择两台CentOS主机S1和S2，假设IP分别为10.148.177.194和10.148.177.197，在S1上安装Docker并设置NetScaler CPX实例，搭建负载均衡拓扑。

6.1

安装Docker

首先安装Docker。

图6.1 （点击可查看大图）

6.2

启动NetScaler CPX和主机端口

获取NetScaler CPX 镜像并在后台以 特权模式 运行容器，指定NetScaler最终用户许可协议EULA，暴露SSH 22和HTTP 80端口，并将30000端口映射出来用于实验，设置ulimit参数core=-1不限制core文件大小，输入密码后进入容器伪终端。

图6.2 （点击可查看大图）

使用如下脚本，分别启动S1和S2的80端口，设置GET请求返回主机名Server及IP。

图6.3 （点击可查看大图）

6.3

搭建负载均衡拓扑

实验1：负载均衡流量管理

假设S1和S2属于 相同Pool，均安装有应用程序A， 分别表示为服务svc-A-S1和svc-A-S2，并绑定到虚拟服务器VIP-A。CPX对外暴露30000端口用于访问应用程序A，负载均衡拓扑、CLI命令及CPX中的配置分别如下图所示。

图6.4 （点击可查看大图）

图6.5 （点击可查看大图）

图6.6 （点击可查看大图）

则在S1执行for i in {1..100}; do curl -v 127.0.0.1:30000 2>/dev/null | grep Server; done访问服务A，流量会 交替分发 到S1和S2上，如下图所示，即： 将流量转发到不同的机器，实现了负载均衡的流量管理。

图6.7 （点击可查看大图）

实验2：七层规则

假设S1和S2属于 不同Pool ，S1安装应用程序A1，S2安装应用程序A2，分别表示为绑定到LBV-A1的服务svc-A1和绑定到LBV-A2的服务svc-A2，CPX对外暴露30000端口，默认情况下访问S1上的应用程序A1。添加Content Switching Policy，当请求token为/check时，将请求路由到S2上的A2，负载均衡拓扑、CLI命令及CPX中的配置分别如下图所示。