16 种设计思想 – Design for failure
一直在说互联网系统应该是design for failure，今天看到的这篇文介绍的虽是简单几句话，但妥妥的设计思想，还是蛮契合SRE精髓。作为一名designer或者developer，应该要对墨菲定律心存敬畏，以下讲一下我对这16中设计思想的一个大致看法吧。
1、防御性设计（Defensive Design）
所谓的防御性设计实际上就是“防呆”，英文叫Idiot Proofing。说白了就是用户有时候会不自觉的做一些蠢事，我们在设计的时候要尽量考虑到一些不规范的交互行为，如果你的用户是一只猴子，你要写包单保证系统不被玩坏。例如，在Android开发中使用到的Monkey Test就是用于这样的目的。
2、边界情况（Edge Case）
这个设计思想在测试领域比较常见，就是我们在设计我们的设计案例的时候有没有充分考虑在边界情况下的系统行为。比较常见的例如，闰年情况、跨日情况等边界。想起刚入行我leader跟我说你的程序在你脑袋有没有跑过一遍所有能想到的情况，没有的话重做。
3、防误措施（Mistake Proofing）
怎么保证不会发生错误。例如在人机交互环节，能不能进行输入校验？
4、解耦（Decoupling）
设计的时候，哪怕是最基础的代码也应该符合开闭原则。远的不说，就单单Spring的IOC就是为了把对象创建及维护从原来的由引用类负责这种强耦合模式转成通过spring容器负责。且解耦一般的做法是通过把内部逻辑封装起来，暴露对外统一API接口，调用方不需要了解被调用方的内部逻辑实现，只需要知道提供什么功能即可。这样再引申一下，解耦的作用就在于复用，把所有的高内聚功能独立成一个个模块，然后就可以像乐高积木一样根据调用方的实际需求进行组装。
宏观的系统设计就更是如此，例如微服务中的Eureka。首先，Eureka客户端通过把自己注册到Eureka服务端（如IP、端口），然后其他服务在调用前通过Eureka获取被调用方的信息，然后再去调用被调用方，然后他们的调用关系就是这样解耦的。
熔断本质上就是一种防御性设计或者策略。假设一个微服务体系下的系统，其中A服务调用B服务。系统的QPS是千级别，当时如果B服务挂掉的话A的线程绝对在短时间内占满耗尽而导致假死，从而形成大量A请求积压而导致情况恶化，最终形成雪崩。
在SpringCloud技术体系中，熔断就是Hystrix所体现的另外一种思想。Hystrix可以通过监控一段事件内的异常次数和响应速度来判断当前服务的健康状况，若服务健康状况不佳则进行熔断，熔断之后新的请求将不会调用实际的业务，而是通过快速失败或优雅降级的方式来快速给用户进行响应。
5、 舱壁模式（Bulkhead）
在分布式系统的设计中有一种舱壁模式。目前比较火的微服务架构我理解实际上就是隔板模式的一个体现。这种模式把系统中的各个功能模块实体进行进程、资源上的隔离，使得系统不会因为某个功能模块试题（即微服务）的局部失败而导致全局失败。
1）资源隔离：
微服务里面的Hystrix则是遵守了该模式，通过为每个单独的服务提供独立的线程池而进行资源隔离。在Hystrix中实际上通过两种方式进行资源隔离：
信号量隔离策略（ ExecutionIsolationStrategy.SEMAPHORE）
Semaphores 隔离就是利用了java.util.concurrent.Semaphore 的功能，从信号量获取到许可才允许执行，否则不允许执行，执行完成后要释放之前获取到的许可。同样的每一个服务依赖都有一个自己的信号量，当该信号量的许可被获取完之后，再有线程要进行依赖调用，发现已经没有可用的信号量，这时候就会被拒绝调用。信号量隔离始终都是运行在 Container 线程内的。它的优势就在于造成的开销更低。
线程隔离策略（ ExecutionIsolationStrategy.THREAD）
所谓的线程隔离，实际上就是每一个依赖调用都有自己的线程池来负责处理，依赖调用都运行在自己线程池中的线程上，当同一个依赖调用使用的线程池中的 Queue size 达到设置的阙值时就会拒绝进行依赖的调用。
具体用法可以通过继承@HystrixCommand实现线程隔离或者交易隔离。
2）数据隔离
上面讲的都是线程隔离，当然数据隔离这个一般的做法有库隔离、表隔离、按字段区分这三种租户隔离的方法。
6、冗余（Redundancy）
所谓的冗余指的通过重复配置关键组件或部件，保证在关键组件失效的情况下还有备份组件运作以便保证系统可以继续提供服务。生活中的例子请参与飞机的双引擎设计。
主从模式就是冗余的体现。在正常情况下，主实例负责提供全部的服务，从实例在主实例整体或部分不可用的情况下，完全替代主实例整体或局部而对外提供服务。
7、重试（Retry）
重试是在分布式系统下处理瞬态故障的一个基本手段，简单有效（当然重试的前提是要求幂等）。但是重试也是可以很危险的，它能够引起把一个局部小时间迅速升级为一个系统重大故障，严重者导致系统假死。
举个简单例子：如果我们的链路类似上图，这里会发生什么问题？在极端情况下，重试次数达到5*5*5*5=625次。当链路中的其中一个服务故障率异常的时候，那重试风暴便开启了，因为重试为服务器带来额外的开销和线程的占用，然后其他新来的请求又形成排队，这样的话就形成了类似的DDos恶性事件。根据我们平时的项目经验：
- 相对较好的是选用3次；
- 且重试的时间一定要设定一定的时间间隔（因为很多时候的瞬态故障更多是网络抖动）
- 尽量只在应用层做重试。
8、撤销（Undo）
这个没什么好说，撤销这个功能应该是标配吧。
9、冷备（Cold Standby）
冷备实际上也是冗余设计的其中一种体现，只是它会更侧重于“冷”，意思是当系统发生宕机时，这个系统是需要手动启动用于替换下线的主实例，它是跟热备是不一样，热备更多体现在自动切换。
10、熔断（Derating）
熔断本质上就是一种防御性设计或者策略。假设一个微服务体系下的系统，其中A服务调用B服务。系统的QPS是千级别，当时如果B服务挂掉的话A的线程绝对在短时间内占满耗尽而导致假死，从而形成大量A请求积压而导致情况恶化，最终形成雪崩。
在SpringCloud技术体系中，熔断就是Hystrix所体现的另外一种思想。Hystrix可以通过监控一段事件内的异常次数和响应速度来判断当前服务的健康状况，若服务健康状况不佳则进行熔断，熔断之后新的请求将不会调用实际的业务，而是通过快速失败或优雅降级的方式来快速给用户进行响应。
具体断路器可以参考以下文章：
Netflix：https://github.com/Netflix/Hystrix/wiki/How-it-Works#CircuitBreaker
Martin Fowler的Circuit Breaker。
11、容错（Error Tolerance）
狭义的容错泛指人机交互界面的时候需要对用户输入进行输入校验，保证数据准确性。
广义的容错应该是两个具有明确边界的事物（如服务间，系统间）交互时候针对可能发生的一切主客观异常情况的防御性手段。常见的容错机制有failsafe、failback、failover、failfast。
failfast更多指的是快速失败。当系统遭遇一定概率的故障时，可预见这不是偶发性故障，然后就要开启类似断路器开关，让后续打进来的流量直接失败快速返回，避免线程积压导致系统滚雪球式崩溃。
failover指的是失效转移。请参考我的上一篇redis的文章《玩转Redis高可用-哨兵模式》，里面的主库崩掉后通过选举重新选定新主库的情况就是失效转移。
failsafe指的是失效安全，具体参考以下第12点。
failback指的是失效自动恢复，具体是指主实例发生故障而导致系统切换到备实例，在主实例恢复后自动转移回主实例上。这种容错在Hystrix的自恢复能力可以得到体现（详看下图）。
上图断路器的原理具体看以下三个关键参数，大体逻辑如下：
// 这个用于设定断路器触发的异常比例阈值，正常情况下断路器处于关闭状态。假设阈值为50%，当在一定时间内（如1分钟），异常调用次数/总调用次数>50%的话，断路器打开，后续所有的请求全部调用getFallback()进行failfast.
HystrixCommandProperties.Setter().withCircuitBreakerErrorThresholdPercentage(50%)
// 上面说的一定的采样周期内的流量至少要达到100，Hystrix才会进行采样统计并计算异常比例，再跟上面设定的异常比例阈值进行比较。
HystrixCommandProperties.Setter().withCircuitBreakerRequestVolumeThreshold(100)
// 当断路器状态为打开后，在下面预设的6000毫秒时间内所有请求被快速failfast；当时间一过，Hystrix会试探性允许一个请求进来，这个时候断路器处于半开状态；如果调用成功，断路器自动关闭，然后应用恢复正常状态。
HystrixCommandProperties.Setter().withCircuitBreakerSleepWindowInMilliseconds(6000)
12、失效安全（Fail safe）
所谓的失效安全，就是指在特定失效的情况下，一个系统或者服务也不会对业务造成损害。实际上，我们使用token进行安全登录也是一种失效安全的体现，如果token失效了（如时间过期），用户是无法登录的，因为正常登录需要token有一种约束因素，这种因素就是时间。如果时间过了，代表这种约束因素不存在或者不再有效了，登录功能就不能正常工作了，这个是一个极好的设计理念。
有点抽象？跟你介绍一个生活的例子。电梯之所以可以正常升降，是因为在通电的过程中，正常工作的约束因素（brake）是关闭的；如果某个特殊情况（如没电），这个约束因素不存在或不再有效了，brake是打开的，因此电梯是不会因为没电而下坠的。这个可以理解了吧？
13、优雅降级（Graceful Degradation）
服务降级跟熔断还是挺像的，只是降级来得更加温和和优雅一点。熔断是直接断掉防止异常进一步扩大而导致雪崩，但是我们的终极目标是提供尽可能多的服务，这个就是优雅降级的理念。在一些异常情况或者秒杀场景下，为了保证核心服务（如商品下单、支付）的正常可用，会放弃掉一些非核心服务（如历史账单查询），这就是所谓的服务降级。
在微服务框架中，一般会使用Hystrix的@HystrixCommand或Feign的@FeignClient对服务进行声明，然后为每个服务配置相应的fallback类，最终结合起来进行服务降级。
14、监控（Monitoring）
我们的系统有哪几个纬度的监控，估计最多就是常规的硬件状态监控。当然这里的监控我理解除了技术指标监控，还更应该有业务指标监控，否则我们都在裸泳，等海水退下去后就一览无遗。
监控实际上是为了更好的主动防御，下图展示一下本人前司的一个运维监控与开发协同的机制（从每个序号顺序往下走）。大家可以看出，一套完善的告警监控系统，能够快速通知开发与运维，开发侧能够完成紧急修复并能够协同运维进行快速部署。在笔者前司经历中，正是有着完善的监控告警系统，大部分故障基本可以在业务发现问题得到有效解决（麻蛋一般在晚上爆问题，那段时间太美好了）。
15、耐用性（Durability）
这里我理解的是系统或数据的耐受性。例如数据，为什么我们一定要持久化到数据库，因为就是要借助数据库硬件各种维度的耐受性。
16、回弹性（Resilience）
这里我看到网上有一个更恰当的翻译，叫“韧性”，就是说我们的设计应该在一些特殊情况下还能通过一系列的手段继续提供尽可能多的服务，你也可以理解为“可靠性”。实际上，我的理解是上面说到的基本上都是回弹性的范畴之内。
服务降级
限流
重试
舱壁模式
防御性设计
当然，现在为了提升系统服务的回弹性，部分头部公司也会使用一些故障注入的办法进行混沌工程式训练，如Netflix的ChaosMonkey，阿里的ChaosBlade等。
参考：
https://simplicable.com/new/design-for-failure
https://github.com/Netflix/Hystrix/wiki/How-it-Works#CircuitBreaker
Martin Fowler的Circuit Breaker。
本文文字及图片出自 InfoQ
你也许感兴趣的：
- 一句话总结《Head first 设计模式》
- 大话设计模式
- 详解设计模式六大原则
- 代码审查“查”什么？
- 【外评】电脑从哪里获取时间？
- 【外评】为什么 Stack Overflow 正在消失？
- Android 全力押注 Rust，Linux 却在原地踏步？谷歌：用 Rust 重写固件太简单了！
- 【外评】哪些开源项目被广泛使用，但仅由少数人维护？
- 【外评】好的重构与不好的重构
- C 语言老将从中作梗，Rust for Linux 项目内讧升级！核心维护者愤然离职：不受尊重、热情被消耗光
你对本文的反应是：