今年1月份的时候，很多人都被“ 全美航班停飞的事件”刷了屏，据说当天造成了全美1万多航班取消或延误。 而故障的原因是美国联邦航空局的「 空中任务通知系统」挂了，具体细节是其中“某个数据库文件损坏”。 当时这个料被爆出后，就有很多吃瓜群众吐槽↓ “ 这么重要的系统在老美那里算「关基」了吧，竟然没点高可用措施？” “ 肯定早上了高可用吧，但上了也能挂？” 其实这种“宕机”，大家也不是头一次见识了。尤其最近几年上云热闹，全球头部的云大厂们，几乎都轮番宕机上过热搜… 每到此时，关于高可用啊、SLA啊、上云不如自建稳啊，这类争论就会此起彼伏。 其实，每一次大规模宕机，都是偶然中的必然！今天，我们就开个话题，好好唠唠“ 明明上了「高可用」还会宕机？我们对IT「高可用」，都有哪些误解？” 一、什么是高可用？高可用， High Availability，有人也缩写成HA。 其实就是通过各种可靠性的设计，把一个系统不能正常提供服务的几率降到最低。 拿上面航班停飞的来举例，如果有个影子版的「 空中任务通知系统」始终在旁边候着，发现“正主儿”宕机以后，它立马无缝接管，航班不受任何影响。 这，就是所谓「高可用」了。但是，需要提醒大家一点， 高可用≠100%无故障。无论我们如何未雨绸缪，如何进行各种冗余设计，宕机的概率依然存在。 所以我们会看到任何系统、任何云服务，给出的SLA，都是多少个9（比如99.9999%），但从来没人承诺100% 。 二、为什么需要高可用？高可用是一项系统性工程。 拿在线式的软件服务为例：网络、主机、存储、系统、软件，以及相关联的数据库、API、各种组件，甚至托管机房的风火水电，都是影响最终高可用结果的因素。

既然是系统性工程，涉及到这么多方方面面，每个环节都要考虑周全，也就意味着更高的成本。

所以，高可用送给你的每个9背后，都暗中标好了价格既然这么费钱，那么追求高可用的道路上，就应该适可而止，够用就好。 第一，从实际业务需求出发，来评估具体的可用性指标，业务连续性要求高的，就必须要“卷”起来。第二，根据行业监管要求，达成相应的合规标准。比如针对银行，就会有类似于《银行业信息系统灾难恢复管理规范》（JR/T 0044—2008）的监管规定，要求必须达到对应的高可用级别。

所以，对高可用指标的追求，往往都是掂量着业务需求+监管需求，在加上自己口袋里的money，最终得到的一个平衡结果。

(资料图片仅供参考)

三、如何进行高可用架构设计？如果已经明确了高可用的需求，那么接下来就要深入了解下，高可用设计，具体应该咋么整？ 通常，高可用设计应该遵循6大原则↓ ❶ 少依赖原则顾名思义，就是在高可用系统设计的时候，应当尽可能减少 不同组件之间的依赖关系。 彼此独立，能不依赖的，尽可能不依赖，越少越好。否则，一个组件挂掉，整个系统就可能“兵败如山倒”。 比如，一个 多依赖系统，是这样的↓ 一个 少依赖系统，是酱婶儿的↓ ❷ 弱依赖原则一定要依赖的，尽可能弱依赖，越弱越好。 如果组件A强依赖组件B，一旦B挂了，A也会翻车，反过来也一样。所以任何强依赖要尽可能转化为弱依赖，从而降低“翻车”的概率。 ❸ 分散原则化整为零，打散成N份，从而分散风险，避免把 鸡蛋放在一个篮子里，一损俱损。 比如设计数据库的时候，不要所有的交易数据都放在同一个库的同一个表里，万一库挂了，就意味着所有交易都停摆。 另外，更典型的还有多AZ设计，多云架构，以及大家最经常听到的异地容灾架构，这些，都是在遵循分散原则。 ❹ 均衡原则在打散拆分成N份的前提下，还要尽可能保证每份都是均衡的，这样风险也被均匀分担，避免某份的权重过大，造成影响的范围过大。 ❺ 无单点原则要有冗余设计，以免出现问题无路可退。 比如支持切换、扩容等策略，链路故障时可以切换到新链路上，主机故障时可以切换到新扩容的机器上。 再比如支持回滚机制，某个操作失败后，可以回滚到上个版本，避免在错误的道路上越走越远，无法收拾残局。 ❻ 自保护原则一旦出现极端情况，要果断「丢车保帅」，牺牲不重要的部分，保护重要的部分。 比如CPU过热保护，也可以看做是类似这样的机制，系统在检测到CPU温度过高后，自动降频，虽然整体处理性能下降了，却不至于完全宕机。 除了这些基础的设计原则需要遵循，还有一个简单粗暴的硬道理↓公有云相比私有云、IDC托管、传统IT架构等等，天然更具备高可用的“潜质”。 首先，云计算的基因就是分布式的， 跟传统集中式架构比拼 RAS 指标、用昂贵的硬件系统来提升 高可用的思路完全不同。 云计算把硬件故障当做“常规事件”，通过分布式架构来 降低依赖、分散和均衡风险、消除单点并提供保护机制。

第二，同样都叫「云计算」，公有云相比私有云、本地虚拟化资源池，可以通过超大规模的资源优势，不断堆buff，堆出更好的伸缩性，遭遇极端场景时，具备更好的高可用潜质。

