大家好，我是码哥，可以叫我靓仔。
作为靓仔，是应该经常打开 B 站的，毕竟里面很多美好的“东西”，结果出现网络错误，我以为由于日夜观摩 B 站的视频导致流量超了。
吃瓜虽好，可不要贪杯。我们的重点是根据 B 站、小红书服务故障来聊聊高可用架构的一些设计思路。
B 站、小红书崩了
在 2024-07-02 上午 10 点~11 点左右，B 站和小红书都崩了，出现了不同程度的故障。
打开微博， 看到 #B 站（哔哩哔哩）、小红书崩了# 的话题相继登上热搜。
图片
用户反馈，B 站崩溃，无法拉取新内容和评论区，用户主页、消息界面、客服页面均不可用。有的页面会返回 -500 错误，视频评论区则一直显示“加载中”。
图片
还有网友反映小红书首页内容无法刷新。有的则表示刷出来的内容也不是我的推荐。
图片
图片
图片
@酷安网 也发文表示网站崩了。随后，阿里云客户服务中心回复：北京时间 2024 年 07 月 02 日 10:04，阿里云监控发现上海地域可用区 N 网络访问出现异常，阿里云工程师正在紧急处理中。
图片
B 站、小红书崩了之后，对于阿里云的回应，网友认为裁员裁到大动脉了有网友认为，这次是阿里云裁员裁到大动脉了。
高可用架构
言归正传，吃瓜归吃瓜，我们应该从阿里云的网络切换故障，看到一些高可用的解决方案。
虽然网络故障，B 站、并不是所有的网页打不开，而且系统并没有垮掉，依然返回相关错误信息或者页面给用户。我们也能从里面了解到大厂工程师如何应对此问题的解决方案。
从这次的故障可以看出，B 站和小红书的系统均满足系统服务可降级。
B 站的做法是提供一个加载错误的页面，引导用户重试。
图片
小红书的降级策略有所不同，因为其表现为无法刷新内容，首页刷出来的内容不是用户推荐的。
所以小红书的降级策略是使用了缓存作为降级，比如平台无法通过网络获取用户推荐的信息流时，就直接从缓存系统或者服务器本地的缓存中获取一些内容返回给用户。
这些也是只码哥根据有限的信息哥大家聊聊，估计不久就会有官方的反馈了。本次故障相当于验证了一把 B 站和小红书的高可用是否足够强大。
故障来源
系统宕机原因主要有以下：
无计划的
- 系统级故障，包括主机、操作系统、中间件、数据库、网络、电源以及外围设备。
- 数据和中介的故障，包括人员误操作、硬盘故障、数据乱了。
- 还有自然灾害、人为破坏，以及供电问题等。
有计划的
- 日常任务：备份，容量规划，用户和安全管理，后台批处理应用。
- 运维相关：数据库维护、应用维护、中间件维护、操作系统维护、网络维护。
- 升级相关：数据库、应用、中间件、操作系统、网络，包括硬件升级。
分个类。
- 网络问题。网络链接出现问题，网络带宽出现拥塞……
- 性能问题。数据库慢 SQL、Java Full GC、硬盘 IO 过大、CPU 飙高、内存不足……
- 安全问题。被网络攻击，如 DDoS 等。
- 运维问题。系统总是在被更新和修改，架构也在不断地被调整，监控问题……
- 管理问题。没有梳理出关键服务以及服务的依赖关系，运行信息没有和控制系统同步……
- 硬件问题。硬盘损坏、网卡出问题、交换机出问题、机房掉电、挖掘机问题……
高可用架构原则
系统出现问题的地方很多，解决的方式各不相同，想要解决问题，先说下高可用的总体解决思路，才能更好的解决问题。
避免发生
想要系统高可用，我们要想办法避免问题的发生。比如说，我们可以通过 UPS（Uninterruptible Power System，不间断电源）来避免服务器断电。
故障转移
如果问题真的发生了，我们要考虑的是如何故障转移，比如说，我们可以通过冗余部署，当一个节点发生故障时，用其它正常的节点来代替问题节点。
主从复制
几乎所有的存储系统都提供了主从复制的功能，例如 MySQL、Redis、MongoDB 等。
主从复制要点：
- 存在一主多从。
- 主机负责读&写，并定期复制数据给从机。
- 从机只负责读。
- 一旦主机宕机，可以通过人工手段，将其中一个从节点作为主节点。
图片
图片来源https://raw.githubusercontent.com/dunwu/images/master/snap/20200614184921.png
分片集群
主从复制有一个问题，每个机器上存储的都是全量数据。
但是，单机的数据存储量总是有上限的，当数据量上升为 TB 级甚至 PB 级数据，单机终究有无法支撑的时候。这时，就需要对数据进行分片（sharding）。
分片后的节点可以视为一个独立的子集，每个子集也要保证高可用降级：系统抛弃部分不重要的功能，比如不发送短信通知，以此确保核心功能不受影响。。
图片
图片来源https://raw.githubusercontent.com/dunwu/images/master/snap/20200614184921.png
服务可降级
如果故障无法正面方式解决，那我们要做的就是努力降低故障带来的影响。比如说流量太大，我们可以通过限流，来保证部分用户可以正常使用，或者通过业务降级的手段，关闭一些次要功能，保证核心功能仍旧可用。
这次 B 站、小红书亦是采取了该方案。
限流
限流则是从用户访问压力的角度来考虑如何应对故障。限流指只允许系统能够承受的访问量进来，超出系统访问能力的请求将被丢弃。
降级
降级指系统将某些业务或者接口的功能降低，可以是只提供部分功能，也可以是完全停掉所有功能。比如 B 站返回错误引导页，以此确保核心功能不受影响。
拒绝服务 - 拒绝低优先级应用的调用，减少服务调用并发数，确保核心应用正常使用。或者随机拒绝部分调用，节约资源，避免要死大家一起死的惨剧。
关闭服务 - 关闭部分不重要的服务，或者服务内部关闭部分不重要的功能，以节约资源。
熔断
熔断和降级是两个比较容易混淆的概念，因为单纯从名字上看好像都有禁止某个功能的意思，但其实内在含义是不同的，原因在于降级的目的是应对系统自身的故障，而熔断的目的是应对依赖的外部系统故障的情况。
我们不去调用出问题的服务，让系统绕开故障点，就像电路的保险丝一样，自己熔断，切断通路，避免系统资源大量被占用
监控
在实践中，系统的故障防不胜防，问题的定位和解决也非常的困难，所以，要想全面保障系统的可用性，最重要的手段就是监控。
通过监控，我们可以实时地了解系统的当前状态，这样很多时候，业务还没出问题，我们就可以提前干预，避免事故；而当系统出现问题时，我们也可以借助监控信息，快速地定位和解决问题。
博主简介
码哥，9 年互联网公司后端工作经验，InfoQ 签约作者、51CTO Top 红人，阿里云开发者社区专家博主，目前担任后端架构师主责，擅长 Redis、Spring、Kafka、MySQL 技术和云原生微服务。
