关于架构设计:架构设计-8高可用架构设计之故障处理

导读：《架构设计》系列为极客工夫李运华老师《从 0 开始学架构》课程笔记。本文为第八局部，次要介绍故障解决，包口典型体现、起因、常见状况、解决思维以及解决办法。如果异地多活看作事先解决的话，那么故障解决能够看作预先预案。

扫描文末二维码 关注公众号 回复“架构设计”获取架构设计笔记残缺思维导图

典型体现

• 零碎并没有宕机、网络也没有中断，但业务却呈现问题了
• 如业务响应迟缓、大量拜访超时和大量拜访出现异常

次要起因

在于零碎压力太大、负载太高，导致无奈疾速解决业务申请，由此引发更多的后续问题。起因分类：

• 外部起因：包含程序 bug 导致死循环，某个接口导致数据库慢查问，程序逻辑不欠缺导致耗尽内存等。
• 内部起因：包含黑客攻击，促销或者抢购引入了超出平时几倍甚至几十倍的用户，第三方零碎大量申请，第三方零碎响应迟缓等。

常见状况

最常见的状况就是，数据库慢查问将数据库的服务器资源耗尽，导致读写超时，业务读写数据库时要么无奈连贯数据库、要么超时，最终用户看到的景象就是拜访很慢，一会儿拜访抛出异样，一会儿拜访又是失常后果。

解决接口级故障的核心思想

• 优先保障外围业务
• 优先保障绝大部分用户

应答办法

降级

降级指零碎将某些业务或者接口的性能升高，能够是只提供局部性能，也能够是齐全停掉所有性能。核心思想：丢车保帅，优先保障外围业务。

常见的实现降级的形式

• 零碎后门降级：就是零碎预留了后门用于降级操作

  • 长处：零碎后门降级的形式实现成本低
  • 毛病：如果服务器数量多，须要一台一台去操作，效率比拟低，这在故障解决争分夺秒的场景下是比拟浪费时间的。
• 独立降级零碎：将降级操作独立到一个独自的零碎中，实现简单的权限治理、批量操作等性能。

熔断

熔断是指依照规定停掉内部接口的拜访，避免某些内部接口故障导致本人的零碎解决能力急剧下降或者出故障。与降级区别：

• 降级的目标是应答零碎本身的故障
• 熔断的目标是应答依赖的内部系统故障的状况

实现熔断机制键点

• 一是须要有一个对立的 API 调用层，由 API 调用层来进行采样或者统计。如果接口调用散落在代码各处，就没法进行对立解决了。
• 二是阈值的设计，例如 1 分钟内 30% 的申请响应工夫超过 1 秒就熔断，这个策略中的“1 分钟”“30%”“1 秒”都对最终的熔断成果有影响。实际中，个别都是先依据剖析确定阈值，而后上线察看成果，再进行调优。

限流

限流指只容许零碎可能接受的访问量进来，超出零碎拜访能力的申请将被抛弃。与降级区别：

• 降级是从零碎性能优先级的角度思考如何应答故障
• 限流则是从用户拜访压力的角度来思考如何应答故障

基于申请限流

分类

• 限度总量，也就是限度某个指标的累积下限，常见的是限度以后零碎服务的用户总量
• 限度工夫量，也就是限度一段时间内某个指标的下限，例如 1 分钟内只容许 10000 个用户拜访；每秒申请峰值最高为 10 万。

长处：无论是限度总量还是限度工夫量，独特的特点都是实现简略。

毛病：

• 比拟难以找到适合的阈值
• 即便找到了适合的阈值，基于申请限流还面临硬件相干的问题。例如一台 32 核的机器和 64 核的机器解决能力差异很大

解决方案

• 为了找到正当的阈值，通常状况下能够采纳性能压测来确定阈值，但性能压测也存在笼罩场景无限的问题，可能呈现某个性能压测没有笼罩的性能导致系统压力很大
• 逐渐优化：先设定一个阈值而后上线察看运行状况，发现不合理就调整阈值。

实用场景：依据阈值来限度访问量的形式更多的适应于业务性能比较简单的零碎，例如负载平衡零碎、网关零碎、抢购零碎等。

基于资源限流

基于申请限流是从零碎内部思考的，而基于资源限流是从零碎外部思考的，也就是找到零碎外部影响性能的要害资源，对其应用下限进行限度。常见的外部资源包含连接数、文件句柄、线程数和申请队列等。基于资源限流相比基于申请限流可能更加无效地反映以后零碎的压力。难点：

• 如何确定要害资源
• 如何确定要害资源的阈值
• 解决方案：逐渐调优的过程：设计的时候先依据推断抉择某个要害资源和阈值，而后测试验证，再上线察看，如果发现不合理，再进行优化。

