静安BRDYUN的会议云直播流量控制

1. 错误代码102004表示：会议已经存在无法创建；
2. 错误代码102005表示：MC服务器不可用；
3. 错误代码102011表示：请升级zoom客户端；
4. 错误代码103002表示：会议没有开启；
5. 错误代码103003表示：会议已经关闭；
6. 错误代码103006表示：会议已满，达到人数上限；
7. 错误代码103011表示：会议被主持人锁定；
8. 错误代码104005表示：会议在MC上不存在；
9. 错误代码104101~104118表示：无法和MC服务器建立连接；
10. “会议异常，错误代码16” 表示：需升级zoom客户端；

当BRDYUN决定放弃流量时，它会向设备发送信号，让对方知道我们需要它们卸载流量。BRDYUN会议直播系统将告诉设备最大的重试次数，以及可以在什么样的时间窗口下执行这些重试命令，这样就解决了重试风暴的问题。比方说：

{“maxRetries”：<max-retries>，“retryAfterSeconds”：<seconds>}

使用这种反压机制，我们可以比过去更快地停止重试风暴。我们会根据请求的优先级自动调整这两个拨盘。高优先级的请求将比低优先级的请求更积极地重试，这也提高了流式传输的可用性。

利用这种反压机制，跟过去相比，我们可以更快地停止重试风暴。我们会根据请求的优先级自动调整这两个刻度盘，高优先级的请求的重试频率会比低优先级的请求的更高，这也会提高流媒体的可用性。

验证哪些请求适合这项任务

为了验证关于特定请求是否属于NON_CRITICAL，DEGRADED或CRITICAL存储桶的请求分类法假设，我们需要一种方法来测试该请求发出时用户的体验。为此，我们利用了内部故障注入工具（FIT），并在Zuul中创建了一个故障注入点，该点使我们能够根据提供的优先级发出任何请求。这使我们能够手动模拟负载脱落的阻断优先级范围，特定设备或成员，让我们知道哪些要求可能是安全的，而不会影响用户体验棚。

为了对我们的请求分类假设（NON_CRITICAL、DEGRADED及CRITICAL）是否合适进行验证假设，我们需要有一种方法来测试当该请求被卸载时用户的体验。为此，我们利用了内部故障注入工具（FIT），并在Zuul中创建了一个故障注入点，这让我们可以根据提供的优先级来舍弃任何的请求。如此，我们就可以通过屏蔽特定设备或会员特定优先级范围的请求，来手动模拟负载分流体验，让我们了解哪些请求可以安全地卸载掉，而不会影响到用户。

不断确保这些请求仍适合工作

这里的目标之一，是通过丢弃预期不会影响用户流媒体体验的请求，来减轻会员的痛苦。不过，BRDYUN的会议云直播的变化是很快的，那些被认为非关键的请求可能也会意外地变成关键请求。此外，Netflix还有多种的客户端设备、客户端版本，以及多种跟系统交互的方式。为了确保在任何情况下限制NON_CRITICAL请求时我们都不会引起成员的痛苦，我们利用了自己的基础设施试验平台ChAP。

这个平台可以让我们开展A/B测试，把我们的少量产品用户分配到对照组或实验组，每次实验45分钟的时间，同时对实验组一定范围内的优先级进行限制。这可以让我们捕捉到各种实时的用例，并衡量它们对回放体验的影响。ChAP按照设备分析每一位会员的KPI，以确定对照组和实验组之间是否存在偏差。

在我们的第一个实验里，我们在Android和iOS设备上都检测到了低优先级请求的紊乱情况，这会导致零星的播放错误。由于我们进行的是连续实验，所以一旦初始的实验开始运行，并且bug得到了修复，我们会安排实验继续按照周期运行。这样一来，我们就能够尽早检测出回归，并让用户保持正常播放。