跨服务降级

降级有熔断非常像，两个关键点

• 如何判定服务健康，在降级中是判断一个服务要不要降级
• 降级之后怎么恢复，也是要考虑抖动的问题

在一些场景下，既可以用熔断，也可以用降级。比如响应时间超出阈值之后，可以选择熔断，完全不提供服务；也可以考虑降级，提供有损服务。
原则上来说，应该优先使用降级。但是有些服务无法降级，尤其是写服务。例如你要从前端接收数据，然后写到数据库，这种场景是无法降级的。另外，如果你希望系统负载尽快降低，那么熔断要优于降级。

如何降级

• 跨服务降级：资源不够的时候可以暂停某些服务，将腾出来的资源给其他更加重要、更加核心的服务使用。
• 本服务提供有损服务：例如APP首页都会有降级策略，在没有触发降级的时候，APP首页是针对个人画像的个性化推荐。而触发降级之后，则可能是使用榜单数据，或是运营提前配置好的静态页面。要点是要知道服务调用者能够接受什么程度的有损。

跨服务降级的措施常见的有三个：

• 整个服务停掉，例如前面提到的停掉退款服务
• 停掉服务的部分节点
• 停止访问某些资源。例如日志中心压力很大的时候，发信号给某些不重要的服务，让他们停止上传日志，只在本地保存日志