大家都知道我虽然是个程序员，但是我喜欢运动，比如跳舞。每天回家睡觉前都会去B站舞蹈区学习相关的舞蹈，昨天也不例外。刚洗完就赶紧坐到电脑前，打开B站舞蹈区准备学咬喵，心小萌和小鲜若的新舞步，不得不说老婆们跳得真好，连我这种内向的人都会不自觉地扭动起来。就在我准备学习下一步动作的时候，我发现了为什么404NOTfound。破碎的。作为一名开发人员，我的第一直觉是系统崩溃了。我什至怀疑这是我网络的问题。发现手机网络正常，电脑也能正常访问其他网页。我知道发展会受到指责。刷新了几次，发现还是老样子。有点同情对应的开发同学，年底应该就没了。（写这篇文章的时候网站还没有恢复）作为一个曾经的程序员，习惯性的思考B站网站结构的组成，以及意外恢复后可能出错的点。（老职业都习惯了）首先我们可以粗略的画一个网站的简单结构图，然后我们就可以猜测这次可能是哪里出了问题。因为熬夜写文章，没在这种以视频直播为主的公司待过，对技术栈了解不多，所以用电商的大体逻辑画了个草图，然后每个人都点了它。从上到下，从入口到CDN内容分发，到前端服务器，后端服务器，分布式存储，大数据分析，风控到搜索引擎推荐，我随便画的，我觉得整体结构应该不会非常大。去网上查了斗鱼、B站、A站等公司，主要技术栈和技术难点主要有：视频接入、存储流、视频编解码、视频编解码、就近节点续传（不同来自我们写的io例子多）数据库系统&文件系统隔离和并发访问流媒体服务器（各大厂商都有，带宽成本高）数据集群，分布式存储，缓存CDN内容分发负载均衡搜索引擎（分片）)弹幕系统并发、线程kafkanio框架（netty）其实和我们都学过的技术差不多，只是它们对应的微服务的语言构成可能有go、php、vue、node的比重比较大。我们来分析一下这次事故可能的原因和地点：1、微盟删库跑路前发生的这种情况。我想不会有任何公司会给这么大的运维权限，比如直接禁止rm-rf、fdisk、drop等主机权限命令。而且数据库现在最有可能是多主多从，多地备份，容灾要做好，如果数据库炸了，CDN的很多静态资源不要加载.页面直接404。2.单个微服务挂掉拖大集群时，现在前后端分离。如果后端挂了，前端很多东西还能加载，但是数据出不来，报错。所以，如果集群挂了，有可能是因为前端挂了，或者前后端挂在一起，但是问题还是一样，现在好像所有的静态资源都访问不了。但是这个点我觉得也是有一点可能的，因为有的服务挂了，导致大量的报错，把集群拉下来，而且越是这样，就会有越多的人不断刷新页面，越做越难对于其他服务重启，但是这个可能性并不是我最后说的可能性高。3、服务器厂商有问题。这种大型网站都是cdn+slb+站点集群。各种限流降级，负载均衡都会做好，做容灾也不会失败。所以，只可能是这些前端服务的服务器厂商有问题。如果CDN挂了，网关负载均衡的压力会很大，最后会造成链雪崩效应挂掉整个系统。但是我比较疑惑的是，B站的BFF应该路由到一些离接入点比较近的机房，这样全国各地的朋友浏览的时候，应该是有些人不错，有些人是坏的，有些人是好人和坏人。是的，但现在看来，一切都坏了。难不成他们赌的是某个厂商的节点区域？我在网上看到云海数据中心也着火了。我不知道这是不是真的。只能等一觉醒来，看B站官宣了。是的，原则上，理论上B站应该从CDN、分布式存储、大数据、搜索引擎等方面采取了很多保障措施。如果真的都集中在一个地方，那实在是不明智。我的感觉是所有的云迁移我都没有做好。离线服务器有问题。正好关键业务没有上云。现在公司用的是公有云+私有云这样的混合云，但是私有云部分都是哔哩哔哩自己的内部业务，所以自己的机房应该没有问题。如果真的像我说的那样，我赌的是服务器厂商，不过CDN有问题也没关系。如果物理机有问题，那么数据恢复可能会很慢。以前做过大数据，知道数据备份是增量+全量的，恢复的时候确实不错，可以从其他区域的节点拉取一部分，但是如果放在一个地方，会很麻烦的。在回放中，我觉得不管最终原因是什么，我们技术人员和企业应该思考的是如何避免这样的事情发生。数据备份：备份一定要做好，不然万一有天灾，心里很难受，所以现在很多云厂商都选择天灾比较少的地方，比如我老家贵州，或者湖底或者海底（比较冷）和成本效益）下降了很多）。全量和增量数据基本都是一直做的。连续增量数据分为天、周、月，以及按时全量数据备份。这样可以大大减少损失，即使所有区域的机械盘都坏掉了（除了地球毁灭，还可以远程灾备找回）。运维权限被克制了，还是怕删库跑路。反正我经常在服务器上rm-rf，不过一般有跳板可以进入的可以通过命令禁止。上云+云原生：现在云产品的各种能力已经很成熟了。企业应该对相应的云厂商有足够的信任。时时刻刻的灾难恢复和应急响应机制是很多企业无法做到的。云原生是近几年大家比较关注的一项技术。docker+k8s对应的一些组合，再加上云计算的各种能力，其实可以实现无人值守，动态伸缩和扩展，以及上面提到的应急响应，但是技术本身需要一定的试用成本，不知道是不是像B站这样的基于视频的系统是合适的。kubernetes的设计也会存在一些编排和通信的问题。建立自己的实力：其实我觉得不管上不上云，都不应该过度依赖很多云厂商。你还是需要有自己的核心技术体系和应急机制。云厂商真的不靠谱怎么办？如何真正做到高可用，我想这是企业技术人员需要思考的问题。比如很多云厂商把一台物理机分成多台虚拟机出售，然后就会出现一台物理机上有多个主机的情况。占用网络带宽，可能会出现丢包的情况，这对游戏用户来说是非常不好的体验，这就是为什么我说不要过度信任和依赖云厂商。如果对方买来挖矿，那就更过分了。榨干算力满负荷跑，就更难受了。B站这一次，幸好提前暴露了这样的问题，而且是晚上，应该还有很多低流量时间可以恢复。写到这里，大部分网页都恢复了，但是我发现还是部分恢复了。不管怎样，下一次就可以彻底消灭了。相信B站会长期忙于结构系统改造，以保证其真正的高可用。希望以后能在晚上稳定的看舞蹈区，而不是盯着502和404的2233妈妈发呆，嘿嘿
