YouTube高扩展之道

YouTube开始定位是在线婚恋网站,但是最后演化成一个视频分享网站,现在每天视频的播放数高达40亿。经历过疯狂的增长过程,Youtube创始团队的工程师Mike Solomon学到很多东西,在2012年PyCon上分享了YouTube的工程经验: Scalability at YouTube (虽然是几年前的演讲,但是很多经验是不会过时的。)

这个演讲不是以架构为中心,没有讲解很多模块互相连接的框图。Mike完全可以大讲架构,他曾经研发YouTube的Servlet框架、视频索引、视频转码、全文检索、CDN等等系统。但是,这个演讲中他放眼全局,分享了多年技术实践中总结的的深厚经验。

对于我来说,从这个演讲中学到的最重要的经验就是:用极简单的工具完成大部分工作。在其他公司都在向更复杂的生态系统迁移的时候,YouTube一直保持着简单的技术栈。他们主要用Python编码,用MySQL做数据库,用Apache做web服务器。在这样一个庞大的网站中,新功能都是从一个简单的Python脚本开始,慢慢演化的。

这并不意味着YouTube没有很酷的技术,他们有,但是他们信奉的哲学,或者说行事方式是实用主义的-让整个系统顺利运转,而不是紧追新奇的技术概念。下面讲讲YouTube怎样演化成世界最大网站之一的。

统计

  • 每天40亿次播放
  • 每分钟上传60小时的视频
  • 3500万+个设备安装有YouTube客户端
  • 2010年营收翻倍
  • 视频个数翻了9个数量级的同时,工程师数量只翻了两个数量级
  • 100万行Python代码

技术栈

  • Python-YouTube大部分代码都是Python代码,你每次观看视频的时候,都在执行一堆Python脚本。
  • Apache - 你认为Apache已经被淘汰了?其实Apache是非常厉害的技术,可以保持技术栈的简单化。在YouTube,每个来自外部的请求都是经过Apache的。
  • Linux - Linux的好处在于,你总可以深入系统查看运行状态,不管你的应用表现如何,你都可以用Linux工具(如strace和tcpdump)来查看它的具体情况。
  • MySQL - 处处都用到。当你观看一段视频的时候,很多数据都来自于MySQL,有时用作关系数据库,有时用于存储二进制BLOB数据。如何调优,如何组织数据对于MySQL非常重要。
  • Vitess - YouTube发布的一个Go语言项目,作为MySQL的前端代理使用。它负责实时地优化查询,重写查询。当前Vitess通过RPC处理YouTube的每个数据库请求。
  • ZooKeeper - 分布式的配置服务器,用于存储配置信息。非常有趣的技术组件,要用好也不太容易。
  • Wiseguy - CGI Servelet服务器。
  • Spitfire - 一个模版系统。支持虚拟的语法树,可以快速实现转换。
  • 串行化格式 - 所有现存格式都太低效。Pickle很糟糕;ProtoBuf也太慢。最后他们自己实现了BSON的编码解码器,比所有你能下载到的串行化方案快10-15倍。

经验教训

  • YouTube之道:选择最简单最通用的解决方案,以保证应对各种问题的灵活性。一旦一个方案过度贴近需求(over-specified),你就把自己堵在墙角了。不要对系统做出太多限定,当你做出各种限定的时候,系统就会自然地变得更加复杂,让你没有退路。这就是可扩展性的关键所在,可扩展的系统不会阻碍你的任何改动,是透明的。这不是时髦的词汇而已,是解决复杂问题的道之所在。
  • 大型系统的设计准则:每个系统都要符合特定需求,要根据你的业务量体裁衣。
  • YouTube没有异步,所有操作都是同步的。
  • 不要盲从教条,遵循设计哲学-保持简洁。如果你做Code Review的时候,发现数千行代码需要改动,涉及很多代码文件,那么系统设计应该有更简单的方案。你的第一个Demo一定要简单,然后在此基础上迭代。
  • 再次强调,解决问题之道用一个词归纳就是简洁。找到能处理问题的最简单的技术。需要解决的问题可能会复杂,但是第一个解决方案一定不会很繁琐,复杂性会随时间自然而然地产生。YouTube很多系统都是从一个Python文件开始的,经过很多年的演变,慢慢变成了巨大的生态系统。所有的原型都是Python写的,并且这样一个原型可以存活很久不被淘汰。
  • 设计Review需要讨论的问题:
    • 第一个解决方案是怎样的?
    • 如何在此基础上迭代?
    • 这些数据将来会被如何使用?
  • 拥抱变化。YouTube一开始是一个婚恋网站,如果以此为目标做设计,可能就没有今天的YouTube了。一定要保持灵活性。
  • YouTube CDN - 一开始完全外包。后来发现成本太高,自己实现。如果你有好的硬件工程师,你也可以做一个很不错的视频CDN。制造一个很大的机架,塞满服务器,装好Lighttpd,然后复写404 handler-找到刚才没有找到的视频。这个系统花了两个礼拜完成,上线第一天就扛住了60G的视频流量。这再次证明了一点:你可以用很简单的工具完成很多事。
  • 测量(measure)很重要。Vitess开始用HTTP协议实现接口,尽管是C写的,但是它非常慢。所以,后来他们直接用python的Socket连接替换了HTTP,整体上节省了8%的CPU。HTTP的报文的封装其实非常昂贵。

扩展性技巧

