参考美团：https://tech.meituan.com/smart_payment.html
https://my.oschina.net/meituantech/blog/1822362
https://awps-assets.meituan.net/mit-x/slide-bundle-2018-2/45/3-美团稳定性保障平台Rhino.pdf
https://www.cnblogs.com/xiexj/p/8486390.html
http://jm.taobao.org/2017/06/22/20170622/
稳定性（降低故障发生率、减小故障影响范围）：措施
ui、接口、性能
监控、故障演练、服务拆分 流量回放、破坏性测试、全链路压测、熔断降级
降级：
强弱依赖（强依赖依据：发生故障时，用户有无感知/核心业务有损失）：
降级主要针对前端操作，对后端接口mock500，判断前端页面是否正常，不需要该接口的功能是否正常。
经验：由于前端降级容错开发需要成本，因此可与研发、产品协商：降级以最小的开发成本（同一个页面5、6个api，每个都考虑后端挂了，目前前端是一个页面同时调用多个接口，如果拆开调用，然后后端api挂了，就不显示，还要考虑超时等情况，那前端开发量*2）：P0、P1页面，如果api1挂了，不影响api2的UI使用；P2、P3页面，如果api1挂了，api2也无法使用，静态UI如按钮、入口等仍可以使用；
熔断：
因此就出现了熔断的逻辑，也就是，如果检查出来频繁超时，就把consumer调用provider的请求，直接短路掉，不实际调用，而是直接返回一个mock的值。等provider服务恢复稳定之后，重新调用。
限流：
而provider有时候也要防范来自consumer的流量突变问题。这样一个场景，provider是一个核心服务，给N个consumer提供服务，突然某个consumer抽风，流量飙升，占用了provider大部分机器时间，导致其他可能更重要的consumer不能被正常服务。所以，provider端，需要根据consumer的重要程度，以及平时的QPS大小，来给每个consumer设置一个流量上线，同一时间内只会给Aconsumer提供N个线程支持，超过限制则等待或者直接拒绝
作为测试可以梳理内容：使用的接口，预计调用量，是否强依赖/弱依赖，是否有预案或限流，限流阈值
