负载均衡 101：具体细节

在当今以应用为中心的动态化市场中，企业面临着越来越大的压力，不仅需要提供客户所期望的信息、服务和体验，而且要做到快速、可靠和安全。关键的网络和应用功能，如负载均衡、加密、加速和安全，可以通过应用交付控制器 (ADC) 提供。ADC 是一种物理或虚拟设备，可以作为物理服务器的代理。随着应用的爆炸式增长，以及持续集成和持续部署 (CI/CD) 的严格周期对组织提出的要求，也难怪有预测称，ADC 的市值到 2020 年将达到每年 29 亿美元。¹

在展望未来之前，不妨先回顾来程。基于网络的负载均衡是 ADC 运行的重要基础。在 20 世纪 90 年代中期，第一批负载均衡硬件设备开始帮助企业通过在服务器和网络之间分配工作负载来扩展其应用。该首批设备符合应用中立性原则，并且独立于应用服务器之外，这意味着它们可以使用简单的网络技术实现负载均衡。从本质上讲，这些设备会向外界展示一个“虚拟 IP 地址”，当用户试图连接时，它们会将连接转发到最合适的真实服务器，进行双向网络地址转换 (NAT)。

然而，随着虚拟化和云计算的出现，负载均衡 ADC 迎来了新迭代，作为软件交付的虚拟版本，用于在管理程序上运行。如今，虚拟设备可以提供与在专用硬件上运行的应用服务具有相同广度的功能。此外，这些虚拟版本大幅消除了在虚拟、云和混合环境之间移动应用服务所涉及的复杂性，使企业能够快速、轻松地在私有或公共云环境中启动应用服务。

容器化是冲击数据中心的最新趋势，它是一种应用虚拟化的方法，有助于部署和运行分布式应用。该过程将应用隔离开来，并将其包含在共享操作系统上明确划分的内存空间中，这使得开发和部署应用相较于构建虚拟设备不仅操作起来更容易，而且速度也更快。由于可移植性和性能的大幅提升，容器化可以为企业提供更高的可扩展性和灵活性。未来，容器架构还可以帮助企业更好地利用不同的云环境。

今天的 ADC 从最初的负载均衡器发展进入了服务虚拟化的过程。而现在，通过纯软件的虚拟版本，ADC 不仅可以提高可用性，还可以帮助企业交付业务所需的可扩展、高性能且安全的应用。不过归根结底，如果没有负载均衡技术的坚实基础，所有这些虚拟化应用服务、共享基础设施部署和智能路由功能都将是纸上谈兵。

要想了解企业如何更好地应对动态发展的市场中的复杂挑战，就要来探讨一下应用交付的基础：负载均衡 101。

在开始之前，让我们先复习一下负载均衡的基本术语。如果每个人使用的都是同一套词汇，这个环节将会容易得多；但遗憾的是，每一家负载均衡设备（进一步来讲，即 ADC）的供应商似乎都在使用不同的术语。好在只要稍加解释，我们就可以快刀斩乱麻，消除乱象。

大多数负载均衡 ADC 所涉及的概念不外乎节点、主机、成员或服务器，有些 ADC 会四者均沾，含义却各不相同。总的来说，所有这些术语想要表达的就是两个基本概念。其一，通常被称为节点或服务器，指的是将从 ADC 接收流量的物理或虚拟服务器的概念。它相当于物理服务器 IP 地址的同义词，在没有负载均衡器的情况下即指服务器名称（例如，www.example.com）所要解析到的 IP 地址。在下文中，我们将以主机来指代这个概念。

第二个概念是用“成员”（然而有时也被一些厂商称为节点）一词来表示。成员通常比主机的定义更明确一些，因为它包括将要接收流量的实际应用的 TCP 端口。例如，一台名为 www.example.com 的主机，其解析地址可能为 172.16.1.10，该地址就代表主机，而该主机还可能有一个应用（Web 服务器）在 TCP 端口 80 上运行，因此成员地址便是 172.16.1.10:80。简单来说，成员包括应用端口的定义以及物理/虚拟服务器的 IP 地址。在下文中，我们称之为服务。

为什么会如此复杂？因为区分服务器和在其上运行的应用服务，可以让负载均衡器单独与应用进行交互，而不是在数据中心或云端与底层硬件或管理程序进行交互。一台主机 (172.16.1.10) 可能有一个以上的服务可用（HTTP、FTP、DNS 等）。通过唯一地定义每个应用（例如 172.16.1.10:80、172.16.1.10:21 和 172.16.1.10:53），ADC 可以基于服务而不是主机，应用独特的负载均衡和健康监控（我们将在后面讨论这个概念）。

总之，大多数基于负载均衡的技术都会用一个术语代表主机或物理服务器，然后用另一个术语代表可在该主机或物理服务器上使用的服务。在本例中，我们所用的就是主机和服务。

