全媒体云架构下的协同生产

2016-02-15毛烨北京中科大洋科技发展股份有限公司

视听界(广播电视技术) 2016年6期

关键词：台网数据中心架构

毛烨北京中科大洋科技发展股份有限公司

全媒体云架构下的协同生产

毛烨北京中科大洋科技发展股份有限公司

本文分析了传统媒体面临的困局，提出全媒体云架构下的协同生产是媒体提升生产力的关键。对协同生产的技术手段，构建云全台网新的设计理念，跨境混合云方式建设新闻云平台，基于互联网和客户端的应用场景进行了阐述。

全媒体云架构协同生产虚拟网络平台混合云应用场景

一、引言

目前，传统媒体的局面比较严峻，广播电视方面的用户耗时、渗透率增长都在下降。从具体的数据来看，从2015年到2016年广告份额已经出现了一个切换点，即2015年后电视广告的份额已经开始低于移动媒体广告份额，虽然差距还不大，但这是一个非常严重的警告。

二、传统媒体的困局

这几年60%官媒已经完成了两微一端平台的布局。在110家采样调查中，微博微信开通率达到了96%，中央媒体和粤沪地方比较高。我们知道微博一天图片量两千万以上，文章量十万以上，视频也有一万。能够看到传统媒体在行动，但互联网媒体平台在内容产量和渠道覆盖方面具有天然优势。

我们应该从根本上改变传统广电生产力，内容不好也不丰富，内容汇聚、制作、运营、发布的手段落后，即使具备了多种传播手段也不能改变局面。如何改变生产力？我的观点是媒体要讲究协同生产，协同生产是互联网媒体采用的一个根本战略，是大规模的社会化内容生产，是平台化的，甚至是生态化的。传统媒体强调的内容生产往往会局限于内容加工的技术实现。我们先看一下协同生产是什么？广义协同生产是大规模、社会化，包括共享经济、网络协同和众包合作三方面；狭义的协同生产是利用互联网及云等技术实现生产组织内部的工作协同，可以做到任何位置，任何终端，任何接入方式的生产制作。众包就是一种无组织有纪律的众包生产。亚马逊、宜家等都已开通了众包服务，他们将产品设计要求向社会发布，这种方式具有更低的成本，更快的速度等优势。由于制作过程复杂，内容审批复杂，组织结构的不灵活，传统广电的内容生产模式是无法带来大量的内容。这里提到几个概念，PUGC还有OUGC模式，包括前面说的众包，可以通过这几种模式结合，实现内容大规模社会化生产，提升传统广电的生产力水平。

三、媒体的协同生产

回到今天的主题，协同生产的技术手段。协同生产新的基础设施，云、网、端。网可以狭义理解为现在的全台网，IT基础设施就是数据中心，数据中心的云发展趋势已经不可逆转。早期的数据中心基本是一种孤岛式模式，资源没有任何的共享和云化。现在经过全台网的几轮升级，整体资源利用率在提升，但IT作为服务交付并没有实现，大量的系统配置和运维需要手工实现，实际项目中真正能做到云的并不多。而云就是需要真正实现计算、存储、网络安全等IT资源的池化，提高系统的整体交付水平，IT的自动化水平。

四、现状：基于中心交换的模块化设计

从上面这张图可以看出这是基于中心化、模块化的设计方案，即传统全台网的实现方案。从物理架构来说是通过核心交换设备把所有业务模块，相当于某一个制作网或者新闻网的物理平面连接起来。右边是一个业务逻辑架构，存在一个交换中心和业务系统逻辑上的分区，物理架构和业务逻辑架构非常相似。实际情况也是一样，业务平面和物理承载网平面基本是吻合的。在这几年其实我们做了很多提升系统效率的工作，比如虚拟化，但是都实现自由定义的网络，如果没有可定义的网络平面，IT资源即使实现池化也是不能流动的，即不能进行重组和定义，IT资源池是一种固定的池，一潭死水。构建与位置无关的资源池，这才是真正云的目标。如果把全台网基础设施分成四个层面，计算、安全、存储以及网络，跟交通系统非常相似，车辆、道路、法规、仓库，里面有一个比较关键的因素道路，如果道路系统建设的不好，就不能实现四通八达，效率很低，车辆、法规、仓库形同虚设。我认为在整个云网建设过程中，网络是一件非常重要的事情。关键是建立虚拟网络平台才能真正实现一个云，不管是公有云还是私有云，把云上的资源彻底池化，未来公有云架构和私有云架构会相通。在物理网络承载上建立Ovrlay网络，建立在已有网络上的虚拟网，这是全台网数据中心向云和虚拟化深入延伸的一个关键点，也是实现云网融合的一个关键点。在虚拟化数据中心做的一个系统，虽然说有一些平面已经实现了资源的池化，但是会发现一个业务系统从顶端一直延伸到所有层面，做的其实并不彻底。现在很多省和市台，如何调动两个数据中心的资源是一个很大的问题。因为我们知道老的数据中心有老的设备，但是新的数据中心可能已经开始建设了大数据系统以及更高端制作系统，老的系统能否利用这些资源，就看如何对网络做改造，理想状态是把两个中心数据打通，让原有的业务系统能够享受到任何新建的资源。根据业务的发展我们可能会继续建立第三个、第四个中心，在这些中心建立新的技术系统，新技术应该让所有系统可以共享，这一点在公有云中已经实现。如公有云里经常出现这样一个问题，在北京机房可以申请一个普通机房，在上海可以申请高端计算机房，是否可以放在一个VPC(虚拟专有云)里？我们希望在私有云的用户上可以DIY系统，可以建立自己的网络平台，任意选取技术资源，最后架构是跨数据中心全局资源的架构。

