从集中到分布，解读网络视频IT架构变迁 作者：朱智力　来源：IT1682006年以视频网站为代表的网络视频行业迅速崛起，IPTV、视频分享网站、视频搜索网站、提供视频服务的互动社区、交友、播客等等新兴媒体发展迅猛。网络视频行业现已成为众多资本机构关注与投资的焦点。但是在网络视频行业发展前景一片大好的同时，一些运营问题也随之显现，步入2007年，资本机构对网络视频行业不再盲目狂热，对商业模式的创新和成本控制提出了更高的要求。今天，纯文字的表现形式已经不能满足用户对更丰富多彩的网络内容的需求，我们需要更丰富的数字出版物、图片、声音以及视频来表达和交流；同时，单向传播也不能满足用户对互动式网络体验的需求，我们需要更丰富灵活的交流与互动体验；IT架构必须能够承载和传播这些爆发式增长的非结构化的数据。同时，用户访问量的增长却从没有停止过，相对于传统应用，网络视频行业应用有着非常庞大的用户数量上涨空间，IT设施面临着强大的成本控制的压力。那么，我们究竟该如何应对网络视频行业的商业模式创新和成本控制的挑战呢？视频网站的典型应用架构我们将以网络视频行业中最具代表性的视频分享网站为例，通过某视频网站的存储环境改造案例来看看网络视频需要什么样的IT结构、分析什么样的存储系统能够更好的来支撑商业模式的创新，并合理的控制成本。视频网站的典型应用架构首先，我们来看看该视频网站的IT结构：如上图所示，分别由流媒体服务器、Web服务器、在线录制服务器、视频转换服务器、数据库服务器、管理服务器、图片服务器和其他服务器等一系列不同数量的服务器组成。这一架构在目前的视频网站中带有一定的典型性。但是由这几个部分组合起来的IT结构，如何才能支撑视频分享门户的竞争优势呢？满足交互性体验和服务压力以下我们将从应用需求和技术特点两方面来分析，该架构如何满足该视频网站的运营需求：1. 交互性体验方面：首先，为满足用户对交互体验的需要并保持自身的原创优势，需要为用户提供视频上传和在线录制视频的功能；其次，需要把不同格式的视频，转换成该网站统一的格式；最后，需要在上传后尽快发布以供播出。2. 服务压力方面：首先，不但需要应对已有的大数量的用户访问，而且将迎接持续的访问量增长；其次，当用户访问量增加时，需要保持良好的反映速度和响应时间；最后，必须面对清晰度日渐提高后，码流增大所带来的服务压力。在各个技术层面上，我们如何更好的满足上述诸多需要呢？1.  在编解码技术层面：编解码技术不断推陈出新，我们可以看到解码效果更好，编码压缩率更高的编解码方式等诸多方面均有良好进展。尤其是由中科院计算所牵头制定的AVS标准，是具有我国自主知识产权的新一代编解码标准，将促进我国网络视频行业的健康发展。2.  在媒体的传输层面：CDN技术已经比较成熟，P2P技术的发展也非常的迅速，虽然存在缺乏统一标准等问题，但无法掩盖P2P技术的锋芒。目前，已有不少的视频平台运营商采用了P2P技术。此外，CDN＋P2P的复合技术也有了比较好的发展。3. 在媒体的服务提供层面：服务器集群技术已经相当成熟：双机到多机的数据库集群、由DNS轮询或相关技术实现的Web服务器集群、由相关查询指向技术实现的流媒体服务器集群等都可以比较方便的实现。成熟的服务器集群技术可以实现按需增加相应应用服务器来应对业务需求，足以为网络视频行业提供良好的支撑。4. 在媒体资源存储方面：需要有大容量、高带宽、可共享的存储技术来支撑，而传统的存储结构和存储技术，却不能很好的满足视频网站的存储需求。那么视频网站在存储方面都有什么具体的要求，存储环境怎样才能够满足这些要求呢？下面我们通过一个实例来详细分析视频网站对存储环境的需求：集中式存储把鸡蛋放到一个篮子里传统存储的体系结构无非有两种：集中式和分布式。网络视频存储方案面临着集中式存储和分布式存储两种选择，两种结构各有优缺点，选择起来其实是比较困难的。本案中的视频网站的存储结构就经历了“集中–分布–分布式的集中存储”的循回式的变迁：该网站建立之初，采用了集中式的存储结构。某视频网站原有集中式存储系统很多网络视频的存储采用的大多类似于上图的、集中式的存储结构来存放所有媒体数据，通常为NAS架构。简单地说，就是一台大容量的文件服务器，而高端的NAS结构是由一个NAS头后面接SAS、SCSI或光纤盘阵。集中式存储的优点是比较明显的：1.  集中存储可实现服务的负载均衡，由于流媒体服务间的数据都是共享且统一的，当发生热点繁忙时，所有流媒体服务器都可为其提供服务，分减压力，而不像分布式的存储会出现热点繁忙，没有热点内容的存储出现空闲这种不均匀情况。2.  集中存储提高了存储资源的利用率。3.  集中的高Raid 级别保护且成本较低，分布式存储都实现Raid保护成本高昂。4.  集中的备份（快照）恢复，能方便的实现远程容灾。5.  集中存储方案管理复杂度相对较低，以管理Mount点为例：需管理Mount点的数量为16（M+N+F+W）个，即上图中的16根蓝线。6. 集中存储同时也是对流媒体服务器视频内容的集中管理。