第三，公有云在底层基础设施层面，通过选址、数据中心级别（风火水电）、多线网络、多DC、多AZ、多区域，各种未雨绸缪，具备更耐折腾的高可用底盘。

所以，当遇到高可用的需求时，优先选择上云，一般可以达到事半功倍的效果。 换句话说，如果想要同样的SLA，对用户来讲，云下的成本要远高于云上。 四、都说云上高可用靠谱，为什么我上了云，结果还是挂了？虽然我说公有云“天然高可用”，但吃瓜群众说“ 你看你看，常有云宕机上热搜！” 首先明确一点，相比云下IT系统成天此起彼伏故障，云宕机其实是小概率事件，只不过云宕机更具新闻性，所以几大头部云商但凡有点风吹草动，行业里就会草木皆兵。

第二，上了云，不等于宕机的锅就可以完全甩给云服务商了，云用户和云服务商需要权责明确，责任共担。

前面我们说过，高可用是一个系统性工程，涉及到服务边界的问题，云服务商没法成为云保姆，大包大揽把所有的事情都兜底。

如果「成熟」的云服务商和云用户，都能把各自的“ 门前雪”扫干净，那么，云上高可用的效果，就可以发挥到极致。 既然话说到这个份上了，我们就要搞清楚，作为云用户，云上有几大雷区必须要规避，否则可能「 上线一时爽，宕机火葬场」

❶ 如果业务需要高可用，一定要在采购之前就设计好高可用架构，无论是线下的IDC还是正经公有云产品，都需要提前设计，一旦部署了业务再回头想要高可用，改造起来可就伤筋动骨了。

❷为了确保整体的可用性，每一个环节都得具备高可用，一个组件出了问题就可能前功尽弃。 ❸在使用云厂商或托管服务之前，要提前调查好各项功能的兼容性和需求是不是匹配，比如权限管理等。 ❹明确云厂商提供产品的可用区，很多云厂商提供了多可用区灾备能力，但也有少数产品因为性能等原因只支持单AZ。 ❺架构的设计和交付务必要对齐，效果图和施工落地不一致的惨案太多太多了。 ❻业务软件尽量做到无状态，这样可以利用云服务的多AZ算力及支持多AZ的PaaS产品，在不大幅增加成本的情况下，支持业务跨可用区的容灾能力。 ❼单元化设计，确保一次用户请求能够在一个可用区完成闭环，不要跨可用区。

五、一个典型的云上高可用架构设计，是怎样的？

我们来看个实际的例子吧，底层咱不说了，云服务商已经帮你把坑填完了，只看用户侧如何填坑↓ 先看错的，这是一个典型的「伪高可用」，各种组件看着都是冗余的，但是却忽略了一个最重要的地方，那就是所有的鸡蛋都在一个篮子里（单可用区架构）。 这种设计，看似做足了功夫，可一旦“可用区不可用”，高可用设计立马失效。 所以，正确的云上高可用设计，一定要把云的优势能用尽用，云的羊毛能薅尽薅… 比如，把上面的设计重来一遍，全部更改为多AZ模式，SLB主备设计， 前 端业务集群双AZ，缓存、数据库也选双AZ版本，文档存储选3AZ高可用。 这样的高可用设计，就是相对靠谱的，单个AZ故障，不会让业务到任何影响。 当然，还要注意高可用设计和实际交付要对齐，比如设计的时候数据库是跨区高可用，交付的时候却买了单AZ版本，购买对象存储的时候，思想开了个小差，本来该选3AZ版本，却点了单AZ版本。 一个小环节的疏漏，就能让“千里之堤溃于蚁穴”了。 再比如把 计算资源和 PaaS类服务（RDS等）整到了不同的可用区。 这样，用户的一次请求无法在一个AZ形成闭环，要跨可用区调用，既让性能打折，还增加了故障概率（任何一个可用区停摆，业务就会挂掉。） 所以，有些云大厂虽然不做“云保姆”，但还是尽可能帮用户“避坑”，比如提供一些专业的 可视化设计部署平台。 基于这样的平台，云用户在规划阶段做好高可用设计，并在部署时进行一致性检查，彻底解决设计与交付脱节的问题。 六、如果必须要用专有云（监管、合规要求），如何建设高可用？

现在大家都知道了关键点：上云更容易实现高可用，建设更简单，TCO更低。

遗憾的是，确实还有很多场景因为监管、合规等问题，暂时不能上云。

此时如果要建设高可用怎么办？❶根据业务属性合理分级。❷低等级就适当降低标准。❸高等级就付出更多成本。

高可用级别与成本之间成正比，所以，根据业务属性，合理设定可承受的风险范围+对业务恢复时间的要求，是弹性/韧性受限的专有云场景建设高可用的关键。

本地冗余架构：可以接受机房级风险，在单一主机、网络、系统、服务故障时，可以快速恢复业务。

同城容灾架构：可以接受区域级风险，但是在机房级风险发生时，能快速恢复业务。

异地容灾架构：除了能承受机房级风险，还要能承受区域级风险，但对快速恢复业务需求不强。

两地三中心架构：除了能承受机房级风险，还要能承受区域级风险，同时对快速恢复业务也有强需求。

小结一下：高可用不等于100%可用，高可用级别跟付出的成本成正比；先评估业务卷到什么程度，再决定高可用卷到什么程度；上云是建设高可用的捷径，云上高可用的TCO成本更低；但是云上高可用和云上安全类似，要注意责任共担模式，并要做到设计和交付对齐。

最后，祝大家永不宕机

标签：