算法

工夫窗：限度肯定工夫窗口内的申请量或者资源消耗量

• 固定工夫窗：统计固定工夫周期内的申请量或者资源消耗量，超过限额就会启动限流。优缺点：

  • 长处：实现简略
  • 毛病：存在临界点问题

• 滑动工夫窗：两个统计周期局部重叠，从而防止短时间内的两个统计点分属不同的工夫窗的状况。优缺点：

  • 长处：解决了临界点问题
  • 毛病：实现简单些

桶算法：用一个虚构的“桶”来长期存储一些货色，来起到管制速率的成果。

• 漏桶：将申请放入“桶”（音讯队列等），业务处理单元（线程、过程和利用等）从桶里拿申请解决，桶满则抛弃新的申请。

  • 设计关键点：

    • 流入速率不固定：可能霎时流入十分多的申请，例如 0 点签到、整点秒杀。
    • 匀速 (极速) 流出：这是了解漏桶算法的要害，也就是说即便大量申请进入了漏桶，然而从漏桶流出的速度是匀速的，速度的最大值就是零碎的极限处理速度。须要留神的是：如果漏桶没有沉积，那么流出速度就等于流入速度，这个时候流出速度就不是匀速的。这样就保障了零碎在收到海量申请的时候不被压垮，这是第一层的保护措施。
    • 桶满则抛弃申请：这是第二层保护措施，也就是说漏桶不是有限容量，而是无限容量，例如漏桶最多存储 100 万个申请，桶满了则间接抛弃前面的申请。

  • 长处

    • 实现简略
    • 提供双层保护措施

  • 毛病

    • 突发大量流量时抛弃的申请较少，因为漏桶自身有缓存申请的作用。
    • 桶大小动静调整比拟艰难（例如 Java BlockingQueue），须要一直的尝试能力找到合乎业务需要的最佳桶大小。
    • 无奈准确管制流出速度，也就是业务的处理速度。
  • 实用场景：次要实用于刹时高并发流量的场景（例如方才提到的 0 点签到、整点秒杀等）。

• 令牌桶：令牌桶算法和漏桶算法的不同之处在于，桶中放入的不是申请，而是“令牌”，这个令牌就是业务解决前须要拿到的“许可证”。也就是说，当零碎收到一个申请时，先要到令牌桶外面拿“令牌”，拿到令牌能力进一步解决，拿不到就要抛弃申请。

  • 设计关键点

    • 有一个处理单元往桶外面放令牌，放的速率是能够管制的。
    • 桶外面能够累积肯定数量的令牌，当突发流量过去的时候，因为桶外面有累积的令牌，此时的业务处理速度会超过令牌放入的速度。
    • 如果令牌有余，即便零碎有能力解决，也会抛弃申请。
  • 长处：能够动静调整解决速率，实现更加灵便。

  • 毛病

    • 突发大量流量的时候可能抛弃很多申请，因为令牌桶不能累积太多令牌。
    • 实现绝对简单。

  • 实用场景

    • 一种是须要管制拜访第三方服务的速度，避免把上游压垮，例如支付宝须要管制拜访银行接口的速率；
    • 一种是须要管制本人的处理速度，避免过载，例如压测结果显示零碎最大解决 TPS 是 100，那么就能够用令牌桶来限度最大的处理速度。

排队

排队实际上是限流的一个变种，限流是间接回绝用户，排队是让用户期待一段时间。优缺点：

• 长处：排队尽管没有间接回绝用户。

• 毛病：

  • 用户等了很长时间后进入零碎，体验并不一定比限流好
  • 因为排队须要长期缓存大量的业务申请，单个零碎外部无奈缓存这么多数据，个别状况下，排队须要用独立的零碎去实现，例如应用 Kafka 这类音讯队列来缓存用户申请。

实用场景：秒杀流动等

集体思考

服务不可能始终 100% 的可用性，开发运维人员要做的就是尽可能的缩小损失，提前做好预案，产生故障之后，第一工夫就是止损。止损往往是一个抉择的过程，要优先保障外围用户能够失常应用。在前司，平台对第三方和本人的服务提供反对，同时，这些能力也有外围能力和非核心能力，当有故障的时候，运维平台通过预案，会将非核心能力摘除（降级）解决。

此外，笔者还负责开发了一套基于 OpenResty 实现的防攻打平台，反对 IP、用户、特定字段的屏蔽、限流、导流（分流）性能。能够无效的缩小服务故障或者流量异样带来的损失。因为曾经在 gitchat 公布了付费文章，因而没方法公开发表了。感兴趣的同学能够 gitchat 上查看 https://gitbook.cn/gitchat/ac…。

reference

1. 《从 0 开始学架构》https://time.geekbang.org/col…