如何高效使用亚马逊EC2之服务可用性与数据存储

1. 在多个Availability Zone（AZ）中部署服务。每个AWS Region内的AZ都是物理上单独隔离的，它们有各自独立的供电系统和网络接入，甚至是两个完全独立的机房。当服务部署在多个AZ下，只有部署的所有AZ都出现故障时，服务才会被完全中断。理论上说，如果服务同时部署在N个AZ的EC2上，那么EC2问题影响服务可用性的概率就降到（0.05N) ×100%。
2. 用Auto Scaling（AS）来自动调度EC2实例。通常来说，当服务遇到一些突发或者预期的高流量时，或者你的服务出现某些异常时，整个服务的可用性会受到极大挑战，而AS机制就是帮助你应对这些情况的。AS机制可以按照之前设定的Scaling Up和Scaling Down条件自动启动或者关闭EC2实例以应对流量变化和服务异常。一般来说，任何在线服务都应该有这种自动横向伸缩的能力，AS就是在基础设施层提供这种能力，而你只需要关注在应用层支持这种能力。当然，如果AS机制不能满足需求，那么完全可以利用EC2的API实现自己的Scaling算法（其实我们就是这么做的）。
3. 用Elastic Load Balancing（ELB）来平衡多个EC2实例的负载。其实，负载均衡是个存在已久的概念，并且在传统的数据中心也已有相应的实现（软件或者直接硬件）。但ELB比起传统数据中心的负载均衡器有以下一些明显的优势。

ELB自身也是自动弹性伸缩的。当有超大流量时（尤其是受网络攻击或者有突发事件时），Load Balancer自身的负载就会是一个巨大的挑战。而ELB是基于EC2实现的，可以非常方便地自动伸缩容量来应对这些状况（注意，ELB自身弹性伸缩对开发人员完全透明，这应该是称它为弹性负载均衡器的原因）。
ELB能非常容易地与AWS的其他服务（如Auto Scaling、Cloud Watch、Route53等）结合使用。尽管ELB可以独立工作，直接向注册的EC2实例分发流量，但向ELB注册一个Auto Scaling Group会是一个更常见的选择。同时，ELB还在利用Cloud Watch确定服务实例的健康状况。另外， ELB的Endpoint也常常作为服务在一个AWS Region的入口而配置在Route53的DNS解析服务中。

4. 在多个数据中心（Region）部署EC2实例。尽管AWS多数据中心的初衷是帮助客户服务全球各地的用（提供更好的网络环境，符合各地的法律需求等），但多数据中心部署也可以帮助我们提高服务的可用性。你可以在一个数据中心彻底瘫痪的情况下把用户导向其他数据中心。但在使用这个方法时，需要注意网络性能和法律风险等相关问题。
在介绍完保证可用性的各种AWS服务后，下面这些使用建议能帮助我们更好地使用这些服务。
1. 尽量在多个AZ中部署大体相当的服务能力（如EC2实例）。尽管EC2可用性是值得信赖的，并且ELB已帮我们很好地平衡负载，但某个AZ整体出现问题的情况还是出现过的。当突发事件发生时，这种多AZ大体平衡的设计可以更好地保证服务可用性。
2. 提供简单的多数据中心切换逻辑。尽管需要多数据中心切换的情形并不是很多，但它却是真实存在的。一个月前，AWS美西数据中心EC2服务就出现问题长达4个多小时。在这期间，我们在美西数据中心的所有服务都不可用，而更严重的是我们服务的绝大部分用户都是来自美西的。幸运的是，我们的服务支持动态多数据中心切换（这个设计初衷是帮助用户动态选择最佳的数据中心），简单地修改一个配置就把所有流量导入到美西数据中心（当然用户的使用体验可能会因为网络延时增加而有所下降）。尽管我们自己实现了数据中心动态切换逻辑，但现在Route53会是一个更好的选择。只需要在Route53中简单设置每个Region Endpoint的Failover逻辑就能达到类似效果。我建议部署在AWS上的全球服务最好使用Route53以增加整体架构的灵活性。