不存在百分百的安全,该给你的系统上个保险了

DD的博客全面升级,阅读体验更佳(尤其是系列教程),后续不再通过这里发布新文章,而是改到 www.didispace.com 发布啦,奔走相告!点击直达~

故障,是每个技术人都不愿遇到,但却总会遇到的事件。程序Bug、安全漏洞、黑客攻击、服务器宕机、网络中断等诸多因素都有可能引发系统故障,使我们的业务面临瘫痪的窘境。这样的例子,国内外都在不断的发生,比如:
2020年,由于严重的全澳性IT故障,Coles的收银机全部不能联网,down机瘫痪。收银员扫不了货品顾客也不能结账,澳洲每家Coles超市都被迫暂时关闭。
2018年,上海的医疗保险信息系统就突发故障,波及上海各大医院的结算系统,致使大量市民在就医时无法正常使用医保卡,众多医院的排队窗口前纷纷大排长龙,场面混乱。事发之后就有不少网友质疑,涉及面如此之广的医保信息系统,“难道没有应急措施?”
这些活生生的真实案例都在提醒我们,技术赋能业务产生更高效率、获取更多价值的同时,保障系统稳定运行也至关重要。一旦系统出现大范围、长时间故障,致使业务中断的后果可能直接磨灭技术赋能带来的收益,甚至还可能带来经济损失、品牌受损等严重后果。

所以,有必要给我们的系统上一份“保险”——构建高可用的系统架构,这是每个技术团队都在努力的核心目标。

什么是高可用

那么怎么样的系统是否具备高可用能力的呢?我认为主要考量两个方面:容错与容灾。

容错能力指的是当故障来临时,业务系统是否可以不中断,继续服务的能力。常规措施就是集群化部署,同样业务的应用部署多台服务器,即时有个别服务坏了,其他服务依然可以提供业务支持。这就像飞机配置多台引擎一样,即时有一台坏了,剩下的依然可以支撑它飞行到指定地点安全着陆。

容灾能力指的是当重大灾难来临时,容错能力已经全部失效了,但我们依然有能力通过一些手段让业务重新恢复。常规措施就是备份,当某个机房发生了严重的故障,所有服务器都无法正常工作了,但数据备份还在,那我们就可以重新加载它们并让系统重新运行起来。这就好比飞机上的引擎全部坏了,但为了保证飞行任务以后还能执行,必须提供保护飞行员逃生的装置,比如通过弹射跳伞的方式令其可以幸存下来,之后又继续再其他飞机上继续执行任务。

高可用系统的构建准备

首先,在构建高可用系统之前,我们要对故障有几个基本的认识:没有任何一个设施是100%安全可靠的。所以,一个系统在设计高可用架构的时候,复杂度随涉及的设施的数量增多而变高。

其次,我们需要尽可能的精简运维体系。简单的说,上云是大部分企业的最佳选择。除非自身团队在同预算的情况下,能够在基建维护上达到相同乃至更高的可用性。不然你机房建设、服务器、网络等基础设施的维护可能都将要你半条命。

再者,必须平常心对待可用性保障,这个道理就不多说了。意外总是在发生,翻翻过去的那些故障,是不是都还历历在目:

2022年6月,Cloudflare的意外中断导致大量热门网站访问出现问题
2021年12月,AWS大面积故障导致大量网站无法服务,亚马逊电商也遭受重创2021年5月,IBM Cloud在短短5天里连续发生两次严重的中断事故
2020年3月,Google Cloud多个地区的云服务瘫痪,时间长达14小时
2019年2月,Google Cloud因光纤受损出现网络问题,时间长达10小时
2018年4月,Azure因受雷雨天气影响导致电压激增而中断服务,时间长达28小时
但是。正因为没有100%的无故障,我们才要用高可用,因为这是唯一挽救你造成巨大财产损失的机会。

最后,我们不得不正视一个云服务用户的常见误区。当我们选择云服务商的时候,需要明确云厂商到底给我们提供了哪些高可用能力,而剩下的高可用能力覆盖是需要我们自己设计和实现的。我们要知道,一个高可用系统的构建是贯穿基础设施、中间件、服务端、客户端等多方面的。对稳定性高度敏感的企业一定要平常心看待故障 ,用好高可用。

(下图展示了云服务厂商和用户的高可用上的责任模型:云服务商提供的主要是基础硬件服务的高可用能力。而我们之前所提到的业务容错(负载架构)、容灾(保障数据备份)能力都是在用户侧的。供参考)

所以,如果在上云的时候,对自身业务系统不做额外的高可用保障,那就很可能出现文章开始我们提到的那些业务窘境。

总结

今天跟大家聊了聊系统上云时,容易被忽略的高可用问题,以及如何做好云上高可用架构的方法。对此你有什么想法呢?留言区一起聊一聊。