从集中到分布，解读网络视频IT架构变迁(下) 作者：朱智力　来源：IT168从集中到分布，化解存储瓶颈接上篇：从集中到分布，解读网络视频IT架构变迁(下)。集中式存储已经拥有了诸多优势，那么为何这家视频网站最终却选择了其他的存储架构呢？该视频网站究竟在运营过程中遭遇到了什么样的阻碍呢？经过我们对整个网站存储结构的分析，原来，NAS头成为整个存储环境的瓶颈……从以下两幅图中，我们可以看到传统的集中存储方案中，存在如下问题： I/O瓶颈 容量扩展性差 性能不可扩展 专业高端NAS成本高昂 单点故障 NAS成为系统瓶颈传统集中式存储的瓶颈随着数据量的增加，存储压力也变得越来越集中，NAS已不足以支撑现有的应用，无法更好的应对未来的挑战。既而，该网站从集中式的存储方式转向了采用分布式的存储方式。分布式存储系统架构图中，每台服务器上都提供文件共享服务，由应用层来实现媒体资源数据在各个服务器集群之间的迁移，从而比较好的解决了集中存储的IO瓶颈问题，但是问题也随之而来。分布式的存储没有负载均衡，例如：发生热点的时候、部分流媒体服务器忙或部分闲置分布式存储利用相对较低率，重复数据大量存在，且份数多无法实现集中的高Raid 级别保护快照、备份、恢复、远程容灾比集中存储实现成本高需要在应用层对存储层过多关注。管理复杂度程几何级增长，整体系统维护工作越来越复杂、繁重。以管理Mount点为例：同样的服务器数，需管理Mount 点的数量为48  [M*(N+F)+W*N]个，即上图中的48根红线，远大于集中存储结构。这仅仅是Mount点一项，还不包括各个点存储数据的维护，在实际应用中相关的工作量是相当惊人，管理员疲于奔命。集中VS.分布？还是分布式的集中？既然传统的集中和分布都存在不同的问题，怎么样去解决？在给出答案之前，我们重新归纳前面分析的视频网站对存储的需求：1. 各种服务器集群之间有视频传递的需求，需要上传服务器、流媒体服务器、在线录制服务器和转换服务器之间的视频文件是互相可见的，翻译成存储的语言则需要文件级共享的存储。2. 各种应用服务器可能使用着不同的操作系统平台，都需要无差异的访问到存储空间，而翻译成存储的语言则需要跨平台共享的存储。3. 多台流媒体服务器之间的存储容量需要共享，从而提高存储空间的利用率。如采用传统SAN上面划分独立的存储空间，给每台服务器的类似做法显然是不可接受的，并且需要视频内容合理的分布在各个存储设备上，翻译成存储的语言则需要存储容量的负载均衡。4. 单台存储设备的存储速度始终是有限的，需要多个存储设备的聚合才能满足视频内容访问量的爆炸式的增长，翻译成存储的语言则需要多台存储设备间的存储速度的聚合，从而实现存储速度的负载均衡。5. 新增视频内容的不断添加会导致存储容量的不断扩大，在添加设备扩展容量的时，能够不影响原有系统，且平滑扩展，能够实现在线的扩展业务系统不停机，翻译成存储的语言则需要容量线性可扩展，能够实现在线扩容。6. 随着用户访问量增长和视频清晰度提高带来的带宽增长等诸多增长因素的影响，对存储带宽的增长需求，要求存储系统实现带宽随容量呈线性增长。7. 合理的成本控制是一个恒久的话题，需要存储系统的总体拥有成本随容量的扩展而合理的扩展，不能出现突变式的增长。8. 稳定性自然不用说，需要存储系统采用冗余结构以提高系统的稳定性。为了满足上述需求，当我们面对“集中VS.分布”这个艰难抉择的时候，技术的不断进步，涌现出：分布式的集中存储结构——集群存储技术，其核心技术是集群文件系统。集群存储系统满足视频行业服务需求目前，广为流行的集群文件系统的典型代表主要有： Google 的GFS （Google File System） 国内中科院研发的BWFS（Blue Whale File System） Panasas 的PanFS （PanFS File System） IBM 的 GPFS （General Parallel File System) CFS 的 Lustre （Lustre File System） 这五种集群文件系统各有特点和优势，一般而言，分布式集中存储相对于传统存储系统来说拥有如下优点：采用统一的全局命名空间，支持文件级共享，且采用分布式存储结构，能实现高聚合I/O带宽，并且跨Linux平台和Windows平台的文件共享，还能够线性扩展I/O带宽，拥有良好的系统负载平稳性，并能够动态扩展存储容量，实现成本可控。基于分布式结构的集中存储如上图所示：该架构能较好的满足网络视频对存储系统的需求。1. 文件共享、统一的全局命名空间——上传服务器和流媒体服务器之间的文件可见性；多台流媒体服务器间的存储容量共享2. 多台存储设备间的存储速度的聚合——流媒体服务器可用的存储速度负载均衡3. 跨平台共享（Windows/Linux）——支持不同平台的流媒体服务器、上传和其他服务器4. 容量线性可扩展——使流媒体服务能应对不断扩大的存储容量需求5. 带宽随着容量线性增长——使流媒体服务能应对不断扩大的用户访问量；          可以按需扩大流媒体服务器的数量而不用担心存储6. 成本需随着容量的扩展而扩展——良好的成本控制7. 全冗余结构——稳定的强壮的存储系统该视频网站最终选择基于BWFS集群文件系统的BWStor蓝鲸集群存储系统。BWFS是由我国中科院计算所工程中心自主研发的文件系统，并经由中科院中科储天公司产品化。中科院中科储天蓝鲸集群存储系统（BWStor）即采用BWFS文件系统为核心技术，是中国自主知识产权存储产品的代表之一。

