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可以通过监控一段事件内的异常次数和响应速度来判断当前服务的健