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 可以通过监控一段事件内的异常次数和响应速度来判断当前服务的健康状况，若服务健康状况不佳则进行熔断，熔断