面向在线协同制作的门户系统设计

ｌ　ＴＶ　ｃｅｎｔｅｒ　

Ｉ里鲤虫必　

文章编号：１００２—８６９２（２０１　１）０９—００８２—０４　

．　

面向在线协同制作的门户系统设计　

茆唯伟　，王兴东　。，孙思慧　

（１．上海交通大学电子工程系图像通信与信息处理研究所，上海２００２４０；　

２．上海市数字媒体处理与传输重点实验室，上海２００２４０）　

【摘　要】根据广域网环境下在线协同节目制作系统的需求，采用Ｊ２ＥＥ平台，搭建了一套高可重用性、可扩展性的门户系统。该　

系统采用ｎｇｉｎｘ作为前端反向代理，以Ｔｏｍｃａｔ作为内容服务器，采用Ｊ２ＥＥ平台的ＳＳＨ架构，ＭｙＳＱＬ作为后台数据库系统，能够支持　

多用户、高并发、线性扩展。重点介绍了门户系统的总体架构及实现方式，包括反向代理服务、视频转码、协同制作业务等模块的　

实现细节，最后介绍了采用ＬｏａｄＲｕｎｎｅｒ进行压力测试的方法。系统将传统的基于客户端的视频制作业务通过网站的新模式呈　

现，并且集成了协同功能。　

【关键词】协同制作；视频转码；反向代理；门户系统　

【中图分类号】ＴＮ９４８　【文献标识码】Ａ　

Ｄｅｓｉｇｎ　ｏｆ　Ｏｎｌｉｎｅ　Ｃｏｌｌａｂｏｒａｔｅ　Ｅｄｉｔｉｎｇ　Ｏｒｉｅｎｔｅｄ　Ｐｏｒｔａｌ　Ｓｙｓｔｅｍ　

ＭＡＯ　Ｗｅｉｗｅｉ　一，ＷＡＮＧ　Ｘｉｎｇｄｏｎｇ　一，ＳＵＮ　Ｓｉｈｕｉ‘’　

（Ｊ．Ｉｎｓｔｉｔｕｔｅ　ｏｆ　Ｉｍａｇｅ　Ｃｏｍｍｕｎｉｃａｔｉｏｎ　ａｎｄ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｐｒｏｃｅｓｓｉｎｇ，Ｄｅｐａｒｔｍｅｎｔ　ｏｆ　Ｅｌｅｃｔｒｏｎｉｃ　Ｅｎｇｉｎｅｅｒｉｎｇ，Ｓｈａｎｇｈａｉ　Ｊｉａｏ　Ｔｏｎｇ　Ｕｎｉｖｅｒｓｉｔｙ，　

Ｓｈａｎｇｈａｉ　２００２４０，Ｃｈｉｎａ；２．Ｓｈａｎｇｈａｉ　Ｋｅｙ　Ｌａｂｏｒａｔｏｒｙ　ｏｆ　Ｄｉｇｉｔａｌ　Ｍｅｄｉａ　Ｐｒｏｃｅｓｓｉｎｇ　ａｎｄ　Ｔｒａｎｓｍｉｓｓｉｏｎｓ，Ｓｈａｎｇｈａｉ　２００２４０，Ｃｈｉｎａ）　

【Ａｂｓｔｒａｃｔ】Ａｃｃｏｒｄｉｎｇ　ｔｏ　ｔｈｅ　ｎｅｅｄ　ｏｆ　ｏｎｌｉｎｅ　ｃｏｌｌａｂｏｒａｔｉｖｅ　ｐｒｏｇｒａｍ　ｅｄｉｔｉｎｇ　ｓｙｓｔｅｍ　ｏｎ　ｔｈｅ　Ｉｎｔｅｒｎｅｔ，ａ　ｐｏｒｔａｌ　ｓｙｓｔｅｍ　ｉｓ　

ｄｅｓｉｇｎｅｄ　ｕｓｉｎｇ　Ｊ２ＥＥ　ｐｌａｔｆｏｒｍ，ｗｈｉｃｈ　ｉｓ　ｒｅｕｓａｂｌｅ　ａｎｄ　ｅｘｔｅｎｓｉｂｌｅ．Ｔｈｅ　ｓｙｓｔｅｍ　ｕｓｅｓ　ｎｇｉｎｘ　ａｓ　ｔｈｅ　ｆｒｏｎｔ—ｅｎｄ　ｒｅｖｅｒｓｅ　ｐｒｏｘｙ，　

