良好架构设计支柱

云计算良好架构设计有五大支柱，分别是：安全性，可靠性，性能效率，成本优化和卓越操作。其中可靠性是指系统从基础设施或者服务故障当中实现恢复、以动态方式获取计算资源以满足需求，以及缓解配置错误或者暂时性网络问题等干扰因素的能力。一般设计原则为：测试恢复规程，自动故障恢复，横向扩展以提升总体系统可用性、多钟小资源代替大资源，不再依靠猜测确定容量需求，自动管理变更。

在我们讨论可靠性和阅读相关文献的时候，我们经常会注意到以下几个概念，它们是高可用（High Availability），容错（Fault Tolerance），灾难恢复（Disaster Recovery）。明白它们的含义和区别有助于我们更好的理解和交流的一致。

高可用（High Availability）

高可用系统是指设计成99.999%的时间可用，即一年允许有5.26分钟的宕机时间，或尽可能接近这个时间。这通常需要设计一个冗余的失效备份系统（failover system），并且能处理跟主系统相同的工作负荷。当主系统出现故障的时候，能自动在很短的时间内切换到备份系统。

在物理基础设施中，要通过设计没有单点故障的系统来达到高可用。也就是说，关键的电力、冷却系统、计算、网络、存储都需要有额外的冗余设计。在阿里云中，我们可以使用多个可用区（Available Zone）来实现物理的高可用，一个可用区包含一个或多个数据中心，一个可用区出现故障，系统能自动使用其它可用区的资源。但要做到自动切换使用其它可用区资源，我们还需要特别设计和注意。

比如我们创建一个高可用的RDS，但可用区我们选择了A，虽然RDS会在可用区A创建2个主备实例，但如果可用区A出现故障，那么这2个实例都不能工作，从而影响RDS的高可用。如果我们选择两个不同的可用区比如A+B，这样就能做到可用区级别的高可用。另外一个例子是，我们设计使用2个ECS来做web server，它们分别放到不同的可用区，这时我们还需要增加一个负载均衡（Load Balancer）来做到流量的分发，同时我们还要有另一个负载均衡待命，当主负载均衡失效的时候，待命的负载均衡能够马上启用并分发流量。

高可用的核心概念就是要有冗余待命的实例同时存在，并且在检测到主实例失效时马上投入工作。否则就只能是一个冗余的系统而不是真正的高可用系统。汽车的备用轮胎是一个高可用的设计，当然它还没有达到刚才我们描述的真正的高可用。

容错（Fault Tolerant）

容错系统跟高可用的概念非常接近，但是它又更近一步，那就是要做到零宕机（Zero Downtime）。高可用能做到5个9（99.999%）的系统可用时间，还不能做到100%，那是因为只是高可用的设计还不能保证零宕机时间。如果我们做到了零宕机，那么这个系统就是一个容错系统。像下面的飞机发动机，设计有4个发动机，如果只是一两个发动机出现故障，并不会完全影响飞机的飞行。现在我们可以理解前面汽车设计的备用轮胎不能算是容错系统，因为换轮胎是需要一定时间，在这段时间汽车不能正常驾驶。

灾难恢复（Disaster Recovery）

有了高可用的设计以及容错系统，我们还需要灾难恢复设计吗？我们已经达到了5个9或者更好的可用性，还搭建灾备实例干嘛呢？灾难恢复是在高可用和容错的基础上又走得更远，那就是在重大灾难发生时，比如飓风、地震或其它引起基础设施的破坏而不能提供服务时，灾难恢复会有一个完整的计划来恢复关键业务系统，而不至于让我们的业务处于瘫痪且不能恢复的状态。比如我们将重要业务放到云服务提供商的一个区域或城市（Region），当这个区域出现上述重大灾难造成我们的客户数据丢失而不能恢复时，这对我们的business会造成毁灭性的打击。那么将重要数据同时备份到其它的一个区域或城市，这样的设计就属于灾难恢复的范畴。

下图中的例子描述的是飞机出现重大事故时飞行员跳伞的情况，这里飞行员就是我们的business。留得青山在，不怕没柴烧。有了他，我们可以继续开创新的天地。

总之，灾难恢复就是确保我们的business不被中断。当然灾难的恢复需要时间，我们也可能会丢失一部分数据。这里有两个重要指标就是RTO（Recover Time Objective），RPO（Recover Point Objective），分别代表恢复需要的时间以及恢复到灾难之前的什么时间的数据。它们都是越短越好。RPO跟我们的备份周期相关，如果数据做到了实时同步，这个时间就会很短；如果每天备份一次且没有增量备份，那么我们就可能丢失一天的内容。要做到RTO时间尽可能短，也是需要通过一些自动化的脚本或基础设施自动创建来实现。这里其实是IaC（Infrastructure As Code）的一些概念。阿里云提供的ROS或者开源的Terraform可以用来做基础设施的脚本管理和维护。

大家可以参考参考资料6来看灾难恢复计划的具体模板。

总结

理解了上面高可用、容错、灾难恢复的几个概念，我们在看资料和交流的时候才知道我们想表达的是哪一个概念，才不至于互相混用这几个词语引起对方的误解。

参考资料

1. AWS Well-Architected Framework
2. Disaster Recovery vs. High Availability vs. Fault Tolerance: What are the Differences?
3. High Availability vs. Fault Tolerance vs. Disaster Recovery
4. The Difference Between Fault Tolerance, High Availability, & Disaster Recovery
5. Building Fault-Tolerant Applications on AWS
6. Disaster Recovery Plan Template