B站崩了?带着A站也一起崩了?
昨天晚上大概10:50分,B站开始出现”页面加载失败,请重试”的画面,不一会,A站也出现“系统繁忙”。
许多人第一时间想到的是自己网或者手机有问题,在经过重连WiFi、重新下载App之类的努力之后,反应快的网友很快意识到一个问题——是不是B站崩了?
到了今天凌晨02:20,B站才发布了第一条正式回应,“昨晚,B站的部分服务器机房发生故障,造成无法访问。技术团队随即进行了问题排查和修复,现在服务已经陆续恢复正常。”
这条回应还是没有公布B站当晚崩掉的原因,之后,知乎上就有大佬开始认真思考B站崩溃可能的真实原因。
有网友参考了一篇去年B站在腾讯云发布的文章,“B站的LB是自研的,还有容灾系统也是自研的”;
所以一种比较靠谱的可能流程是:
首先我们可以大致画一下简单的一个网站组成的架构图,我们再去猜想这次问题可能出在什么地方。
因为熬夜写文章哈,我也没在这种主要靠视频直播的公司呆过,技术栈也不是很了解,所以就用电商的大概逻辑,画了一个草图,大家轻点喷。
从上到下,从入口到cdn内容分发,到前端服务器,后端服务器,分布式存储,大数据分析,风控到搜索引擎推荐这我就随便画了一下,我想整体架构应该不会差异特别大。
我去网上随便查了一些类似斗鱼,B站,a站这样的公司,主要技术栈和技术难点主要有:
视频访问存储
- 流
- 就近节点
- 视频编解码
- 断点续传(跟我们写的io例子差多)
- 数据库系统&文件系统隔离
并发访问
- 流媒体服务器(各大厂商都有,带宽成本较大)
- 数据集群,分布式存储、缓存
- CDN内容分发
- 负载均衡
- 搜索引擎(分片)
弹幕系统
- 并发、线程
- kafka
- nio框架(netty)
其实跟我们大家学的技术都差不多,大部分技术体系差不多,不过语言应该是go为主,前端框架vue,node为主。
我们分析下这次事故可能出事的原因和地方:
1、删库跑路
之前微盟发生过这个事情,我觉得各个公司应该都不会把运维的权限给这么大了,比如主机权限直接禁止了rm-rf、fdisk、drop这样的命令。
而且数据库现在大概率都是多主多从,多地备份的,容灾也应该是做的很好的,而且光是数据库炸了,那cdn的很多静态资源应该也不会加载不出,整个页面直接404了。
2、单微服务挂掉拖垮大集群
现在都是前后端分离的,如果是后端挂了,前端很多东西依然是能加载只是数据出不来报错,所以集群要挂也可能是前端挂了,或者前后端一起挂了,但是还是那个问题,现在看起来是所有静态资源都无法访问了。
不过这个点我觉得也有一点可能,因为部分服务挂了,导致大量报错,拉挂了集群,而且越是这样大家越会不断刷新页面,给其他服务重启增加难度,但是这个可能性没我最后说的可能性大。
3、服务器厂商出问题了
这种大网站都是cdn+slb+站集群,各种限流降级、负载均衡按道理都会做的很好,而且他们按道理不会不做容灾。
所以只有可能是这些前置服务的服务器厂商出问题了,CDN如果挂了那网关负载均衡啥的压力都大了,最后导致连锁的雪崩效应打挂了整套系统。
但是我比较疑惑的是B站的BFF应该会路由到一些接入节点比较进的机房,这样全国各地的小伙伴刷的时候,应该是有些人好,有些人坏,有些人时好时坏才对,但是现在看来是全坏了,难道他们押宝了一个厂商的一个节点片区?
我看网上也在传云海数据中心起火了,不知道真假,只能等醒来看看B站官宣了,B站原则上,理论上,从CDN、分布式存储、大数据、搜索引擎都应该做了很多保证措施才对,如果真all in了一个地方那确实不太明智。
我的感觉就是没做好全部上云,线下的服务器出了问题,刚好是没上云的是关键业务,现在公司都是公有云+私有云这样的混合云搭配用的,但是私有云部分都是B站自己的内部业务,所以应该不会他自己的机房出问题。
如果真像我说的,押宝了一个服务器厂商,只是cdn出问题还好,如果物理机还出问题了,那数据恢复可能就慢了,我自己之前做大数据的,我知道数据备份都是增量+全量,恢复的时候真的好了一部分还可以从其他地区节点拉,但是如果是放在一个地方了,那就麻烦了。
部分内容转载自知乎:敖丙
特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.