2025.06.12 B站崩了，根因及恢复过程猜想

影响范围和故障时间

影响范围：大面积崩盘。

影响时长：17点左右开始，21-22点左右恢复，4个小时左右。

根因猜想

大面积的崩盘， 肯定是基建发生了问题， 基础不牢，地动山摇。

据内部人员小道消息：服务发现/注册中心 发生了故障。

什么是注册中心

注册中心是服务实例信息的存储仓库，也是服务提供者和服务消费者进行交互的桥梁。它主要提供了服务注册和服务发现这两大核心功能。

简单理解，在微服务中，他是交通枢纽和指挥官。

常见的注册中心有：Zookeeper、Eureka、Nacos、Consul、ETCD

4 小时尝试恢复过程猜想

发生故障可能的原因：

• • 单服务的实例数过多 or 总订阅量过多 达到集群承载能力上限 【容量上限没有预估好】
• • 管理员误操作 or 物理机硬件异常(离散度不够) or 故障演练

故障处理过程

1）重启的时候采取的一次一个节点（防止节点上保留的实例数据丢失）

滚动重启后，负载没降下来

2）滚动升配， 再次尝试降低负载

负载有缓解，但还是比较高

3）尝试扩容

负载不均衡

4）尝试删除集群临时文件（raft、实例目录）

全部重新分配

5）并发过高导致机器承载不住， 那就降级，分两步， 一，关闭服务推送，使其用本地缓存；二， 防火墙上 drop 掉一些非核心应用的连接

# 先允许集群之间端口的访问，然后限制其他服务的端口访问
iptables -A INPUT -p tcp --dport $port -s  $CIDR1 -j DROP
iptables -A INPUT -p tcp --dport $port -s  $CIDR2 -j DROP

6）等集群负载下来后， 服务在逐步放开

Todo

• • 预案完善
• • 集群进行压测，进行容量评估
• • 识别性能瓶颈，进行调优，如配置参数，升级开源组件版本， 定制化开发 增量推送，支持全局动态降级等
• • 考虑更优的集群方案，能力不足时，是否考虑拆成多个小集群，最小链路形成一个小集群。降低爆炸半径。