Ｔｏｍｃａｔ　ａｓ　ｔｈｅ　ａｐｐｌｉｃａｔｉｏｎ　ｓｅｒｖｅｒ，ｔｈｅ　ＳＳＨ　ａｒｃｈｉｔｅｃｔｕｒｅ　ｂａｓｅｄ　ｏｎ　Ｊ２ＥＥ，ＭｙＳＱＬ　ａｓ　ｔｈｅ　ｂａｃｋ－ｅｎｄ　ｄａｔａｂａｓｅ　ｓｙｓｔｅｍ．Ａｎｄ　

ｔｈｅ　ｓｙｓｔｅｍ　ｃａｎ　ｓｕｐｐｏｒｔ　ｍｕｌｔｉ－ｕｓｅｒ，ｈｉｇｈ　ｅｏｎｃｕｒｒｅｎｅｙ　ａｎｄ　ｌｉｎｅａｒ　ｅｘｐａｎｓｉｏｎ．Ｔｈｅ　ｏｖｅｒａｌｌ　ｆｒａｍｅｗｏｒｋ　ａｎｄ　ｉｍｐｌｅｍｅｎｔａｔｉｏｎ　ｏｆ　

ｔｈｅ　ｐｏｒｔａｌ　ｓｙｓｔｅｍ　ａｒｅ　ｉｎｔｒｏｄｕｃｅｄ，ｉｎｃｌｕｄｉｎｇ　ｄｅｔａｉｌｓ　ｏｆ　ｓｏｈｗａｒｅ　ｍｏｄｕｌｅｓ　ｓｕｃｈ　ａｓ　ｔｈｅ　ｒｅｖｅｒｓｅ　ｐｒｏｘｙ　ｓｅｒｖｉｃｅ，ｖｉｄｅｏ　

ｔｒａｎｓｃｏｄｉｎｇ，ｃｏｌｌａｂｏｒａｔｉｖｅ　ｐｒｏｇｒａｍ　ｅｄｉｔｉｎｇ．Ａｔ　ｌａｓｔ，ｌｏａｄ　ｔｅｓｔｉｎｇ　ｕｓｉｎｇ　ＬｏａｄＲｕｎｎｅｒ　ｉｓ　ｉｎｔｒｏｄｕｃｅｄ．Ｔｈｅ　ｓｙｓｔｅｍ　ｒｅｐｒｅｓｅｎｔｓ　

ａｎ　ｎｅｗ　ｍｏｄｅｌ　ｗｈｉｃｈ　ｕｓｅｓ　ｔｈｅ　ｎｅｔｗｏｒｋ　ｍｏｄｅ　ｔｏ　ｓｕｂｓｔｉｔｕｔｅ　ｔｈｅ　ｔｒａｄｉｔｉｏｎａｌ　ｃｌｉｅｎｔ—ｂａｓｅｄ　ｐｒｏｇｒａｍ　ｅｄｉｔｉｎｇ　ｂｕｓｉｎｅｓｓ，ａｎｄ　

ｉｎｔｅｇｒａｔｅｓ　ｃｏｌｌａｂｏｒａｔｉｏｎ　ｃａｐａｂｉｌｉｔｉｅｓ．　

【Ｋｅｙ　ｗｏｒｄｓ】ｃｏｌｌａｂｏｒａｔｉｖｅ　ｐｒｏｇｒａｍ　ｅｄｉｔｉｎｇ；ｖｉｄｅｏ　ｔｒａｎｓｃｏｄｅ；ｒｅｖｅｒｓｅ　ｐｒｏｘｙ；ｐｏｒｔａｌ　ｓｙｓｔｅｍ　

０　引言　

传统的基于桌面应用程序的节目制作软件，往往受　

限于产品对用户计算机性能的要求，并且操作和功能设　

置过于复杂，无形中增加了与使用者之间的距离。将传　

统的节目制作软件用网络的形式呈现并且提供用户协　

同的功能，本身就是一件激动人心的事情。而在整个基　

于广域网环境的在线节目协同制作系统中，提供服务的　

能够提供稳定、有效的用户管理、素材文件管理、项目管　

理等功能。并且，为了使门户系统能够支持多用户和处　

理高并发情况，在系统架构设计时考虑到可扩展性，采　

用前端反向代理、静态缓存、服务器集群等技术。　

１　系统架构设计　

在线协同制作门户系统除了具备视频分享类网站　

视频上传、预览、评论、分享等基本功能外，用户上传的　

