B站崩了,如何防止类似事故的出现?

发表于:2021-7-14 10:33

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:敖丙    来源:掘金

#
B站
分享:
  大家都知道虽然我是一个程序员,但是我非常热爱运动,比如跳舞,这不每天回家睡前我都会在B站舞蹈区学习相关的舞蹈。
  昨天也不例外,我一洗漱完就飞奔坐在电脑前,打开B站舞蹈区准备学习咬人喵,欣小萌、小仙若他们新的舞蹈动作,不得不说老婆们跳的真好,连我这种内向的人也不自觉的跟着扭动了起来。
  正当我准备学下一个动作的时候,我发现怎么404 NOT found了。
  坏了,作为开发的我第一直觉是系统崩了,我甚至怀疑是我网的问题,我发现手机网络正常电脑访问其他网页也正常,我就知道开发要背锅了。
  我刷新了几次,发现还是这样,我就有点同情对应的开发同学了,年终应该没了。(到我写这个文章的时候网站还没恢复)
  作为前程序员的我,就习惯性的去想B站的网站架构组成,以及这次事故复盘下来,可能会出问题的点。(老职业习惯了)
  首先我们可以大致画一下简单的一个网站组成的架构图,我们再去猜想这次问题可能出在什么地方。
  因为熬夜写文章哈,我也没在这种主要靠视频直播的公司呆过,技术栈也不是很了解,所以就用电商的大概逻辑,画了一个草图,大家轻点喷。
  从上到下,从入口到cdn内容分发,到前端服务器,后端服务器,分布式存储,大数据分析,风控到搜索引擎推荐这我就随便画了一下,我想整体架构应该不会差异特别大。
  我去网上随便查了一些类似斗鱼,B站,a站这样的公司,主要技术栈和技术难点主要有:
  视频访问存储
  · 流
  · 就近节点
  · 视频编解码
  · 断点续传(跟我们写的io例子差多)
  · 数据库系统&文件系统隔离
  并发访问
  · 流媒体服务器(各大厂商都有,带宽成本较大)
  · 数据集群,分布式存储、缓存
  · CDN内容分发
  · 负载均衡
  · 搜索引擎(分片)
  弹幕系统
  · 并发、线程
  · kafka
  · nio框架(netty)
  其实跟我们大家学的技术都差不多,不过他们的对应微服务的语言组成可能go、php、vue、node占比比较大。
  我们分析下这次事故可能出事的原因和地方:
  1.删库跑路
  之前微盟发生过这个事情,我觉得各个公司应该都不会把运维的权限给这么大了,比如主机权限直接禁止了rm-rf、fdisk、drop这样的命令。
  而且数据库现在大概率都是多主多从,多地备份的,容灾也应该是做的很好的,而且光是数据库炸了,那cdn的很多静态资源应该也不会加载不出,整个页面直接404了。
  2.单微服务挂掉拖垮大集群
  现在都是前后端分离的,如果是后端挂了,前端很多东西依然是能加载只是数据出不来报错,所以集群要挂也可能是前端挂了,或者前后端一起挂了,但是还是那个问题,现在看起来是所有静态资源都无法访问了。
  不过这个点我觉得也有一点可能,因为部分服务挂了,导致大量报错,拉挂了集群,而且越是这样大家越会不断刷新页面,给其他服务重启增加难度,但是这个可能性没我最后说的可能性大。
  3.服务器厂商出问题了
  这种大网站都是cdn+slb+站集群,各种限流降级、负载均衡按道理都会做的很好,而且他们按道理不会不做容灾。
  所以只有可能是这些前置服务的服务器厂商出问题了,CDN如果挂了那网关负载均衡啥的压力都大了,最后导致连锁的雪崩效应打挂了整套系统。
  但是我比较疑惑的是B站的BFF应该会路由到一些接入节点比较进的机房,这样全国各地的小伙伴刷的时候,应该是有些人好,有些人坏,有些人时好时坏才对,但是现在看来是全坏了,难道他们押宝了一个厂商的一个节点片区?
  我看网上也在传云海数据中心起火了,不知道真假,只能等醒来看看B站官宣了,B站原则上,理论上,从CDN、分布式存储、大数据、搜索引擎都应该做了很多保证措施才对,如果真all in了一个地方那确实不太明智。
  我的感觉就是没做好全部上云,线下的服务器出了问题,刚好是没上云的是关键业务,现在公司都是公有云+私有云这样的混合云搭配用的,但是私有云部分都是B站自己的内部业务,所以应该不会他自己的机房出问题。
  如果真像我说的,押宝了一个服务器厂商,只是cdn出问题还好,如果物理机还出问题了,那数据恢复可能就慢了,我自己之前做大数据的,我知道数据备份都是增量+全量,恢复的时候真的好了一部分还可以从其他地区节点拉,但是如果是放在一个地方了,那就麻烦了。
  复盘
  我想不管最后是什么原因造成的,我们技术人和公司应该思考的就是怎么去避免这样事情的发生。
  数据备份:备份一定要做,不然如果真发生什么自然灾害,那是很难受的,所以很多云厂商现在都选在贵州我老家这样自然灾害比较少的地方、或者湖底、海底(比较凉快成本能下去不少)。
  全量、增量基本上都是一直要做的,分天、周、月不断的增量数据,以及按时的全量数据备份,这样可以让损失降低很多,就怕所有地区的机械盘都坏了(异地容灾除了地球毁灭不然都能找回来)。
  运维权限收敛,还是怕删库跑路,反正我是经常在服务器上rm-rf,不过一般有跳板机才能进去的都可以做命令禁止。
  上云+云原生:云产品的各种能力现在很成熟的,企业应该对对应的云厂商有足够的信任,当然也得选对才行,云产品的各种能力是其一,还有关键时刻的容灾、应急响应机制都是很多公司不具备的。
  云原生是近些年才大家才重视的技术,docker+k8s这对应的一些组合,加上云计算的各种能力,其实可以做到无人值守,动态缩扩容,以及上面说的应急响应,但是技术本身是需要一些尝试成本的,而且我也不知道B站这样视频为主的体系,适不适合。
  kubernetes的设计上也会存在一些编排、通信的问题。
  自身实力打造:其实我觉得不管是上云,还是不上云,都不能太依赖很多云厂商,自己的核心技术体系和应急机制还是要有,如果云厂商真的靠不住怎么办?怎么去做真正的高可用,这我觉得是企业技术人员需要去思考的。
  举个例子,很多云厂商都是一个物理机隔成多个虚拟机售卖,然后就会存在单物理机多宿主的情况,假如其中一方是电商玩双十一,一方是游戏厂商,对方大量占用网络带宽,你就可能存在丢包的情况,这对游戏用户来说是体验极差的,这样就是我说为啥不要过于信任和依赖云厂商的原因。
  对方万一买了去挖矿,那更过分,把算力榨干,满负荷跑更难受。
  B站这次,好在这样的问题提前暴露了,而且是晚上,应该有不少流量低谷的时间去恢复,我写到这里的时候,网页大部分恢复了,但是我发现还是部分恢复。
  不管怎么说下次就可以完全杜绝了,相信B站后面很长一段时间都会忙于架构体系改造,去保证自己真正的高可用。
  希望以后能让我稳定的在晚上看看舞蹈区,而不是盯着502、404的2233娘发呆,嘻嘻。

  本文内容不用于商业目的,如涉及知识产权问题,请权利人联系51Testing小编(021-64471599-8017),我们将立即处理
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号