共计 2487 个字符，预计需要花费 7 分钟才能阅读完成。
大家都晓得尽管我是一个程序员，然而我十分酷爱静止，比方跳舞，这不每天回家睡前我都会在 B 站舞蹈区学习相干的舞蹈。
昨天也不例外，我一洗漱完就飞奔坐在电脑前，关上 B 站舞蹈区筹备学习咬人喵，欣小萌、小仙若他们新的舞蹈动作，不得不说老婆们跳的真好，连我这种外向的人也不盲目的跟着扭动了起来。
正当我筹备学下一个动作的时候，我发现怎么 404 NOT found 了。
坏了，作为开发的我第一直觉是零碎崩了，我甚至狐疑是我网的问题，我发现手机网络失常电脑拜访其余网页也失常，我就晓得开发要背锅了。
我刷新了几次，发现还是这样，我就有点同情对应的开发同学了，年初应该没了。（到我写这个文章的时候网站还没复原）
作为前程序员的我，就习惯性的去想 B 站的网站架构组成，以及这次事变复盘下来，可能会出问题的点。（老职业习惯了）
首先咱们能够大抵画一下简略的一个网站组成的架构图，咱们再去猜测这次问题可能出在什么中央。
因为熬夜写文章哈，我也没在这种次要靠视频直播的公司呆过，技术栈也不是很理解，所以就用电商的大略逻辑，画了一个草图，大家轻点喷。
从上到下，从入口到 cdn 内容散发，到前端服务器，后端服务器，分布式存储，大数据分析，风控到搜索引擎举荐这我就轻易画了一下，我想整体架构应该不会差别特地大。
我去网上轻易查了一些相似斗鱼，B 站，a 站这样的公司，次要技术栈和技术难点次要有：
视频拜访存储
- 流
- 就近节点
- 视频编解码
- 断点续传（跟咱们写的 io 例子差多）
- 数据库系统 & 文件系统隔离
并发拜访
- 流媒体服务器（各大厂商都有，带宽老本较大）
- 数据集群，分布式存储、缓存
- CDN 内容散发
- 负载平衡
- 搜索引擎（分片）
弹幕零碎
- 并发、线程
- kafka
- nio 框架（netty）
其实跟咱们大家学的技术都差不多，不过他们的对应微服务的语言组成可能 go、php、vue、node 占比比拟大。
咱们剖析下这次事变可能出事的起因和中央：
1. 删库跑路
之前微盟产生过这个事件，我感觉各个公司应该都不会把运维的权限给这么大了，比方主机权限间接禁止了 rm-rf、fdisk、drop 这样的命令。
而且数据库当初大概率都是多主多从，多地备份的，容灾也应该是做的很好的，而且光是数据库炸了，那 cdn 的很多动态资源应该也不会加载不出，整个页面间接 404 了。
2. 单微服务挂掉拖垮大集群
当初都是前后端拆散的，如果是后端挂了，前端很多货色仍然是能加载只是数据出不来报错，所以集群要挂也可能是前端挂了，或者前后端一起挂了，然而还是那个问题，当初看起来是所有动态资源都无法访问了。
不过这个点我感觉也有一点可能，因为局部服务挂了，导致大量报错，拉挂了集群，而且越是这样大家越会一直刷新页面，给其余服务重启减少难度，然而这个可能性没我最初说的可能性大。
3. 服务器厂商出问题了
这种大网站都是 cdn+slb+ 站集群，各种限流降级、负载平衡按情理都会做的很好，所以只有可能是这些前置服务的服务器厂商硬件出问题了。
然而我比拟纳闷的是 B 站的 BFF 应该会路由到一些接入节点比拟进的机房，这样全国各地的小伙伴刷的时候，应该是有些人好，有些人坏，有些人时好时坏才对，然而当初看来是全坏了，难道他们押宝了一个厂商的一个节点片区？
我看网上也在传云海数据中心起火了，不晓得虚实，只能等醒来看看 B 站官宣了，B 站原则上，实践上，从 CDN、分布式存储、大数据、搜索引擎都应该做了很多保障措施才对，如果真 all in 了一个中央那的确不太理智。
我的感觉就是没做好全副上云，线下的服务器出了问题，刚好是没上云的是要害业务，当初公司都是私有云 + 公有云这样的混合云搭配用的，然而公有云局部都是 B 站本人的外部业务，所以应该不会他本人的机房出问题。
如果真像我说的，押宝了一个服务器厂商，物理机还出问题了，那数据恢复可能就慢了，我本人之前做大数据的，我晓得数据备份都是增量 + 全量，复原的时候真的好了一部分还能够从其余地区节点拉，然而如果是放在一个中央了，那就麻烦了。
复盘
我想不论最初是什么起因造成的，咱们技术人和公司应该思考的就是怎么去防止这样事件的产生。
数据备份： 备份肯定要做，不然如果真产生什么自然灾害，那是很好受的，所以很多云厂商当初都选在贵州我老家这样自然灾害比拟少的中央、或者湖底、海底（比拟凉爽老本能上来不少）。
全量、增量基本上都是始终要做的，分天、周、月一直的增量数据，以及按时的全量数据备份，这样能够让损失升高很多，就怕所有地区的机械盘都坏了（异地容灾除了地球覆灭不然都能找回来）。
运维权限收敛，还是怕删库跑路，反正我是常常在服务器上 rm-rf，不过个别有跳板机能力进去的都能够做命令禁止。
上云 + 云原生： 云产品的各种能力当初很成熟的，企业应该对对应的云厂商有足够的信赖，当然也得选对才行，云产品的各种能力是其一，还有关键时刻的容灾、应急响应机制都是很多公司不具备的。
云原生是近些年才大家才器重的技术，docker+k8s 这对应的一些组合，加上云计算的各种能力，其实能够做到无人值守，动静缩扩容，以及下面说的应急响应，然而技术自身是须要一些尝试老本的，而且我也不晓得 B 站这样视频为主的体系，适不适宜。
本身实力打造： 其实我感觉不论是上云，还是不上云，都不能太依赖很多云厂商，本人的核心技术体系和应急机制还是要有，如果云厂商真的靠不住怎么办？怎么去做真正的高可用，这我感觉是企业技术人员须要去思考的。
举个例子，很多云厂商都是一个物理机隔成多个虚拟机售卖，而后就会存在单物理机多宿主的状况，如果其中一方是电商玩双十一，一方是游戏厂商，对方大量占用网络带宽，你就可能存在丢包的状况，这对游戏用户来说是体验极差的，这样就是我说为啥不要过于信赖和依赖云厂商的起因。
对方万一买了去挖矿，那更过分，把算力榨干，满负荷跑更好受。
B 站这次，好在这样的问题提前裸露了，而且是早晨，应该有不少流量低谷的工夫去复原，我写到这里的时候，网页大部分复原了，然而我发现还是局部复原。
不管怎么说下次就能够齐全杜绝了，置信 B 站前面很长一段时间都会忙于架构体系革新，去保障本人真正的高可用。
心愿当前能让我稳固的在早晨看看舞蹈区，而不是盯着 502、404 的 2233 娘发愣。
