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

AIGC动态2周前更新 admin
86 0 0
B 站崩,小红书崩,罪魁祸首竟然是。。难绷!

 

文章摘要


【关 键 词】 故障阿里云服务降级网络异常应对策略

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

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

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

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

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

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

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

豆包-智能助手

原文和模型


【原文链接】 阅读原文 [ 2196字 | 9分钟 ]
【原文作者】 脚本之家
【摘要模型】 gpt-4o
【摘要评分】 ★★★★★

© 版权声明
讯飞星火大模型

相关文章

星火内容运营大师

暂无评论

暂无评论...