本文版权归作者所有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
转载自夜明的孤行灯
什么是降级
当出现大流量或者其他情况时我们需要保护我们的系统，这里有三大利器：缓存、降级和限流。
降级是一种利用有限资源，保障系统核心功能高可用、有损的架构方法。降级的最终目的是保证核心服务可用，即使是有损的，同时有些服务是无法降级的。
实施降级
实施降级需要综合分析系统情况和业务情况，要判断是否可以“丢卒保帅”，同时梳理出核心链路，保护核心业务。
考虑到影响业务的范围降级可以分为以下几种：
页面降级
在特殊情况下（一般是热门活动），有些页面占用了一些稀缺服务资源，在紧急情况下可以对其整个降级，页面暂时无法访问。
页面片段降级
比如商品页面中包含其他商品推荐信息，这个片段可以暂时屏蔽。
页面异步请求降级
比如商品详情页上有推荐信息/配送至等异步加载的请求，如果这些信息响应慢或者后端服务有问题，可以进行降级
服务功能降级
比如渲染商品详情页时需要调用一些不太重要的服务，比如外卖中的骑手配送路径，紧急情况下可以不显示路径，只显示配送时间和状态。
读降级
比如多级缓存模式，如果后端服务有问题，可以降级为只读缓存，这种方式适用于对读一致性要求不高的场景；
写降级
特殊情况下如果可以接收最终一致性，可以直接写cache，用于缓解数据库的压力，比如秒杀。
降级预案
一般情况下降级的发生是可以预期的，比如相关业务促销，或者新业务进入新城市的时候。这个时候预案是最重要的，首先再次明确核心链路是什么，哪些不能超时，不能不可用，哪些可以接收一定超时，不能不可用，哪些可以超时，可以不可用。
我们假象一个微信公众号点餐系统，比如下图
很容易梳理出来查看菜品，余额和消费付款都是核心，会直接影响交易本身。而会员信息修改，发放优惠券就是暂时不可用的，而菜品评价是可以部分可用或者接收一定的超时的。
梳理出这些内容以后，那么就需要明确降级开关的触发条件和方式，这个是业务和技术的综合问题，同时要明确降级触发以后的需要周知的干系人。
自动降级
监控对于系统的健康必不可少，监控可以覆盖很多方面，比如流量，JVM，日志等等。而自动降级是一个很吸引人的东西，它是根据系统负载、资源使用情况、SLA等指标自主进行降级。
超时降级
当访问的数据库或者rpc调用超过默认设定值以后，若服务不是核心服务的话可以在超时后自动降级；具体的服务响应最大时间需要和服务提供方商议，或者根据监控系统的历史数据来评估。
失败次数降级
有时候依赖一些不稳定的API，比如调用第三方商家系统，当失败调用次数达到一定阀值后自动降级；然后通过异步线程去探测服务是否恢复了，则取消降级。
这个有点类似半开式熔断。
故障降级
比如要调用的远程服务挂掉了比如Dns故障，则可以直接降级。降级后的处理方案有：兜底数据、缓存或者默认值。
限流降级
当我们去秒杀或者抢购一些限购商品时（比如小米抢购...），此时可能会因为访问量太大而导致系统崩溃，可以用限流来限制访问量，当达到限流阀值，后续请求会被降级；降级后的处理方案可以是：排队页面。
参考
http://jinnianshilongnian.iteye.com/blog/2306477
本文版权归作者所有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
转载自夜明的孤行灯