前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >就算云厂商水逆了,服务也不能倒

就算云厂商水逆了,服务也不能倒

原创
作者头像
黄希彤
修改2018-08-08 11:49:32
4.3K5
修改2018-08-08 11:49:32
举报
文章被收录于专栏:黄希彤的专栏

这阵子接连发生极小概率事件:先是几条光缆同时被挖断导致一个服务区失联、然后又是一个硬盘出现罕见的静默错误(写入数据和读取出来的不一致)后居然被选中为主数据源导致故障意外放大以至于导致客户数据丢失。用星座小王子的话讲,这是腾讯云水逆了吧?

俗话说了,皮之不存毛将焉附,云厂商出问题了是不是在云上的服务就都要跟着嗝屁了呢?但是俗话也不是说了,不要吊死在一颗树上?这几次的事情让我想起2016年的云+未来峰会上,我在下午的开发者专场的圆桌论坛中回答观众问题的时候,现场有一个观众站起来问:

我们都知道今天早上XX云的北京机房光缆挖断导致北京区域无法服务,我想请问腾讯云的黄先生,你们云厂商一天到晚讲的服务冗余、异地多活是不是都是停留在PPT上的

当时我是这样回答的:

服务冗余、异地容灾是我们互联网公司在建设海量服务的时候培养出来的高可用架构能力,当然不是停留在PPT上的。但是我们云厂商对外提供的服务不管有多少个9的可用性,都不可能是100%可用的,友商会遇到的问题我们也不能确保一定不会发生在我们身上。所以我们云厂商提供给用户的真正有价值的服务并不是一个一定不会出问题的服务,而是让我们可以低成本快速的搭建一个服务冗余、异地容灾的架构的能力。所以我们使用云服务的时候一定要正确的架构好自己的系统,让他有冗余、有弹性、遇到问题能够自我恢复。

前几天听逻辑思维讲到孙子兵法,有一句话我觉得从另个一角度很好的诠释了这个意思:不可胜在己,可胜在敌。一个系统真正的健壮性在于使用者正确的使用云提供的能力做出健壮的架构。。

具体到这几次“水逆”的问题,我们在系统架构之初能够做出什么好的设计来规避呢?简单来讲,架构系统的时候要秉承“面向失败做设计”的理念,尽量不假设有哪个服务是永远不会出问题的。

  • 假如我们担心一个服务区的光缆被挖断了影响服务,我们可以在一个地区的两个以上的服务区里面部署我们的服务器,比如在广州二区广州三区各放一批服务器。对外通过负载均衡来提供服务的时候,负载均衡是可以把服务分配到一个地区的不同服务区里面的,跨域增加的时延通常也只有几个毫秒,通常对服务没有什么影响。

这样假如广州三区服务中断了,负载均衡可以即刻识别出来服务器离线并且吧流量全部分配给广州二区,同时广州二区的服务器压力增加也可以通过弹性伸缩服务自动触发服务器扩容,这样在管理员还没来得及反应过来的时候故障就已经自动处理完了。

因为们不能提前知道负载均衡是否也在出问题的区域,所以还要在每个可用区里面部署相互冗余的负载均衡。如果服务依赖了云数据库,那就需要在两个区做主从设计和主从切换逻辑。

(这样做用户的体验其实会受到部分影响的,因为域名被解析到两个负载均衡以后,有一半的用户会被指向已经不能访问的负载均衡,过了一小段时间客户端发现当前IP不能连接的时候才自动切换到备用的IP上恢复服务。如果能够自己做一点儿开发,用拨测触发dns解析自动变更的话就更好)

  • 假如我们担心整个广州所有可用区都被核弹团灭了(嗯我们不能排除突然打核战可能性,所以云厂商就算未来也没办法承诺100%的可用性),那就要把服务分布到两个以上的城市,比如北京和上海。因为跨城市的访问要通过公网,服务区之间就不能像一个局域网一样的通信了,CAP问题变得突出。这个时候架构上有更多的文章可以做了,是一个主服务区一个备用服务区,有问题再切换,还是每个地区都提供服务,然后放弃短时间的数据一致性,只达成最终数据一致性,不同的架构师对不同的系统会有自己的选择。
  • 假如我们担心硬盘数据突然坏掉了(像这次的极低概率事件)、系统有bug数据被写坏了 、系统有安全漏洞被黑客清空了数据。那我们就需要做好一个数据备份回滚的机制。比如在腾讯云上,我更加推荐使用云硬盘而不是本地硬盘来做系统盘和数据盘,除了可靠性更高之外和容许系统在未来调整配置之外,很重要的一点是,云硬盘支持定期的自动快照(https://cloud.tencent.com/document/product/362/8191 目前7个以内的快照是免费服务,业界唯一)这样出问题的时候回滚系统恢复数据就非常轻松了。

有可能政治不正确的感慨几句,个人感觉现在国内的云厂商迫于竞争局势,大家都不怎么主动给中小用户讲面向云的容灾架构的重要性,而是反复的给用户强调自己的服务的可靠性,好像一教用户容灾就是对自己的服务一点儿信心都没有似的,而用户因此对于安全的理解也就都误解为云厂商会提供100%的可用性。所以每次出问题都是,云不能确保完全的可用性,而用户又不能对自己放在云上的服务做好充分的自我保护,其实大家都有问题。不过“100%可用性“对于云是不可能达成的目标,而在云时代,架构师在云上对自己的系统做一个健壮的设计,其实是更加容易和便宜的事情

码了这么多字,最后刷脸夹带一点儿正能量的私货,Stone虽然没有接受过打赏,但是万一你看完想赏两个银子,我有一个正能量的好朋友现在正需要帮助,她是stone所负责的扶贫项目的一个志愿者,我觉得一个一直在帮助别的人,应该比起其他很多人更加值得我们去帮助。请扫描下面的二维码支持(筹款3天后结束)。

如果想打赏请微信扫描
如果想打赏请微信扫描

(本文授权无偿完整转载)

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
负载均衡
负载均衡(Cloud Load Balancer,CLB)提供安全快捷的流量分发服务,访问流量经由 CLB 可以自动分配到云中的多台后端服务器上,扩展系统的服务能力并消除单点故障。负载均衡支持亿级连接和千万级并发,可轻松应对大流量访问,满足业务需求。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档