云端应用系统的设计原则揭秘

每当我们在完成搭建云端应用系统这样一个系统性大工程的时候，爱德华·墨菲那略带嘲讽的洞见总会在我们耳畔回响：

一、任何事都没有表面看起来那么简单；
二、所有的事都会比你预计的时间长；
三、会出错的事总会出错；
四、如果你担心某种情况发生，那么它就更有可能发生。

我们都不愿意看到墨菲定律的应验，但每次它都会像“智子”一样横亘在我们的面前。聪明的人，选择接受现实。

所以AWS的推荐设计原则就是：搭建一个云端应用系统时，需要记住的一个原则是“design for failure”，也就是系统架构设计的时候需要考虑到应用系统的每一个层面，包括硬件和软件是可能出现故障的，并据此在应用系统架构设计上消除单一故障点，从而实现高可用性的系统架构。

有些应用由于历史或其他原因，没有按照这个原则设计高可用的架构，因此在部署上存在单一故障点，比如某一台EC2实例的软件或者底层硬件出现故障的时候会影响到这部分应用。如何保证或者大大提高单机EC2的可用性是非常重要的问题。

针对这些用户的需求，AWS推出了两个非常有用的监控功能：自动重启(auto reboot)EC2实例的CloudWatch警报和自动恢复(auto recovery)EC2实例的CloudWatch警报。这两个警报能够在你设定的阀值内自动重启因为实例故障或者底层硬件故障的EC2实例，最快时间恢复实例健康，从而大大降低了down机时间，让应用系统快速从软件或者底层的软硬件故障中自动地恢复，大幅度提升应用的整体可用性。具体介绍如下：

自动恢复EC2实例的CloudWatch警报

任何物理机都可能发生故障，云端的物理主机也不例外。使用AWS云平台，当底层硬件发生故障时，你无需人工干预或者联系AWS的支持工程师帮助您处理并恢复实例，通过事先创建 CloudWatch 的StatusCheckFailed_System（状态检查失败（系统））警报监控 EC2 实例，在实例运行的物理主机发生底层硬件故障的时候能够自动触发警报，一方面根据配置发送通知给贵司相关人员，另一方面以最快时间将实例迁移到健康的物理硬件上，并保持实例 ID、私有 IP 地址、弹性 IP 地址以及所有实例元数据不变。

自动恢复实例的Cloudwatch警报有以下要求：
· 仅支持C3、C4、M3、R3 和 T2 实例类型
· 仅支持VPC 中的实例，不支持EC2-Classic 实例
· 仅支持完全使用EBS 存储的实例，不支持使用任何实例存储卷的实例

自动重启EC2实例的CloudWatch警报

以前当您遇到由于实例内部的软件故障导致实例无法正常访问时，你只能选择手动重启实例让实例从故障中恢复，这个过程由于需要人工的干预，可能导致较长时间的实例不可访问。现在，您可以创建Cloudwatch的StatusCheckFailed_Instance（状态检查失败（实例））警报监控 EC2 实例，并在实例运行状况检查失败时自动重启此实例，从而实现在短短几分钟时间内即可重启您的实例并恢复实例。重启实例时，其仍驻留在相同的物理主机上，因此您的实例将保留其公有 DNS 名称、私有 IP 地址及其实例存储卷上的任何数据。

如何配置

为了大幅度提升单机的高可用性，建议您在一个实例上同时配置上述两种Cloudwatch警报，以监控软硬件故障并自动恢复实例。配置的时候需要注意的一点是：使用IAM user创建两个警报，其中自动重启EC2实例的警报的检测周期必须要大于自动恢复实例的警报的检测周期，比如下面例子中，自动重启EC2实例的检测周期是3， 自动恢复EC2实例的检测周期是2。

自动重启EC2实例的警报的示例（StatusCheckFailed_Instance）：

自动恢复EC2实例的警报的示例（StatusCheckFailed_System）：

更多信息请参考

http://docs.aws.amazon.com/zh_cn/AmazonCloudWatch/latest/DeveloperGuide/UsingAlarmActions.html#AddingRecoverActions(http://docs.aws.amazon.com/zh_cn/AmazonCloudWatch/latest/DeveloperGuide/UsingAlarmActions.html#AddingRecoverActions)