B站、小红书崩了？罪魁祸首竟然是...

今天上午10点到11点左右，B站和小红书相继崩溃，让不少用户瞬间“崩溃”。用户反馈称，B站在崩溃期间无法刷新内容和评论区，无法发送评论和弹幕，甚至用户主页、消息界面和客服页面也不可用。用户访问某些页面时会看到-500错误码，评论区一直显示“加载中”等问题，简直是“大半个B站都崩了”的感觉。

这种情况不禁让人疑惑，像B站这种大用户量、大规模的平台，通常会使用微服务架构独立部署各个模块，怎么会这么多功能一起崩掉呢？推测可能是公共服务或者底层基础设施出了问题。比如用户服务，几乎所有面向用户的模块都会调用用户服务来获取用户信息，如果用户服务出问题，自然会影响到很多功能。

然而，这次不仅仅是B站，小红书、酷安网、恋与深空等多个平台也同时崩掉，显然问题不仅在于B站自身。根据网上信息，真正的罪魁祸首是阿里云的网络访问服务出现了问题。

阿里云网络访问服务问题

2024年7月2日10:04，也就是B站崩掉的时间，阿里云监控发现上海地域可用区N网络访问异常。

很快，阿里云完成了网络切流调度，上海可用区N的网络恢复正常，受影响的系统也逐渐恢复。

什么是可用区N网络？

可用区是指在同一地域内，电力和网络互相独立的物理区域。例如，华北2（北京）地域支持12个可用区，包括北京可用区A和北京可用区B。同一可用区内实例之间的网络延时更小，用户访问速度更快。B站和小红书的总部都在上海，选择阿里云的上海可用区来提高网络访问速度是很合理的选择。

网络访问异常的影响

网络访问异常的后果我们都经历过，比如家里网络中断时无法访问网站。同样地，依赖网络传输数据的B站，一旦网络中断，各种依赖该网络的API和服务调用都会故障，导致无法获取展示给用户的数据。

即使是阿里云这样的服务商，网络故障也无法完全避免。可能是气象原因，或是某个不法分子把网线铲断了，都会导致网络故障。不过，阿里云通过划分可用区，至少能保证故障不会影响到多个地域，而且通过网络切流调度，快速将系统切换到另一个可用网络，解决速度也算高效。

大厂工程师的应对方案

通过这次故障，我们可以看到大厂工程师如何应对此类问题。B站和小红书都采用了服务降级的策略。

B站的服务降级策略

B站在故障时提供了一个加载出错的页面，引导用户稍后再试。虽然有些页面的降级不够优雅，比如返回错误码和英文报错信息给用户，但基本实现了应对方案。

小红书的服务降级策略

小红书的表现是无法刷新内容，首页显示的不是用户推荐内容，但用户仍然能看到一些内容。小红书可能使用了缓存作为降级策略，比如无法通过网络获取用户推荐信息流时，从分布式缓存或服务器本地缓存中获取一些默认内容。

防御性编程的重要性

这让我想起之前在腾讯时，导师曾说过“不要信任第三方服务”，我们要遵循防御性编程，假设第三方系统一定会出现故障，并提前做好应对策略。

提高系统可用性的建议

虽然本次故障无法完全预料，但对于B站这样的大公司来说，应该还是有应对之法的。比如将服务跨可用区部署，不仅在阿里云的上海可用区，还可以部署在其他可用区，甚至其他云服务提供商。或者采用异地多活，在不同地理位置同时运行同一个服务，提高可用性和容灾能力。

当然，这些策略可能会增加成本，也有可能B站有其他原因不采用这些策略。我们不是内部人士，只能通过有限信息进行推测。相信不久后官方会发布事故复盘报告，届时我们能了解到更多细节。

结语

这次B站和小红书的崩溃事件，让我们看到了大型平台在面对突发故障时的应对策略和解决方案。希望通过这次事件，大家能对网络服务和系统容灾有更深的理解。也期待未来能有更多可靠的技术手段来预防和应对类似的突发事件。

---

希望这篇文章能帮你更好地了解B站和小红书崩溃的原因，以及大厂在面对突发故障时的应对之道。