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出问题还好，如果物理机还出问题了，那数据恢复可能就慢了，我自己之前做大数据的，我知道数据备份都是增量+全量，恢复的时候真的好了一部分还可以从其他地区节点拉，但是如果是放在一个地方了，那就麻烦了。
部分内容转载自知乎：敖丙
热门跟贴