YouTube架构分析 YouTube的成长速度惊人，目前每天视频访问量已达1亿，但站点维护人员很少。他们是如何管理，以实现如此强大供应能力的？被Google收购后，又在走什么样的发展道路呢？转载一些相关的文章，参考学习一下原文: YouTube ArchitectureYouTube发展迅速，每天超过1亿的视频点击量，但只有很少人在维护站点和确保伸缩性。平台ApachePythonLinux(SuSe)MySQLpsyco，一个动态的Python到C的编译器lighttpd代替Apache做视频查看状态支持每天超过1亿的视频点击量成立于2005年2月于2006年3月达到每天3千万的视频点击量于2006年7月达到每天1亿的视频点击量2个系统管理员，2个伸缩性软件架构师2个软件开发工程师，2个网络工程师，1个DBA处理飞速增长的流量Java代码  while (true)   {     identify_and_fix_bottlenecks();     drink();     sleep();     notice_new_bottleneck();   }   while (true) { identify_and_fix_bottlenecks(); drink(); sleep(); notice_new_bottleneck(); }每天运行该循环多次Web服务器1，NetScaler用于负载均衡和静态内容缓存2，使用mod_fast_cgi运行Apache3，使用一个Python应用服务器来处理请求的路由4，应用服务器与多个数据库和其他信息源交互来获取数据和格式化html页面5，一般可以通过添加更多的机器来在Web层提高伸缩性6，Python的Web层代码通常不是性能瓶颈，大部分时间阻塞在RPC7，Python允许快速而灵活的开发和部署8，通常每个页面服务少于100毫秒的时间9，使用psyco(一个类似于JIT编译器的动态的Python到C的编译器)来优化内部循环10，对于像加密等密集型CPU活动，使用C扩展11，对于一些开销昂贵的块使用预先生成并缓存的html12，数据库里使用行级缓存13，缓存完整的Python对象14，有些数据被计算出来并发送给各个程序，所以这些值缓存在本地内存中。这是个使用不当的策略。应用服务器里最快的缓存将预先计算的值发送给所有服务器也花不了多少时间。只需弄一个代理来监听更改，预计算，然后发送。视频服务1，花费包括带宽，硬件和能源消耗2，每个视频由一个迷你集群来host，每个视频被超过一台机器持有3，使用一个集群意味着：-更多的硬盘来持有内容意味着更快的速度-failover。如果一台机器出故障了，另外的机器可以继续服务-在线备份4，使用lighttpd作为Web服务器来提供视频服务：-Apache开销太大-使用epoll来等待多个fds-从单进程配置转变为多进程配置来处理更多的连接5，大部分流行的内容移到CDN：-CDN在多个地方备份内容，这样内容离用户更近的机会就会更高-CDN机器经常内存不足，因为内容太流行以致很少有内容进出内存的颠簸6，不太流行的内容(每天1-20浏览次数)在许多colo站点使用YouTube服务器-长尾效应。一个视频可以有多个播放，但是许多视频正在播放。随机硬盘块被访问-在这种情况下缓存不会很好，所以花钱在更多的缓存上可能没太大意义。-调节RAID控制并注意其他低级问题-调节每台机器上的内存，不要太多也不要太少视频服务关键点1，保持简单和廉价2，保持简单网络路径，在内容和用户间不要有太多设备3，使用常用硬件，昂贵的硬件很难找到帮助文档4，使用简单而常见的工具，使用构建在Linux里或之上的大部分工具5，很好的处理随机查找(SATA，tweaks)缩略图服务1，做到高效令人惊奇的难2，每个视频大概4张缩略图，所以缩略图比视频多很多3，缩略图仅仅host在几个机器上4，持有一些小东西所遇到的问题：-OS级别的大量的硬盘查找和inode和页面缓存问题-单目录文件限制，特别是Ext3，后来移到多分层的结构。内核2.6的最近改进可能让Ext3允许大目录，但在一个文件系统里存储大量文件不是个好主意-每秒大量的请求，因为Web页面可能在页面上显示60个缩略图-在这种高负载下Apache表现的非常糟糕-在Apache前端使用squid，这种方式工作了一段时间，但是由于负载继续增加而以失败告终。它让每秒300个请求变为20个-尝试使用lighttpd但是由于使用单线程它陷于困境。遇到多进程的问题，因为它们各自保持自己单独的缓存-如此多的图片以致一台新机器只能接管24小时-重启机器需要6-10小时来缓存5，为了解决所有这些问题YouTube开始使用Google的BigTable，一个分布式数据存储：-避免小文件问题，因为它将文件收集到一起-快，错误容忍-更低的延迟，因为它使用分布式多级缓存，该缓存与多个不同collocation站点工作-更多信息参考Google Architecture，GoogleTalk Architecture和BigTable还有从DBA Notes看到过的一些：一、系统主要用Python开发，用psyco提高性能看到这个我总算知道Google为什么要收购YouTube了，都喜欢用Python嘛，本 来就有缘。用Python开发的速度显然比用C/C++、 Java等高不少，这一点eBay就比较传统，用C++/Java来写，结果落得需要几百个工程师，编译一次很久。最感兴趣的是用了psyco这个东西，所说这玩意相当于Java中的JIT编译器，通常能将Python代码的执行速度提高4倍，对于算法集中的代码甚至能提高10到100倍。二、使用lighttpd给视频内容本身提供服务时用了lighttpd，不能Apache，据说性能提高不少，但有了说这个还不好，应该用nginx，俄罗斯人写的一玩意。三、最流行的内容自己不管，放在CDN上YouTube很会享受，最常访问的内容自己的系统不管，放在运营商和Google（估计是被Google收购之后吧？）的内容分发网络上。他们自己的服务器只要处理一些不常访问的漏网之鱼就可以了，负载大大减轻。四、缩略图是最大的问题，自己搞不定，最后用Google的BigTable搞定俗话说人小鬼大绝对是有道理的，那么大的视频没什么问题，小小的缩略图却是个大问题。原来YouTube的开发人员用lighttpd，发现效果不太好，就改了代码，但效果还是不行。最后被Google收购后用了BigTable才算搞定这个问题。五、MySQL swap问题，把swap关掉就行了YouTube用MySQL存元数据，结果在Linux上swap颠簸很厉害，解决的方法也简单，把swap关掉就好了。而且人家胆子大，服务还在那里跑，这边就把它关了。六、MySQLYouTube 用MySQL也是摸着石头过河，一开始只用一个主服务器和replication，显然过一阵子这个方法就不行了。后面他们尝试把视频和非视频业务分开处 理，但这个方法也顶不了多久。最终还是走到数据分区这条正道上来。对数据库服务器的磁盘系统的选择也很有意思，最早是用10块盘做RAID 1+0，但发现盘太多了也使不上劲，所以后来改后一堆RAID 1。

