B 站崩了,受害程序员聊聊
非吃瓜,B 站事件始末分析 + 防治技术分享
大家好,我是鱼皮,昨天小破站崩了的事情相信很多朋友都听说了。
这要是搁以前,不爱吃瓜的我根本不会去关注这种事,崩了就崩了呗,反正天塌下来有程序员大佬们扛着,很快就会好的。
但这次不太一样,因为我自己也成为了本事件的 “受害者” !
后来我才发现,弹幕区连进房提示都没了,总不可能几分钟没人进来吧?肯定是出事了!
我以为是弹幕卡了,于是就关闭弹幕再打开,结果还是一样。然后我就想着重启下直播,结果关掉之后再也打不开了,屏幕上直接提示:似乎已断开和服务器的链接。
然后是 502 错误网关:
原因猜测
昨晚剪视频到凌晨 2 点多,本来想直接睡觉,但手贱又打开了知乎,发现 “B 站崩了” 是 Top 1 热门的问题,出于好奇就点进去想了解下事故背后的真正原因,看看大家的高见。
本来我一个非 B 站工作的外来人,对它的技术架构没有深入了解;再加上缺少关键信息、没有可靠的推测凭据,所以不准备发表意见的。结果发现前排没有几个程序员在从技术的角度推测事故原因,都是一些帮大家吃瓜更香的小回答。那我不妨根据过往学到的架构知识,做一波推测,万一推中了感觉也挺惊喜的。
其实在 20 年的时候,B 站技术总监毛剑老师就在腾讯云 + 社区分享过《B 站高可用架构实践》讲座,当时我全程看完了,但没想到,有一天,高可用的 B 站不可用了。
所以在这次分析前,我先把《B 站高可用架构实践》文章又读了一遍,有趣的是,短短半天,这篇文章的阅读量涨了 15 万!
不过我觉得没必要,因为毛剑老师分享的技术确实是很实用的高可用解决方案,只不过还是缺少了一些印证吧。
文章地址:https://cloud.tencent.com/developer/article/1618923
下面说下我的猜测。
猜测 1:网关挂了
首先,这次小破站事故发生时,其他站点竟然也崩了!比如 A 站、晋江、豆瓣,统统都上了热搜。
一旦 CDN 挂了,该地区用户的流量会全部打到网关上:
此外,网关通常还承担起了保护服务弟弟们的使命,统一负载均衡、控制流量、熔断降级等。
按道理来讲,通常网关不仅要保护下游的服务,自身也是需要安全保护的。但为什么网关没有保护好自己呢?
我的猜测是:网关还没有来的及开启保护措施(自身的熔断降级等),就被流量瞬狙了。
网关一挂,服务没爹,服务缺少了调用入口,自然就不可用了,未必所有网关后的服务都处于瘫痪状态。
猜测 2:服务雪崩
还有一种猜测是 B 站系统存在很多服务的 调用链 。由于 CDN 或者部分机器挂掉,导致某个下游服务 A 的执行耗时增加,从而导致上游调用服务 A 的服务 B 执行耗时也增加,让系统单位时间的处理能力变差。再加上上游不断积压请求,最终导致整个调用链雪崩,所有链上服务从儿子到爸爸全部灭门。
为什么其他两家很快就恢复了,B 站却花了几个小时才恢复正常呢?
感觉多少和 B 站自研组件有关系,一方面受到云服务商的影响,导致下游的服务连锁挂掉了,故障面积大 ;另一方面重启也需要时间,而且重启过程中,上游的负载均衡也未必能承受住流量高峰,所以想要恢复到正常水平,至少要等待很多容器副本完全重启。
另外昨天 23 点半左右,我打开 B 站时,看到的内容是几个小时前的老数据,说明这个时候 B 站已经重启了部分服务副本,并且开启了降级措施,并没有查询真实数据。
没想到自己的这个回答还在知乎小火了一把,第一次成为了 千万浏览量 问题的 Top 2,受宠若惊,受宠若惊。。。
暂时想到这么多,当然还有其他的技术。
时间有限,就先不对这些技术展开去讲了。关于如何减少系统出现的 Bug、保证服务高可用,欢迎大家阅读我的历史文章:揭秘软件开发的达摩克利斯之剑,以上很多技术也都有讲解。
收获感悟
关于这次事故,我作为受害者之一,也有一些收获和感悟,而不是吃瓜吃了个寂寞。
首先是要有 质疑精神 ,我们在写程序出现问题时,习惯性地先从自己身上找原因没有任何问题,但自己排查没有发现 Bug 后,应该大胆推测是我们用到的类库、组件、或者依赖服务、甚至有可能是编辑器出了问题,而不是认为知名的东西一定正确。像小破站出了问题后,我竟然怀疑是自己的直播被封了哈哈,差点想找到管理去跪了。
在编程方面,我们不能只去背知识、听别人讲,做 八股文架构师;而是要做实践经验丰富的工程师,不盲目相信、不想当然,而是在实践中积累经验、结合实际去优化系统。
最后再送大家一些 帮助我拿到大厂 offer 的学习资料:
我是如何从零开始通过自学,拿到腾讯、字节等大厂 offer 的,可以看这篇文章,不再迷茫!
我是鱼皮,点赞 还是要求一下的,祝大家都能心想事成、发大财、行大运。
本文文字及图片出自 InfoQ
你也许感兴趣的:
- 【外评】电脑从哪里获取时间?
- 【外评】为什么 Stack Overflow 正在消失?
- Android 全力押注 Rust,Linux 却在原地踏步?谷歌:用 Rust 重写固件太简单了!
- 【外评】哪些开源项目被广泛使用,但仅由少数人维护?
- 【外评】好的重构与不好的重构
- C 语言老将从中作梗,Rust for Linux 项目内讧升级!核心维护者愤然离职:不受尊重、热情被消耗光
- 【外评】代码审查反模式
- 我受够了维护 AI 生成的代码
- 【外评】Linux 桌面市场份额升至 4.45
- 【外评】作为全栈开发人员如何跟上 AI/ML 的发展?
你对本文的反应是: