均衡网络流量的常用技术，它们的优势和利弊权衡。

大型的多站点互联网系统，包括内容分发网络（CDN）和云服务提供商，用一些方法来均衡来访的流量。这篇文章我们讲一下常见的流量均衡设计，包括它们的技术手段和利弊权衡。

早期的云计算服务提供商，可以提供单一一台客户 Web 服务器，分配一个 IP 地址，然后用一个便于人读的域名配置一个 DNS 记录指向这个 IP 地址，再将 IP 地址通过边界网关协议（BGP）宣告出去，BGP 是在不同网络之间交换路由信息的标准方式。

这本身并不是负载均衡，但是能在冗余的多条网络路径中进行流量分发，而且可以利用网络技术让流量绕过不可用的网络，从而提高了可用性（也引起了非对称路由的现象）。

简单的 DNS 负载均衡

随着来自客户的流量变大，老板希望服务是高可用的。你上线第二台 web 服务器，它有自己独立的公网 IP 地址，然后你更新了 DNS 记录，把用户流量引到两台服务器上（内心希望它们均衡地提供服务）。在其中一台服务器出故障之前，这样做一直是没有问题的。假设你能很快地监测到故障，可以更新一下 DNS 配置（手动更新或者通过软件）删除解析到故障机器的记录。

不幸的是，因为 DNS 记录会被缓存，在客户端缓存和它们依赖的 DNS 服务器上的缓存失效之前，大约一半的请求会失败。DNS 记录都有一个几分钟或更长的生命周期（TTL），所以这种方式会对系统可用性造成严重的影响。

更糟糕的是，部分客户端会完全忽略 TTL，所以有一些请求会持续被引导到你的故障机器上。设置很短的 TTL 也不是个好办法，因为这意味着更高的 DNS 服务负载，还有更长的访问时延，因为客户端要做更多的 DNS 查询。如果 DNS 服务由于某种原因不可用了，那设置更短的 TTL 会让服务的访问量更快地下降，因为没那么多客户端有你网站 IP 地址的缓存了。

增加网络负载均衡

要解决上述问题，可以增加一对相互冗余的四层（L4）网络负载均衡器，配置一样的虚拟 IP 地址（VIP）。均衡器可以是硬件的，也可以是像 HAProxy 这样的软件。域名的 DNS 记录指向 VIP，不再承担负载均衡的功能。

四层负载均衡器能够均衡用户和两台 web 服务器的连接

四层均衡器将网络流量均衡地引导至后端服务器。通常这是基于对 IP 数据包的五元组做散列（数学函数）来完成的，五元组包括：源地址、源端口、目的地址、目的端口、协议（比如 TCP 或 UDP）。这种方法是快速和高效的（还维持了 TCP 的基本属性），而且不需要均衡器维持每个连接的状态。（更多信息请阅读谷歌发表的 Maglev 论文，这篇论文详细讨论了四层软件负载均衡器的实现细节。）

四层均衡器可以对后端服务做健康检查，只把流量分发到健康的机器上。和使用 DNS 做负载均衡不同的是，在某个后端 web 服务故障的时候，它可以很快地把流量重新分发到其他机器上，虽然故障机器的已有连接会被重置。

当后端服务器的能力不同时，四层均衡器可以根据权重做流量分发。它为运维人员提供了强大的能力和灵活性，而且硬件成本相对较小。

扩展到多站点

系统规模在持续增长。你的客户希望能一直使用服务，即使是数据中心发生故障的时候。所以你建设了一个新的数据中心，另外独立部署了一套服务和四层负载均衡器集群，仍然使用同样的 VIP。DNS 的设置不变。

两个站点的边缘路由器都把自己的地址空间宣告出去，包括 VIP 地址。发往该 VIP 的请求可能到达任何一个站点，取决于用户和系统之间的网络是如何连接的，以及各个网络的路由策略是如何配置的。这就是泛播。大部分时候这种机制可以很好的工作。如果一个站点出问题了，你可以停止通过 BGP 宣告 VIP 地址，客户的请求就会迅速地转移到另外一个站点去。

多个站点使用泛播提供服务

这种设置有一些问题。最大的问题是，不能控制请求流向哪个站点，或者限制某个站点的流量。也没有一个明确的方式把用户的请求转到距离他最近的站点（为了降低网络延迟），不过，网络协议和路由选路配置在大部分情况下应该能把用户请求路由到最近的站点。

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

