负载平衡101： 螺母和螺栓

在当今充满活力的、以应用为中心的市场中，企业面临着越来越大的压力，需要快速、可靠、安全地提供客户期望的信息、服务和体验。 关键网络和应用功能（例如负载平衡、加密、加速和安全）可以通过应用交付控制器 (ADC) 提供，ADC 是作为物理服务器代理的物理或虚拟设备。 随着应用s的爆炸式增长，以及持续集成和持续部署（CI/CD）的严格周期对组织的要求不断提高，到 2020 年，ADC 市场规模预计将达到每年 29 亿美元，这也就不足为奇了。¹

但在走向未来之前，让我们先看看我们是如何到达这里的。 基于网络的负载平衡是 ADC 运行的重要基础。 20 世纪 90 年代中期，第一批负载平衡硬件设备开始通过在服务器和网络之间分配工作负载来帮助组织扩展其应用s。 这些首批设备与应用程序无关，并且位于应用服务器之外，这意味着它们可以使用简单的网络技术进行负载平衡。 本质上，这些设备会向外界呈现一个“虚拟 IP 地址”，当用户尝试连接时，它们会将连接转发到最合适的真实服务器进行双向网络地址转换（NAT）。

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

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

当今的 ADC 是通过服务虚拟化过程从第一个负载均衡器发展而来的。 现在，借助纯软件虚拟版本，ADC 不仅可以提高可用性，还可以帮助组织提供其业务所需的可扩展、高性能和安全的应用s。 但最终，如果没有负载平衡技术的坚实基础，所有这些虚拟化应用服务、共享基础设施部署和智能路由功能都不可能实现。

为了了解企业如何更好地应对动态发展的市场所带来的复杂挑战，让我们探索应用交付的基础： 负载平衡 101。

在开始之前，让我们先回顾一下负载平衡的基本术语。 如果每个人都使用相同的词汇，这会更容易；不幸的是，每个负载平衡设备（以及 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地址。 在本文的其余部分，我们将其称为服务。

为何如此复杂？ 因为服务器和在其上运行的应用服务之间的区别使得负载均衡器可以单独与数据中心或云中的应用s而不是底层硬件或虚拟机管理程序交互。 主机（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 事务中，服务器可以指定“保持活动”连接，将多个短暂连接转变为单个长寿命连接，可以像其他长寿命连接一样进行处理。 然而，这只能带来一点点缓解，主要是因为随着网络和移动服务的使用增加，保持所有连接打开的时间比必要的时间长会给整个系统的资源带来压力。 这就是为什么今天——为了可扩展性和可移植性——许多组织都转向构建依赖于 API 的无状态applications。 这基本上意味着服务器将忘记所有会话信息以减少资源负载，在这些情况下，通过传递会话 ID 以及持久性概念来维护状态。

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

如今，ADC 的智能使组织能够打开数据包并为其中的几乎任何内容创建持久表。 这使得他们能够使用唯一信息（例如用户名）来保持持久性。 然而，组织必须确保这些可识别的客户端信息会出现在每个请求中，因为任何没有该信息的数据包都不会被保留下来，而且会再次进行负载平衡，这很可能会破坏应用。

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

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

如果您想了解更多有关高级应用交付的工作原理和 ADC 的未来的信息，请阅读《应用交付控制器的演变》和《超越普通的旧式负载平衡》 。