负载均衡允许企业在多个后端目的地之间分配入站应用流量，包括在公有或私有云中的部署。因此也就有必要给出后端目的地集合的概念。集群（也被称为池或农场）在这里指代的是在任何数量的主机上可用的类似服务的集合。例如，所有提供公司网页的服务都会被收集到一个名为“公司网页”的集群中，而所有提供电子商务服务的服务都会被收集到一个名为“电子商务”的集群中。

虚拟服务器是实际服务器（物理、虚拟或容器）的代理，与虚拟 IP 地址结合，即为呈现给外界的应用端点。

了解完这些名词后，我们便已掌握了负载均衡的基本知识。负载均衡 ADC 向外界展示的是虚拟服务器，每个虚拟服务器都指向一个驻留在一个或多个物理主机上的服务集群。

虽然图 2 可能无法代表所有真实世界的部署，但它确实为继续讨论负载均衡和应用交付的过程提供了基本结构。

在建立了这个通用词汇之后，让我们来研究一下如何将应用交付给客户的简单事务。如图所示，负载均衡 ADC 通常位于客户端和为客户端提供所需服务的主机之间。与应用交付中的大多数事情一样，这种定位也并非一种规则，更多的还是所有部署类型中的一种最佳实践。我们仍假设已经为 ADC 配置了一个虚拟服务器，并且该服务器指向一个由两个服务点组成的集群。在这一部署场景中，主机通常会有一条指向负载均衡器的回传路由，这样回传流量在返回客户端的途中就会通过它进行处理。

基本的应用交付事务如下：

• 客户端尝试与服务连接。
• ADC 接受连接，并在决定应由哪台主机接收连接后改变目标 IP（可能还有端口），以匹配所选主机的服务（注意：客户端的源 IP 不受影响）。
• 主机接受连接，并通过其默认路由 ADC 响应原始来源，即客户端。
• ADC 拦截来自主机的返回包并当即改变源 IP（和可能的端口），以匹配虚拟服务器 IP 和端口，并将数据包转发回客户端。
• 客户端接收返回包，认为它来自虚拟服务器，并继续处理。

这个非常简单的例子相对容易理解一些，但有几个关键要素需要注意。首先，客户端所知道的是，它要向虚拟服务器发送数据包，然后虚拟服务器会做出响应，这一点很简单；第二，执行 NAT。此时 ADC 会将客户端（或虚拟服务器）发送的目标 IP 替换为所选主机的目标 IP，以实现对请求的负载均衡。第三，便是这个过程中完成“双向”NAT 的环节。从主机返回的数据包的源 IP 将是主机的 IP，如果不改变这个地址，只是简单地将数据包转发给客户端，那么客户端会认为接收的数据包并非来自请求对象，因此便会直接将其丢弃。但是，负载均衡器会记住该连接并重写数据包，这样源 IP 便是虚拟服务器的 IP，从而解决了该问题。

通常这时会出现两个问题：负载均衡 ADC 如何决定将连接发送到哪个主机？以及如果选定的主机不工作会怎样？

我们先讨论第二个问题。如果选定的主机不工作会怎样？简单的答案是，它会不响应客户端的请求，导致连接尝试最终超时失败。这种状况显然不可取，因为它不能确保高可用性。这就是为什么大多数负载均衡技术都包括一定级别的健康监控，以确定主机是否真正可用，然后再尝试向其发送连接。

健康监控设有多个级别，每个级别的健康监控的粒度和重点都在不断提升。基本监控器只是简单地对主机本身进行 ping。如果主机对 ping 没有响应，那么就可以推定主机上定义的任何服务都可能已经宕机，应该将其从可用服务集群中删除。然而问题在于，即使主机响应 ping，也不一定意味着服务本身工作正常。因此，大多数设备都可以进行某种形式的“服务 ping”，从简单的 TCP 连接一直到通过脚本或智能交互与应用进行交互。这些更高级别的健康监控器不仅可以为实际服务（相对于主机而言）的可用性提供更多的可靠性，而且还可以让负载平衡器区分单个主机上的多个服务。负载均衡器可以判断出，虽然一个服务可能不可用，但同一主机上的其他服务可能工作正常，因此仍应该将其视为用户流量的有效目的地。

这就回到了第一个问题。ADC 如何决定向哪个主机发送连接请求？每台虚拟服务器都有一个特定的专用服务集群（列出提供该服务的主机），构成可用性列表。此外，健康监控会修改该列表，使其成为提供指定服务的“当前可用”主机的列表。ADC 正是从这个修改后的列表中选择将接收新连接的主机。主机的精准选择取决于与该特定集群相关联的负载均衡算法。其中一些算法包括最小连接数、动态比率和简单轮询。轮询时，负载均衡器只需从列表顶部开始向下，将每个新连接分配给下一个主机；当到达列表底部时，只需从顶部重新开始即可。虽然该过程简单，可预测性也很好，但有时它会推定所有连接在后端主机上的负载和持续时间都是相似的，而事实却并非总是如此。更先进的算法会使用诸如当前连接数、主机利用率，甚至是主机现有流量的真实响应时间，以便从可用的集群服务中挑选出最合适的主机。