为了维持稳定性，需要能够控制每个站点的流量大小。要实现这种控制，可以给每个站点分配不同的 VIP 地址，然后用简单的或者有权重的 DNS 轮询来做负载均衡。

多站点提供服务，每个站点使用一个主 VIP，另外一个站点作为备份。基于能感知地理位置的 DNS。

现在有两个问题。

第一、使用 DNS 均衡意味着会有被缓存的记录，如果你要快速重定向流量的话就麻烦了。

第二、用户每次做新的 DNS 查询，都可能连上任意一个站点，可能不是距离最近的。如果你的服务运行在分布广泛的很多站点上，用户会感受到响应时间有明显的变化，取决于用户和提供服务的站点之间有多大的网络延迟。

让每个站点都配置上其他所有站点的 VIP 地址，并宣告出去（因此也会包含故障的站点），这样可以解决第一个问题。有一些网络上的小技巧，比如备份站点宣告路由时，不像主站点使用那么具体的目的地址，这样可以保证每个 VIP 的主站点只要可用就会优先提供服务。这是通过 BGP 来实现的，所以我们应该可以看到，流量在 BGP 更新后的一两分钟内就开始转移了。

即使离用户最近的站点是健康而且有服务能力的，但是用户真正访问到的却不一定是这个站点，这个问题还没有很好的解决方案。很多大型的互联网服务利用 DNS 给不同地域的用户返回不同的解析结果，也能有一定的效果。不过，因为网络地址的结构和地理位置无关，一个地址段也可能会改变所在位置（例如，当一个公司重新规划网络时），而且很多用户可能使用了同一个 DNS 缓存服务器。所以这种方案有一定的复杂度，而且容易出错。

增加七层负载均衡

又过了一段时间，你的客户开始要更多的高级功能。

虽然四层负载均衡可以高效地在多个 web 服务器之间分发流量，但是它们只针对源地址、目标地址、协议和端口来操作，请求的内容是什么就不得而知了，所以很多高级功能在四层负载均衡上实现不了。而七层（L7）负载均衡知道请求的内容和结构，所以能做更多的事情。

七层负载均衡可以实现缓存、限速、错误注入，做负载均衡时可以感知到请求的代价（有些请求需要服务器花更多的时间去处理）。

七层负载均衡还可以基于请求的属性（比如 HTTP cookies）来分发流量，可以终结 SSL 连接，还可以帮助防御应用层的拒绝服务（DoS）攻击。规模大的 L7 负载均衡的缺点是成本 —— 处理请求需要更多的计算，而且每个活跃的请求都占用一些系统资源。在一个或者多个 L7 均衡器前面运行 L4 均衡器集群，对扩展规模有帮助。

结论

负载均衡是一个复杂的难题。除了上面说过的策略，还有不同的负载均衡算法，用来实现负载均衡器的高可用技术、客户端负载均衡技术，以及最近兴起的服务网络等等。

核心的负载均衡模式随着云计算的发展而不断发展，而且，随着大型 web 服务商致力于让负载均衡技术更可控和更灵活，这项技术会持续发展下去。

via: https://opensource.com/article/18/10/internet-scale-load-balancing

作者：Laura Nolan 选题：lujun9972 译者：BeliteX 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

在严重的故障发生之前，找到引起问题的异常事件，并修复它。

黑天鹅 Black swan 用来比喻造成严重影响的小概率事件（比如 2008 年的金融危机）。在生产环境的系统中，黑天鹅是指这样的事情：它引发了你不知道的问题，造成了重大影响，不能快速修复或回滚，也不能用值班说明书上的其他标准响应来解决。它是事发几年后你还在给新人说起的事件。

从定义上看，黑天鹅是不可预测的，不过有时候我们能找到其中的一些模式，针对有关联的某一类问题准备防御措施。

例如，大部分故障的直接原因是变更（代码、环境或配置）。虽然这种方式触发的 bug 是独特的、不可预测的，但是常见的金丝雀发布对避免这类问题有一定的作用，而且自动回滚已经成了一种标准止损策略。

随着我们的专业性不断成熟，一些其他的问题也正逐渐变得容易理解，被归类到某种风险并有普适的预防策略。

公布出来的黑天鹅事件

