微服务可用性设计(三)：降级、重试、负载均衡、最佳实践

降级

通过降级回复来减少工作量，或者丢弃不重要的请求。而且需要了解哪些流量可以降级，并且有能力区分不同的请求。我们通常提供降低回复的质量来答复减少所需的计算量或者时间。我们自动降级通常需要考虑几个点：

• 确定具体采用哪个指标作为流量评估和优雅降级的决定性指标(如，CPU、延迟、队列长度、线程数量、错误等)。
• 当服务进入降级模式时，需要执行什么动作？
• 流量抛弃或者优雅降级应该在服务的哪一层实现？是否需要在整个服务的每一层都实现，还是可以选择某个高层面的关键节点来实现？

降级本质为: 提供有损服务。

• UI 模块化，非核心模块降级。
• BFF 层聚合 API，模块降级。
• 页面上一次缓存副本。
• 默认值、热门推荐等。
• 流量拦截 + 定期数据缓存(过期副本策略)。
  

处理策略

• 页面降级、延迟服务、写/读降级、缓存降级
• 抛异常、返回约定协议、Mock 数据、Fallback 处理

同时我们要考虑一下几点：

• 优雅降级不应该被经常触发 - 通常触发条件现实了容量规划的失误，或者是意外的负载。
• 演练，代码平时不会触发和使用，需要定期针对一小部分的流量进行演练，保证模式的正常。
  应该足够简单。

重试

当请求返回错误(例: 配额不足、超时、内部错误等)，对于 backend 部分节点过载的情况下，倾向于立刻重试，但是需要留意重试带来的流量放大:

• 限制重试次数和基于重试分布的策略(重试比率: 10%)。
• 随机化、指数型递增的重试周