编辑是该系统的一大特点ｎ　。系统设计从业务功能、性　

门户系统是决定用户体验的关键因素，搭建一个用户体　共享视频都将是在线视频制作的素材，视频的在线协同　

验好、高可用性、高可扩展性的门户系统至关重要。　

将传统的单机节目制作通过Ｗｅｂ方式实现，并且实　

现多用户之间的协同功能，需要门户系统和节目制作系　

能要求、易于拓展等方面进行考虑。系统架构包括系统　

的构成和业务模块设计两个部分。　

１．１系统的构成　

统之间无缝结合，门户系统和后台的节目制作协同服务　

器之间具有良好的交互策略以及门户系统与集群转码　

系统之间可行的转码任务管理通道。门户系统还需要　

基金项目：国家“８６３”计划项目（２００８ＡＡ０１Ａ３１８）　

门户系统主要由反向代理服务器、内容服务器集　

群、数据库服务器等构成，如图１所示。　

８２　１　

电

视

技

ｎ　ｅ　ｅ　ｒｉｎｇ　

ｉｄ

ｅ　ｏ

ＣＥｎｇｉ

。　，年第，　∞期（总第ｓｓ　期）　

丁Ｖ　ｃｅｎｔｅｒｌ　

电积巾心Ｉ　

反向代理服务　

器：主要实现对后端　

文件下载模块：在Ｊａｖａ程序中调用存储系统提供的　

下载ＤＬＬ接口，获得文件的下载地址，生成文件的下载　

ＵＲＬ。　

内容服务器的负载均　

＆瓣赢　Ｉ　誊　／　

衡、静态文件缓存、页　

面重定向，以提高用　

户的访问速度，减轻　

服务器的压力。　

Ｗｅｂ内容服务器　

数据库访问模块：向业务层提供数据库读取等操作　

服务。　

２　系统的实现　

系统采用Ｊ２ＥＥ平台嘲，配合ＭｙＳＱＬ数据库　］以及相　

集群：实现系统的业　

图１　门户系统架构　

务功能，完成用户管　

理、项目管理，与协同管理服务器进行交互，是系统功能　

实现的核心部分。　

数据库服务器：用户信息、海量视频文件信息、项目　

信息等的保存与管理。　

１．２业务模块设计　

按照系统的功能将应用分成业务模块进行实现，主　

要包括用户管理模块、用户组管理模块、文件管理模块、　

项目管理模块、消息管理模块等，如图２所示。　

图２系统业务模块图　

反向代理服务模块：实现负载均衡、静态文件缓存等　

功能。　

个人信息管理模块：主要实现用户的登入、登出、注　

册等操作，同时需要保证ｓｅｓｓｉｏｎ和ｃｏｏｋｉｅ内容的更新与　

同步。　

文件上传模块：实现调用ＡｃｔｉｖｅＸ上传插件，实现无　

大小限制的文件上传。　

消息管理模块：实现好友请求处理、组请求处理等消　

息处理功能。　

组管理模块：用户组的创建、查询、添加／删除、解散　

组等操作。用户组同时也是协同项目的归属者。即为了　

保护协同项目的可操作性、保密性，同一组内的成员才有　

权限加入该组的协同项目。　

项目管理模块：项目的创建、项目状态查询、项目成　

员添加、项目发布等功能。　

关技术实现，按照业务需求分模块实现各部分的功能，并　

且设计一种能给用户优质用户体验、易于功能拓展的协　

同制作业务流程。　

协同制作作为门户最主要的业务，其涉及到的关键　

技术主要有：不同格式视频的统一低码率格式转码，以　

便视频编辑的特效和素材预览；反向代理服务器的搭　

建，以减轻Ｗｅｂ服务器的访问压力，实现可平滑拓展的　

网络架构。　

２．１反向代理服务器　

ｎｇｉｎｘ以其稳定性、高并发性、低系统资源等特性获　

得越来越多的应用。本系统主要利用ｎｇｉｎｘ做静态文件　

的缓存、后端Ｗｅｂ内容服务器的负载均衡。　

利用ｎｇｉｎｘ的静态文件缓存功能，客户端发送过来的　

请求首先送到反向代理服务器。如果客户请求的内容在　

反向代理服务器的缓存中存在，就直接返回给用户，不需　

要再去访问后端的内容服务器。如果客户请求的内容不　

在缓存中，则将请求进一步送到内容服务器，并将内容服　

务器返回的结果缓存起来，并进一步送给客户端。　

