eBay流量管理之负载均衡及应用交付 (ebay流量怎么样)

1. HLB 基本介绍

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

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

如下图所示：

图 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）等。

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 支持十余种负载均衡算法，能够适应众多应用场景。常用的算法如：

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

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

2.4 应用交付之七层规则

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

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

一个 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.自动化管理方案

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

6. 小试牛刀

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

以为例，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 中的配置分别如下图所示。