B 站的前端崩了，后端的你别慌！

昨天晚上笔者刷 B 站时突然发生登陆不上的情况，用流量还是 WIFI 都不行，当时我第一反应是手机的问题，但重装 APP 重启机器都没能解决，后来刷知乎才知道昨晚 B 站、A 站、豆瓣甚至连同微博都有过中断的情况。凌晨 1 点左右 B 站基本恢复了正常，今早我们看到 B 站就昨天晚上的崩溃致歉，并说明事故原因是不同服务器机房出现故障所致。

 

从事故经过中可以看到像 B 站、A 站这种用户上亿的视频网站，即使是在凌晨的访问中断都会造成极大影响。因此笔者作为一名多年战斗 IT 一线的老兵一下子就来了精神，连夜写下本文来，以 B 站本次事件为切入点，谈谈如果在网站崩溃当天值班该怎么办?

 

知识储备：一个用户请求的神奇之旅

首先，无论你是访问 B 站还是其它 APP，第一步都要先访问 DNS 服务器，进行域名解析。一般来说 DNS 服务器会根据用户所在的网络情况，把到用户访问延时最低的服务 IP 返回给用户，在用户通过 DNS 服务器解析得到 B 站的 IP 地址之后，再将实际请求发向该 IP。

接下来就会来到 CDN 节点。一般像 B 站这种体量的网站，在流量进入到自身体系之前，都会进行 CDN 加速。这里先对 CDN 稍等科普：一般来说网站上的内容分为静态和动态两种，其中静态内容对所有客户都一样，比如首页最顶端的动图，而动态内容一般需要根据不同用户而针对性计算处理，比如为你推荐，猜你喜欢的内容，如下图所示：

 

可以看到静态内容的变动周期较长，对所有人都呈现相同的内容，其特别之处在于需要大流量支撑，但却不怎么需要算力支撑；动态内容则是对用户个性化的内容投放，流量不大，但却需要很强的算力支撑。而 CDN 节点就是由公有云厂商专门针对静态内容展现提供的加速服务，通过 CDN 加速节点，B 站可以先把静态内容先缓存到引用公有云的 CDN 节点上，以此把很大一部分流量压力隔离到网站自身的信息系统体系之外。

在走完上述的流程之后，用户请求才会最终走入 B 站的系统体系内部，一般来说先过负载，再进入微服务的调用链。之前 B 站的技术总监毛剑老师曾对于 B 站的高可用方案做过介绍，具体可以参考：https://blog.csdn.net/QcloudCommunity/article/details/105697605?utm_source=app&app_version=4.11.0，因此这里就不专门针对 B 站的情况进行单独论述，接下来我们对于高可用体系做一个整体介绍。

对付网站崩溃的杀手锏——高可用体系

在正式开讲高可用体系之前，我们先来讲一下 RTO 与 RPO 的概念，这是评价高可用体系的两个重要指标：

RTO（Recovery Time Objective）：RTO 是指灾难发生后，从 IT 系统崩溃导致业务停顿开始，到 IT 系统完全恢复，业务恢复运营为止的这段时间长度。RTO 用于衡量业务从停顿到恢复的所需时间。

RPO（Recovery Point Objective）：IT 系统崩溃后，可以恢复到某个历史时间点，从历史时间点到灾难发生时间点的这段时间长度就称为 RPO。RPO 用于衡量业务恢复所允许丢失的数据量。

简单来讲 RTO 就是灾难发生后业务中断的时间，RPO 就是灾难发生后数据丢失的数量。比如这次 B 站的中断事件业务历时半小时恢复，而数据没有失去，那么其 RTO 就是 30 分钟，RPO 为 0。

一般来说像负载、消息队列、Web、APP 这些类型的节点，都彼此独立，横向互不干扰；数据库类型的主备节点之间则需要互相同步数据。以数据中心的角度来看，目前比较流行的高可用体系是两地三中心的架构，如下：

主中心：正常情况下全面提供业务服务；

同城中心：一般使用主中心的数据库节点会通过同步复制的方式来向同城灾备中心的数据节点同步数据，保证同城中心数据复本为最新，随时可以接管业务，以保证在出现中心级崩溃时的 RTO 指标，即保证业务可以快速恢复；

异地中心：主中心数据库一般使用延时异步复制（延时时间一般为 30 分钟左右）的方式向异地灾备中心传输数据，其中延时同步复制的好处是一旦主中心出现删库跑路等人为破坏事件，也不会立刻涉及异地中心，以此保证 RPO 的指标。

一句话总结高可用体系的最佳实践就是，负载、消息队列、Web、APP 及实时同步的数据库节点负责业务连续性，支持灵活切换，优先保证用户体验；异地的延时同步数据库节点则优先保证数据连续性，确保企业生存底线。那么我们就可以知道遇到这种史诗级的大事故，值班人员首先要定位问题原因以及具体位置，如果是人为破坏则快速使用延时同步的数据库节点接管业务，如果是系统自身问题则需要快速将问题节点进行切换，把影响降到最低。

排除最不可能的，剩下的只能是真相

在排错之前我们先看看值班员目前还会接收到什么信息。首先是在 B 站崩溃的同时，A 站、豆瓣等网站都有短暂的崩溃现象，如果大家同时崩这会不会将矛头指向云服务商？