利用ｎｇｉｎｘ的负载均衡功能，能够将多台内容服务器　

进行集群，同时对外提供服务。用户的访问请求，将由反　

向代理服务器的调度策略，根据后端各个ＨＴＦＰ服务器　

的运行状况，做负载均衡处理，决定由后端的哪台内容服　

务器提供服务。同时，后端的某台用户服务器意外宕机　

时，反向代理服务器也能进行智能切换，保证服务的稳　

定、可持续性。　

ｎｇｉｎｘ在Ｌｉｎｕｘ环境下的安装和配置并不复杂，主要　

通过一个配置文件来定义各种服务的功能，利用ｎｓｉｎｘ作　

为高速缓存代理，它具有以下作用：　

１）加快对客户的响应时间，减轻后端内容服务器的　

负载；　

２）保障内容服务器的安全；　

３）减少内容服务器节点之间占用的网络带宽；　

４）对内容服务器进行负载均衡。　

２．２视频转码服务　

根据系统需求，系统能够支持ＭＰＥＧ一２，ＭＰＥＧ一４，　

：。。　锑　∞期ｃ总第　期，　８３　

ｌ丁Ｖ　ｃｅｎｔｅｒ　

ｌ电积【ｌ】心　

Ｈ．２６４，ＤＶ等格式的视频上传。因此，必须将上传的原始　

素材统一转化为一种低码率素材，通过流化服务器提供　

给用户素材预览以及编辑时候的特效、成品预览。系统　

因此设计了后台对上传的素材文件统一低码率格式转　

码的功能。　

为了降低各个子系统之间的耦合性，将门户系统和　

后台的集群转码系统分别开来，由门户系统对每个上传　

的文件发起素材默认转码的任务请求，通过ＸＭＬ交互的　

方式提交转码任务给转码系统，转码调度系统对任务　

ＸＭＬ进行解析，将转码任务分发给各个运算节点，目标　

格式文件生成后，通知门户监控中心，并且将转码任务　

结果以ＸＭＬ的形式返回，门户通过ＸＭＬ处理系统对各　

个文件的转码状态进行控制处理。整个视频转码功能　

的结构如图３所示。　

图３转码功能结构图　

同时，由于集群转码系统的独立性，该系统还将转　

码单独作为一项供用户使用的业务功能，用户可以上传　

支持的视频格式文件，通过系统在服务端将视频转换成　

用户设定的目标格式，再下载。这种工作方式免去了用　

户安装复杂转码工具的困扰，并且利用服务端强大的集　

群运算性能，能够大大减少转码所需要的时间，用户付　

出的代价仅仅是通过Ｗｅｂ上传文件和下载目标文件的　

时间。　

２．３协同制作业务流程设计　

协同制作作为门户系统的核心应用，其包括的主要　

功能有：新建协同项目、用户加入、用户退出、项目保存、　

项目发布、项目删除等。从Ｗｅｂ应用的角度，图４给出协　

同制作的主要业务流程。　

门户系统负责协同制作项目的管理，在用户选择启　

动某个协同项目时，将项目的ＩＤ号和用户ＩＤ通过参数方　

式传给客户端ｓｗｆ进行初始化。并且在接收到成品通知　

之后，门户系统需要发起后台转码的任务，将成品转码　

成低码率文件，供用户在网页上预览。　

门户系统与协同服务器之间除了通过参数传递进　

８４　Ｖ矿　Ｑ　。Ｉｌ　　Ｉｔ　　Ｊ，　２０１１年第３５￣０９期（总第３５９期）　

图４协同制作业务流程图　

行通信，还通过调用协同服务器开放的Ｗｅｂ　Ｓｅｒｖｉｃｅ，来　

协助协同服务器进行项目的管理和成员状态的控制。　

３　性能测试　

系统在部署上线之前，需要进行功能验证测试、压　

力测试等，以保证在运行过程中能够满足给定的容量和　

业务响应时间指标。对门户系统进行性能测试的工具　

很多，其中Ｍｅｒｃｕｃｙ　ＬｏａｄＲｕｎｎｅｒＩ４　是专业工具之一，它是　

一

种预测系统行为和性能的负载测试工具，能够以模　

拟成千上万用户实施并发负载和及时性能监测的方式　

来确认和查找问题。通过使用ＬｏａｄＲｕｎｎｅｒ，企业能最　

大限度地缩短测试时间，优化性能和加速应用系统的　

发布周期。　

