摘要：在微服务架构下，一个服务可能依赖多个下游服务，为了保证自身服务的可用性，当下游服务出现故障时，特别是强依赖的下游服务出现故障时，如何做才能最大程度的保证自己不受影或者说把影响降到最低？
关键词：微服务 降级 高可用
一、依赖服务的分级
一个服务依赖的可能有很多个，但并不是每一个依赖都需要同等对待，我们可以将依赖服务对本身逻辑的影响范围大致分为弱依赖和强依赖。
- 弱依赖：不影响核心逻辑的依赖服务，例如：直播APP列表中主播的角标信息，即时没有数据也不影响进房。
- 强依赖：影响核心逻辑的依赖服务，例如：直播APP列表中主播的房间号，没了就进不了房。
注意，同一个服务在不同的场景下分级可能会不一样，并且随着业务的变化，强依赖和弱依赖间可能发生转变。
二、降级的时机
根据降级的触发条件可分为主动降级和被动降级；
- 主动降级：一般在大型活动时产生流量尖峰，系统无法支撑，提前对非核心的业务进行了降级处理；
- 被动降级：一般是在发生故障时自动触发预设的降级策略。
举个例子，某个流量明星的演唱会独家直播，可能带来平时流量的10+倍以上，预估已经达到了某些瓶颈，为了保证核心业务的可用性，就需要提前做好预案牺牲一些边缘业务。
三、降级的策略
降级策略大致可以分为以下几类，不同的策略适用的场景和依赖级别会有所不同，下面针对每一种降级策略进行了分析，多种策略可以根据情况结合使用。
1、读旧
每次服务调用成功时，记录服务的结果，下一次失败时读取缓存的旧数据；可以根据时延要求选择本地缓存、分布式缓存、数据库或本地文件。
适用场景：
弱依赖&强依赖，只读业务，能够接受一定的延迟，有足够的存储资源。
需要注意：
- 分布式缓存或数据库只是把服务故障转移到另一个依赖，依赖故障多是网络故障时谨慎选择。
- 冷数据无法降级；
- 降级后的数据存在一致性问题；根据业务情况设置合理的有效期；
- 数据量大时消耗过多的存储（特别是缓存）且命中率低，可以设置合理的缓存大小，使用LRU方式替换旧缓存。
举例：
查询用户的守护主播服务故障时可以使用旧数据，因为有守护的用户占比小（占用缓存小），且活跃度高（冷数据少）。
2、PlanB
提前准备好候选方案，核心业务甚至可以有PlanC、PlanD等，按业务损害从小到大排序。
适用场景：
弱依赖&强依赖，只读业务，有备用数据。
需要注意：
根据业务评估影响范围以及合理的备选方案。
举例：
直播推荐页的信息流依赖个性化推荐服务失败时，降级使用热门推荐；热门推荐接口也故障时，使用备用接口，备用接口的逻辑尽可能简化降低故障概率并采用较长的CDN缓存；备用接口依然失败时继续降级为使用客户端缓存。
3、默认值
直接返回配置中的默认值或者空数据。
适用场景：
弱依赖，只读业务。
需要注意：
默认值尽量有多种选择，避免千篇一律。
举例：
主播标语服务，在配置中心配置一批中性的默认标语，标语服务失败时直接随机取一条返回给用户，故障率不高的情况下用户基本上感知不到异常。
4、放弃部分请求
选择性丢弃部分请求，也是一种限流措施。
适用场景：
弱依赖&强依赖，部分特殊场景。
需要注意：
需要尽量保障丢弃后的请求不会使用户流程受阻，或导致用户体验受损严重。
举例：
在大型活动直播间的弹幕，当大量弹幕刷屏时，使用一定采样比率丢弃部分弹幕，用户并不会太在意自己的弹幕是否飘过，是在太多了。
5、降低质量
使用低资源消耗的服务替代高资源消耗的服务。
适用场景：
弱依赖&强依赖，部分特殊场景。
举例：
直播视频使用低码率替代高码率，使用标清替代高清，也可以根据用户的等级区别对待，比如VIP用户推高清，普通用户推标清。
6、提高参与门槛
其实这算一个限流的措施，比如当直播间人数已经接近设定阀值时，限制只有VIP用户才能继续进入。
7、反向过滤
过滤某个集合中的子集时，通过补集过滤，补集读取失败时放弃过滤；例如白名单改成黑名单（需要注意数据量），黑名单服务故障时则降级为通过；
适用场景：
弱依赖。
举例：
查询有线主播的城市列表，依赖服务提供无在线主播的城市（而不是有在线的城市），服务失败时则可以采用全部城市都显示的方式，比一个城市或极少城市显示体验好。
8、补偿
采用事后处理，可以是自动或者手动补偿。
适用场景：
弱依赖&强依赖，对实时性有一定容忍度。
举例：
Appstore充值服务在海外经常导致校验凭证失败，这时可以记录日志采用后台自动补单方式，并告知用户稍后查询，正常重试几次后基本能够完成到账。
9、容灾
依赖服务需要使用同城双机房、异地三机房、两地三中心等灾备方案中的一种，调用方通过灾备自动切换方案进行重试。
适用场景：
弱依赖&强依赖。
需要注意：
扩机房重试可能产生较高的时延，根据业务情况设置合理的超时时间。
举例：
关注服务是一个核心的业务，部署了异地双活，当单机房故障时重试另一个机房通常都能够成功。
四、总结
降级是一种保障高可用非常有效的手段，但同时对设计者的要求也较高；实际工作中需要对业务非常了解，能够对每种降级方式给业务带来影响精确的评估。另外对于依赖服务，要有合理的超时和重试机制，预留好降级需要的时间和资源，比如依赖超时太长或重试次数太多，你的上游已经中断请求了，这时再好的降级也是徒劳的。