这里没有什么新理论,但是你会发现有些核心理念可以应用于很多不同的场景中。

  • 分而治之
    很多扩展性的问题不过是把工作分成小块而已,这个原则可以应用在系统的各个层次。在web层,你可以有很多完全相同而又相互独立的web服务器,可以水平扩容,这是分治。在数据库层分片(Sharding)的核心,也是分治。你需要尽早考虑的是,怎样把工作分成小块并且在各块之间确保通信,这将会影响今后系统扩展的能力。在这里,Python语言动态特性的优势就体现出来了。不管你的API设计得多么糟糕,你都可以用替换、修改、修饰(stub/modify/decorate)等方法来规避问题。
  • 大致正确即可(可以稍微作弊)
    系统的状态就是它报告给用户的状态。如果用户不能看出系统的偏差,那它就没有偏差。举个例子,如果用户A发布一个评论,与此同时另外一个用户B加载了这个页面,他在300-400毫秒内可能看不到这条评论。用户B不会在乎,但是用户A在乎自己的评论已经发布。所以你可以作弊一下,在用户A的页面显示这条评论。你的系统不必保持全局一致的事务性,因为实现这样的系统非常昂贵,而且毫无必要。因为评论不是财务交易,作弊无伤大雅。
  • 因地制宜
    你了解系统需要的一致性模型吗?对于评论来说,最终一致性(Eventually Consistent)应该足够,但是租赁一部影片可不行。租赁涉及到金钱交易,所以我们必须尽力保证一致。可见,不同数据的一致性要求是不一样的。
  • 抖动(在系统内引入熵)
    在YouTube技术团队内部,熵是一个常用词。如果系统没有抖动,你就会遇到踩踏事件(Thundering Herds)。分布式系统很像气象系统,在这样的系统里面debug就像是天气预报一样毫无确定性可言。抖动带来的随机性可以避免一些东西在系统中累积。
    以缓存失效为例。对于热点视频,我们尽可能的多用缓存。最火的视频可能缓存24小时,但是如果所有缓存的失效时长相同,那么所有缓存服务器将在同一时刻失效,这会造成回源的踩踏事件。
    加入抖动就是让这些缓存在18-30个小时之间的随机时间失效。这样可以避免回源的流量叠加。这样的技巧在整个系统中随处可见。分布式系统本身有一种“自同步”的倾向,很多操作会自动对齐(line up), 而这对系统自身是毁灭性的。这种现象很有趣,比如一台机器的磁盘变慢,这时候所有主机都在等待某个请求的返回,机器收到的其它请求就会被同步(对齐)。这种现象在系统里有很多机器、很多事件的时候就会发生。每发生一次,系统的熵就会减少一些,你必须把这些熵加回去才能保证系统健康运行。
  • 作弊(怎样制造假数据)
    这是很有用的技巧。最快的函数调用是不调用任何函数。如果你有一个单调上升的计数器,比如视频播放次数或者用户页面查看次数,你可以每次访问都更新计数器。或者,你也可以每隔一段时间更新一次,增加一个随机数,只要它是从奇数变成偶数,用户很有可能相信这个数字是真的。这是数据造假的技巧。(原来YouTube数据也会造假……)
  • 模块化的重要性
    在YouTube中的Python程序,会逐渐被RPC隔离开。代码结构的优劣往往依赖于程序员的自我约束,所以必须确立良好的代码规范,但另一方面,如果自我约束的效果不好,总可以用RPC把模块强制隔离开,来确保接口输入输出的清晰、规范。
    不是每个模块的实现都是完美的。模块可能存活一个月或者半年,这很难说。如果严格定义模块边界,你就有很大的灵活性,你可以把模块替换掉(比如用C重写),或者干脆抛弃。
    模块之间交互的数据需要定义严格的数据规范。
  • 效率有时需要让步于可扩展性
    效率经常要让步于扩展性。最高效的程序是用C写,把所有功能塞在一个进程里面,但是这样没法扩展。
    着眼于宏观,看看你的各个组件是如何分离的。是用RPC比较好还是内联调用比较好?可能将来这个问题的答案和今天不一样。
    注重算法。Python并没有花力气优化算法的实现,和C相比很多算法很低效,但是方便使用。可以用C来优化核心算法。
    度量。在Python里面很多度量是违背直觉的,比如垃圾回收的代价。在YouTube的应用中很大一部分时间是用于串行化的,串行化的调优就非常重要。
  • Python实用建议
    尽量写无脑的代码,这样更容易查找,更容易维护。代码越高深莫测,就越难搞清楚它是如何工作的。
    不要用很多OO的特性。我们使用了很多namespace, 也用Class来组织数据,但是几乎不用OO的特性。
    代码树应该什么样?要简单、实用、优雅、正交、易于组合。

参考资料

http:// highscalability.com/blo g/2012/3/26/7-years-of-youtube-scalability-lessons-in-30-minutes.html

https://www. youtube.com/watch? v=G-lGCC4KKok

http:// highscalability.com/you tube-architecture

http://www. slideshare.net/didip/su per-sizing-youtube-with-python/25-Questions

https://youtube.googleblog.com

稿源:架构之美 (源链) | 关于 | 阅读提示

本站遵循[CC BY-NC-SA 4.0]。如您有版权、意见投诉等问题,请通过eMail联系我们处理。
酷辣虫 » 后端存储 » YouTube高扩展之道

喜欢 (0)or分享给?

专业 x 专注 x 聚合 x 分享 CC BY-NC-SA 4.0

使用声明 | 英豪名录