Facebook 的 PHP 性能与扩展性 炙手可热的 Facebook 是用 PHP 开发的。随着一些技术交流，逐渐能看到 Facebook 技术人员分享的经验。近期这个 geekSessions 站点上看到 Facebook 的 Lucas Nealan 分享的文档比较有参考价值。Cache 为 王任何一个成功的站点都有一套最合适自己的 Cache 策略。Note：这个层次图画的稍微有点问题，不是严格从上到下的。The Alternative PHP Cache , APCFacebook 平均每个用户每天要访问超过 50 个页面，PHP的页面载入时间的优化就比较重要了。在 PHP Cache 层，Facebook 采用了 APC。关于facebook APC 介绍的PDF.Lucas Nealan 的 PPT 举了一个例子，一个页面显示的时间从 4000 多毫秒降到了 100 多 毫秒。在 apc.stat 关闭的模式下，性能还要更好一些。不过需要重启动或用apc_cache_clear() 来通知更新。Memcached 层APC Cache 的是非用户相关的信息，而用户相关的数据 Cache 当然是在 Memcached 中。Facebook 部署了超过 400 台 Memcached 服务器，超过 5TB 的数据在 Memcached 中。这是当前世界上最大的 Memcached 集群了。也给 Memcached 贡献了不少代码，包括 UDP 的支持和性能上的提升(性能提升超过 20%)。程序 ProfilingFacebook 开发人员大量采用 Callgrind 、APD、 xdebug 、KCachegrind 等工具进行基准性能测试。任何一个 Web 项目，这也是不可或缺，也是比较容易忽略的一环。所有开发人员都应该具备熟练使用这些工具的能力才好。补充一下：语言的选择为什么 Facebook 选择 PHP 而不是其他语言? 用Flickr 的 Cal Henderson 这句话就能说明了: “Languages’s don’t Scale, Architecture Scale”。从 80-20 的原则看，APC 和 Memcached 是最主要的。在这两个环节上下功夫，受益/开销比要大于另外几个环节。(上面的图是从 Lucas Nealan 的文档截的，版权所有是他的)作者: Fenng网址: http://www.dbanotes.net/arch/facebook_php.html

