今年1月份的时候，很多人都被“全美航班停飞的事件”刷了屏，据说当天造成了全美1万多航班取消或延误。
而故障的原因是美国联邦航空局的「空中任务通知系统」挂了，具体细节是其中“某个数据库文件损坏”。
当时这个料被爆出后，就有很多吃瓜群众吐槽↓
“这么重要的系统在老美那里算「关基」了吧，竟然没点高可用措施？”
“肯定早上了高可用吧，但上了也能挂？”
其实这种“宕机”，大家也不是头一次见识了。尤其最近几年上云热闹，全球头部的云大厂们，几乎都轮番宕机上过热搜…
每到此时，关于高可用啊、SLA啊、上云不如自建稳啊，这类争论就会此起彼伏。
其实，每一次大规模宕机，都是偶然中的必然！
今天，我们就开个话题，好好唠唠“明明上了「高可用」还会宕机？我们对IT「高可用」，都有哪些误解？”
一、什么是高可用？
高可用，High ，有人也缩写成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成本更低；但是云上高可用和云上安全类似，要注意责任共担模式，并要做到设计和交付对齐。
最后，祝大家永不宕机
限时特惠:本站持续每日更新海量各大内部创业课程，一年会员仅需要98元，全站资源免费下载
点击查看详情
站长微信:Jiucxh
