负载均衡
通过在流量增加时使新的 VM 联机来进行横向扩展是通过缩放满足需求的有效策略。 可快速预配 VM 这一事实对于实现弹性而言至关重要。 但是，除非流量在这些服务器之间分发，否则使其他服务器联机没有用。 总体而言，这有助于系统处理增加的负载。 这就是为何负载均衡对于弹性如此重要，因为它可以动态调整专用于任务的资源数量。
对负载均衡的需求源于两个基本要求。 首先，吞吐量通过并行处理提高。 如果一台服务器可在单位时间内处理 5,000 个请求，那么 10 台完全负载均衡的服务器可在单位时间内处理 50,000 个请求。 其次，负载均衡的资源可提供更高的可用性。 负载均衡器可将请求定向到负载较轻的服务器，而不是将请求转发到已经难以跟上需求的服务器。 此外，如果服务器离线且负载均衡器识别出该服务器，则负载均衡器可将请求定向到其他服务器。
什么是负载均衡？
负载均衡的一种已知形式是轮询机制 DNS，许多大型 Web 服务使用它在若干台服务器之间分发请求。 具体而言，多个前端服务器（每个都具有唯一 IP 地址）共享一个 DNS 名称。 为了平衡每个 Web 服务器上的请求数量，Google 等大型公司为每个 DNS 条目维护和管理一个 IP 地址池。 当客户端发出请求（例如，向 www.google.com 发出请求）时，Google 的 DNS 从池中选择一个可用地址，然后将其发送到客户端。 用于调度 IP 地址的最简单策略是使用循环机制队列，在每次 DNS 响应后，系统会重新排列地址列表。
在云出现之前，DNS 负载均衡是减少长距离连接延迟的简单方法。 DNS 服务器上的调度程序已编程为使用地理位置最接近客户端的服务器 IP 地址进行响应。 最简单的方法是使用位于池中且在数字上最接近客户端 IP 地址的 IP 地址进行响应。 此方法不可靠，因为 IP 地址未在全局层次结构中分布。 当前技术更加复杂，并依赖于基于 Internet 服务提供商 (ISP) 的物理映射的 IP 地址到位置的软件映射。 由于此映射以昂贵的软件查找形式实现，此方法可提供更好的结果，但计算成本很高。 然而，由于 DNS 查找仅在客户端首次建立与服务器的连接时发生，查找速度缓慢导致的成本可被分摊。 所有后续通信直接在客户端和拥有已调度 IP 地址的服务器之间发生。 DNS 负载均衡方案的示例如图 9 所示。
图 9：云环境中的负载均衡。
此方法的缺点在于，服务器发生故障时，切换到其他 IP 地址取决于 DNS 缓存的生存时间 (TTL) 配置。 已知 DNS 条目长期有效，且更新需要一周以上时间传播。 这意味着很难向客户端快速“隐藏”服务器故障。 降低缓存中 IP 地址的有效性 (TTL) 可改善这一状况，但会牺牲性能并增加查找次数。
新式负载均衡通常指使用专用实例（或一对实例）将传入请求调度到后端服务器。 对于指定端口上的每个传入请求，负载均衡器会根据分发策略将流量重定向到其中一个后端服务器。 这样一来，负载均衡器可维护请求元数据，其中包括应用程序协议标头（例如，HTTP 标头）等信息。 在这种情况下，由于每个请求都通过负载均衡器，无需担心信息过时的问题。
尽管所有类型的网络负载均衡器都会将请求以及任何上下文转发到后端服务器，但在将响应返回到客户端时，它们可能会采用两种基本策略之一1：
代理：在此方法中，负载均衡器从后端接收响应并将响应中继返回客户端。 负载均衡器充当标准 Web 代理并参与两端的网络事务，即将请求转发到客户端并发回响应。
TCP 切换：在此方法中，与客户端的 TCP 连接切换到后端服务器，且服务器直接将响应发送到客户端，而不会通过负载均衡器。
后一种策略如图 10 所示。
图 10：从调度程序到后端服务器的 TCP 切换机制。
负载均衡的优势
负载均衡的优势之一是，它有助于掩盖系统中的故障。 只要客户端接触的是代表多个资源的单个终结点，就可以使用其他资源为请求提供服务，向客户端隐藏单个资源中的故障。 但现在，负载均衡器本身成为单一故障点。 如果其出于任何原因出现故障，则即使所有后端服务器仍在运行，也不会处理任何客户端请求。 因此，为了实现高可用性，负载均衡器通常成对实现。
更重要的是，负载均衡可通过在云中的多个计算资源之间分发工作负载来提高响应度。 在云中提供单个计算实例存在诸多限制。 之前的模块讨论了对性能的物理限制，这种情况需要提供更多资源来应对增加的工作负载。 通过使用负载均衡，较大的工作负载可跨多个资源分发，因此，每个资源可以独立且并行地满足其请求，从而提高应用程序的吞吐量。 负载均衡还可改善平均响应时间，因为有更多的服务器可用于处理工作负载。
运行状况检查是实现成功负载均衡策略的关键。 负载均衡器需要知道资源何时会变得不可用，以免将流量转发到该资源。 Ping-echo 监视指负载均衡器使用 Internet 控制消息协议 (ICMP) 请求“ping”服务器，这是用于检查特定资源运行状况的最常用策略之一。 除了在将流量转发到资源时考虑资源的运行状况外，一些负载均衡策略还会考虑其他指标，例如吞吐量、延迟和 CPU 利用率。
负载均衡器通常必须保证高可用性。 最简单的方法是创建多个负载均衡实例（每个具有唯一 IP 地址）并将其链接到单个 DNS 地址。 每当负载均衡器因任何原因发生故障时，都会使用新的负载均衡器对其进行替换，且所有流量都会传递到故障转移实例，并最大限度地降低对性能的影响。 同时，可以配置一个新的负载均衡器实例来替换发生故障的实例，且必须立即更新 DNS 记录。
除在后端服务器之间分发请求外，负载均衡器还经常使用相关机制来减少服务器上的负载并提高总体吞吐量。 其中一些机制包括：
SSL 卸载：HTTPS 连接会导致性能成本增加，因为通过这些连接的流量会加密。 可通过安全套接字层 (SSL) 建立客户端与负载均衡器的连接，并通过未加密的 HTTP 将请求重定向到每台服务器，而不是通过 SSL 满足所有请求。 此技术可大幅减少服务器上的负载。 此外，只要不通过开放网络发出重定向请求，就可以维护安全性。
TCP 缓冲：一种策略，通过与负载均衡器的缓慢连接减轻客户端负载，从而减轻为这些客户端提供响应的服务器的负担。
缓存：在特定方案中，负载均衡器可为最常用请求（或无需前往服务器即可处理的请求，例如静态内容）维护缓存，以减少服务器上的负载。
流量控制：负载均衡器可使用此技术延迟数据包流或重新设置数据包流的优先级，以优化服务器配置的流量。 这确实会影响某些请求的 QoS，但可确保能够处理传入负载。
请务必记住，负载均衡仅在负载均衡器本身没有无法承受的负载时才有效。 否则，负载均衡器会成为瓶颈。 幸运的是，负载均衡器往往不会对收到的请求进行处理，而是依靠后端服务器来完成将请求转换为响应的实际工作。
公平调度
云中使用多种负载均衡策略。 最常见的一种是公平调度，该策略使用简单的轮询机制算法在所有节点之间平均分发流量。 它既不考虑系统中单个资源的利用率，也不考虑请求执行时间。 此方法尝试使系统中的每个节点保持忙碌，并且是最容易实现的方法之一。
AWS 在其 Elastic Load Balancer (ELB) 产品/服务中使用此方法。 ELB 预配负载均衡器，用于平衡连接的 EC2 实例之间的流量。 负载均衡器本质上是 EC2 实例本身加用于专门路由流量的服务。 随着负载均衡器背后的资源横向扩展，新资源的 IP 地址将在负载均衡器的 DNS 记录上更新。 此过程需要几分钟时间才能完成，因为它既需要监视时间又需要预配时间。 此缩放期（在负载均衡器准备好处理更高负载之前的等待时间）称为“预热”负载均衡器。
AWS 负载均衡器还会监视与其连接的资源，以便工作负载分发维护运行状况检查。 Ping-echo 机制用于确保所有资源均正常运行。 ELB 用户可以通过指定延迟和重试次数来配置运行状况检查的参数。
基于哈希的分发
此方法尝试确保来自同一客户端的请求在每次会话期间都定向到同一服务器，方法是对定义每个请求的元数据进行哈希处理并使用哈希来选取服务器。 如果正确完成哈希处理，则请求将在服务器之间相对平均地分发。 此方法的一个优势在于，其本身适用于会话感知型应用程序，此类应用程序可将会话数据存储在内存中，而不是将其写入共享数据存储（例如数据库或 Redis 缓存）。 不足之处在于必须对每个请求进行哈希处理，这会导致少量延迟。
Azure 负载均衡器使用基于哈希的机制分发负载。 此机制基于源 IP、源端口、目标 IP、目标端口和协议类型为每个请求创建哈希，以确保在一般情况下，来自同一会话的每个数据包都命中同一后端服务器。 选择哈希函数，使到服务器的连接分发是随机的。
其他负载均衡策略
如果特定服务器因处理一个请求（或一组请求）而停顿，使用轮询机制或基于哈希的调度算法的负载均衡器仍将向其转发请求。 还有其他更复杂的策略可用于在考虑容量的情况下平衡多个资源之间的负载。 衡量容量的两个最常用指标是：
请求执行时间：基于此指标的策略使用优先级调度算法，因此，请求执行时间用于为各个请求选择目标。 使用此方法的主要挑战在于准确衡量执行时间。 负载均衡器可通过使用（并持续更新）内存中表来猜测执行时间，该表存储将请求转发到每台服务器的时间与其返回时间之差。
资源利用率：基于此指标的策略使用 CPU 利用率来平衡节点之间的利用率。 负载均衡器基于资源的利用率维护资源的排序列表，并将接收的每个请求定向到负载最小的资源。
负载均衡对于实现可缩放的云服务而言至关重要。 如果没有在后端资源之间分发流量的有效方法，则会严重限制通过在需要时创建资源并在不需要时取消预配资源所获得的弹性。
参考
- Aron, Mohit and Sanders, Darren and Druschel, Peter and Zwaenepoel, Willy (2000). "Scalable content-aware request distribution in cluster-based network servers." Proceedings of the 2000 Annual USENIX technical Conference.