作者：Tsahi Levent-Levi（原文链接）
翻译：刘通
原标题：How to Prepare Your WebRTC Application for a Surge in Traffic
让我们从流量激增的坏处开始说起。你的服务是提供给人用的，而这些人却没有得到真正好的服务—他们受到的服务质量并不拔尖。他们经历的是无法加入会话，低比特率或者无法忍受的丢包率。这与你运行时遇到500和502错误还不一样，直到接到用户的投诉之前你可能根本不会意识到哪里出了问题。
所以现在怎么办？
我在这篇文章中要讨论两点：
1.学会如何预测服务突然莫名出现问题
2.为你的WebRTC应用发展做好准备
学会如何预测服务突然莫名出现问题
尽管你的生意中包括很多用户，但是如果你没有给你的WebRTC应用做好准备，大量的用户数给你服务带来的影响可能是毁灭性的。当然，有的时候会迫使你的服务完全下线，但是大部分情况中，服务还是会保持运行但是会给用户带来极差的使用体验。可能会让用户等待很长时间才能连接成功，要他们刷新网页才能链接，或者音视频的质量极差。
即使你明白了这点，也很难搞明白应该做些什么：
#你要投入更多的机器设备来解决问题吗？
#你需要检查你的网络连接吗？
#你要怎么才能找到受到影响的用户，然后告诉他们发生了什么事情？
这一堆烂摊子要花费你好多时间和精力才能解决。
以下是你可以尝试做的一些事情，以及预测可能会突然出现的小问题：
设一个基线
你需要知道你WebRTC服务的表现参数。为了做这个，最好的方法是以可接受的负载运行一会应用，然后记录下来重要的参数。
需要注意这几个参数：
#通道的比特率
#平均丢包率
#Jitter
现在你有一个基线了，是时候测试你的WebRTC应用到底能够有多大的流浪处理能力。当你不断堆加用户数的时候，它到底能够承受住多少负载。
一个简单的办法是安置一个testRTC的监控器，然后使用rtcSetTestExpection()来标识你所选择的基线的阈值。比如“我不想要超过平均0.5%的丢包率”或者“平均比特率必须高于500kbps”。突破所涉阈值的时候，你会得到提醒并且可以看到是因为流量增长，还是使用方式改变等等原因造成的阈值突破。
为你的WebRTC应用发展做好准备
通常情况下，有三大限制需要注意：
1.单独一个会话可以长到多大？
2.可以在单独的一个服务中塞进多少个用户？
3.我同时可以给多少个用户提供服务？
#1单独一个会话可以长到多大？
如果可以处理500个1对1对话，并不意味着就可以扩大到处理100组10用户会话了。会话人员数量的增长并不是线性的。达到承受极点的后果有可能会卡死你的服务器，或者只是提供不足以满足这些用户数的特别低的比特率。
要搞清楚你知道你想要运行的最大会话容量是什么。
除了进行自动测试和对比实际参数和基线参数以外，你还可以使用testRTC运行测试，并且可以同时使用你自己的浏览器加入会话以实际感受到通话质量如何。这么做的话就会加入一些人为因素。
#2可以在单独的一个服务中塞进多少个用户？
最大容量测试是针对多少会话/用户/其他内容你可以安置在一个服务器中。当你达到这个数的时候，你就应该启用另一个服务器并且使用负载平衡器来进行流量分摊。
基于你自己的场景和基础设备找到这个最大容量是十分重要的。
#3我同时可以给多少个用户提供服务？
现在你知道如何从一个服务器中分摊流量了，从这个角度看，流量的增加可以视为线性增加了。所以现在是时间可以尝试一下自动分摊和自动下降流量了，以及测试其工作情况是否良好。
这么做会极大的降低突发状况的潜在风险。
CDN及缓存
确保你的WebRTC应用所有的HTML资源都是通过CDN服务的。
在某些情况中，当我们给测试加大压力时，只是在提供WebRTC应用服务的HTML页前面放200个浏览器就会造成网页加载的间歇性失败。这是因为网页服务部分应用经常会被WebRTC开发者所忽视，他们总是将自己的时间和精力集中在更大的资源消耗者上面。
我们遇到很多例子是我们的客户网络在CDN中放入一小小的JavaScript文件。可不要成为这种人。
在地理上的布置
虽然网络和WebRTC是全球性的，但是流量可是局地的。
你可不想要在不必要的情况下就将你的用户发送给地球的另一端。你需要将你的媒体和NAT穿透服务器尽可能的部署在与用户近的地方。这给你需要优化网络末端的时候一定的灵活性。
确保你的部署是随着很多数据中心一起进行的，并且用户要被路由到正确的数据中心。
监控所有事情
CPU、缓存、内存、网络等等。
在其顶端加上从服务器收集来的应用参数。
然后加上一个testRTC监控器来检查端到端媒体质量来确保所有事情都在始终运行。
如果你的服务质量有所提升或者下降，那么就需要进行很大时间跨度的检查。
压力测试
加上你预计可以处理的负载，然后检查整个系统。
每次升级末端的时候都要进行系统检查，因为小小的一个改变都有可能造成整体表现的巨大变化。
不要让任何事情逃脱你的掌控
WebRTC有很多一直在改变的部分，所以部署工作并不是像更新一个WordPress网站一样简单。你应该为流量激增做好准备，意味着：
1.清楚你服务质量的基线是什么
2.知道你容量的最大值以及分摊策略
3.监控你的服务质量，这样你就可以在用户投诉之前进行改善工作
希望你能够严肃看待这件事情。