在构建一个云全台网的时候，对传统的按照业务模块的设计方案提出了挑战，我们应该采用一种新的设计理念，是基于资源的设计模型。我认为这也是下一步全台网改造的重点。在实际操作中我认为这两种方案应该结合，对业务系统设计应该要模块化来实现原来的业务网，比如新闻网，制作网等。采用资源模型去设计全台网，主要是服务于IT基础设施，将业务平台设计和基础设施的设计两者分开，而且由于系统可以自由的定义网络平面，就可以更自由设计我们的系统，基础设施层面只要考量整体需求就可以了，比如总体带宽、总体计算量，总体存储量，当然也包括新技术的应用。

五、跨境混合云方式建设新闻云平台

刚才提到的都是私有云，私有云的下一步是升级的混合云架构。上图中是混合云设计的一个方案，公有云之间实际差别是非常大的，这和选择不同品牌的产品相似，产品的具体问题要具体分析。以亚马逊为例，亚马逊全球是一张网，中国是一张网，国际出口走的是中国电信，可以买专线，但太贵，可以直接通过互联网，但是慢的难以忍受。如果我们的业务是全球业务，就要具体分析现在网络运营商或者云的运营商现状。亚马逊全球一张网是光网互联，节点都直连。假设我们利用亚马逊的公有云，在华盛顿向北京传输数据，数据可以先直接传输到亚马逊华盛顿节点，数据可自动复制到亚马逊全球网的另一个节点，如果连接北京最快的是韩国或者日本，也是离中国最近的节点，就可以选择复制到韩国或者日本，然后再传输到北京数据中心，数据并没有经过几跳，这比直接利用互联网传输的效率高得多。利用公有云可以实现非常高速非常廉价的数据传输。在未来大型赛事，也包括跨境大型综艺节目外景采集，可以尝试这种基于公有云的廉价安全的方式。

现在很多电视台已经开发了一些互动业务，大洋为武汉电视台做了一个APP，武汉电视台的电视问政栏目和新闻APP端有互动内容，用户可以参与投票，对参与节目的市政府领导进行评分。在电视直播的时候用户量非常大，包括下载和评论、投票，如果利用私有云资源往往是不够的。随着栏目一期一期播出，用户量增速非常快，互动访问量也远超私有云平台的承载能力，而由于节目互动产生的突发性网络负载时间并不长，产生的时间完全可以预估。通过混合云架构，利用阿里云进行资源补充，将用户互动负载降解，通过公有云可灵活弹性扩展的特性就可支撑此类大型互动节目。

我们再看一下利用网和端的应用场景，通过大洋平台我们已经给新闻中心提供了很多方面的工具和服务，比如说选题报道和新闻通联、全球数据回传、资料搜集等方面，记者可以在报道现场和出差的时候实现任意编辑。具体解决方案是基于BS编辑的解决方案，编辑终端通过互联网接入公有云，实现编辑操作的回传，电视台私有云平台将实时编辑的回显画面通过流媒体的方式，通过公有云推送至终端，同时利用公有云与台内网的专线或者VPN连接，保证了带宽的稳定性和高并发。基于互联网的内外协同编辑解决方案，构建一个混合云制作平台VPC，低码率素材文件同步至公有云，故事板和字幕文件双向同步，用户可在外场通过移动终端编辑公有云中的低码素材，并将故事版文件实时同步至私有云，台内用户可打开故事版文件继续编辑，实现协同编辑的应用场景。

六、基于互联网和客户端的应用场景

我们把在线远程编辑分成几种模型，远程桌面模式、后台渲染模式、本地渲染模式、视频生产模式。基于后台渲染模式的BS非编，整个运算集群都在后台的私有云或者公有云里，任何浏览器都可以打开，编辑的码率可以是700K、200M都可以。由于可以控制输出网络的带宽，理论上可以在任何位置，既可以在台内直接编辑200Mbps码率的高清视频素材，也可以回家远程编辑。一些高端的视频编辑操作，比如双窗口Trim模式，还有画面特技都可以做。除了刚才说的一些具体工具以外，我们还针对电视台新闻中心整体解决方案提供了两微一端发布平台，已经给客户提供了新闻客户端整合公众号的能力。我们针对地方新闻的需求，将互动产品，视频直播、点播等所有新媒体平台所需要的工具都打包在客户端上，地方台的新闻中心可以独立发展自己的新闻客户端，能够和客户实现互动。刚才提到的一个新闻客户端和直播融合的模式，在讲混合云降解的时候已经提到，这就是“掌上武汉”，提高了电视直播时观众的参与度，同时在直播过程中做了APP推广，这是非常好的一个案例。