如果你是早期的云计算服务提供商，你可以使用一个单独的客户web服务器，为它分配一个IP地址，并配置一个DNS（域名系统）记录来将它与一个易读的名字关联起来，之后通过BGP（边界网关协议）来传播IP地址，这是种在网络间交换路由信息的标准方式。

在冗余的网络路径上分发流量，在不可用的基础设施周围进行路由来提高可用性（会导致不对称路由等现象），这些从本质上讲并不是负载均衡。

简单的DNS负载均衡

随着客户服务流量的增长，业务方希望获得更高的可用性。你添加了另一个具有公网IP地址的web服务器，并更新了DNS记录来将用户引导到这两个web服务器（希望稍微公平一些）。直到某一个web服务器意外宕机前，这种方法都是可行的。假设你快速检测到故障，可以通过更新DNS配置（手动方式或使用软件）来停止引用损坏的服务器。

遗憾的是，由于DNS记录是有缓存的，这些缓存记录可能会在客户端或者DNS层次结构中的其他名称服务器中，在它们过期之前，大约有50%的请求仍然可能失败。DNS记录的TTL（time to live，生存时间）通常为几分钟或更长，因此这会对系统的可用性造成重大影响。

更糟糕的是一些客户端完全忽略了TTL，所以一些请求将在一段时间内被定向到已经宕机的web服务器上。设置非常短的DNS TTL也不是什么好主意；这意味着DNS服务的负载增加，延迟增加，因为客户端不得不更加频繁地执行DNS查找。如果你的DNS服务不可用，那么使用更短的TTL访问服务将更快地降级，因为缓存服务IP地址的客户端更少。

增加网络负载均衡

为了解决这个问题，你可以添加一对冗余的4层（Layer 4）网络均衡器，并在相同的虚拟IP（VIP）地址提供服务。它们可以是硬件设备，或者像HAProxy这样的软件均衡器。这意味着DNS记录仅仅指向虚拟IP而不再做负载均衡。

4层均衡器将来自因特网的流量均衡地引导至后端服务器。这通常是基于每个IP包的5元组的哈希（一个数学函数）完成的：源IP地址和目标IP地址，以及端口加上协议（如TCP或UDP）。这种方式快速、高效（并且仍然维持了TCP的基本属性），并且不需要均衡器维护每个连接的状态。(更多信息可以参考谷歌关于Maglev的论文，它详细讨论了4层均衡器软件的实现。)

4层均衡器可以进行健康检查，并仅仅向那些通过检查的web服务器发送流量。与DNS均衡不同的是，如果一个web服务器崩溃，将流量重定向到另一个web服务器上的延迟很小，尽管现有连接将被重置。

4层均衡器可以做加权平均，处理不同容量的后端，它为运维人员提供了强大的能力和灵活性，同时在计算能力方面相对便宜。

走向多站点

系统继续扩张。即使你的数据中心出现故障，你的客户也希望能继续保持运转。你会构建一个新的数据中心，其中包含自己的一组后端服务和另一组4层均衡器，它们在与之前一样的虚拟IP上提供服务。DNS设置不变。这两个站点的边缘路由器都在传播地址信息，包括服务的虚拟IP。根据终端用户和系统之间的网络连接情况，以及它们的路由策略配置，发送到虚拟IP的请求可以到达任一个站点。这被称为anycast（任播）。大多数情况下，这种方法都很有效。如果其中一个站点出现故障，你可以停止通过BGP传播服务虚拟IP，这样流量就可以迅速转移到另一个站点。

这个设置有几个问题。最糟糕的是，你无法控制流量的走向或者限制发送到某个特定站点的流量。通常，决定路由的网络协议和配置应该将用户路由到最近的站点，不过就网络延迟而言，你并没有明显的方法来实现这个目标。

在多站点系统中控制入站请求

为了维持稳定性，你需要控制每个站点的流量，你可以为每个站点分配不同的虚拟IP，并使用DNS的简单循环或加权循环来均衡流量。

现在产生了两个新的问题。

首先，使用DNS均衡意味着你有缓存记录，这不太适用于那些需要迅速重定向流量的场景。

第二，每当用户做一次新的DNS查询，虚拟IP会将用户连接到一个随机的站点，而不一定是离用户最近的那一个。如果你的服务站点分布广泛，根据用户和服务站点之间的网络延迟，各个用户感知到的系统响应性能会有较大波动。

让每个站点不断传播虚拟IP，并为所有其他站点（以及任何有问题的站点的虚拟IP）提供服务，你可以通过这种方式解决第一个问题。一些网络技巧（比如从备份中传播不那么特殊的路由信息）可以确保虚拟IP对应的主站只要是可用的，那么它便是首选。这是通过BGP完成的，因此在更新BGP后的一到两分钟内，我们应该会看到流量的移动。

除了让距离用户最近的健康站点为其提供服务以外，并没有一个更加优雅的选择。很多大型互联网服务尝试使用DNS来向不同位置的用户返回不同的结果，并在一定程度上取得了成功。不过这种方法总是有点复杂和容易出错，因为因特网的寻址方案并不是按地理位置组织的，地址块可以改变位置（例如，当公司重新组织其网络时），很多终端用户仍然可以通过缓存名称服务器获得服务。

增加7层负载均衡

随着时间的推移，你的客户开始对一些更加高级的特性提出要求。

虽然4层负载均衡器可以高效地在多个web服务器之间分配负载，但这种分配是只在源IP地址和目标IP地址、协议和端口上进行的。4层均衡器对请求的内容一无所知，所以也无法实现很多高级特性。相对而言，7层（L7）负载均衡器知道请求的结构和内容，可以做得更多。

在7层均衡器中可以实现的一些特性包括缓存、限流、错误注入和代价敏感的负载均衡（部分请求需要更多的服务端处理时间）。

它们还可以基于请求的属性（例如HTTP cookies）进行均衡、终止SSL连接，并帮助抵御应用层拒绝服务（DoS）攻击。7层均衡器成本较高，不易扩容——它们为处理请求做了更多的计算，而且每个活动请求都会消耗一些系统资源。在一个或多个7层均衡器池前运行4层均衡器可以帮助解决扩展问题。

结论

负载均衡是一个复杂的难题。除了本文描述的策略之外，还有不同的负载均衡算法、用于实现负载均衡器的高可用技术、客户端负载均衡技术以及最近兴起的服务网格。

随着云计算的发展，核心的负载均衡模式也在不断演进，大型web服务也将继续改进负载均衡所能提供的控制和灵活性。

查看英文原文：https://opensource.com/article/18/10/internet-scale-load-balancing

活动推荐

12 月 7 日北京 ArchSummit 全球架构师峰会上，来自 Google、Netflix、BAT、滴滴、美团等公司技术讲师齐聚一堂，共同分享“微服务、金融技术、前端黑科技、智能运维等相关经验与实践。详情点击 https://bj2018.archsummit.com/schedule

创作场景

解密因特网级别的负载均衡常用手段