原文：Globo.com’s Live Video Platform for FIFA World Cup ’14- Part II – DVR and Microservices
作者： Floyd Smith 译者：杰微刊兼职翻译汪建
下文改编自环球网的Leandro Moreira 和Juarez Bochi两位工程师 2015年九月份在San Francisco市举办的nginx会议的演讲。这篇博客是两部分的第二部分，这部分主要关注与使用nginx构建微服务。第一部分主要讲了传输及缓存方面的工作，可以在https://www.nginx.com/blog/globo-coms-live-video-platform-fifa-world-cup-14-part-delivery-caching/这里找到，同样你也可以从YouTube上观看完整的研究视频。
内容表
19:02 DVR
20:24 DVR的挑战——故障转移
21:06 DVR的挑战——存储
22:11 使用Redis作为数据存储
23:20 巴西大选
24:12 从Redis到Cassandra
25:11 等候区
27:40 等候区的架构
29:02 国际足联2014世界杯成绩
31:00 回顾和下一步
31:58 NGINX + Lua 表现惊人
33:17 开源软件开发
33:55 总结和未来
34:50 问答
19:02 DVR
Juarez：到2013年，我们对我们的基础设施和我们提供的用户体验感到很满意，于是我们开始思考我们还可以为2014年世界杯做些什么其他事情。
我们决定开发的其中一个功能就是DVR，DVR代表数字视频录像机，它可以提供暂停视频播放、回放和重新观看视频的功能。
要做到基于HLS协议的DVR，我们只需使用一个更大的播放列表，正如你之前见到过的那样，播放列表只是一个排列多个片段的文本文件。对于DVR，要将这些几分钟的视频替换成一个完整的比赛视频的片段。
重新回顾我们的解决方案，我们可以说主要有两大块：采集和前端。两者之间的接口就是存储，存储存放的都是被我们分割后的片段，分割后的文件通过NGINX提供给用户访问请求。
20:24 DVR的挑战——故障转移
因此存储是一个问题，因为我们没有故障转移能力，如果视频流停止了，那么我们不得不重新开始，我们正在使用的EvoStream服务器，只会删除播放列表并重新开始一个新的列表。
如果不提供数字视频录像机DVR功能的话，这个不算是一个问题，因为就算发生故障用户也只会看到缓冲提示并且很快就会重新连接，然后视频流又恢复正常。但是如果你丢失了旧的播放列表，那用户就不能找回原来的播放点，所以对于DVR，我们必须保持所有片段和播放列表的状态。
21:06 DVR的挑战——存储
我们也有点担心存储大小问题，因为对于单一流来说，一场比赛我们会按照比特率对其进行切分，这里会切分成6种比特率，每个比特率对应着不同的质量。用户根据自己带宽情况，可以观看符合条件的任一个资源，大约每5秒视频就有4.5兆字节，所以对于两小时的比赛，这将达到大约6G字节。
我们环球公司播放两个同时进行的比赛和其他播放的视频流，所以我们需要大约40G字节，这并不算很多，我们可以将他们全部都放到RAM中，所以我们决定使用Redis作为视频的存储。
Leandro：我们刚刚替换了我们旧的架构，旧的架构将数据保存到一个目录下，而现在我们将数据块和HLS文件保存到Redis中。
22:11 使用Redis作为数据存储
Juarez：我们用Python建立了一个守护程序，它只是一个简单的脚本，它可以监听文件，当文件被分割成片段后将它们移动到Redis数据库。然后我们使用NGINX配合Lua模块从Redis获取视频流列表，动态查看播放列表。这项工作紧紧花费了我们一两天的时间。
Leandro：使用Python感觉很好，但与此同时我们发现很难对其进行扩展，我不知道是不是因为我们没有足够的经验，对于我们来说，Python确实很难在将其扩展到多核，所以监听文件变化并保存为HLS协议文件的守护程序给我们带来很多痛苦。如果让我们重新做一遍，我们可能会选择另外一种语言，但在当时这是最简单的解决方案，现在它仍然在工作。
Juarez：是的，这个已经成为一个问题，尤其是在巴西大选直播期间。
23:20 巴西大选
所以，后来，当我们在直播巴西大选时，我们有超过30个同时播放的视频流，每个视频流有各自的状态。如Leandro所说，Python脚本成为了一个瓶颈，并且在使用Redis上我们也遇到了问题，因为我们无法把所有这些都放进内存，所以我们决定从Redis转向Cassandra。
需要澄清一下，世界杯直播时我们仍然使用Redis，巴西大选时发生在世界杯之后，我们认为这个比较有趣所以在这里分享。
24:12 从Redis到Cassandra
除了解决其扩展性问题，我们没有必要对守护程序做过多其他的改动。但在前端我们必需为Lua开发一个新的驱动程序。在那时候我们没有找到任何NGINX的Lua驱动模块，所以我们必须自己编写。从那时起，越来越多人使用这个模块，这让人看着很高兴。
25:11 等候室
我们必须做的另外一件事情是建立一个等候区，我们没有使用CDN，我们已经和巴西的几个互联网服务提供商合作，我们有两个数据中心。
有时用户可能通过一个低宽带的ISP连接我们观看视频，这样会导致在此ISP上的所有用户都体验很不好，所以我们决定创建一个等候区，如果太多用户从同一个连接观看视频，我们会将他们放进一个队列里。
Leandro：我们在后面将涉及更多等候区的相关细节，但首先，我们要讨论下我们多连接的解决方案，使得用户能根据IP选择走哪个线路。
选播的工作原理是这样的：你要有一个BGP协议，该协议用于决定路线，然后我们要有ISP，由于我们是一个互联网公司，我们属于一个自治系统，所以我们可以用公司的ISP进行数据交换。
所以由我们决定线路，然后我们的ISP将承认这条线路，现在，如果在圣保罗附近有很多用户，当他们试图访问给定的地址是，ISP会智能的将他们的请求路由到最近的PoP。
现在我们可以更加深入地讨论等待区了。
这里我们可以看到ISP Y只有非常低的带宽连接到我们，所以连接他们的用户在看直播时将会体验很差。但他们不会抱怨他们的ISP，他们会通过推特来抱怨我们，这显然是不理想的，所以我们想出了等候区方案。
27:40 等候区的架构
这里我们可以看到ISP Y只有非常低的带宽连接到我们，所以连接他们的用户在看直播时将会体验很差。但他们不会抱怨他们的ISP，他们会通过推特来抱怨我们，这显然是不理想的，所以我们想出了等候区方案。
27:40 等候区的架构
我不知道你们是否像我们一样喜欢足球，但我们对这个结果不满意，但这就是生活。
我非常兴奋我们有很多的带宽供我们使用，该图大致显示了我们对比赛进行直播时的几个峰值，这并不是所有比赛的情况，但我对这个结果非常满意。
我们有超过50万用户同时在线，并且我们可以很容易地支持更多的用户。我们本来预计有100万用户同时在线观看，但我们怀疑真实的在线用户可能比预期的要少，因为当巴西进行比赛时，人们可以从家里观看比赛，所以，很多人们更愿意通过电视观看，于是通过环球网观看的用户会少很多。
另一个很酷的数字是某场比赛达到640Gbps，我认真这是相当不错的。
既然我们有索伦仪表盘，我们可以通过监控软件Graphite进行估算，结果是所有观众观看的时间总和大致超过1600年，我们有超过四千万用户观看。
这里你可以看到我们的平均比特率，这里面也有我高兴的事情，就是我们每个节点使用了仅仅10%CPU就能达到20G每秒速度。
31:00 回顾和下一步
既然我们已经展示了我们的成绩，我觉得是时候回顾一下，并且讨论下我们下一步可以为我们的平台做什么事。
Juarez：我们在视频流方面使用了很多NGINX，我们用它来做传输、用来做缓存。我们开发了地理定位、授权、认证等多个模块。
我们也围绕它内置了很多微服务，我们使用NGINX和Lua用于播放列表的生成，也用于等候区。我们还有另外一个前面没有时间提及的系统，这个系统可以锁定一个用户可以拥有并发会话的数量，但这主要用于封闭播放，而不是用于像世界杯这样的直播。
31:58 NGINX + Lua 表现惊人
我们真的很喜欢NGINX和Lua，我们也很高兴尝试了nginScript，但到目前为止，我们更喜欢Lua，它也是在巴西被创造出来的。
Leandro：这个与目前的问题不相关。
Juarez：哈哈，是的，这个与目前的问题不相关。我认为我们应该看看技术方面的东西，我们一直在尝试并且非常喜爱的框架是Busted，它在测试驱动开发方面表现良好，使我们的生活更轻松。
Lua是一个小语言，所以很容易学习，与C语言比起来，我们在开发UGINX+Lua时体验更加好，使用Lua语言开发起来更快，然而你仍然可以获取接近C语言的性能，所以我们对此十分满意。
Leandro：Lua至少对我们来说更加容易，因为我们不是C语言专家。
33:17 开源软件开发
我们真的很喜欢NGINX和Lua，我们也很高兴尝试了nginScript，但到目前为止，我们更喜欢Lua，它也是在巴西被创造出来的。
Leandro：这个与目前的问题不相关。
Juarez：哈哈，是的，这个与目前的问题不相关。我认为我们应该看看技术方面的东西，我们一直在尝试并且非常喜爱的框架是Busted，它在测试驱动开发方面表现良好，使我们的生活更轻松。
Lua是一个小语言，所以很容易学习，与C语言比起来，我们在开发UGINX+Lua时体验更加好，使用Lua语言开发起来更快，然而你仍然可以获取接近C语言的性能，所以我们对此十分满意。
Leandro：Lua至少对我们来说更加容易，因为我们不是C语言专家。
33:17 开源软件开发
Leandro：综上所述，从2010年到2014年，我们从RTMP协议转移到HLS协议，然后我们推出这个叫DVR的功能。
现在，我们期待奥林匹克运动会的到来，我们正考虑提供不同类型的方式，例如Dynamic Adaptive Streaming over HTTP。我们可能会改变采集方面关于信号被摄入的方式，也许要让它支持4K。
Juarez：有一件事我们肯定知道的是，我们将继续使用NGINX。
Leandro：是的。
34:50 问答
1、有多少用户在看巴西队和德国队的比赛？详细情况你知道吗？
Juarez：我觉得在第三个进球之后，没有一个观众（笑）。不，只是开个玩笑。观看巴西队比赛的观众很少，因为几乎所有人都使用电视在看比赛，而不是通过互联网，大约有10万左右的用户使用播放器观看。
2、关于前端NGINX服务器，使用了NGINX Plus机器还是NGINX开源机器。
Leandro：使用了开源机器，我们使用了社区中的一款。
Juarez：是的，我们使用了默认的NGINX开源解决方案，我们也有我们的一些硬件负载均衡器，我们使用它们对跨NGINX多个实例的拆分负载。
3、你在讨论的irqbalance和CPU亲和力，你是怎么意识到这是一个问题的呢？
Juarez：我们注意到的第一件事是我们一直在丢失数据包，而且我们注意到的第二件事是机器只有一个CPU核在工作，我们发现使用最多CPU的进程是处理网卡软中断的那个进程，所以我们首先安装irqbalance将负载分到其他CPU核上，我们发现将中断指定到某个CPU核上性能会更好。
Leandro：所有这一切要归结到这一事实，那就是我们看到每个节点的极限是拥有20Gbps传输能力，但我们并没有达到20Gbps，所以我们就认为可能是NGINX存在问题，或者是其他问题导致的，因为它仅仅用于处理静态文件，这个不应该这么难，所以我们开始研究、故障排除，然后我们就能够理解和运用刚才前面讲到的优化方案。
Juarez：另外一个有趣的数字是，仅仅使用2台NGINX服务器，我们就可以处理10万用户的访问，这个等同于我们使用50台Flash媒体服务器处理的用户量。
