架构师训练营第 11 周作业

导致系统不可用的原因有哪些？保障系统稳定高可用的方案有哪些？请分别列举并简述。

导致系统不可用的原因

硬件故障 - 内存颗粒损坏，硬盘损坏，服务器电源断电，交换机故障，网线故障

软件 bug - 软件有测试环境没有发现的 Bug

系统发布 - 发布过程中，配置参数和数据库更新不匹配，数据库没增加字段。

并发压力 - 高并发的情况下，大量用户请求到达服务器，大量线程在争夺资源，最后把资源耗尽，系统崩溃。

网络攻击 - 恶意的网络攻击，恶意的访问者通过恶意的手段去攻击系统。

外部灾害 - 修路挖断光纤，地震

保障系统稳定高可用的方案

解耦 - 代码的低耦合有利于提升系统的可用性

高内聚、低耦合的组件设计原则

面向对象基本设计原则

面向对象设计模式

领域驱动设计建模

隔离

业务与子系统隔离

微服务与中台架构

生产者消费者隔离 - 消息队列

虚拟机与容器隔离

异步

多线程编程

反应式编程

异步通信网络编程

事件驱动异步架构

备份

集群设计

数据库复制

CAP 原理

Failover（失效转移）

数据库主主失效转移

负载均衡失效转移

如何确认失效，需要转移？

设计无状态的服务

幂等

应用调用服务失败后，会将调用请求重新发送到其他服务器，但是这个失败可能是虚假的失败。比如服务已经处理成功，但是因为网络故障应用没有收到响应，这时应用重新提交请求就导致服务重复调用，如果这个服务是一个转账操作，就会产生严重后果。

服务重复调用有时候是无法避免的，必须保证服务重复调用和调用一次产生的结果相同，即服务具有幂等性。有些服务天然具有幂等性，比如将用户性别设置为男性，不管设置多少次，结果都一样。但是对于交易等操作，问题就会比较复杂，需要通过交易编号等信息进行服务调用有效性校验，只有有效的操作才继续执行。

事务补偿

传统事务的 ACID

原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation，又称独立性）、持久性（Durability）

分布式事务的 BASE

基本可用（Basic Availability ）、软状态（Soft-state）、最终一致性（Eventual consistency）

事务补偿：通过执行业务逻辑逆操作，使事务回滚到事务前状态

重试

远程服务可能会由于线程阻塞、垃圾回收或者网络抖动，而无法及时返还响应，调用者可以通过重试的方式修复单次调用的故障。

上游调用者超时时间要大于下游调用者超时时间之和。

熔断

当某个服务出现故障，响应延迟或者失败率增加，继续调用这个服务会导致调用者请求阻塞，资源消耗增加，进而出现服务级联失效，这种情况下使用断路器阻断对故障服务的调用。

断路器三种状态：关闭，打开，半开

限流

在高并发场景下，如果系统的访问量超过了系统的承受能力，可以通过限流对系统进行保护。限流是指对进入系统的用户请求进行流量限制，如果访问量超过了系统的最大处理能力，就会丢弃一部分的用户请求，保证整个系统可用，保证大部分用户是可以访问系统的。这样虽然有一部分用户的请求被丢弃，产生了部分不可用，但还是好过整个系统崩溃，所有的用户都不可用要好。

限流的几种算法

计数器算法（固定窗口，滑动窗口）

固定窗口：使用计数器在周期内累加访问次数，当达到设定的限流值时，触发限流策略。下一个周期开始时，进行清零，重新计数。

滑动窗口：将时间周期分为 N 个小周期，分别记录每个小周期内访问次数，并且根据时间滑动删除过期的小周期。

令牌桶算法

以固定的速度向令牌桶中增加令牌，直到令牌桶满，请求到达时向令牌桶请求令牌，如获取到令牌则通过请求，否则触发限流策略

漏桶算法

访问请求到达时直接放入漏桶，如当前容量已达到限流值，则进行丢弃。漏桶以固定的速率进行释放访问请求，直到漏桶为空。

自适应限流

没有提前的人工评估， 便没有提前的评估过时与人的评估疏漏/错误!

实时自动评估 QPS

业务流量的不确定性与技术方案的自适应性天生一对!

降级

有一些系统功能是非核心的，但是它也给系统产生了非常大的压力，比如说在电商系统中有确认收货这个功能，即便我们不去确认收货，系统也会超时自动确认收货。

但实际上确认收货这个操作是一个非常重的操作，因为它会对数据库产生很大的压力：它要进行更改订单状态，完成支付确认，并进行评价等一系列操作。如果在系统高并发的时候去完成这些操作，那么会对系统雪上加霜，使系统的处理能力更加恶化。

解决办法就是在系统高并发的时候，比如说像淘宝双 11 的时候，当天可能整天系统都处于一种极限的高并发访问压力之下，这时候就可以将确认收货、评价这些非核心的功能关闭，将宝贵的系统资源留下来，给正在购物的人，让他们去完成交易。

异地多活

如果整个数据中心都不可用，比如说数据中心所在城市遭遇了地震，机房遭遇了火灾或者停电，这样的话，不管我们的设计和系统多么的高可用，系统依然是不可用的。

为了解决这个问题，同时也为了提高系统的处理能力和改善用户体验，很多大型互联网应用都采用了异地多活的多机房架构策略，也就是说将数据中心分布在多个不同地点的机房里，这些机房都可以对外提供服务，用户可以连接任何一个机房进行访问，这样每个机房都可以提供完整的系统服务，即使某一个机房不可使用，系统也不会宕机，依然保持可用。

异地多活的难点是数据一致。