昨晚，很多小伙伴发现 B 站居然崩了，正躺平着刷朋友圈的我突然被这个消息刷了屏！
接下来我的群也炸了！
“我还在看番，突然就没了”
“我头一回这么认真学习，咋就 404 NOT found 了？？？”
“我还以为我路由器断网了，还傻乎乎的过去看了一下，检查没问题又重开了vpn……”
好生热闹，不崩不知道，原来大家这么离不开 B 站。
接下来更离谱的是，由于 B 站崩了，失去精神支柱的大量用户涌入 A 站、晋江、豆瓣，也让它们崩了，热搜上了一个接一个，让微博的开发心头一紧。
真是生动演绎了“互联网内卷之谁也别想睡觉”！，此处心疼开发几秒钟。
作为一个 IT 教育界的小编，出于职业的本能反应，就开始思考：是出啥问题了？
我在网上一查，一下子就看到什么大楼停电、大楼着火、蒙古上单之类的，甚至都惊动了消防出来辟谣。
不过呢，这些原因看着乐呵就行了，对于我这个传播知识的小编来说来说，还是要秉持着正确吃瓜的原则，帮大家剖析其中的原因，让大家学到东西，还能避坑。
所以我灵机一动，想到了找个专家老师给大家讲解。
于是我特地邀请了业内的服务端技术专家朱荣鑫（aoho）老师为我们剖析下其中的原因，传授下正确的吃瓜“姿势”。
朱荣鑫-服务端技术专家，源图信息架构负责人
微服务早期的实践者，微服务方面的技术专家，对云原生、微服务、容器化、高并发、分布式等有多年深入的实践经验。
《Spring Cloud微服务架构进阶》、《Go 语言高并发与微服务实战》、《Go 微服务实战 38 讲》作者、公众号【 aoho 求索】的作者。
------------------------------------------------------

以下是朱荣鑫（aoho）老师针对这个问题的一些看法和解答：

昨晚，我熬夜肝完文章后，大概到了一点多，我翻了下朋友圈，看到不少朋友在刷 B 站崩了的消息。
我看到有些朋友还把毛剑老师去年分享的 《 B 站高可用架构实践》 文章给翻出来了，手速真快。
我也看过这篇文章，说实话，我觉得没啥毛病，负载均衡、限流、重试、超时、级联故障，分布式系统高可用的方案基本都列出里面。
我都有点怀疑 B 站崩了是不是为了让毛老师出圈。
后来官方给出了一个不太明确的原因-服务器机房发生故障。
不管怎样，我们技术人员应该居安思危，多思考思考，怎么样避免这类事情再次发生，所以我就分析了一些原因，大家可以跟着思考讨论一下。
网上流传了一些 B 站崩了的原因：
  • 网传 B 站大楼有火情发生-目前已被上海消防辟谣；
  • 流量激增导致的服务宕机-这种几乎不可能，又不是明星炸微博，排除热点事件的可能性；
  • 除了 B 站，同一时间出问题的还有 A 站、豆瓣等，只不过后者在极短的时间内恢复了，因此怀疑依赖的公共服务出了问题，某云服务供应商的机房发生了断电之类的异常；
  • CDN 云服务挂掉了，使用 CDN 应对高并发场景是一个比较成熟的方案，如果 CDN 不可用，会导致大量请求直接打到网关；
  • 删库跑路 rm -rf，相信经过这两年的微盟等公司的案例，B 站对于主从备份和权限管理应该比较严格，这种可能性比较小。
我分析了一下，其实对于 B 站这次服务挂掉的情况来说，最有可能的原因还是最后两种：
视频网站读请求大部分都经过 CDN 和缓存，由云服务商的故障引发部分机房的服务宕机。
或者是 CDN 的故障导致大量请求直接回源到 B 站后端服务，导致网关、后端服务级联的崩溃。
这过程中比较可疑的是，B 站自研的限流、降级、超时等组件并没有很好地发挥该有的功能，导致没有支撑得住用户的正常访问。
系统提供的服务要始终可用，然而故障不可避免，特别是在分布式系统下，面对不可控的用户流量和机房环境，系统故障将会显得更加复杂和不可预测。

高并发场景如何保证高可用？