会是云厂商的问题吗？先说结论：不会。这个原因应该是最先排除的，因为国内的几大云厂商大多都会建设体内的闭环体系，比如蚂蚁，淘宝和天猫等阿里系 APP 都是自家云服务的客户，他们都没问题，那就不能怀疑到阿里头上去；同理微信目前虽然还没完全上云，但 QQ 可是在 2019 年就完成上云了，QQ 没崩那大概率鹅厂的 CDN 也是健康的。而且 A 站、豆瓣大多是 B 站的替代品，所以这些网站的崩溃，大概率是 B 站崩溃而引起的竞品网站流量高峰，与大型云服务商无关。

会是负载均衡的锅吗？这个原因也能排除，不过我们看到 B 站最开始崩溃的时候，是完全没有服务降级，直接把裸奔的 502 界面返回给了用户，这个页面中明晃晃地显示了“Powerd by Tengine“，不少人也就据此分析称这应该是 Tengine 这个负载均衡的锅。

 

但个人认为也正是这个报错把 Tengine 洗白了。因为这里 Tengine 还有能力向用户返回数据，并没有崩溃迹象，问题很明显是出在了负载下面的服务。

部分服务器机房故障只能是唯一的解。按照我的理解，B 站回应的“部分服务器机房故障“指的是部分机房同时故障，影响到了关键服务。我们知道直接给用户返回这种纯字符式的错误码是一个很糟糕的方案，这与返回“B 站走丢了”，“弹幕君太忙了”之类话术相比，虽然从技术角度来看相差不多，但用户感受差距太大。不把裸奔的 502，404 等界面返回给用户是微服务体系中降级、限流的基本要求，之前 B 站的技术总监毛剑老师在做高可用体系分享时曾提过 B 站的系统已经完成了微服务改造。因此综合一下信息我们可以知道，云服务商大概率没事，负载均衡应该还是健康的，而微服务的降级、限流等措施却全部没有工作。依据这些现象，我们大概能知道故障发生在某个与主页有着强关联的关键性服务上，而且这个服务是全军覆没的状态。

部分服务器大概率是数据库服务器。一般来说 APP、Web 等类型的同类节点彼此独立，不会互相横向影响，跨机房的集体宕机可能性很低，这方面的原因也大概率能排除；不过正如前文所说数据加节点之间可是要进行数据同步的，有可能互相影响。那么我只能大胆猜测是某个部署重要服务数据库的机房出现严重问题，并且该数据库节点不但没有正常切换，还横向影响其它数据库节点，造成该关键服务整体中断。虽然这个推论也会有很多解释不通的地方，比如数据库出现问题时一般降级和限流的能力不会消失，但是在这起事件中限级能力却意外消失了；而且 B 站肯定也会选择分布式数据库，即便个别切片有问题，切换应该也不需要这么长时间。但是由于负载和云厂商以及 APP、Web 节点故障的原因可以直接排除，所以只能大胆推测剩下这个可能性最大的原因了。

专家建议

针对 B 站这次事故，CSDN 采访了相关方面的专家，希望能为减少此类事故的发生提供一些建议。

本文作者 CSDN 博客专家、阿里云 MVP、华为云 MVP 马超表示：

“想做好高可用体系，最好的办法就是红蓝军对抗，拨线式和断电式的破坏式验证是必不可少的，单纯的纸上谈兵很难有效应对这种史诗级事件。不过我们也应该看到不少互联网企业尤其是创业型企业，都没有百年老店的观念，追求爆发式发展很多，但暗自练就内功却很少。虽然这种事件平时大概率不会出现，但一旦出现，没有过硬的内功就撑不过去，因此笔者这里还是呼吁业界对于高可用灾备体系加以重视，这毕竟是 IT 企业的生命线。”

而针对网友提出“有人说'多集群存放在同一个机房中，那么高可用架构不论多好都等同于没有'，而论架构的安全与稳定，上云是优选吗？"的问题，来自开源基础软件公司 Zilliz 的质量保障团队负责人乔燕良进行了解答：

“关于多集群在同一机房中是否还需要高可用的疑问是在忽视故障范围的前提下讨论有效性。当然网友有此疑问也情有可原，因为目前多数场景下高可用都是在同一机房中的，主要是由于高可用都依赖低网络延迟，而一旦跨地区，机房之间的网络延迟将大大增大。因此想跨地区实现高可用性势必将大大增加经济成本。那么上云呢？论架构的安全与稳定，论经济效益的投入与产出，上云确实是目前的最优选择。云服务供应商有专业的技术团队，提供丰富的即插即用的组件，可以让我们把更多的经历投入到业务创新。世界范围内，已经有越来越多的企业选择直接上云，使用云原生服务。目前国内对数据云服务还普遍存在着一定的担忧（欧美市场选择数据云服务已是常态化），但考虑到近期国家对数据安全的重视，紧密出台了相关监管政策，我相信过不了多时，数据云服务也会和其他云服务一样，让企业享受“坐享其成”的收益而受到追捧。”

除此之外，乔燕良也就此事给予了相关建议以降低类似事件的发生概率：

“在服务器机房发生故障的情况下，高可用本身可能已经“不可用”，因此企业要降低此类事故的发生，灾备方案成为必不可少的一环。以我多年从事灾备方案的经验看，目前国内企业在灾备方案上的投入是比较“节约”的。除了政府规定的银行，保险，金融等企业外，一般商业集团都没有完善的灾备方案，其主要原因就是贵。那么有没有针对一般企业经济一点的灾备方案呢？建议从最重要的数据服务开始。数据是一个企业的生命，只要数据还在，所有服务都可以东山再起。一般企业可以上云，选择一个云原生的数据服务，然后将数据实时备份到更经济的对象存储中，如 AWS 的S3。更进一步，还可以在多个区域中备份同一份数据，实现真正的万无一失。”