面对AWS的中断，我们该采用什么样的架构

摘要

本文针对AWS宕机事件，分析了面对云服务中断时，作为应用架构和运维人员，采用何种架构方式能够尽可能规避这种事件的影响。

本文最初发表于For Else网站，经原作者Jeff Carter许可，由InfoQ中文站翻译分享。

前段时间AWS经历了中断，为了应对这种停机时间，已经有了很多关于架构的讨论以及它们能够如何有效处理这种状况。因为这些讨论在成本、复杂性和权衡方面有很大的不同，所以我想在概览层面简要介绍其中的几个，然后深入介绍一个在很多的对话中被忽略的一种架构。

多云

首先，就是关于多云价值的讨论。它的理念就是在多个云中运行你的应用。

通过将负载分散到多个供应商，我们就能够在其中的某一个供应商出现故障的时候得以幸免于难。在理论上，这种方式听起来很不错！当然，两家云厂商不会同时宕机。但是，在实践中，由于种种原因，在应用层面这样做是很困难的：

• 每种云的基础设施是不同的
• 部署的复杂性会大幅度增加
• 两者之间的带宽费用是相当高昂的

鉴于此，多云架构并不是高可用的可行方案（少数的边缘情况除外）。

多Region

接下来，是关于多Region的讨论。AWS Region是由多个可用区（availability zone，AZ）组成的，每个AZ是一个或多个的数据中心，它们具有独立的电源、网络和连接。在一个Region的多个AZ中运行能够提供高可用性，但是无法提供灾难恢复（Disaster Recovery，DR）功能。为了实现这一点，我们需要多个Region。一个非常简略的多Region结构如下所示：

这种方式解决了多云架构的多个问题：

• 应用依然在同一个云中运行，所以基础设施保持不变
• Region是完全独立的，因此能够获得同样的可用性的优势
• Region之间的带宽费用要比云之间的费用低得多

但令人遗憾的是，大多数的评论都是围绕Active-Active的多Region。也就是将负载同时分布到多个Region，这带来了很多关于持久化同步方面的复杂性。同时，这种方式也会增加部署方面的复杂性，并且很多地方都很容易出错，甚至它本身的停机时间比AWS导致的停机时间可能还要长。

多Region DR

这是最近以来一种被忽视的方案。它的理念是在同一时间只有一个Region处于活跃状态，在发生灾难的时候，另外一个备用的Region能够接管系统的功能（因此是DR）。这种方式和上面所述方案的收益是一样的，但是它能够极大地规避全Active-Active架构的复杂性。在这种架构下，备用Region不用完全构建，只需要复制持久化数据即可。

但是，稍等，在发生灾难的时候，部署完整的应用栈难道不需要一段时间吗？是的，是这样的，不过这是允许的！对于大多数常见的中断场景来说，高可用是通过使用多AZ实现的，这种方式就足够了。如果整个Region出现问题，就像我们前段时间在AWS上所看到的那样，花费小于一个小时的时间从备份中建立一个新的应用栈，仍然要比大于八个小时的中断更可取。这个过程可以通过自动化的方式来进行简化，但即便是手动的（但经过了实践检验）操作，有可选的备用方案也是很重要的。

所以，我们更深入地探讨一下这种架构：

• 应用程序像平常那样部署在主Region中
• 使用AWS托管的服务、备份和副本实现数据持久化，这通常只需要一两个配置即可：
  
  • 在不同的Region中为RDS添加一个读副本
  • 创建Dynamo DB global表
  • 启用S3 bucket副本
• 在进行故障恢复的时候，将应用程序部署在其他的Region上，并更新DNS的设置
  
  • 这一过程要定期进行测试

这是一个银弹吗？绝不是这样。它并不适用于任何类型的工作负载，也绝对不可能适用于任何类型的中断。然而，它是一个相对简单的方案，并且有一定的成本效益。

总结

总之，中断肯定是会发生的，这丝毫不会降低AWS的价值，但是这确实表明了良好架构和规划的重要性。我们可以设计一些非常昂贵和复杂的系统来缓解这些中断，但这对大多数客户来说是过犹不及和不切实际的。幸运的是，我们还有一些其他的选择，它们可能会提供一个“足够有效”的解决方案，并有合理的权衡，这应该成为在AWS上开展工作时的“最佳实践”。