博客|Netflix 技术博客：区分优先级的负载分流，保持服务的稳定可靠( 三 ) 优先|分流|负载|服务|博客

利用这种反压机制，跟过去相比，我们可以更快地停止重试风暴。我们会根据请求的优先级自动调整这两个刻度盘，高优先级的请求的重试频率会比低优先级的请求的更高，这也会提高流媒体的可用性。
验证哪些请求适合这项任务为了验证关于特定请求是否属于NON_CRITICAL，DEGRADED或CRITICAL存储桶的请求分类法假设，我们需要一种方法来测试该请求发出时用户的体验。为此，我们利用了内部故障注入工具（FIT），并在Zuul中创建了一个故障注入点，该点使我们能够根据提供的优先级发出任何请求。这使我们能够手动模拟负载脱落的阻断优先级范围，特定设备或成员，让我们知道哪些要求可能是安全的，而不会影响用户体验棚。
为了对我们的请求分类假设（NON_CRITICAL、DEGRADED及CRITICAL）是否合适进行验证假设，我们需要有一种方法来测试当该请求被卸载时用户的体验。为此，我们利用了内部故障注入工具（FIT），并在Zuul中创建了一个故障注入点，这让我们可以根据提供的优先级来舍弃任何的请求。如此，我们就可以通过屏蔽特定设备或会员特定优先级范围的请求，来手动模拟负载分流体验，让我们了解哪些请求可以安全地卸载掉，而不会影响到用户。
不断确保这些请求仍适合工作这里的目标之一，是通过丢弃预期不会影响用户流媒体体验的请求，来减轻会员的痛苦。不过，Netflix的变化是很快的，那些被认为非关键的请求可能也会意外地变成关键请求。此外，Netflix还有多种的客户端设备、客户端版本，以及多种跟系统交互的方式。为了确保在任何情况下限制NON_CRITICAL请求时我们都不会引起成员的痛苦，我们利用了自己的基础设施试验平台ChAP。
这个平台可以让我们开展A/B测试，把我们的少量产品用户分配到对照组或实验组，每次实验45分钟的时间，同时对实验组一定范围内的优先级进行限制。这可以让我们捕捉到各种实时的用例，并衡量它们对回放体验的影响。ChAP按照设备分析每一位会员的KPI，以确定对照组和实验组之间是否存在偏差。
在我们的第一个实验里，我们在Android和iOS设备上都检测到了低优先级请求的紊乱情况，这会导致零星的播放错误。由于我们进行的是连续实验，所以一旦初始的实验开始运行，并且bug得到了修复，我们会安排实验继续按照周期运行。这样一来，我们就能够尽早检测出回归，并让用户保持正常播放。

文章插图
FIX前后实验数据回归检测（SPS表示流媒体的可用性）
获得的好处2019年那时候，我们的逐步负载分流法还没有到位，Netflix的流媒体服务就经历过服务宕机的事件，导致相当大一部分比例的会员制一段时间都没法播放玩游戏。但到了2020年，我们的实现刚刚部署几天之后，团队就开始看到这种解决方案的好处了。当时Netflix也出现了类似的问题，其构成的潜在影响跟2019年的那次中断是一样的。但跟那时不同的是，Zuul的逐步流量卸载开始慢慢转移流量，直到服务处于健康状态，而这个过程中会员的播放能力一点都没受影响。
从下图可以看出，在发生事件期间，当Zuul在根据请求优先级执行逐步的流量卸载时，反映流媒体播放稳定性的每秒可用性指标（SPS）的情况。图中的不同颜色表示不同优先级请求被限制的情况。

文章插图
这样，当基础设施一边从系统故障中自动恢复时，会员们仍能高兴地在Netflix上观看自己喜欢的节目。
后续工作至于未来，我们的团队正在考虑把请求优先级的运用扩展到其他用例上面，比方说设备和后端之间更好的重试策略，动态更改卸载阈值，利用混沌测试作为指导原则来调整请求优先级，以及其他能让Netflix更具弹性的领域。
如果你对帮助Netflix应对不断变化的系统和意外故障感兴趣的话，请与我们联系。我们正在招聘！
译者：boxi。
【 博客|Netflix 技术博客：区分优先级的负载分流，保持服务的稳定可靠】