足够先进的应用交付系统还能够将健康监控信息与负载均衡算法进行结合，从而拥有对服务依赖性的解读能力。当一个主机有多个服务，并且这些服务对于完成用户请求而言缺一不可时，该功能的作用将尤其明显。在这种情况下，您并不想看到用户访问的主机上一个服务可用，而其他服务却停止运行。换句话说，如果主机上的一个服务发生故障，您所希望的是主机能够从集群的可用服务列表中提供另一个服务。随着服务与 HTML 和脚本的差异化越来越大，这个功能将变得越来越重要。

负载均衡涉及在客户端发起事务请求时挑选可用服务，但这部分工作在解决方案中只占半壁江山而已。一旦建立了连接，ADC 必须持续跟踪判断该用户的后续流量是否应该进行负载均衡。一般来说，实施负载均衡后，在处理后续流量时就需要面对两个具体问题：连接维护和持久性。

如果用户试图利用一个不会立即关闭的 TCP 长连接（端口 21：FTP、端口 23：Telnet 或其他），则负载均衡器必须确保通过该连接传输的多个数据包不会在经过负载均衡后被发送至其他可用的服务主机上。这就是连接维护，它涉及两大关键能力：其一是持续跟踪开放连接及其所属的主机服务的能力；其二是负载均衡器必须能够持续监控该连接，以便在连接关闭时更新连接表。这对于大多数 ADC 来说称得上一个标准套餐。

然而越来越常见的情况是，客户端会使用多个 TCP 短连接（例如，端口 80：HTTP）来完成单个任务。在某些情况下，比如标准的 Web 浏览，持久性或许可有可无，因为每个新请求都可以进入任意一个后端服务主机；但是在很多情况下（XML、电子商务等），来自同一用户的多个连接都要进入同一个后端服务主机会变得极其重要，而此时无需负载均衡。这个概念就叫做持久性，或者说服务器亲和力。

根据协议和所需的结果，有多种方法可以解决这个问题。例如，在现代 HTTP 事务中，服务器可以指定一个“持续”连接，将多个短连接变成一个单一长连接，处理时与其他长连接一样。然而这种做法治标不治本，主要原因在于，随着 Web 和移动服务的使用量增加，让所有连接保持开放超过必要时间会使整个系统的资源紧张。这就是为什么如今为了可扩展性和可移植性，许多组织正在转向构建依赖 API 的无状态应用。这基本上意味着服务器将抹去所有会话信息，以减少资源负载，在这些情况下，状态会通过传递会话 ID 以及通过持久性的概念来维护。

最基本的持久性形式之一是源地址亲和力，它包括简单地记录传入请求的源 IP 地址和经过负载均衡后接收请求的服务主机，以及将所有未来事务都转到同一个主机。实现这一目的方法有两种：使用 SSL 会话 ID 和 cookie。SSL 持久性使用 SSL 会话 ID 跟踪 SSL 会话，这意味着即使客户端的 IP 地址发生变化，负载均衡器也会根据会话 ID 识别出持久性会话。基于 cookie 的持久性提供了另一个选项，即在客户端的计算机上插入一个 cookie 来唯一识别会话，然后在请求中引用该 cookie，这样连接就会进入正确的服务器。

今天，ADC 智能化允许企业打开数据包，并且几乎可以为数据包中的任何内容创建持久性表，使其能够通过用户名等独特信息来维持持久性。然而企业必须确保这种可识别的客户端信息存在于每一个发出的请求中，因为任何缺少该信息的数据包都无法保持持久性，并将再次经过负载均衡，这很有可能导致应用被破坏。

最初，负载均衡的重点是在整个网络中分配工作负载，并确保应用和服务的可用性。然而随着技术的发展，负载均衡器演变为应用交付平台，用于确保组织的关键应用高度可用且安全。虽然基本的负载均衡仍然是应用交付的基础，但现代 ADC 提供了更多强化功能。

企业意识到，只是能够获得一个应用并不意味着它可用，而部署无法使用的应用对企业而言则意味着浪费时间和金钱。这就是现代 ADC 的用武之地，它允许企业将基于网络的服务（如 SSL/TLS 卸载、缓存、压缩、速率整形、入侵检测、应用防火墙，甚至远程访问）整合到一个单一的战略点中，该点可以在所有应用服务和所有主机上共享和重用，从而创建一个虚拟化的 Application Delivery Network。这使得网络、应用和运营团队能够更好地响应业务需求、缩短交付时间和提高可扩展性，同时完全不会牺牲安全需求。

如果您想了解更多关于高级应用交付的工作原理和 ADC 的未来发展方向，欢迎阅读《应用交付控制器的演进》和《超越简单旧式负载均衡》。