系统在测试过程中，可以通过脚本录制，对整个应　

用系统处理静态请求、动态请求、数据库处理能力、特定　

的业务进行负载测试。本文中通过录制用户打开主页　

面的脚本，对多用户并发请求主页面的场景进行测试。　

３．１测试环境　

测试环境中机器设备的配置情况见表１。　

表１机器配置表　

ＬｏａｄＲｕｎｎｅｒ中测试场景配置如下：逐步加载１　０００　统响应静态文件的测试只是一部分。测试方案中，更要　

个Ｖｕｓｅｒ，每隔１５　Ｓ添加５０个Ｖｕｓｅｒ（虚拟用户），每个　重点考虑对动态页面请求、核心业务等进行性能和压力　

测试，因为动态页面的响应需要经过Ｔｏｍｃａｔ处理并且多　

Ｖｕｓｅｒ在一次请求页面返回后间隔３—５　Ｓ发起下一次请　

求，并且每次请求浏览器不缓存页面数据，相当于每次请　

求都是模拟一个新用户重新发起。加载的主页大小为　

１１２　ｋｂｉｔ。　

数情况下涉及到数据库的操作，很容易成为系统的瓶　

颈。通过测试找到系统的瓶颈所在，然后优化代码及　

系统配置，从而提高系统的性能和稳定性。最后，测试　

方案中还可以通过设定混合场景，按照百分比来模拟　

不同的用户同时操作不同的业务，模拟系统真实的运营　

环境。　‘　

３．２测试结果　

图５　图７是系统测试的相关结果图。从结果可以看　

出，系统在完全加压的状态下运行了２０　ｍｉｎ，系统的最大　

网络吞吐量达到２８　Ｍｂｙｔｅ／ｓ，每秒请求响应次数峰值达　

到３　５１４。对于１１２　ｋｂｉｔ的静态页面请求，平均的响应时　

间为０．０１２　Ｓ，没有失败的事物数。并且观察到反向代理　

服务器的ＣＰＵ占用率稳定在１５％左右，由于静态文件在　

反向代理服务器端有缓存，所以后端的Ｔｏｍｃａｔ应用服务　

器和数据库服务器在本测试中没有承受压力。　

４　小结　

系统在实现过程中，还解决了许多性能优化的问　

题。例如，对于门户系统中许多需要与数据库进行交互　

的动态页面，在实际应用中，这些页面不需要很强的实时　

性，并且对所有用户都具有一致性，采用对这些页面伪静　

态化的策略，即在服务端模拟ＨｒＩＴＩ１Ｐ请求生成静态页面　

并适时更新。用户请求的内容是静态的，这就进一步减　

轻了后端内容服务器和数据库的压力。　

Ⅱ　

旺　

门户系统通过各个模块的协同工作，将协同制作、素　

套　

蚓　

材预览、成品发布、文件下载等功能集成一体，具有很广　

阔的应用前景。系统良好的架构设计，在系统需要增加　

自身访问容量的时候，只需平滑扩展服务器的数量，就能　

００：００：００　００：０５：００　００：１０：００　００：１５：００　００：２０：００　００：２５：００　００：３０：００　

场景运行时刻　

提升系统的访问容量和并发数。　

参考文献：　

［１］孙思慧　军，王兴东．面向在线制作的集群转码系统设计［Ｊ］．电视　

技术，２０１０，３４（１）：１８—２１．　

［２　刘中兵．开发者突击：ＪａｖａＷｅｂ主流框架整合开发【２］Ｍ］．北京：电子　

工业出版社，２００８．　

图５平均响应时间　

［３】唐汉明．深入浅出ＭｙＳＱＬ数据库开发、优化与管理维护［Ｍ】．北京：　

人民邮电出版社，２００８．　

［４］刘群策．ＬｏａｄＲｕｎｎｅｒ￣１１软件项目性能测试【Ｍ】　Ｅ京：机械工业出版　

社．２００８．　

责任编辑：哈宏疆　收稿日期：２０１０－１２－３１　

ｏｏ　

场景运行时刻　

图７平均网络吞吐量　

该测试表明在１　０００用户并发请求静态页面情况　

下，系统能够稳定的运行，并且从测试结果来看，系统还　

能支持更多的并发请求。在实际系统测试过程中，对系　

２０１１年第３５卷第ｏ９期（总第３５９期）　

矿　ｉ　ａｃｅ　０　匹　ｉ　Ｐ　ｒ　Ｈ　ｉ　

电　８５