面向新闻业务系统的AB岛架构简介

2015-03-15贾明

中国传媒科技 2015年3期

文｜贾明

前段时间，我台新闻频道高清视音频制播系统建设完毕，如何应对新闻业务的安全，尤其是新闻节目直播的安全是一个重要的问题，现将其中一个解决安全问题的设计思路简要介绍一下。

一、设计背景

众所周知，相对于有完善安全机制的演播室系统，单一的新闻制作网和文稿系统是节目直播流程中的薄弱点，系统故障容易造成整个业务的中断，解决这个薄弱点就能极大提高新闻直播中的安全性。另一方面，为避免高额的投资，我们需要共享演播室系统。所以我们与索贝厂方协商，提出了A、B岛架构的设计思路。

二、实现方法

A/B岛架构用于两个业务相似、规模差不多、系统间有较多素材需要交互的场景。（图1）此架构下，两个网共用一套数据库和演播室系统，存储、交换部分和其他后台服务独立部署。两网之间通过接口打通，实现文稿、素材和成片的快速交互和节目共享播出。而且，其中一个系统有故障时，故障网络的业务可快速切换至另一网络继续运行，这样相当于实现系统级别的互备。

这种A/B岛架构，A、B两部分相对独立，互为备份，有效避免制作单点。统一的演播模块独立于制作，配有完善的安全机制，在确保安全播出的前提下为制作提供更为灵活的播出手段。这种解决思路，为大型新闻制播系统的建设提供了新颖有效的解决方案。

在以往新闻制播网络的建设中，大多建立单一的制作岛配合演播室联动完成新闻制播业务。这种模式下，一旦制作模块出现故障，所有新闻制作业务将陷入瘫痪，对新闻播出安全造成影响。这一点上我们是有深刻教训的，我想全国各兄弟台也会经常遇到这种情况。A/B岛架构的提出，旨在一方面建立两个相对独立的制作岛应对单个系统故障造成业务中断的情况，提升新闻业务安全性。另一方面建立统一的、安全机制完备的共享演播室，避免重复投资，提高演播室利用率。其系统架构示意图如下图1所示：

三、详细设计及运行机制

如上图1所示，A、B两个制作岛在数据库、文稿、编辑、串联单制作在内的多个部分都相对独立。同时，A、B岛对应一套共享演播模块。在日常业务中，两制作岛虽然在技术结构层级上相对独立，但在业务方面是统一面向新闻制作业务的，这将有两个系统之间的数据交互的问题产生，针对这种需求，系统进行如下设计：

● 素材通过索贝特有的ML（资源管理器）服务跨数据库访问，实现双方互相可见。通过部署迁移服务器实现素材在两个岛在线存储间的迁移。

● 文稿库进行了拆分，将选题库作为独立数据库分离出来，A、B岛共同访问，后续文稿流程在各岛内独立完成；

● 审片软件进行改动，实现对A、B岛的审片在同一个审片系统中完成。

在A、B岛协同工作条件下， A、B岛选题库如果分离的情况下，将使得一个系统内无法完成统一的选题申报、审核工作，因此必须建立统一的文稿选题库，如下图2所示：

在日常工作中，A、B岛两部分个自拥有独立的文稿、制作系统，分别对新闻频道用户、栏目、账号、权限、空间等进行配置。而A、B网的相互系统独立性可以满足A、B两部分在出现其中任何一个全网故障时，互为灾备的系统设计要求。

由于ML提供多节点的支持，也就使得ML可以实现对A、B岛的跨数据库访问，在A、B岛间可互相看到对方公布的素材，如图3，可通过拖拽发送MPC调度，后台配置MPC迁移服务器，完成素材在A、B两岛在线存储间的迁移，入库工作。

如图4，当A岛业务比较繁忙时，记者可利用B岛的空闲非编站点，使用B岛所属的临时栏目、空间制作A岛节目，做好后将素材生成。然后由处于A网的编辑把素材调用至A网，在A网进行审查、送播等一系列流程。

图1

图2

图3

图4

审片设计

除了文稿，素材相关流程交互以外，A、B岛的审片软件也适应协同工作进行功能改进：

1、使用统一的登录TAB页面，使用户登录时无须区分登陆的是A部分或是B部分。

2、在A岛查询页中和B岛查询页中只能查到对应网的文稿节目信息。

3、但当用户需要查询或者审查另外一个网的节目时，切换TAB页，后台数据库访问会自动切换到另一网内。

4、审查站点可同时访问到A、B两岛的存储以满足审查需要。

四、其它问题

由于A、B两岛频繁浏览、交换素材节目等工作，以及全网的高清编辑业务，为缓解存储和网络的带宽压力，编辑网络码率设为高、中、低三档，分别对用于成片、编辑和浏览等不用情况。在两岛的栏目、用户分配上，最好将联系性强、共享性强的栏目放在同一个岛内，这样可有效缓解不必要的资源交换，节省资源和带宽。在以前的新闻制播网络建设上，多为配置单一存储体支撑全网编辑，一旦出现故障，节目制作、播出均会受到影响。在这个设计中，A、B两岛实现了这种双存储架构，再结合厂家提供的数据同步技术，实现了存储数据的有效互为备份和故障快速切换，更好地实现了数据安全。