所有科技公司都有生产环境的故障，只不过并不是所有公司都会分享他们的事故分析。那些公开讨论事故的公司帮了我们的忙。下列事故都描述了某一类问题，但它们绝对不是只一个孤例。我们的系统中都有黑天鹅在潜伏着，只是有些人还不知道而已。

达到上限

达到任何类型的限制都会引发严重事故。这类问题的一个典型例子是 2017 年 2 月 Instapaper 的一次服务中断。我把这份事故报告给任何一个运维工作者看，他们读完都会脊背发凉。Instapaper 生产环境的数据库所在的文件系统有 2 TB 的大小限制，但是数据库服务团队并不知情。在没有任何报错的情况下，数据库不再接受任何写入了。完全恢复需要好几天，而且还得迁移数据库。

资源限制有各式各样的触发场景。Sentry 遇到了 Postgres 的最大事务 ID 限制。Platform.sh 遇到了管道缓冲区大小限制。SparkPost 触发了 AWS 的 DDoS 保护。Foursquare 在他们的一个 MongoDB 耗尽内存时遭遇了性能骤降。

提前了解系统限制的一个办法是定期做测试。好的压力测试（在生产环境的副本上做）应该包含写入事务，并且应该把每一种数据存储都写到超过当前生产环境的容量。压力测试时很容易忽略的是次要存储（比如 Zookeeper）。如果你是在测试时遇到了资源限制，那么你还有时间去解决问题。鉴于这种资源限制问题的解决方案可能涉及重大的变更（比如数据存储拆分），所以时间是非常宝贵的。

说到云产品的使用，如果你的服务产生了异常的负载，或者你用的产品或功能还没有被广泛使用（比如老旧的或者新兴的），那么你遇到资源上限的风险很大。对这些云产品做一下压力测试是值得的。不过，做之前要提醒一下你的云服务提供商。

最后，知道了哪里有限制之后，要增加监控（和对应文档），这样你才能知道系统在什么时候接近了资源上限。不要寄希望于那些还在维护服务的人会记得。

扩散的慢请求

“这个世界的关联性远比我们想象中更大。所以我们看到了更多 Nassim Taleb 所说的‘黑天鹅事件’ —— 即罕见事件以更高的频率离谱地发生了，因为世界是相互关联的” —— Richard Thaler

HostedGraphite 的负载均衡器并没有托管在 AWS 上，却被 AWS 的服务中断给搞垮了，他们关于这次事故原因的分析报告很好地诠释了分布式计算系统之间存在多么大的关联。在这个事件里，负载均衡器的连接池被来自 AWS 上的客户访问占满了，因为这些连接很耗时。同样的现象还会发生在应用的线程、锁、数据库连接上 —— 任何能被慢操作占满的资源。

这个 HostedGraphite 的例子中，慢速连接是外部系统施加的，不过慢速连接经常是由内部某个系统的饱和所引起的，饱和与慢操作的级联，拖慢了系统中的其他部分。Spotify 的一个事故就说明了这样的传播 —— 流媒体服务的前端被另一个微服务的饱和所影响，造成健康检查失败。强制给所有请求设置超时时间，以及限制请求队列的长度，可以预防这一类故障传播。这样即使有问题，至少你的服务还能承担一些流量，而且因为整体上你的系统里故障的部分更少了，恢复起来也会更快。

重试的间隔应该用指数退避来限制一下，并加入一些时间抖动。Square 有一次服务中断是 Redis 存储的过载，原因是有一段代码对失败的事务重试了 500 次，没有任何重试退避的方案，也说明了过度重试的潜在风险。另外，针对这种情况，断路器设计模式也是有用的。

应该设计出监控仪表盘来清晰地展示所有资源的使用率、饱和度和报错，这样才能快速发现问题。

突发的高负载

系统在异常高的负载下经常会发生故障。用户天然会引发高负载，不过也常常是由系统引发的。午夜突发的 cron 定时任务是老生常谈了。如果程序让移动客户端同时去获取更新，这些客户端也会造成突发的大流量（当然，给这种请求加入时间抖动会好很多）。

在预定时刻同时发生的事件并不是突发大流量的唯一原因。Slack 经历过一次短时间内的多次服务中断，原因是非常多的客户端断开连接后立即重连，造成了突发的大负载。 CircleCI 也经历过一次严重的服务中断，当时 Gitlab 从故障中恢复了，所以数据库里积累了大量的构建任务队列，服务变得饱和而且缓慢。