吃瓜之余，我们也要思考下，高并发场景下实现高可用需要从哪些方面着手，需要注意些什么？
在大规模的分布式系统中，各个模块之间存在错综复杂的依赖调用关系，比如前端服务依赖于后端服务获取业务处理数据，后端服务依赖于数据库进行数据持久化处理，如果任一环节出现问题，都有可能导致雪崩式、多米诺骨牌式故障，甚至可以断言故障的出现成了常态。
系统出现故障的原因多种多样，主要有以下这些：
  • 网络问题，网络连接故障、网络带宽出现超时拥塞等；
  • 性能问题，数据库出现慢查询、Java Full GC 导致执行长时间等待、CPU 使用率过高、硬盘 IO 过载、内存分配失败等；
  • 安全问题，被网络攻击，如 DDoS 等；异常客户端请求，如爬虫等；
  • 运维问题，需求变更频繁不可控，架构也在不断地被调整，监控问题等；
  • 管理问题，没有梳理出关键服务以及服务的依赖关系，运行信息没有和控制系统同步；
  • 硬件问题，硬盘损坏导致数据读取失败、网卡出错导致网络 IO 处理失败、交换机出问题、机房断电导致服务器失联，甚至是人祸（比如挖掘机挖断机房光缆，导致一整片机房网络中断）等。
对于分布式场景下高可用的技术研究与实践，其实已经很成熟，也有很多经验了。根据上面的故障原因，我们大致分为如下几点。

1.冗余设计，负载均衡

降低单点故障的不二法门就是冗余设计，通过多点部署的方式，并且最好部署在不同的物理位置上，避免单机房中多点同时失败。冗余设计不仅可以提高服务的吞吐量，还可以在出现灾难时快速恢复。

2.熔断设计

这里我们可以类比电路系统的断路器机制，当下游服务因为过载或者故障出现各种调用失败或者调用超时现象时，及时“熔断”服务调用方和服务提供方的调用链，保护服务调用方资源，防止服务雪崩现象的出现。

3.限流设计

熔断设计保护的是服务调用者，即上游服务的可用性，对于下游服务提供者，考虑到自身服务实例的负载能力，同样需要限流设计保护自己不被过量的流量冲垮。一般来讲有这样几种限流策略：拒绝服务、服务降级、优先级请求、延时处理、弹性伸缩等。

4.超时设计

这种方法是给服务调用添加一个超时计时器，在超时计时器到达之后，调用结果还没返回，就由服务调用者主动结束调用，关闭连接，释放资源。通过超时设计能够有效减少系统等待时间过长的服务调用，使服务调用者有更多的资源处理其他请求，提高可用性。
其他还有的手段诸如实时监控和度量、接口缓存、重试设计、幂等性设计、无状态设计、降级设计等。
在系统运行过程中，无论是系统内部还是系统外部依赖都极可能出现故障导致不可用。在这种情况下，你就需要时时考虑在故障情况下如何保证系统的基本可用性，采用多种设计防止故障的产生或者在故障出现之后如何恢复和可用。
唐太宗李世民有云：“夫以铜为镜，可以正衣冠；以史为镜，可以知兴替；以人为镜，可以明得失。”
所以，拿到正确的吃瓜“姿势”之后，我们也应该以此为鉴，未雨绸缪，特别是开发人员，这次 B 站的事情是一个很鲜活的案例，估计以后面试也是一个常考题了。
此处小编要押题了，其实，上面那些对于此次事件的“解读”，朱老师在他的《Go 微服务实战 38 讲》课程里都有详细讲述，还有更多深度解析，干货非常多。
如果你：
  • 没有实战开发经验，掌握了微服务相关的知识，却没有真正实践过；
  • 只零散的看过讲解微服务组件的应用，没有通过完整的案例来了解微服务架构；
  • 对 Go 微服务没有很了解，大多数实践还是 Java 为主；
  • 没有云上开发的经验，很多时候都是在本地机器上运行应用。
那朱老师的这个课程你真的要好好学了，内容的价值远超你的想象。
之前有个技术大牛就曾给我剖析过，用 Go 落地践行微服务架构绝对是一种趋势。
我们都知道技术也是有风口的，选择一个有未来的知识去学习，一来求职的时候薪资高，因为供小于求；二来是你的技术眼界是超前的，再去学习别的知识也都会很快，更别说这次 B 站崩掉的原因朱老师已经在课程中详细讲解过了。
目前这个课程已有 1.75W 人加入了学习队伍，这里小编也附上一些用户的评价。
讲到这里，我得好好说说这门课程的福利了：拉勾教育跟朱荣鑫（aoho）老师决定，将这门课程 8 元返场，让一些错过优惠的同学，用最大的优惠学习到最好的、口碑一级棒的 Go 微服务课程。
这个原价98元的专栏，
优惠期间只要 8 元，就可永久解锁
赶紧扫描下方二维码，加入学习吧～
 ‍
‍
继续阅读
阅读原文