已经在之前的文章中介绍了Netflix在API网关Zuul中实施的按优先级减载策略来保障服务的可用性。当前这一策略已经扩展到了单个服务级别。重点关注在视频控制层面（即AWS中的后台服务）和数据平面。

相对于之前在API网关Zuul中的实现，在服务级别中使用优先减载策略的优势在于：

总体思路是先在PlayAPI服务中引入优先减载策略，验证后再全面推广。PlayAPI是视频流控制平面上的一个关键后端服务，用于播放前的manifest拉取。

根据请求的重要性将其分为两类：

PlayAPI之前采用并发控制器来限流，但是没有区分流量类型，这会导致两类流量之间的相互影响。

可行的解决方案之一是隔离两类流量，将关键请求和非关键请求分片到单独的集群。但是带来的问题是成本的增加，包括开发（系统复杂度）、维护（机器、流水线、监控）成本。

不进行物理隔离，而是在 PlayAPI 中实现了一个并发限制器，限制器优先处理用户发起的请求，而非预取请求。

此机制使用开源Netflix/concurrency-limits Java 库的分区功能。我们在限制器中创建了两个分区：

每个实例都可处理两种类型的请求，并且具有两个分区，分区的大小可动态调整，以确保预取请求仅获得过剩容量。这允许用户发起的请求在必要时“窃取”预取容量。

分区限制器配置为预处理Servlet 过滤器，它使用设备发送的 HTTP 标头来确定请求的关键性，从而避免了读取和解析被拒绝请求的请求主体的需要。这确保了限制器本身不是瓶颈，并且可以在使用最少 CPU 的情况下有效地拒绝请求。例如，过滤器可以初始化为

请注意，在稳定状态下，不会出现任何限制，优先级对预取请求的处理也没有影响。优先级机制仅在服务器达到并发限制并需要拒绝请求时才会启动。

在部署优先负载削减几个月后，Netflix 的基础设施出现一次故障，影响了许多用户的流媒体播放。故障修复后，Android 设备每秒的预取请求量激增 12 倍，可能是因为排队请求积压。

虽然预取请求的可用性下降到 20%，但由于优先减载，用户发起请求的可用性达到 99.4% 以上。

预取和用户发起请求的可用性

我们一度限制了超过 50％ 的所有请求，但用户发起的请求的可用性仍然保持在 99.4％ 以上。

基于这种方法的成功，我们创建了一个内部库，使服务能够根据可插入利用率措施执行优先负载削减，具有多个优先级别。

与需要处理大量具有不同优先级的请求的 API 网关不同，大多数微服务通常只接收具有几个不同优先级的请求。为了保持不同服务之间的一致性，我们引入了四个预定义的优先级存储桶，灵感来自Linux tc-prio 级别：

服务可以选择上游客户端的优先级，也可以通过检查各种请求属性（例如 HTTP 标头或请求正文）将传入请求映射到这些优先级存储桶之一，以实现更精确的控制。以下是服务如何将请求映射到优先级存储桶的示例：

优先级减载仅在达到目标 CPU 利用率后才开始减载，并且随着系统负载的增加，将逐步减载更关键的流量以保持用户体验。

例如，如果集群的自动扩展目标是 CPU 利用率达到 60%，则可以将其配置为在 CPU 利用率超过此阈值时开始减少请求。当流量高峰导致集群的 CPU 利用率大大超过此阈值时，它将逐渐减少低优先级流量以节省资源用于高优先级流量。这种方法还为自动扩展（即服务扩容）提供了更多时间，以便向集群添加更多实例。一旦添加了更多实例，CPU 利用率就会降低，低优先级流量将恢复正常服务。

根据不同优先级存储桶的 CPU 利用率（X 轴）计算的负载削减请求百分比（Y 轴）

优先级减载策略的目标：

原文中还有相关实验来验证减载策略的有效性。

有些服务不是 CPU 密集型的，而是 IO 密集型的，受支持服务或数据存储的影响，当它们在计算或存储容量方面超载时，它们可以通过增加延迟来施加反压。对于这些服务，我们重新使用优先负载削减技术，但我们引入了新的利用率指标来输入削减逻辑。除了标准自适应并发限制器（本身是平均延迟的度量）之外，我们的初始实现还支持两种基于延迟的削减形式：

容灾策略的整体思路应该是越接近故障点实施容灾策略效果越好，所以Netflix在之前API网关实施减载策略的基础上进一步推广至微服务级。但是实施的思路是相同的：