B 站崩，小红书崩，罪魁祸首竟然是。。难绷！
The following article is from 程序员鱼皮 Author 鱼皮
将 脚本之家 设为“星标⭐”
第一时间收到文章更新
来源 | 程序员鱼皮
今天上午 10 点 ~ 11 点左右，B 站和小红书都崩了，出现了不同程度的故障。
根据用户反馈，B 站崩溃时，无法刷新内容和评论区，也发不了评论和弹幕，而且用户主页、消息界面、客服页面均不可用。具体表现为用户访问某些页面时会看到 -500 错误码，评论区列表一直显示为 “加载中” 等等。
这是什么概念？给我的感觉是，大半个 B 站基本都崩了，就很离谱！
一般情况下，像 B 站这种大用户量、大规模的平台，肯定是使用微服务等架构独立部署各个模块的，但是这次竟然这么多功能一起崩掉了？鱼皮大胆猜测，应该是公共服务或者是底层基础设施出现了问题。
何为公共服务？比如用户服务，几乎所有面向用户的模块都会调用到用户服务来获取用户信息。仔细观察可以发现，B 站崩溃的功能基本都是和用户强相关的。比如用户要发送评论，没有用户信息，怎么能让他发送呢？要看用户主页，获取不到用户信息，看个毛呢？
当然，以上仅仅是我的猜测。这次和 B 站一起崩掉的，还有小红书、酷安网、恋与深空等等，这就意味着事情并没有那么简单，绝对不只是 B 站自己的锅。
根据网上的信息，真正的罪魁祸首果然是基础设施 —— 阿里云的网络访问服务出了问题。
北京时间 2024 年 07 月 02 日 10:04 分，也就是 B 站崩掉的时候，阿里云监控发现上海地域可用区 N 网络访问出现了异常。如图：
不过很快，阿里云就完成了网络切流调度，并且很快恢复了上海可用区 N 的网络，过了一段时间后，崩掉的系统都开始陆续恢复。
解释一下什么是可用区 N 网络。可用区是指在同一地域内，电力和网络互相独立的物理区域。例如，华北2（北京）地域支持 12 个可用区，包括北京可用区 A 和北京可用区 B 等。同一可用区内实例之间的网络延时更小，其用户访问速度更快。
而 B 站和小红书的总部正好都在上海，所以选择了阿里云的上海可用区，提高网络访问速度，这很合理；然后给他们提供服务的阿里云的上海地域的网络出了问题，导致他们崩掉，这再合理不过了。
网络访问异常的后果想必大家都经历过，比如你家里网络中断时，就无法访问网站。而同样的，依赖网络去传输数据的 B 站，一旦网络中断，各种依赖该网络的 API、服务调用都会故障，就导致无法获取到展示给用户的数据。
事实上，哪怕是阿里云，网络故障这类事件也无法完全避免。举个极端的例子，因为一些气象原因、或者有个不法分子把网线铲断了，都可能会导致网络故障。不过阿里云通过划分可用区，起码保证故障不会影响到多个地域。而且通过网络切留调度，快速将系统切换到另一个可用网络，解决速度也还算高效。
通过这次故障，我们能够了解到大厂工程师应对此类问题的解决方案。
B 站和小红书都采用了 服务降级 的策略，比如 B 站的做法是提供一个加载出错的页面，引导用户稍后再试。
虽然有些页面降级的不够优雅，把错误码和英文的报错信息返回给了用户。。
小红书的策略不太一样，故障的表现是无法刷新内容、并且首页刷出来的不是用户的推荐内容：
但用户还是能够看到一些内容的，如图：
小红书应该是使用了缓存作为降级策略，比如无法通过网络获取到用户推荐的信息流，那么就直接从分布式缓存或者服务器本地的缓存中获取一些默认内容即可。
当然，还有一种可能，就是没走缓存，而是改为调用获取公共信息流的服务。举个例子，假如小红书的热门板块没有故障，那么 APP 主页可以获取热门板块的数据，而不用获取故障的推荐信息流。
这让我想起来，之前在腾讯的时候，导师跟我说过 “不要信任第三方服务”。也就是说，我们要遵循防御性编程，假设第三方系统一定会出现故障，并且提前做好应对它的准备。比如使用了 XX 云的数据同步，即使官方承诺说同步不会出现数据丢失，我们也要考虑到数据丢失的可能性，在业务代码中编写应对策略。
虽然本次故障无法预料，但是对于 B 站这样大型的公司来说，我觉得应该还是有应对之法的。比如将服务跨可用区部署，不止将服务部署在阿里云可用区 N 网络，还可以部署在上海的其他可用区；还可以采用多云部署，同时将服务部署在其他云服务提供商，发现阿里云寄了，就自动切换到其他服务商；甚至还可以采用异地多活，在不同地理位置同时运行同一个服务，从而提高可用性和容灾能力。
当然，理论归理论，B 站可能也用到了这些策略，或者有自己不用这些策略的原因（比如成本），由于咱也不是内部人士，只能通过有限的信息随便聊聊，也给大家科普一些开发知识。相信不久后官方就会发布事故复盘报告啦~
END
家人们，小编来给大家安排福利了~