当前位置: 首页 > 科技观察

哔哩哔哩崩塌上热搜,高可用呢?

时间:2023-03-14 22:41:12 科技观察

图片来自抱途网崩了!累了一整天的年轻人,准备躺下拿出手机,打开熟悉的小破站APP,一键链接到自己喜欢的up主的最新视频。突然发现:瞬间,“哔哩哔哩崩盘”的消息登上热搜,微博运维紧张。有网友表示:A站、豆瓣等网站也出现访问失败,重连Wi-Fi也没用。今天凌晨,B站发布公告称,昨晚,B站部分机房出现故障,导致无法访问。技术团队第一时间排查修复问题,目前服务已逐渐恢复正常。“小破站”怎么了?这种模棱两可的说法,显然挡不住吃瓜群众的热情。短短几分钟,关于哔哩哔哩的各种猜测和新闻变成了上百个论坛:有火灾,有删库跑路,有刑事案件,有服务器供应商,有黑客,有楼塌,有外星人等等。.还有人在B站运营小姐姐的朋友圈里大Po,说B站停电了……紧接着,有专业人士指出:作为一家上市的互联网公司,B站B有多个服务器备份。最起码,楼里停电的解释只能用来蒙骗没学过数据库的高中生。至于为什么A站和晋江文学网宕机,估计是因为B站宕机,大量用户没啥可看的,就涌入A站和豆瓣,导致网站流量激增,即使A站和B站不共享云端。服务也可能不堪重负。B站超7000万日活跃网友的威力可见一斑。来看几个比较靠谱的猜测:①知乎作者@黄菲纯瞎猜,应该是etcd挂了。一般来说,它会导致几乎所有的请求都是502,或者前后端之间的网络路径完全宕机,或者后端服务全部宕机。那么现在大型互联网公司的基础设施是怎样的呢?他们中的大多数使用Kubernetes在全国的数据中心实现容器编排和网络虚拟化。在Kubernetes的设计中,网络插件和pod编排是相对独立的。如果只是网络插件的问题,那么网络插件在部分服务器上的缓存还在,部分用户肯定还是可以正常使用的。现在一切都宕机了,只能是etcd宕机了,导致反向代理无法通过etcd找到对应pod的虚拟ip,无法通过网络插件与对应pod通信。②知乎作者@k8seasy认为,这基本上是网站本身的问题。从大约30分钟的恢复时间,几乎100%的恢复情况来看,应该是某个核心组件挂掉了,导致核心服务不可用。有很多这样的可能性。最有可能的原因是推出了新版本。一开始还好,升级了一些集群。结果新版本有bug,到某个时候直接挂了。老版本没有承受压力。居住。然后紧急定位回滚解决。也有网友指出,此次事件与云服务商密不可分:云服务商提供的CDN出事后,大量请求绕过CDN,直接打到网关。网关收到大量请求,自动启动容灾策略。灾难恢复策略启动服务降级。服务降级但没有完全降级,CDN宕机,网关也宕机,服务雪崩,崩塌到整个环境。盘点史上严重服务宕机事件:最高损失数亿美元玩宕机。7小时无法访问微信:2013年7月22日,微信服务宕机,造成近7小时网络中断。据微信官方消息,由于上海某施工队挖通通信光缆,导致腾讯华东数据处理中心的业务请求分流至华南、华北地区,导致业务全面瘫痪。与支付宝“剁手”失败:2015年5月27日下午,部分用户反映支付宝网络出现故障,无法登录或支付。支付宝相关负责人表示,故障原因是杭州市萧山区某处光纤被剪断。该事件导致部分用户无法使用支付宝。随后支付宝工程师紧急将用户请求切换到其他机房,受影响的用户开始逐渐恢复。晚上7点20分,支付宝宣布用户服务全面恢复正常。在国外,网络宕机事件屡见不鲜。亚马逊云服务罢工:2015年9月,亚马逊云服务器因新上线的DynamoDB功能产生大量数据请求导致过载而崩溃。因此,包括Reddit、Tinder、Netflix和IMDB在内的许多流行应用程序和网站都罢工了几个小时。除Netflix外,绝大多数亚马逊云服务客户在这场“突袭”中被发现措手不及。Netflix此前曾使用一种名为“混沌工程”的技术来模拟类似服务中断事件的发生,将此次事故的影响降到最低。纳斯达克停摆:2013年8月22日,因纳斯达克交易所备份服务器出现严重错误,纳斯达克停摆3个多小时。当它恢复营业时,已经引起了市场的恐慌。大量交易者涌入交易窗口抛售交易所运营商纳斯达克OMX集团的股票,导致OMX集团股价当日下跌超过5%。事后估计,纳斯达克停摆造成的经济损失可能高达数亿美元。全国宕机:2016年10月21日上午,众多美国用户突然发现包括Twitter、CNN、Spotify等大型网站无法登录。这场网络瘫痪从美国东部开始,一路波及到美国东部。整个美国。后来发现原因是服务器遭受了黑客的DDoS攻击。对于B站宕机,开源基础软件公司Zilliz质保团队负责人乔艳良做了更专业客观的分析:目前网站故障主要分为软件服务故障和故障原因由硬件服务引起。软件服务故障一般可以理解为代码逻辑缺陷。增加或更新某个功能引入缺陷导致整个服务中断是很常见的。硬件服务故障一般是一些服务设备损坏导致的服务中断,比如光纤被挖。破碎的。如果要降低宕机风险,就需要提高服务的高可用性。首先在架构上,建议采用云原生架构,实现自动容错机制和故障隔离,以便在服务出现故障时能够快速迁移或回滚。其次,为了防范硬件故障的风险,需要完善的容灾计划。目前对于同城双活或者异地容灾都有比较成熟的方案。国内企业在这方面的投资相对“省钱”。B站的高可用架构请看文章:《月均活跃用户达1.3亿,B站高可用架构实践》哔哩哔哩,一定下次!来源:转载自公众号新智元(ID:AI_era)参考:http://www.zhihu.com/question/472065470