2012年冬季，美国东部区域的AWS Elastic Load Balancer服务出现问题，导致Netflix出现长达7个小时的服务中断。（Netflix运行在AWS上，没有自己的数据中心。除了视频流，用户与Netflix的所有交互都是由AWS来处理的。用户在点击“播放”按钮后，我们的CDN服务器会提供视频内容。）在服务中断期间，所有进入美国东部的流量都无法访问我们的服务。
为了防止这种情况再次发生，我们决定建立一个区域失效备援系统。失效备援是一种计算机系统保护措施，在主系统发生故障时，备用设备自动接管主系统的工作。
区域失效备援降低了风险
我们扩展到三个AWS区域：美国两个（美国东部和美国西部），欧盟（EU）一个。我们保留足够的容量来执行失效备援，足以承担单个区域的服务中断带来的风险。
典型的失效备援如下所示：
- 发现其中的一个区域出现问题。
- 增大“救世主”区域的容量。
- 将一些来自问题区域的流量引到救世主区域。
- 将DNS从问题区域切换到救世主区域。
让我们来详细解释每一个步骤。
- 定位问题
我们需要度量指标，最好是一个可以告诉我们系统健康状况的度量指标。在Netflix，我们使用一种称为每秒流启动量（简称SPS）的业务度量指标，也就是已成功开始播放节目的客户端数量。
我们按照区域对这些数据进行分区，可以随时绘制出每个区域的SPS数据，并将它们与前一天和前一周的SPS数据进行比较。如果SPS图出现下降，表示用户无法播放流式节目，说明我们遇到麻烦了。
问题不一定出在云基础设施上。Netflix生态系统由数百种微服务组成，问题有可能是糟糕的代码部署导致的，也有可能是因为海底电缆被切断，等等。我们可能不知道具体的原因，只知道出问题了。
如果只发现一个区域出现SPS下降，那么这是进行区域失效备援的最佳时机。如果多个区域都出现SPS下降，那我们就不走运了，因为我们一次只能对一个区域进行失效备援。这就是为什么我们要通过交错的方式，每次只在一个区域里部署微服务。如果部署出现问题，我们可以立即回滚，并调试问题。
- 加大救世主区域的容量
一旦确定了问题区域，我们就要准备让救世主区域接收问题区域的流量。在打开开关之前，需要适当地加大救世主区域的容量。
在这种情况下，多少容量才合适呢？Netflix的流量模式在一天当中不是固定不变的。高峰期通常发生在下午6至9点左右，不过高峰期在不同区域达到的时间是不一样的。美国东部的高峰流量比美国西部要早3个小时，比欧盟区域晚了8个小时。
在对美国东部进行失效备援时，我们将来自美国东部的流量发送到欧盟区域，将来自南美洲的流量发送到到美国西部。这样做是为了减少延迟，并为客户提供最佳的体验。
我们可以基于每个微服务的历史数据，使用线性回归的方式预测在一天中的某个时间段被发送到救世主区域的流量。
一旦确定了每个微服务需要承担的流量大小，我们就通过设置每个集群的期望流量来触发伸缩，剩下的就是让AWS发挥它的魔力。
- 重定向流量
现在，微服务集群已经扩展好了，我们开始重定向从问题区域流向救世主区域的流量。 Netflix开发了一款名为Zuul的高性能、跨地域的边缘代理服务器，并已经将它开源。
这些代理服务用于验证请求、对负载进行分片、重试失败的请求等。Zuul还可以进行跨区域代理。我们用它将流量从问题区域发送出去，并逐渐增加需要重新路由的流量，直到达到100％。
有了这种渐进式的代理，我们的服务就可以使用自己的伸缩策略进行反应式的伸缩，以便应对预测伸缩和实际伸缩之间存在的流量变化。
Zuul承担了繁重的工作，将所有来自问题区域的流量转移到救世主区域。接下来是时候放弃问题区域了，而DNS切换在这个时候开始闪亮登场。
- 切换DNS
失效备援的最后一步是更新指向问题区域的DNS记录，并将它们重定向到救世主区域。这将导致所有的用户流量从问题区域移走，而DNS缓存没有过期的客户端仍然被路由到问题区域。
以上就是有关Netflix进行失效备援的背景情况。这个过程需要很长时间才能完成——大约45分钟（还是在最好的情况下）。
用闪亮的新技术加速这一过程
我们注意到，大部分时间（大约35分钟）都花在等待救世主区域的扩容上。尽管AWS可以在几分钟内为我们提供新实例，但启动服务、进行预热、在注册UP之前处理其他启动任务占用了太多的时间。
我们认为这个时间太长了。我们希望在10分钟内完成失效备援，在不增加业务负担的情况下做到这一点，并且把成本控制在一定范围之内。
我们保留所有三个区域的容量，用于容纳失效备援流量。既然我们已经为这些容量付过钱了，为什么不用它们呢？于是，我们启动了Nimble项目。
我们的想法是为每个微服务维护一个热备份实例池。当我们准备好进行失效备援时，可以简单地将热备份实例注入到群集中，让它们处理实时的流量。
未使用的预留容量称为槽（trough）。 Netflix的一些团队使用槽容量来运行批量作业，所以我们不能简单地将所有可用的槽变成热备份。相反，我们可以为每个微服务维护一个影子集群，并为这些影子集群准备足够多的实例，以便在一天当中的某个时间段处理失效备援流量。剩下的实例可用于批处理作业，其他人可以自由使用。
在进行失效备援时，我们并不是通过传统的伸缩方法触发AWS为我们提供实例，而是将影子集群中的实例注入到实时集群中。这个过程大约需要4分钟，而过去需要35分钟。
由于容量注入很快，我们不必谨慎地通过代理来移动流量，以便触发伸缩策略。我们只需要简单地切换DNS并打开闸门，就能极大地缩短服务中断的时间。
我们在影子集群中添加了过滤器，防止暗实例发出错误的度量指标。错误的度量指标会给度量空间造成混乱，影响正常的运营。
我们还通过修改服务发现客户端来阻止影子集群中的实例自己注册到注册服务上。在触发失效备援之前，这些实例将一直呆在小黑屋中（这当然是一句俏皮话了）。
现在，我们可以在7分钟内完成区域失效备援。因为利用了现有的预留容量，所以不会产生任何额外的基础设施成本。用于编排失效备援的软件由三名工程师组成的团队使用Python开发。
英文原文：opensource.com/article/18/…
感谢张婵对本文的审校。
