这阵子接连发生极小概率事件:先是几条光缆同时被挖断导致一个服务区失联、然后又是一个硬盘出现罕见的静默错误(写入数据和读取出来的不一致)后居然被选中为主数据源导致故障意外放大以至于导致客户数据丢失。用星座小王子的话讲,这是腾讯云水逆了吧?
俗话说了,皮之不存毛将焉附,云厂商出问题了是不是在云上的服务就都要跟着嗝屁了呢?但是俗话也不是说了,不要吊死在一颗树上?这几次的事情让我想起2016年的云+未来峰会上,我在下午的开发者专场的圆桌论坛中回答观众问题的时候,现场有一个观众站起来问:
我们都知道今天早上XX云的北京机房光缆挖断导致北京区域无法服务,我想请问腾讯云的黄先生,你们云厂商一天到晚讲的服务冗余、异地多活是不是都是停留在PPT上的?
当时我是这样回答的:
服务冗余、异地容灾是我们互联网公司在建设海量服务的时候培养出来的高可用架构能力,当然不是停留在PPT上的。但是我们云厂商对外提供的服务不管有多少个9的可用性,都不可能是100%可用的,友商会遇到的问题我们也不能确保一定不会发生在我们身上。所以我们云厂商提供给用户的真正有价值的服务并不是一个一定不会出问题的服务,而是让我们可以低成本快速的搭建一个服务冗余、异地容灾的架构的能力。所以我们使用云服务的时候一定要正确的架构好自己的系统,让他有冗余、有弹性、遇到问题能够自我恢复。
前几天听逻辑思维讲到孙子兵法,有一句话我觉得从另个一角度很好的诠释了这个意思:不可胜在己,可胜在敌。一个系统真正的健壮性在于使用者正确的使用云提供的能力做出健壮的架构。。
具体到这几次“水逆”的问题,我们在系统架构之初能够做出什么好的设计来规避呢?简单来讲,架构系统的时候要秉承“面向失败做设计”的理念,尽量不假设有哪个服务是永远不会出问题的。
这样假如广州三区服务中断了,负载均衡可以即刻识别出来服务器离线并且吧流量全部分配给广州二区,同时广州二区的服务器压力增加也可以通过弹性伸缩服务自动触发服务器扩容,这样在管理员还没来得及反应过来的时候故障就已经自动处理完了。
因为们不能提前知道负载均衡是否也在出问题的区域,所以还要在每个可用区里面部署相互冗余的负载均衡。如果服务依赖了云数据库,那就需要在两个区做主从设计和主从切换逻辑。
(这样做用户的体验其实会受到部分影响的,因为域名被解析到两个负载均衡以后,有一半的用户会被指向已经不能访问的负载均衡,过了一小段时间客户端发现当前IP不能连接的时候才自动切换到备用的IP上恢复服务。如果能够自己做一点儿开发,用拨测触发dns解析自动变更的话就更好)
有可能政治不正确的感慨几句,个人感觉现在国内的云厂商迫于竞争局势,大家都不怎么主动给中小用户讲面向云的容灾架构的重要性,而是反复的给用户强调自己的服务的可靠性,好像一教用户容灾就是对自己的服务一点儿信心都没有似的,而用户因此对于安全的理解也就都误解为云厂商会提供100%的可用性。所以每次出问题都是,云不能确保完全的可用性,而用户又不能对自己放在云上的服务做好充分的自我保护,其实大家都有问题。不过“100%可用性“对于云是不可能达成的目标,而在云时代,架构师在云上对自己的系统做一个健壮的设计,其实是更加容易和便宜的事情。
码了这么多字,最后刷脸夹带一点儿正能量的私货,Stone虽然没有接受过打赏,但是万一你看完想赏两个银子,我有一个正能量的好朋友现在正需要帮助,她是stone所负责的扶贫项目的一个志愿者,我觉得一个一直在帮助别的人,应该比起其他很多人更加值得我们去帮助。请扫描下面的二维码支持(筹款3天后结束)。
(本文授权无偿完整转载)
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。