动态基础架构 帮助构建“智慧的地球” 世界正在变得更小、更扁平—但也必须变得更智能。每天，世界都变得更加仪器化、互连和智能化，从而在社会和组织层面都创造了新的机遇。在这个日益数字化的世界中，我们可以解决棘手的问题，使企业更加靠近客户，并且显著缩短决策周期，帮助高级主管实现竞争优势。当前的企业面临的主要挑战是：• 实现卓越的区别化服务交付• 降低成本，并且提高所有业务资产的投资回报• 管理并控制业务风险• 敏捷且快速地采取行动应对任何一项挑战—更不必说应对所有挑战—都要求企业的底层业务和IT基础设施具有极高的灵活性和响应能力。但是，当前基础设施中的许多资产缺乏弹性、处于孤立状态，并且过时，导致成本和复杂性高得难以承受，同时阻碍企业的灵活运作。当前的基础设施并未做好应对未来挑战的准备。对于许多企业来说—变革势在必行。变革可能实现，工具已经存在，而且任务已经明确。这些对于解决当前的问题是必要的条件，但不是充分条件—我们还必须抓住未来的机遇。为了实现这两方面的目标，现在我们应该开始以不同的方式来思考基础设施。IBM已经制订出了针对动态基础架构的战略，将帮助企业满足客户对服务的更高期望，解决居高不下的成本压力以及新的风险和威胁，同时为实现突破性的生产力、更快地创造价值以及更高的响应速度奠定基础，从而实现企业和社会所要求的更快速度。在这个智能的世界中，我们的基础设施需要促进我们的发展，而不能阻碍发展。这样的基础设施正变得仪器化、互连和智能化，从而将业务和IT基础设施结合在一起，为企业创造新的机遇。