再看亚马逊4·21事故 反思云端应用架构

云计算是一种新型的计算模式。其显著优势之一是云计算用户可以随时随地的使用来自互联网的服务，并且按使用量付费。在需要增加（或减少）计算能力时，可立即获得（或释放）资源，而在传统数据中心（非私有云环境）中，用户却需要采购硬件，安装配置操作系统和中间件软件，再部署应用。两种方式在运维工作上的差异一目了然，这正是云计算能够受到业界热捧和追逐的主要原因之一。那么，云计算是完美无缺的么？不尽然如此。在云计算的世界里，运维工作不再由云计算用户承担，转而交给虚拟化和自动化技术以及云计算提供商来承担。同时，云计算用户在享受弹性资源扩张或收缩的同时，也在一定程度上失去了对其使用资源的控制权，而如果云服务供应商的服务出现故障，或者云服务供应商由于商业运作的失败或其他原因而关门倒闭时，云计算用户就可能会面临巨大的风险。

2011年4月21日至22日是值得云计算从业者纪念的日子。Amazon的IaaS服务出现故障，导致许多商业网站的服务中断，影响非常严重。据Amazon官方网站称，受影响最严重的网站中有Reddit， Foursquare和Quora等。此事件发生后，人们一时陷入慌乱，对云计算可用性的担心骤然升温。同时，也有人乘机夸大云计算的弊端，并宣称“云计算已死”（这让笔者想起当年关于“SOA已死”的论战）。炒作行为是可以理解的，我们自然不用去理会。但是，作为云计算用户，我们需要思考的是，如何保证即便在云服务不可用的情况，我们的应用架构仍然能够屹立不倒？本文正是站在云计算用户的角度试图探讨这一问题。

“4- 21”事故分析

Amazon将其基础设施划分为“区域（Region）”，这些区域好比一个个数据中心。例如，US-East-1是Amazon位于北弗吉尼亚的数据中心，而US-West-1则是位于硅谷的数据中心。每个数据中心又被划分成多个可用分区（后简称为AZ），AZ就好比资源池，它由一组物理和逻辑资源组成。

Amazon的提供的虚拟机是EC2（Elastic Compute Cloud）。而其存储服务是EBS（Elastic Block Storage）。EBS是基于网络高性能且高可用的块（block）级别的持久化存储服务。EBS可以挂接到某一个EC2实例上作为其文件系统使用。

当用户获得一个EC2分区实例时，同时会得到一块存储区。不过，该存取区是透明的，而且其生存周期与EC2实例是同步的。当EC2实例销毁时，该存储区也一同销毁，基于此，需要持久化的用户数据是不应该放在该存储上。

一般而言，运行网站和产品的云计算用户至少需要申请一个EC2实例和一个EBS存储。在EC2上运行应用和数据库，而数据则存储在EBS中。但是，若要将EBS存储挂接到EC2实例上，二者必须在同一AZ中（如图1.a所示）。用户也可以直接使用Amazon提供的RDS（Relational Database Service），它是一个运行着MySQL的EC2实例，此时应用和数据就可分别位于不同的AZ中（如图1.b所示）。当然，将应用和存储分开还有其他方法，本文不再赘述。

“4-21”事故中，位于US-East-1区域的EBS存储和Amazon RDS服务都出现了问题。表现出来的现象是：不在US-East-1区域的用户未受影响，未使用EBS和RDS的用户不受影响。一般情况下，使用EBS或RDS是非常普遍的现象，因为大多数软件或网站都依赖于数据存储，所以，即便运行应用的EC2未受影响，也会由于应用需要访问已出现问题的ESB或RDS上的数据，仍然会导致服务不可用或服务变慢的问题。

Amazon事故的的发生加速了人们对云可用性的思考，也进一步凸显了好的应用架构的优势，多家企业纷纷通过博客分享了他们使用Amaozon AWS的经验，对云计算用户端架构的建议。接下来，我们看看他们是怎么做的。