故障是每个技术人都不想遇到，但又总会遇到的事件。程序错误、安全漏洞、黑客攻击、服务器停机、网络中断等诸多因素都可能导致系统故障并使我们的业务瘫痪。这样的例子在国内外不断发生。比如2020年，由于全澳IT严重故障，Coles所有收银机都无法联网，down机瘫痪。收银员无法扫描商品，顾客无法结账。澳大利亚的每一家Coles超市都被迫暂时关闭。2018年，上海医保信息系统突然出现故障，影响了上海各大医院的结算系统，导致大量市民就医时无法正常使用医保卡。事发后，不少网友质疑医保信息系统涉及面如此之广，“没有应急措施吗？”这些真实案例提醒我们，技术赋能业务产生更高的效率，获得更多的价值，同时保障系统的稳定运行也非常重要。一旦系统出现大规模、长期故障，业务中断的后果可能会直接抹杀技术赋能带来的收益，甚至可能带来经济损失、品牌受损等严重后果。因此，有必要给我们的系统加一份“保险”——构建一个高可用的系统架构，这是每个技术团队都在努力的核心目标。什么是高可用性？那么什么样的系统才具备高可用能力呢？我觉得主要有两个考虑：容错和容灾。容错性是指当故障来临时，业务系统能否不间断地继续服务。常规措施是集群部署。同一个业务应用部署多台服务器。即使某些服务出现故障，其他服务仍然可以提供业务支持。这就像一架装有多个发动机的飞机。即使一台发动机出现故障，其余部分仍可支撑其飞至指定地点并安全着陆。容灾是指当发生重大灾难时，容错已经全部失效，但我们仍然有能力通过某种手段恢复业务。常规措施是备份。当某个机房发生严重故障，所有服务器都不能正常工作，但是数据备份还在，我们可以重新加载它们，让系统重新运行。这就好比飞机上所有的发动机都坏了，但是为了保证以后的飞行任务能够执行，就必须要有一个保护飞行员逃生的装置，比如弹射、跳伞，这样才能活下来，然后继续在其他位面继续任务。搭建高可用系统的准备工作首先，在搭建高可用系统之前，我们需要对故障有几个基本的认识：没有任何设施是100%安全可靠的。因此，在为系统设计高可用架构时，复杂度会随着涉及的设施数量的增加而增加。其次，我们需要尽可能精简运维体系。简单来说，上云是大多数企业的最佳选择。除非你自己的团队在同样的预算下能够在基础设施维护上达到同样甚至更高的可用性。否则，你的机房建设、服务器、网络等基础设施的维护，可能会耗去你半条命。再者，我们要以平常心对待可用性保证，这个原因我就不多说了。事故时有发生。你还记得过去的失败吗？2022年6月，Cloudflare意外中断导致大量热门网站无法访问。2021年12月，大量网站无法访问服务，亚马逊电商也受到重创。2021年5月，IBMCloud在短短5天内经历了两次严重中断。2020年3月，谷歌云在多个地区的云服务瘫痪长达14小时。20192018年2月，谷歌云因光纤损坏而出现长达10小时的网络问题。2018年4月，Azure服务因雷雨导致电压激增而中断28小时。正是因为没有100%无故障，我们才使用高可用，因为这是唯一的机会，让你免于造成巨大的财产损失。最后，我们不得不正视一个云服务用户普遍存在的误区。我们在选择云服务提供商的时候，需要明确云提供商为我们提供了哪些高可用能力，剩下的高可用覆盖范围需要我们自己去设计和实现。我们要知道，一个高可用系统的构建贯穿于基础设施、中间件、服务器、客户端等诸多方面。对稳定性高度敏感的企业，一定要冷静对待故障，用好高可用。（下图为云服务商和用户的高可用责任模型：云服务商主要提供基础硬件服务的高可用。而业务容错（负载架构）、容灾（保证数据备份）能力都在用户端。供参考）因此，如果你在上云时不为自己的业务系统提供额外的高可用保障，那么很有可能会出现我们在文章开头提到的业务困境。综上所述，今天和大家聊了聊系统上云时容易忽略的高可用问题，以及如何做好云上高可用架构。你对此有何看法？一起在留言区交流。欢迎来到我的公众号：程序员DD。第一时间了解行业前沿资讯，分享深度技术干货，获取优质学习资源
