最近小破站崩了的事情相信很多朋友都听说了。
2021年7月13日晚上23:44分，亿级流量的平台崩了🤔
7月13日 “B 站崩了” 事件
- 猜测 1：网关挂了
- 猜测 2：服务雪崩
- 猜测3:自研组件问题
- 防治技术
- 总结:
打开 B 站，先是 404 Not Found 找不到资源：
然后是 502 错误网关：
猜测 1：网关挂了
首先，这次小破站事故发生时，其他站点竟然也崩了！比如 A 站、晋江、豆瓣，统统都上了热搜。
这些事故同时发生，说明是这些系统依赖的公共服务出了问题，而唯一有能力导致大规模服务瘫痪的就是 CDN 了。
CDN 是内容分发网络，提前将源站内容发到各个地区的服务器节点，之后就可以让不同地区的用户就近获取内容，而不是都到源站获取，从而起到内容加速、负载均衡的作用。图片用户就近访问内容一旦 CDN 挂了，该地区用户的流量会全部打到网关上。
CDN 挂了网关就像是家族老大，用户有需求就跟老大说，然后老大再分配需求给弟弟们去完成。图片此外，网关通常还承担起了保护服务弟弟们的使命，统一负载均衡、控制流量、熔断降级等。按道理来讲，通常网关不仅要保护下游的服务，自身也是需要安全保护的。
但为什么网关没有保护好自己呢？
我的猜测是：网关还没有来的及开启保护措施（自身的熔断降级等），就被流量瞬狙了。网关一挂，服务没爹，服务缺少了调用入口，自然就不可用了，未必所有网关后的服务都处于瘫痪状态。
猜测 2：服务雪崩
还有一种猜测是 B 站系统存在很多服务的 调用链 。由于 CDN 或者部分机器挂掉，导致某个下游服务 A 的执行耗时增加，从而导致上游调用服务 A 的服务 B 执行耗时也增加，让系统单位时间的处理能力变差。再加上上游不断积压请求，最终导致整个调用链雪崩，所有链上服务从儿子到爸爸全部灭门。
猜测3:自研组件问题
感觉多少和 B 站自研组件有关系，一方面受到云服务商的影响，导致下游的服务连锁挂掉了，故障面积大 ；另一方面重启也需要时间，而且重启过程中，上游的负载均衡也未必能承受住流量高峰，所以想要恢复到正常水平，至少要等待很多容器副本完全重启。
防治技术
再简单聊一下服务故障的防治技术，就是如何保证服务的高可用性，尽量持续为用户提供服务而不宕机。
我将了解到的技术简单分类，整理成了一张思维导图：
总结:
首先是要有 质疑精神 ，我们在写程序出现问题时，习惯性地先从自己身上找原因没有任何问题，但自己排查没有发现 Bug 后，应该大胆推测是我们用到的类库、组件、或者依赖服务、甚至有可能是编辑器出了问题，而不是认为知名的东西一定正确。
