B 站崩，小红书崩，罪魁祸首竟然是。。难绷！

752 0 0

文章摘要

今天上午10点至11点左右，B站和小红书等多个平台出现了不同程度的故障。用户反馈显示，B站在崩溃时无法刷新内容和评论区，用户主页、消息界面和客服页面均不可用，具体表现为访问某些页面时出现-500错误码，评论区列表一直显示为“加载中”。这种情况表明，B站的大部分功能都受到了影响。

通常，像B站这样的大型平台会使用微服务架构独立部署各个模块，但此次故障涉及多个功能，推测可能是公共服务或底层基础设施出现了问题。公共服务如用户服务，几乎所有面向用户的模块都会调用到用户服务来获取用户信息，因此一旦公共服务出现问题，多个功能都会受到影响。

不仅是B站，小红书、酷安网、恋与深空等平台也在同一时间出现了故障。根据网上的信息，真正的原因是阿里云的网络访问服务出现了问题。阿里云监控发现上海地域可用区N网络访问异常，随后阿里云迅速完成了网络切流调度，恢复了上海可用区N的网络，受影响的系统也逐渐恢复正常。

可用区是指在同一地域内，电力和网络互相独立的物理区域。B站和小红书的总部都在上海，因此选择了阿里云的上海可用区来提高网络访问速度。然而，阿里云的网络故障导致了这些平台的崩溃。网络访问异常的后果类似于家庭网络中断，依赖网络传输数据的平台一旦网络中断，各种依赖该网络的API和服务调用都会故障，导致无法获取展示给用户的数据。

尽管阿里云通过划分可用区和网络切流调度来提高故障处理效率，但网络故障仍然无法完全避免。大厂工程师通常会采用服务降级策略来应对此类问题。B站在故障期间提供了一个加载出错的页面，引导用户稍后再试，而小红书则使用了缓存作为降级策略，无法通过网络获取到用户推荐的信息流时，从分布式缓存或服务器本地缓存中获取一些默认内容。

防御性编程是应对第三方服务故障的一种策略，即假设第三方系统一定会出现故障，并提前做好应对准备。对于B站这样的公司，可以通过跨可用区部署、多云部署或异地多活等策略来提高服务的可用性和容灾能力。尽管这些策略可能会增加成本，但可以有效减少单点故障的影响。

此次故障事件展示了大厂工程师应对网络故障的解决方案和策略，尽管无法完全避免故障，但通过合理的架构设计和应对策略，可以最大限度地减少故障对用户的影响。相信不久后，相关平台会发布事故复盘报告，进一步解释此次故障的具体原因和解决措施。