昨天 B站又血崩了？！

b站怎么不能投屏了

6月12日17左右，哔哩哔哩（B站）服务器突发大范围异常情况，众多用户反映无法正常使用App及网页端服务，"#B站崩了#"话题迅速冲上微博热搜榜，持续登顶数小时。

据多位网友反馈，故障主要表现为视频无法加载、页面打开缓慢或白屏、图片加载失败等问题。有用户表示："打开B站后一直转圈圈，什么都看不了"，"首页能打开但是视频播放不了"。不过，也有部分用户表示自己的App使用正常，显示出此次故障可能存在地域差异。（你是不是也怀疑自己断网了）

故障现象

视频无法加载

评论区无法加载

部分博主的个人主页打不开

引用B站大佬：鱼皮的故障猜测分析

虽然不是内部人员，但是从专业技术人员的角度，也说说我对这次事故的分析和看法。

首先，这次的事故算是血崩，高低是个 P0 级事故。对于 B 站这样的大型系统，背后起码有成千上万个服务器对吧？肯定用了微服务架构，把大系统拆分成不同的服务，有的服务专门负责播放视频，有的专门处理评论，有的跑推荐算法。能够同时影响到这些服务的，到底是何方神圣呢？

没错，就是 Service Discovery 服务发现系统，听起来很高大上，但其实很好理解。

它就像是一个存储了海量地址信息的导航系统，当用户执行了 B 站的某个操作，比如点击一个视频的时候，其实是向网关服务器发了一个请求，然后网关它要知道把这个请求交给哪个服务器去处理，就需要找到 Discovery 导航系统，获取到服务器的地址信息，然后就可以把请求转发给这台服务器去处理了。

那为什么 Discovery 一崩，整个 B 站就跟着崩了呢？这就是微服务架构的一个特点 —— 高度依赖服务发现。打个比方，如果 B 站是一个超大型商场，Discovery 就是商场里的导购台和所有的指示牌系统。

想象一下，如果商场里所有的指示牌突然全部黑屏了，导购台的工作人员也被降本增效了，会发生什么？顾客找不到电影院在哪里，找不到餐厅，找不到卫生间，甚至找不到出口！

然后我们再看看那个 504 错误 Gateway Time-out。作为程序员看到这个错误，DNA 动了，我第一反应就是："这是网关层面的问题！"

504 错误是什么呢？就是负责接受和转发请求的网关服务器，在等待后端服务响应的时候超时了。用人话说，就像你给朋友打电话，电话是通了，但是朋友在那边一直不说话，你等啊等，最后实在等不下去了，就挂掉了。

这就更证实了我刚才的分析啊，请求能到达 B 站的大门口，但是门口的接待员找不到或者联系不上里面具体负责的部门来处理请求，等来等去就超时了。

还有一个很有意思的点，据说这次只有 10% 左右的请求失败。这个数据其实挺有信息量的！为什么不是 100% 都挂了呢？

这说明几个问题：第一，B 站肯定部署了多个 Discovery 服务实例，专业术语叫 集群部署。就像商场不会只有一个导购台，而是有好几个，其中一部分坏了，其他的还能用。第二，可能有一些 容错机制 在起作用，比如缓存机制，没办法从服务器获取到最新的信息，咱就退而求其次，直接把之前加载过临时存在服务器内的数据返回给用户，这就是为什么有些朋友看到的推荐内容是乱七八糟的。

第三，可能有 降级策略，就是当主要的 Discovery 服务不可用时，会启用备用的服务发现机制。

最后一个现象也很有意思，就是直播没有中断，但是弹幕会时不时丢失。这就体现了微服务架构的特点 —— 不同的业务域是相对独立的。

直播服务和弹幕服务虽然都是B站的功能，但是它们在技术架构上可能属于不同的服务集群。直播服务可能有自己独立的服务发现机制，或者它使用的 Discovery 集群比较稳定；而弹幕服务可能更依赖于出故障的那个 Discovery组件。

写在最后

同为运维人员，看到这个故障还是挺让人难受的，假如我是这个负责发布的运维话，晚上肯定是一个不眠之夜。奔溃修复之后又要写故障报告、预估损失、影响面等。还得对事故顶级和复盘。最后可能还得准备简历。。。

最后，祝愿天下运维服务器永不蛋机！！！