缓解AWS中断的架构

上周，随着AWS最近的停运，人们对各种架构及其在应对停机方面的有效性进行了大量讨论。由于这些方法在成本，复杂性和权衡方面存在很大差异，因此我想在较高层次上进行研究，然后再深入探讨其中不幸的是很多对话中都缺少的一种方法。

首先是有关多云的价值的评论。这样的想法是在…多个云中运行您的应用程序。通过将负载分散到多个提供程序中，可以避免其中之一发生故障。理论上，这听起来很棒！当然，两个云供应商不会同时崩溃！实际上，由于多种原因，这在应用程序级别上是可怕的：

因此，对于高可用性（在少数几个极端情况之外），多云架构将不是可行的选择。

接下来，有关于多区域的讨论。 AWS区域是一组多个可用区（AZ），每个可用区是一个或多个具有独立电源，网络和连接性的离散数据中心。在多个可用区中的单个区域中操作可提供高可用性，但不提供灾难恢复。为此，您需要多个区域。一个多区域设置的非常简化的版本如下所示：这解决了使用多云的几个问题：

您的应用程序将保留在同一云中，因此基础架构将保持不变

不幸的是，大多数评论都围绕Active-Active多区域。即，将负载同时分布在多个区域中。使持久层保持同步会增加很多复杂性。这也增加了部署的复杂性，并且有很多地方出错。与AWS相比，这可能导致更多的自我停机时间。

这是最近几天被大大忽略的一种。这种想法是一次仅激活一个区域，而在发生灾难时辅助区域可以接管（因此称为DR）。这具有上述好处。但是，它能够在很大程度上缓解整个Active-Active设置的复杂性。在这种设置下，不需要完全构建辅助区域-仅需要复制持久数据。

但是，等等，如果发生灾难，部署整个应用程序堆栈是否需要花费一些时间？是的，是的。这没关系！通过使用多个可用区来实现高可用性，足以应对大多数常见的停机情况。如果整个区域都有问题，如我们上周看到的那样，从备份中建立新堆栈的时间少于＆lt; 1小时，则要比＆gt; 8小时停机更可取。可以通过自动化来简化此过程，但是即使它是手动（但已实践）的操作，您实际上也有选择的事实很重要。

使用AWS托管服务，持久性数据的备份和复制通常是一两个配置设置：

如果发生故障转移，请在其他区域中部署应用程序（希望使用“基础结构即代码”）并更新DNS设置

这是银子弹吗？绝对不。它不会对每种工作负载都起作用，并且绝对不会对每种类型的中断都起作用。但是，这是一个相对简单的解决方案，也可以节省成本。上周，它可以允许客户端备份并正常运行us-east-1中的服务。

总之，发生中断。这不会以任何方式降低AWS的价值，但确实表明了良好架构和计划的重要性。可以设计一些非常昂贵和精巧的系统来减轻这些故障，但是对于大多数客户而言，它们是过大且不切实际的。幸运的是，还有其他选择可以提供具有合理权衡的“足够有效”的解决方案，当在AWS中工作时，这些选择应成为“最佳实践”。