引言
故障，不管它发生的概率有多低，终归还是会发生的。
——墨菲定律
概念
单点故障
顾名思义，单个点发生的故障，扩展到云上的环境，指的就是单个节点发生的故障导致整个链路瘫痪。这里的节点可以是一台服务器，一个数据库，一台网络设备，乃至一个应用程序。
打个简单的比方，一个加工厂流水线只有甲乙丙丁四名员工，一个加工需求进来，需要甲乙丙丁依次处理方能完成，此时针对流水线的作业，四名员工就是链路的单点，任何一人请假或者离职，流水线作业就无法正常，此时就形成了单点故障。
高可用
HA（High Availability）。字面意思，就是保障高可用性。这里的可用性，我们通常用平均无故障时间来度量，可以说平均运行多长时间才会发生一次故障，也可以以平均一个周期内非故障时间与总时间的比例来表示。
容灾
DR（Disaster Recovery）。字面意思是灾难恢复。在云上环境我们可以理解为保障灾难情况下系统和业务的正常运行。
通常我们容易将高可用和容灾混淆，它们都是考虑维持业务的持续性运行，规避单点故障，粗略来说不区分彼此亦无不可，如果需要更好地细分和理解，那么高可用注重的是维持业务在周期内更长的可运行时间，而容灾注重的是极端情况下的业务恢复。
云上单点故障
随着云的日益普及，越来越多人享受到了云给我们带来的便利。由于用户群体多样化的增加，用户之间运维水平和故障意识也呈现较大的差距，单点故障成为越来越多人需要面对的问题。
举个例子，当前一个常见的简单业务场景：
尤其针对小型网站服务，很多用户只是单一用一台服务器来承载Web应用和数据库。这种情况下，数据库、服务器或者服务器上的业务程序出问题了，发生了单点故障，那么整个业务链路就处于不可用状态。很多用户抱着侥幸心理，直到发生问题时候才惊醒，然而问题已经出现，损失已无法挽回。
使用误区
不少用户在享受云的便利性和性价比的时候，通常有一些理解的误区:
1. 云服务的可用性等同于业务的可用性
云服务提供商一般都有产品SLA，拿最基础的云服务器来说，阿里云基础的ECS服务器可用性是99.95%，
参考：https://help.aliyun.com/knowledge_detail/40683.html
用户在使用时候就容易觉得自己的业务在上面跑就是有这么高的可用性，但云服务器ECS的服务可用性不等于用户业务的可用性。此可用性是从云服务器基础设施可用性角度来说的，而云服务器提供给了用户，操作系统的选择以及后续系统和软件环境的部署和维护都是需要用户考虑的，内核、系统服务、业务程序、安全等各方面都有可能出现问题，从而影响业务的正常提供，而事实也往往是这些操作系统内的问题引发了业务的瘫痪，所以实际业务可用性通常都低于云服务可用性。退一万步来讲，只论云服务的可用性，放在一个较长的时间区间，不可用的时间也是一个不可忽视的数值，我们并不知道可能在什么时候发生，也不应该拿运气来赌。
2. 用了云服务，出现问题那肯定都是云服务商的问题
打个比方，张三买了套房，随后张三按自己喜好弄了欧式装修，购置了家电。此时冰箱坏了或者墙纸脱落，张三自然会去找电器和装修公司理论，而不会想到去找房地产商。
转化到云上，其实云上基础产品多是IaaS（Infrastructure as a Service）层的服务，仍拿阿里云ECS服务器来说，阿里云提供服务器资源，用户购买后可以*灵活地在上面部署操作系统和软件环境，阿里云负责保障服务器的正常运行，而用户则需要对服务器内自己的操作系统和软件环境的正常运行负责，当然由于底层原因造成的影响仍是需要阿里云负责。
观念的转变是一个过程，也不是那么容易，但是划分清楚职责才有利于整个行业和生态的健康发展。
3. 高可用和容灾方案成本太高，划不来
针对不同的架构、需求和预算，有不同的高可用和容灾解决方案，如果实在成本有限，我们也可以优先针对业务链路上最容易出现问题的节点做高可用方案。尤其当前各行业竞争激烈，客户体验越来越重要，一次故障带来潜在的客户流失和体验下降的损失是不可估量的，而且挽回需要的投入往往比事先规避要大的多。怕什么就容易来什么，不如一开始就把潜在的故障风险降低。
4. 一台高配顶多台低配
有的客户喜欢买一台高配置服务器，性价比高，而且只要维护一套环境，殊不知单点高配机器一旦出问题，整个业务就完了，而通过多台低配服务器承载业务，能有效地规避单台服务器故障影响整个业务链路。
云上环境的高可用和容灾
不管业务是不是在云上，服务的稳定和连续性总归是无法回避的话题。从前面的论述中，我们了解到了高可用性和容灾的概念以及单点故障的危害性。虽然云上的产品已有很高的可用性，我们仍不能忽视构建业务高可用性和容灾的重要性。
基本产品
ECS
云服务器，相当于阿里云上的虚拟机，本身没有高可用性和容灾，需要通过架构来实现。
SLB
负载均衡，高可用性和容灾可以从两点来阐述：
- 负载均衡的服务提供是基于集群部署的，各集群有一定数量的节点，避免了单点故障，个别或者部分节点服务器宕机不会影响负载均衡服务的提供。
- 当前提供的负载均衡实例大多是多可用区实例，主备实例在同城不同可用区机房，当主实例机房出现故障，能及时进行切换，来实现容灾和服务的高可用性。
RDS
云数据库。
1.单机基础版RDS：
只包含一个节点，没有备用节点用于故障恢复
https://help.aliyun.com/document_detail/48980.html
2. 双机高可用版RDS：
在同一可用区有主备实例，在主实例出现故障时候可以进行主备切换，具有高可用和容灾特性.
3. 多可用区RDS：
主备实例在不同可用区
RDS之间还可以用DTS同步和迁移数据。
OSS
依托于阿里云底层盘古存储，文件以chunk分块方式存储，默认每块存三副本，并分布在不同机架的ChunkServer节点上。底层服务器出现宕机也不会导致数据不可用。
可以参考云盘的三副本技术介绍：
https://help.aliyun.com/document_detail/35108.html
示例介绍
这里介绍几种基本的企业高可用和容灾架构。
1. 多可用区SLB + 不同可用区ECS
引用帮助文档的图，在负载均衡实例下绑定不同可用区的 ECS，当可用区A未出现故障时，用户访问流量如蓝色实线所示；当可用区A发生故障时，用户访问流量的分发将变成红色虚线，这样即可以避免因为单个可用区的故障而导致对外服务的不可用，也可以通过不同产品间可用区的选择来降低延迟。
具体请参考：
https://help.aliyun.com/document_detail/55386.html
2. 多可用区SLB + 不同可用区ECS +高可用RDS
多可用区版RDS：
对于没有多可用区RDS的地域，可以在对应可用区分别建立一台RDS，其中备用可用区的作为备库，跟主可用区的RDS实例进行同步。
3. 高可用性-异地容灾
基于前面阐述的同城多可用区情况，在异地也部署一套环境，具体访问可以配置DNS解析来实现，数据库同步也可以通过DTS。