导读

日拱一卒，功不唐捐，分享是最好的学习，一个知识领域里的 “道 法 术 器” 这四个境界需要从 微观、中观以及宏观 三个角度来把握。微观是实践，中观讲套路，宏观靠领悟。本系列文章我把它命名为《分布式系统架构设计三十六式》，讲诉分布式系统里最重要的三十六个虚数的中观套路，而微服务的本质也是分布式，因此搞明白这三十六个最重要的知识点也就同时能搞明白微服务。

实现一个分布式系统通常会面临三大难题： 故障传播性、业务拆分与聚合以及分布式事务 。本系列中的服务治理章节主要是为了解决故障传播性的难题，它包括： 隔离、熔断、降级、限流、容错以及资源管控 ，本文将讲诉服务治理里的 “降级” 模式。

动机

1. 某些时候系统会遇到负载过高的问题，当系统外来的或内部的负载过高超过预先定义的阈值，为了保证更重要的更紧急的业务的服务质量，希望将一些非核心的、不紧急的业务降低服务质量，从而释放一些额外的资源给紧急业务使用。比如一个分布式系统里的读、写、数据校验、空间回收都比较消耗资源，在白天为了保证读和写的服务质量，可以把数据校验的服务通过限流或减少线程数之类的方式使得可以调用的资源配额减少，从而释放部分资源给读和写使用，保证读写的服务质量。同样在读和写业务不繁忙的时候，降低读和写的资源配额，从而释放资源给空间回收使用，通过这种方式动态调整局部业务的服务质量从而保证关键业务的服务质量，提升用户体验。

2. 在云服务里“可用性”指标是一个非常重要的SLA指标，在可用性出现不达标的情况下需要根据SLA进行赔偿，因此，我们希望分布式系统不管出现怎么样的故障，比如服务器故障，磁盘故障，网络故障都能保持可用性，起码要保证单点故障不会造成系统故障，比如，在系统出现严重故障的时候，可以停止负载较高的写操作从而保证“读”或者“查询“服务。

降级模式

从故障处理角度来讲，服务降级简单来说就是这一功能或服务直接不能用，而在动态调整系统整体的服务质量的时候，降级是降低某些当前非重要或非核心业务的资源，从而释放部分资源给重要的或紧急的业务使用。

在故障处理的时候，对比“熔断”，降级是更严重的故障处理方式，最后拿来兜底用的。比如某个功能出故障，“熔断”是不管怎么样，都希望这个功能还能救活，降级是发现试着救了几次发现还是救不活，就下狠心砍掉这个部分，断臂求生，起码要保证整体是活的，这样整体还有救活的希望。

从系统的角度来说降级有 读功能降级，写功能降级以及级联组件降级，还有自动降级或者人工降级。比如，在云服务里，为了保证高可用性，在出现系统级的故障后，可以把写功能降级，就是这个服务只能读，只能查询不能写了，因此在设计的比较好的云服务里，按时间的维度来度量可用性已经没有太大的意义，因为不管怎么样它都是服务可用的，系统都是活着的，起码部分服务可用，因此在云服务里更合理的新的衡量可用性的指标方式是请求失败比率。

降级模式设计思路

降级触发策略

• 超时降级：在超时重试的次数达到一个阈值后就触发降级；
• 失败比率降级：当某个服务的失败的比率达到一定比率后就开始降级；
• 系统故障降级：比如网络故障，硬盘故障，电源故障，服务器故障，数据中心故障等；
• 限流降级：某些访问量太大的场景会触发限流，当达到限流阈值后，请求也会被降级；
• 重要业务救急降级：比如为了保证读或者查询的功能，降低写或者数据校验的资源配额，从而实现读服务的质量保证。

降级处理措施

• 资源配额调度，调度不紧急的业务支援紧急的重要的业务；
• 抛出异常，直接抛出异常，打印出出错日志，然后就不管了，请求会丢失，这在需要保证幂等性的请求里不合适；
• 直接返回， 直接返回拒绝服务，这里请求也会丢失，这在需要保证幂等性的请求里不合适；
• 调用回退方法，调用出现服务降级时对应的业务处理逻辑，不同场景降级处理的逻辑不同，比如可以把请求再挂到等待队列里继续重试之类，这里需要根据业务场景合理设计回退方法；

降级分级策略

一般可以把降级的等级分为几个层次，比如P0级，P1级，P2级，P3级，级别越高表示问题越严重， 比如：

1. 重要业务救急降级可以定义为P0级降级，只是调度次要的资源去救急，并不会出现故障；
2. 限流降级可以定义为P1级降级，只是为了保证服务质量，而且如果不限流可能会出现系统负载过高从而出现故障；
3. 超时降级以及失败比率降级可以定义为P2级降级，出现小范围故障，触发P2级降级，保证小故障不蔓延不传播从而造成大范围的故障；
4. 系统故障降级可以定义为P3级降级，系统出现大范围故障，从而触发P3级降级，比如，此时可以只保证最低资源的的读请求服务，写和其他业务全部被禁止。

配置中心

如下图所示是一个简单的配置中心物理架构图：