B站崩了，如何防止相似事故的出现？

你们都知道虽然我是一个程序员，可是我很是热爱运动，好比跳舞，这不天天回家睡前我都会在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+站集群，各类限流降级、负载均衡按道理都会作的很好，并且他们按道理不会不作容灾。

 

因此只有多是这些前置服务的服务器厂商出问题了，CDN若是挂了那网关负载均衡啥的压力都大了，最后致使连锁的雪崩效应打挂了整套系统。

 

可是我比较疑惑的是B站的BFF应该会路由到一些接入节点比较进的机房，这样全国各地的小伙伴刷的时候，应该是有些人好，有些人坏，有些人时好时坏才对，可是如今看来是全坏了，难道他们押宝了一个厂商的一个节点片区？

 

我看网上也在传云海数据中心起火了，不知道真假，只能等醒来看看B站官宣了，B站原则上，理论上，从CDN、分布式存储、大数据、搜索引擎都应该作了不少保证措施才对，若是真all in了一个地方那确实不太明智。

 

个人感受就是没作好所有上云，线下的服务器出了问题，恰好是没上云的是关键业务，如今公司都是公有云+私有云这样的混合云搭配用的，可是私有云部分都是B站本身的内部业务，因此应该不会他本身的机房出问题。

 

若是真像我说的，押宝了一个服务器厂商，只是cdn出问题还好，若是物理机还出问题了，那数据恢复可能就慢了，我本身以前作大数据的，我知道数据备份都是增量+全量，恢复的时候真的好了一部分还能够从其余地区节点拉，可是若是是放在一个地方了，那就麻烦了。

 

复盘

我想无论最后是什么缘由形成的，咱们技术人和公司应该思考的就是怎么去避免这样事情的发生。

 

数据备份： 备份必定要作，否则若是真发生什么天然灾害，那是很难受的，因此不少云厂商如今都选在贵州我老家这样天然灾害比较少的地方、或者湖底、海底（比较凉快成本能下去很多）。

 

全量、增量基本上都是一直要作的，分天、周、月不断的增量数据，以及按时的全量数据备份，这样可让损失下降不少，就怕全部地区的机械盘都坏了（异地容灾除了地球毁灭否则都能找回来）。

 

运维权限收敛，仍是怕删库跑路，反正我是常常在服务器上rm-rf，不过通常有跳板机才能进去的均可以作命令禁止。

 

上云+云原生： 云产品的各类能力如今很成熟的，企业应该对对应的云厂商有足够的信任，固然也得选对才行，云产品的各类能力是其一，还有关键时刻的容灾、应急响应机制都是不少公司不具有的。

 

云原生是近些年才你们才重视的技术，docker+k8s这对应的一些组合，加上云计算的各类能力，其实能够作到无人值守，动态缩扩容，以及上面说的应急响应，可是技术自己是须要一些尝试成本的，并且我也不知道B站这样视频为主的体系，适不适合。

 

kubernetes的设计上也会存在一些编排、通讯的问题。

 

自身实力打造： 其实我以为无论是上云，仍是不上云，都不能太依赖不少云厂商，本身的核心技术体系和应急机制仍是要有，若是云厂商真的靠不住怎么办？怎么去作真正的高可用，这我以为是企业技术人员须要去思考的。

 

举个例子，不少云厂商都是一个物理机隔成多个虚拟机售卖，而后就会存在单物理机多宿主的状况，假如其中一方是电商玩双十一，一方是游戏厂商，对方大量占用网络带宽，你就可能存在丢包的状况，这对游戏用户来讲是体验极差的，这样就是我说为啥不要过于信任和依赖云厂商的缘由。

 

对方万一买了去挖矿，那更过度，把算力榨干，满负荷跑更难受。

 

B站此次，好在这样的问题提早暴露了，并且是晚上，应该有很多流量低谷的时间去恢复，我写到这里的时候，网页大部分恢复了，可是我发现仍是部分恢复。

 

无论怎么说下次就能够彻底杜绝了，相信B站后面很长一段时间都会忙于架构体系改造，去保证本身真正的高可用。

 

但愿之后能让我稳定的在晚上看看舞蹈区，而不是盯着50二、404的2233娘发呆，嘻嘻

最后

最近我整理了整套《JAVA核心知识点总结》,说实话 ,做为一名Java程序员,不论你需不须要面试都应该好好看下这份资料。拿到手老是不亏的~个人很多粉丝也所以拿到腾讯字节快手等公司的Offer

进【Java进阶之路群】，找管理员获取哦-！

​