几乎所有的服务都会受突发的高负载所影响。所以对这类可能出现的事情做应急预案 —— 并测试一下预案能否正常工作 —— 是必须的。客户端退避和减载通常是这些方案的核心。

如果你的系统必须不间断地接收数据，并且数据不能被丢掉，关键是用可伸缩的方式把数据缓冲到队列中，后续再处理。

自动化系统是复杂的系统

“复杂的系统本身就是有风险的系统”
—— Richard Cook, MD

过去几年里软件的运维操作趋势是更加自动化。任何可能降低系统容量的自动化操作（比如擦除磁盘、退役设备、关闭服务）都应该谨慎操作。这类自动化操作的故障（由于系统有 bug 或者有不正确的调用）能很快地搞垮你的系统，而且可能很难恢复。

谷歌的 Christina Schulman 和 Etienne Perot 在用安全规约协助保护你的数据中心的演讲中给了一些例子。其中一次事故是将谷歌整个内部的内容分发网络（CDN）提交给了擦除磁盘的自动化系统。

Schulman 和 Perot 建议使用一个中心服务来管理规约，限制破坏性自动化操作的速度，并能感知到系统状态（比如避免在最近有告警的服务上执行破坏性的操作）。

自动化系统在与运维人员（或其他自动化系统）交互时，也可能造成严重事故。Reddit 遭遇过一次严重的服务中断，当时他们的自动化系统重启了一个服务，但是这个服务是运维人员停掉做维护的。一旦有了多个自动化系统，它们之间潜在的交互就变得异常复杂和不可预测。

所有的自动化系统都把日志输出到一个容易搜索的中心存储上，能帮助到对这类不可避免的意外情况的处理。自动化系统总是应该具备这样一种机制，即允许快速地关掉它们（完全关掉或者只关掉其中一部分操作或一部分目标）。

防止黑天鹅事件

可能在等着击垮系统的黑天鹅可不止上面这些。有很多其他的严重问题是能通过一些技术来避免的，像金丝雀发布、压力测试、混沌工程、灾难测试和模糊测试 —— 当然还有冗余性和弹性的设计。但是即使用了这些技术，有时候你的系统还是会有故障。

为了确保你的组织能有效地响应，在服务中断期间，请保证关键技术人员和领导层有办法沟通协调。例如，有一种你可能需要处理的烦人的事情，那就是网络完全中断。拥有故障时仍然可用的通信通道非常重要，这个通信通道要完全独立于你们自己的基础设施及对其的依赖。举个例子，假如你使用 AWS，那么把故障时可用的通信服务部署在 AWS 上就不明智了。在和你的主系统无关的地方，运行电话网桥或 IRC 服务器是比较好的方案。确保每个人都知道这个通信平台，并练习使用它。

另一个原则是，确保监控和运维工具对生产环境系统的依赖尽可能的少。将控制平面和数据平面分开，你才能在系统不健康的时候做变更。不要让数据处理和配置变更或监控使用同一个消息队列，比如，应该使用不同的消息队列实例。在 SparkPost: DNS 挂掉的那一天 这个演讲中，Jeremy Blosser 讲了一个这类例子，很关键的工具依赖了生产环境的 DNS 配置，但是生产环境的 DNS 出了问题。

对抗黑天鹅的心理学

处理生产环境的重大事故时会产生很大的压力。为这些场景制定结构化的事故管理流程确实是有帮助的。很多科技公司（包括谷歌）成功地使用了联邦应急管理局事故指挥系统的某个版本。对于每一个值班的人，遇到了他们无法独立解决的重大问题时，都应该有一个明确的寻求协助的方法。

对于那些持续很长时间的事故，有一点很重要，要确保工程师不会连续工作到不合理的时长，确保他们不会不吃不睡（没有报警打扰的睡觉）。疲惫不堪的工程师很容易犯错或者漏掉了可能更快解决故障的信息。

了解更多

关于黑天鹅（或者以前的黑天鹅）事件以及应对策略，还有很多其他的事情可以说。如果你想了解更多，我强烈推荐你去看这两本书，它们是关于生产环境中的弹性和稳定性的：Susan Fowler 写的《生产微服务》，还有 Michael T. Nygard 的 《Release It!》。

via: https://opensource.com/article/18/10/taxonomy-black-swans

作者：Laura Nolan 选题：lujun9972 译者：BeliteX 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出