安阳电视台主干平台方案V1.0

安阳电视台主干互联平台方案说明书北京中科大洋科技开展股份2023年4月概述本方案主要是针对安阳电视台主干平台建设的方案提出的，方案对贵台主干平台在功能和结构上都提出了完整和详细的建议，用来作为现阶段主干平台建设规划设计的参考。通过主干平台的建设，为安阳电视台即将建设的媒资系统与制作、播出等应用系统实现平安、高效、智能的互联，以及满足对未来系统和业务的扩展的支持。本方案的内容主要分为三个局部。第一局部主要介绍找主干平台设计中的关键技术点，包括主干平台的根本结构，数据通信方式的选择等；第二局部主要介绍了系统互联的根底和相关标准，包括系统互联设计的根本要素，接口参数的定义等；第三局部对本方案设计的互联平台的结构和功能进行了详细的说明和介绍。设计要点系统结构图上图为我们为安阳电视台设计的主干平台系统拓扑图，各子系统通过千兆核心交换机接入主干平台，我们会根据台内的业务量具体调整主干互联平台。以ESB＋EMB为核心我们知道，系统间交换涉及两类数据，一类是实体视音频文件，一类是控制信息或元数据信息；ESB、EMB工作原理图上图是ESB、EMB的工作原理图，如下图，图上方是EMB〔企业媒体总线〕，负责视音频档的交换，相对控制信息逻辑和处理来说，处理相对要简单。中间是各个子系统，封装为粗粒度效劳，通过效劳注册，告诉平台他的输入输出；最下方是元数据交互平台(ESB企业效劳总线)，要复杂的多，我们设计的原那么是希望各子系统相对独立，流程对各子系统透明。元数据描述，流程描述和元数据传输和封装必须支持公开标准。我们将这一些列标准标准通过主干平台整合在一起，因此，主干平台的作用主要是效劳发布，流程控制，信息元数据翻译。数据通讯方式选择元数据通讯方式选择元数据和控制信息主要指系统间交互时的一些指令、响应、状态、描述元数据〔如节目名称，代码，格式〕等，这些信息最大的特点在于数据量小，属于结构化数据范畴。元数据信息的交互传输接口可以采用的技术和标准也非常多，如TCP/IP通讯、Webservice远程同步调用、消息异步通知、文件+目录监控的异步单向通知、工作流调度、数据库访问等等。目前这局部信息的交互从交互的模式上可以分为同步和异步两种交互模式：同步交互：有些类似于我们打，即请求和答复属于同步发生且双方都以阻塞方式进行通讯，如果一方没有就绪那么通讯无法完成。异步交互：有些类似于我们发短信，即请求和答复属于异步发生，交互双方都以非阻塞方式进行通讯，任何一方都只和消息中心建立联系，一旦发送〔或接收〕完成，那么立即可以进行其他的工作。同步和异步的两种通讯模式各有特点，就好比打和发短信。同步方式最大的优点在于能够立即得到对方的响应，因此在一些同步性强，信息处理时间短的交互中较为常用，但同步方式对系统之间的关联度要求高，一旦对方系统出现问题，那么交互无法成功。异步方式最大的优点在于异步处理，因此可以使得系统之间的耦合度降低，尤其在一些需要长时间处理或人工干预的任务通知方面，异步通讯更具有优势。但异步方式对一些要求立即响应的交互那么不太适合。下面根据我们在安徽台、中央台、黑龙江台等异构互联工程的实施经验，主要集成在消息交互和Webservice交互两种方式，因此这里只分析两者的工作原理。A.基于消息〔Message〕的通讯交互：系统A和系统B通过访问公共消息队列接口来发送和订阅消息，所有底层通讯逻辑通过调用第三方软件接口〔如IBMMQ〕实现，通讯模式属于异步通讯。如以下图所示：B.基于Webservice的通讯交互：Webservice的接口方式是目前IT行业系统整合采用的比拟普遍的系统交互通讯方案，Webservice组件的调用也可以看作是远程同步调用，通过HTTP协议并封装SOAP协议实现信息和元数据的交互。Webservice属于典型的同步交互模式。如以下图所示：综上所述，在互联设计中，对于元数据通讯技术方式，我们采取“Webservice〞为主要，其他方式为辅助和扩展的方式，主要考虑如下：在主干互联平台上，对外系统交互主要以Webservise方式，一是该通讯方式为主流和趋势化方向方式，二是能够得到及时的交互和影响。对于存在较长时间的任务转换，有主干平台的ESB进行中间的交互缓存，即使外部对接系统故障，也不耽误交互消息和数据的传送。对于元数据通讯的选择，技术上没有绝对的优劣选择，只是根据不同的业务需要而定，另外对于目录侦测和插件交互的实现方式，对于已经建设并且比拟老或者小规模定制化的的系统互联，采用它是比拟好的方式〔如演播室与新闻和制作的备播交换需求〕。总结，元数据通讯技术手段，最理想的是支持各种方式，实际使用中，根据不同业务需求进行灵活选择。目前主要是以基于Webservise为主进行推荐。媒体数据通讯方式选择系统间媒体数据迁移主要有两种技术实现方式：一是采用文件共享方式，包括LAN文件共享和SAN文件共享，另一个是采用FTP文件传输模式。针对此两种数据传输方式的优略，及采用方案选择，所以下文就简要描述两种方式的优略。SAN文件共享方式如下图，系统A，B，C三个SAN系统通过FC路由器联通，但考虑到平安因素，系统之间无法直接访问，但三个系统均可以向数据处理中心开放，因此系统之间的数据传输由这个数据处理中心承当。SAN共享方式实现媒体数据交互最大的优点在于带宽高，但由于FC互联，因此本钱较高，且各系统存储直接对数据处理中心开放，系统数据的平安性较差。FTP文件传输模式如以下图所示：系统A和系统B通过FTP客户端/效劳器进行以太网连接，并通过FTP协议实现大对象数据的交互，而系统内部那么可以采用带宽较高的FC连接。FTP模式最大的优点用于单网连接，因此本钱较低，而且系统都是通过Ftp方式对外开放提供数据访问，所以数据平安性都会较高，但传输效率和带宽比SAN共享模式要低。基于系统的独立性及平安性设计考虑，本次的设计纲要的建议采用的是Ftp方式的媒体数据迁移方式。在选择采用基于Ftp的传输模式后，在EMB中针对媒体数据文件传输实现方案在技术逻辑模型上，还存在两种实现手段：点对点的N*N架构：即将EMB中的Actor迁移器进行分布部署的原那么，两个系统间数据迁移为点对点的数据传输迁移，即每个系统都部署相应的Ftp效劳器，且每个系统Ftp效劳器都对其他系统开放，星型的N*1架构：即子系统提供访问端口，而数据迁移那么通过集中部署在主干平台的迁移器进行转发，即每个系统提供Ftp端口，但端口都只针对主干平台开放，通过主干进行数据迁移，实现每个系统间完全隔离两种架构示意如以下图所示：从上图中可以看到，逻辑架构以及数据处理的资源共享程度来看，N*1的星型结构比拟好，从系统的耦合度以及集成复杂程度来看，N*N更加简单和实用。N*N和N*1在交换处理流程上非常类似，区别在于N*N在实现具体的媒体数据文件传输时由分布在各个系统的Actor迁移器来完成，而N*1在实现时通过各系统的Ftp效劳器及共享的Actor交换中心集中处理。针对上述两种实现模式，各有各自的优缺点，如果只是针对数据迁移，那么两种方式构架根据实际情况都可以进行选择，都能在一定程度上保障系统的平安：N×N在于简单实用，效率高，但是由于FTP需要对所有的子系统开放，系统的独立性受限，平安性存在一定的风险，但系统由于采用各FTP为直通的数据传输方式，针对传输链路部署简单，且无须配置中间Actor数据迁移器，本钱也会有所降低；N×1在于系统的独立性很高，各子系统都只针对主干平台开放Ftp端口，平安性更有保障，但通过中转的数据迁移方式，效率会略有降低，且由于同时需要在子系统部署FTP和主干平台部署Actor迁移器，所以本钱和系统复杂程度会有所提高；如果系统EMB只负责数据迁移，那么两种模式都可以选择。但由于目前设计的EMB效劳，除了设计数据迁移效劳外，还需提供转码效劳、提供自动技审效劳，在两种模型下，如果构建转码效劳和自动技审效劳，那么技术构架模型如以下图所示：从上图中可以看到，在N×1架构下，系统只需在主干平台集中部署转码效劳器、自动技审效劳器即可，且集中部署的效劳器可以共享使用，而且可以平行扩展，扩展的设备可以为所有的系统交换数据传输效劳；而在N×N架构下，需要实现效劳，需要在每个所需的系统配置转码效劳、自动技审效劳，且为每个系统配置的效劳都为独享效劳，无法实现平行扩展和共享使用，对于系统的扩展，可能需要在多个系统都进行设备和效劳器的扩展。从这个层面上分析，由于数据迁移效劳器的本钱实际上低于转码效劳器、自动技审效劳器的本钱，采用N×1架构下，系统的建设本钱和扩展本钱都会低于N×N架构。并且集中部署后，除了保证各业务系统的独立性外，还可以实现集中统一的数据流量监控。从这方面考虑，采用N×1架构更符合系统的设计需求和实际使用需求。总结：对于媒体数据通讯技术手段的选择，主流建议采用N×1架构的FTP迁移方式。互联根底与标准系统互联设计的四要素要实现全台数据交换业务，需要制定数据交换的标准，这个标准中包括了对各种媒体对象实体的定义，也包含了控制信息的定义；还需要对全台媒体数据交换业务进行分析，得出每个业务场景的流程模型和交互的数据，并得到各个系统效劳接口参数，从而最终实现交换业务。如何能用科学的方法得到上述内容，就涉及到系统互联设计的方法论。要实现全台的媒体数据交换，涉及到这样四个要素：业务实际的数据交换业务，例子：备播交互业务，谁发起的，中间要交换哪些数据，何时结束等等。电视台业务人员最熟悉，平台研发人员也必须熟悉。流程业务经过抽象后得到的流程模型，对应到实现上是BPEL工作流引擎中的流程模板；也可能不涉及到工作流引擎，是发起交换的系统定制开发的一段交换逻辑处理的代码。由设计人员根据业务来定义。效劳各个参与交换的系统暴露出来的效劳，以及他们要调用的外系统的效劳。效劳对应到实现是效劳接口参数的Schma定义和WSDL定义。由研发人员定义。标准媒体数据交换的实现离不开标准，标准包括如下内容：软件通讯接口标准、视音频数据编解码标准、视音频文件格式标准、元数据交换标准、管理控制信息交换标准。标准由电视台业务人员和各方研发人员共同制定。四要素模型如以下图所示媒体数据交换四要素之间的关系是：通过对实际交换业务的抽象得到流程模型流程模型反过来又可以检验实际交换业务中的不合理之处，对业务进行优化流程模型通过细化明确交换涉及的数据，包括元数据信息和媒体数据；流程模型通过细化得到交换中要用到的效劳；标准那么是对交换中用到所有的元数据信息的结构的一个集合，同时还要保证前瞻性和扩展性；标准对交换中的元数据结构和效劳接口的定义有一个约束，所有的媒体数据结构和效劳接口参数结构都应该在标准的覆盖之内互联交换的标准设计数据交换的过程中，涉及到元数据和控制信息的交互和媒体数据文件的交互。如图：在异构系统的互联工程中，A、B两个系统之间元数据的交互大局部是采用双方约定格式和schema的方式，采用一种定制化的互联。如果将来参加了系统C，可能系统A和C之间约定的元数据格式和A、B之间的又不相同。这种一事一议的做法，会造成不标准，开发本钱高，风险不容易控制且系统扩展性较低等问题。通过制定标准来约束系统之间的交互信息，那么可以方便不同的系统实现接入。一个典型的例子是各个制作岛入库媒资的时候，需要提交编目元数据，各个岛可能是异构的，是不同厂商的产品，这就要求各个系统要按照一个标准的元数据格式来；各个制作岛之间也要交互素材，也是一样的问题。根据对交换需求和业务的分析，媒体数据交换标准主要应该包括软件通讯接口标准、视音频数据编解码标准、视音频文件格式标准、元数据交换标准、管理控制信息交换标准。如以下图所示：对照上面点对点系统互联所需约定的内容，控制信息和元数据交换标准均属于信息交互协议的定义；内容数据方面对应的文件格式和编解码格式标准；软件接口定义那么对应着信息通讯的定义；另外，文件传输技术也需要在集成方面进行设计和制定要求。A.控制信息层标准设计控制信息层主要描述效劳调用信息、源和目标版块信息、用户信息，以及输出参数里面作为异步调用关联的RequestID等，这些信息作为通用输入输出头信息定义在每个效劳接口里面。B.元数据层标准设计元数据层主要描述媒体对象实体的元数据信息，如素材属性定义、文稿属性定义、故事板属性定义等。C.内容数据层标准设计定义媒体文件格式标准，包括编码格式和文件封装选用：编码格式是视音频素材的压缩编码格式，如Mpeg2I、DV25/50、Mpeg2IBP等；文件封装是各种文件的外部包壳，如MXF、GXF、AVI等，是对该视音频文件的描述，包括PAL/NTSC制、画面尺寸、帧速率、每帧的位置描述，以及其他私有或共有描述信息等。。D.通讯技术层标准设计通讯技术层在元数据层采用Webservice、消息、组件调用等标准通讯方式，本次规划主要采用WebService方式，媒体数据通讯交互本次主要采用Ftp方式实现，通过EMB的调用实现。在该层中，主要通过标准化的效劳定义来描述，如系统间的入库效劳、素材查询效劳，以及主干平台的效劳注册等一系列效劳，在此暂不详细描述。总结：互联互通的四个层面，主要通过三种标准〔媒体资源及控制信息交互协议Mreml(MediaResourceExchangeMarkupLanguage)；媒体资源格式标准；通讯接口效劳标准〕来制定标准，以便各异购接入厂商能够互相识别，目前大洋准备通过已经运行的CCTVSATA和正在建设的CCTV新楼互联工程，与国内外厂商〔Avid，Apple，索贝，新奥特，捷成等〕联合制定全面的标准标准。效劳与接口参数定义效劳接口定义原那么接口定义的原那么：统一定义：各个系统统一定义，接口风格统一，粒度统一，命名统一粒度适合：效劳接口的粒度适宜，既可以保证重用性，又不至于过于琐碎复杂松散耦合：接口不依赖于调用方，也不依赖于互联业务流程可重用性：接口在ESB互联的时候可以提供效劳，但即使在点到点互联的时候也可以用。1.接口定义总体说明A.提取接口颗粒度的原那么如下：必要性：以满足系统间交互需要为前提，提炼必须的接口。共性：通过比照、归纳、抽取共同点的方式，提炼接口。兼顾根本集和扩展集：制定接口标准的根本集，并提供某些特色接口扩展集。B.对于各个系统都具有的共性效劳，采用统一的接口定义方式:一致的接口定义包括：效劳名称、方法名称、输入输出参数格式、相关命名空间等定义。这样不同系统中的相同效劳，只是调用地址不同，其他定义完全相同，调用方使用相同的代码就可以调用不同系统的效劳。如新闻和制作系统提供的入库效劳等，他们都需要提交到中心媒资。C.关于异步效劳的回调接口定义：系统互联中存在同步效劳，如对媒资的素材检索查询和节目信息查询等，这些都是同步效劳。同步效劳的典型特点是调用后，马上进行即时回馈。除了同步效劳之外，同样需要异步效劳的支持，如对媒资素材的下载申请等，它需要在媒资内部进行近线迁移下载到在线，然后根据目标需要内部转码等环节，因此不可能对外部效劳调用马上进行回馈，只能等处理完成后再进行异步回调，反应通知给外部调用系统。调用这些异步效劳后时，先同步返回提交结果，等效劳执行完成后，效劳提供方会调用原始调用方的异步回调接口，通知效劳最终执行结果。由于不同效劳异步返回的数据结构是不同的，针对不同返回结构需要定义不同的异步回调接口。异步效劳回调接口在异步效劳提供方定义，在效劳调用方实现。很多异步效劳是在ESB中调用的，ESB会通过配置方式自动实现这些异步回调接口。调用异步效劳的各个业务系统，都需要有异步回调效劳，实现的相应的异步回调接口，大局部异步回调接口定义是一致的。2.效劳命名标准如果各个系统的效劳功能定义一样，名称也需要一样，以便保持唯一性。比方各个系统都有“导入允许〞和“入库效劳〞，这些效劳的名称在各系统之间都是一样的。3.接口参数定义方式：参数主要由输入参数、输出参数构成，参数包含的内容主要来源于媒体对象标准，同时也包含在系统间交互时的管理及相关控制信息，如源系统和目标板卡的系统ID等。参数的大小写敏感；该定义采用XMLSchema的通用数据类型，与具体的编程语言无关，可以通过工具映射到具体的编程语言数据类型。4．接口参数封装方式根据业务系统实际情况对业务标准建模后，满足了业务的科学性和适应性。从大的技术体系上来讲，业务标准应该能在J2EE技术体系与.NET技术体系下使用。更细节的说，业务标准至少能满足在这两个技术体系下的消息、网络效劳、组件调用等技术表现模式。效劳命名标准的映射将解决业务标准在不同技术体系下的表现形式。参数映射－WebService基于SOAP和HTTP的WebService，是最广泛使用的系统互联方式。必须提供标准的WSDL定义，将接口参数和方法映射为SOAP消息和动作。目前有各个平台和编程语言下的开发工具，能够根据WSDL定义自动生成效劳实现方和效劳调用方的代码，这大大提高了WebService开发效率。接口参数的具体Schema定义一定要在WSDL里面表达出来，这样才能自动生成符合Schema定义的代码。WSDL定义要符合Webservice互操作标准〔WS-I〕，这样便于在各个开发环境下实现互操作。参数映射－组件实现接口参数可以映射为对应开发语言的类或者映射为XML字串组件方式的应用没有Webservice广泛。参数传递采用XML字符串方式在实现上更简单一些。参数映射－消息队列〔包括JMS消息队列、IBMMQ消息队列、MSMQ消息队列〕对于各种不同的消息队列，参数对应的消息都是符合Schema标准的XML字符串方式，只是具体的消息发送API不同，接口定义是一致的。由于消息队列为异步方式，输入输出参数中必须填写标准中RequestID字段，实现异步响应和原始请求的关联。主干互联平台主干平台组成与概述主干支撑平台主要细分为业务支撑平台和根底支撑平台两个平台，它是一个公共的支撑平台，不属于任何的业务系统，是全台网络的根底和核心，是实现具有松、紧耦合相结合的全台架构的关键。其模块组成如以下图所示：根底支撑平台根底支撑平台由根底网络平台、系统软件平台组成，它为电视台网业务系统提供软硬件根底运行环境，并实现各业务系统在网络层的互联互通。业务支撑平台业务支撑是电视台网集成架构的核心，由公共效劳平台、互联互通平台组成，为各业务系统提供用户认证、效劳注册、消息、报表、转码、迁移、智能监控、数据交换、流程控制等公共效劳，实现业务系统在平台上的集成，业务系统间数据的交换和路由，跨系统业务流程的管理和控制，以及公共效劳的提供和管理，并实现全台业务系统的统一管理和互联互通。除了根本功能本身外，平台要实现以下目标：平台的建设是效劳于全台整体业务的规划的，所以，平台必须要满足台内在业务系统新建、整合及开展各个阶段的要求。平台的引入一定不能以牺牲系统交互效率为代价，要保证一定的高效性。平台的引入不能使系统增加故障点，要充分保证系统的平安性。反过来，通过平台的业务交互管理功能及某些平安辅助手段，要提升整个系统平安性。平台上的技术标准及技术实现都应该是开放的，易于实现的。大洋TIPA互联架构ESB＋EMB双总线广电总局全台网建设白皮书建议，全台网互联可采用ESB+EMB的双总线模型，并且以此规划支持平台的架构。大洋是白皮书建议的主要参与者之一。全台网各应用系统是通过ESB〔企业效劳总线〕和EMB〔企业媒体总线〕实现各个应用系统互联互通的，ESB+EMB共同组成了系统互联平台。在全台网络构架中，ESB+EMB是一个中间件产品，它以ESB引擎为核心，支持Webservice、JMS、FTP目录监测多种系统互联接口方式，在系统互联中位于中心的位置。实现了此种方式的系统互联后，各个系统之间不是点对点的对接，而是通过一条可以实现复杂逻辑过程的BUS连接起来。ESB〔企业效劳总线〕将各个系统独立的效劳和业务流程剥离开来，互联的各个系统之间是基于工作流的松散耦合。在业务流程发生改变或者需要新的业务流程时，原先开发的效劳不需要做修改，只需要修改流程模型和增加必要的新效劳，对原先系统不会有影响。ESB参考业务流程执行语言〔BPEL〕标准，采用面向效劳的系统架构〔SOA〕，通过图形化流程配置，能够把各个系统的效劳组织为一个业务流程。EMB〔企业媒体总线〕是针对广电行业系统设计的特殊总线，它实际是ESB〔企业效劳总线〕的重要执行器之一。由于视音频数据处理特殊性，必须将管理控制信息处理和传输和媒体数据的处理传输别离开，EMB〔企业媒体总线〕就是专门处理媒体数据交互过程中的大对象数据任务，如视音频数据的传输，验证、转化等。ESB+EMB是居于SOA架构的全新的面向异构应用系统集成互联模型，系统结构如以下图所示：ESB+EMB实现应用系统互联，所以ESB和EMB是整个系统互联的支撑，也是企业EAI的根底，所以在全台网络构架中ESB+EMB称为支撑平台或者主干平台。 总结：简单来说，ESB是全台各系统交互的接口人和调度管理者，EMB是媒体数据的搬迁、转换执行者。前者发指令，后者实现数据搬迁。大洋TIPA互联架构如上图所示，为大洋TIPA3.0互联架构，是ESB＋EMB的一个具体表达，是从目前已经实施的大洋全台网工程建设的一个高度提炼。通过大洋ESB＋EMB，实现电视台主要生产制播系统的互联互通和数据交换。大洋TIPA产品是新一代的实现大中规模的电视台、大中型行业用户的系统互联解决方案，而且特别适合异构环境、跨业务系统、跨厂商系统环境下的互联互通。大洋的系统互联解决方案经历了三个阶段，第一个阶段是通过各个业务系统开发插件实现互联，这种方式耦合度较紧密；第二个阶段是通过工作流引擎实现系统互联，这种方式实现了互联交互逻辑和各个业务系统剥离，降低耦合度；第三个阶段大洋公司通过在SOA架构、ESB实现、BPEL引擎实现等IT领域积累的丰富的经验，推出了自己的ESB产品，同时发扬了自身在视音频技术领域的传统优势，推出了EMB产品，并且通过双总线架构，将两者有机结合起来，协同工作，形成了第三代互联产品TIPA。大洋ESB，主要实现各系统间的效劳路由，协议转换和适配，以及基于BPEL引擎的效劳编排作用。为了方便对效劳的注册和业务流程的编排，大洋ESB还提供配置功能，在此根底上，实现全台交换业务流程的各效劳图形化的监控。大洋EMB由EMBManager和EMBActor组成，前者是实现数据迁移和转换的调度指挥中心，后者是进行具体数据迁移和转换的执行，采用集群式工作方式。同样，也提供任务配置和分发执行监控功能。与广电总局白皮书的ESB＋EMB相同，大洋ESB是实现元数据和消息的交换调度中心，大洋EMB是实现媒体数据的搬迁和转换中心，共同承当全台生产业务系统的数据交换，是SOA思想的表达和实现。大洋TIPA架构特点1．高标准性：DY-ESB符合SOA架构DY-ESB包含了BPEL流程引擎，可以方便的满足随需应变的业务流程DY-ESB使用WSIF技术，能支持各种符合标准的webservice效劳DY-ESB可以将流程发布为一个效劳，使得各个系统只需要通过效劳来交互DY-ESB通过XSLT标准进行元数据的格式转换，能实现强大的数据适配功能2．高灵活度：DY-ESB支持多种效劳方式，包括webservice、JMS、FTP；而且支持多种效劳方式之间的透明转换DY-EMB支持多种传输方式，包括直接传输、间接传输、流方式传输TIPA互联对各个系统的要求很少，不对效劳参数和元数据格式做强制要求，大大提高了跨厂商系统互联的可实现性3．高伸缩性：DY-EMBActor可以根据承当的业务量，方便快捷的扩容TIPA中各个模块可以集中部署，也可以考虑系统的平安而独立部署4．高兼容性：高标清兼容，支持上下变换和格式转换支持多种编码格式：MPEG2I、MPEG2IBP、DV25、DV50、DVSD、DVHD、HDV、DNxHD等格式，并支持新媒体的格式转换，如H.263、H.264、MPEG4、WMV、RM等支持多种文件封装格式，如AVI、TS、MXF、MP4、3GPP、WMV等支持富媒体资源的传输：包括文档、图片、工程文件等5．高平安性：DY-ESB引擎支持集群方式运行DY-ESB可采用Unix，Linux操作系统；DY-EMB可采用Linux操作系统。DY-EMBManager支持主备方式运行DY-EMBActor支持集群方式运行DY-EMB支持文件的MD5校验，保证数据平安6．可监管性：可以通过图形化软件监控跨系统的业务和流程可以通过图形化软件对EMB的设备和任务进行监控大洋ESB设计大洋ESB平台架构DY-ESB系统包含了ESB引擎〔DY-ESBEngine〕、系统配置模块〔DY-ESBConfig〕、系统监视器〔DY-ESBMonitor〕等模块。DY-ESBEngineDY-ESB引擎提供了对各种效劳消息路由支持，提供了效劳的参数格式转换，提供对各种效劳的适配器功能。DY-ESB引擎中还包含一个BPEL工作流流程引擎，流程引擎的主要功能是实现流程的流转功能，处理各种活动、消息和事件，从而实现业务场景。每一个定义的流程模板都对应一个效劳，可以是WebService，也可以是JMS消息等，流程中的活动可以自动的调用各系统提供的效劳。DY-ESB引擎还提供了一套对外的效劳接口，包括各个系统的流程效劳的查询接口，流程实例的运行状态接口等。DY-ESBConfig这个模块提供效劳注册，配置管理的功能；实现方便易用的可视化流程模板定制。流程模板自动生成的流程图可以供ESB监控使用。同时提供流程分类设置与管理、流程模板设置与管理、流程权限等的设置和管理。图形化的流程模板配置在ESB中注册webservices效劳给流程中的一个节点选择调用的webservice效劳为流程节点增加连接DY-ESBMonitorDY-ESBMonitor主要功能是对流程引擎运行过程中的各种信息进行监控和管理。包括效劳执行状态监控、异常流程的跳转、中止、流程处理过程跟踪等等。可以查看图形化的流程整体运行情况，也可以查看单个流程实例的运行情况。流程监控使用了web2.0技术，有很好的交互性。基于web2.0的ESB监控查看一个流程实例的执行情况大洋ESB设计关键点ESB组织流程编排ESB是一个功能丰富的系统级根底组件，它既可以提供效劳代理的功能，又可以提供交互流程的管理功能。其中前一个功能是ESB的根本功能，后一个功能那么一般由ESB包含的BPEL工作流引擎来完成。交互流程的实现是由ESB承当还是各个系统自己组织，是一个需要权衡考虑的问题。在流程组织上，存在两种可能，一是发起方组织，二是由ESB组织。我们采用灵活性更高，系统接入更简单的ESB组织流程的方式。ESB组织交互流程这种方式下，ESB既提供效劳代理，又负责组织业务流程。各个需要交互的系统只需要将自己的效劳注册到ESB上，并且通过全台ESB来定义流程模板就可以实现互联。示意图如下：要点1ESB中部署所有交换业务的流程模板，使用ESB的BPEL流程引擎2数据交换相关的各系统将效劳注册到ESB中，如图中的A、B系统和EMB系统。3由ESB组织流程。ESB调用各个系统提供的效劳来完成数据交换。4各个系统的效劳注册到ESB上以后，由ESB直接调用，效劳的调用不需要代理。特点1系统交互的灵活性较低：因为是ESB组织交互流程，实现的方式必须通过ESB的BPEL工作流引擎。2对接入系统的要求比拟低：因为是由ESB组织流程，各个系统不需要考虑交换流程的组织，只需要在ESB上注册自己提供的效劳。3ESB的负载高：因为ESB需要组织所有的交换流程，功能比拟复杂；ESB上将运行大量的媒体数据交换业务的流程实例，负载比拟重。这点问题不大，本次提供的ESB效劳器采用SUNV490高性能小型机，其承当负载能力不容疑心。4系统故障隔离度低：交互流程是ESB统一组织，如果ESB出现问题，所有生产系统的交换流程都将受到影响。因此，我们在技术实现上加强ESB的平安。5统一流程监控的较容易：所有的流程都在ESB的流程引擎中运行，可以通过ESB的工作流监控统一监控。利用WSOC技术实现各系统间松散耦合效劳的组织和编排〔WSOC〕技术带来的系统间的松散耦合性，是使用ESB的最大优点，业务变化后可以方便的进行灵活适配。以制作域的素材入库媒资业务场景为例，假设业务发生了变化了，比方以前没有MD5校验，现在想参加这个环节。那么只需要修改流程模板，参加MD5校验节点。制作和媒资都不需要做修改，这些变化对它们是透明的，即使是EMB，也不知道流程模板修改了，它也不关心，它只是提供了MD5校验功能，所以说系统是松散耦合的。利用WSDI技术将流程发布为一个粗粒度的效劳流程动态发布为效劳〔WSDI〕技术使得流程本身也是一个粗粒度的效劳，使得各个系统之间只需要通过效劳来交互，再也不需要用到特定的流程API。用制作域素材入库媒资业务为例，定义了一个流程模板，叫“制作域素材入库媒资〞，这个流程模板对应一个由ESB自动生成的webservice。当制作调用这个效劳后，对应执行的并不是一个普通的webservice〔通过程序开发实现的效劳就是普通的webservice〕，它执行的是BPEL流程引擎的逻辑，是按照流程模板的定义执行流程。利用WSIF技术实现效劳的动态调用效劳调用框架〔WSIF〕技术，使得ESB可以调用各种各样的效劳，只要外系统的效劳提供了效劳的WSDL文件，无论是什么样的参数格式，无论是什么类型的效劳，ESB都可以调用，不需要修改任何软件。除了webservice，ESB还提供了对JMS消息接口和FTP接口方式的支持。这个技术带来的好处是，可以直接使用其他系统已有的效劳，而不是要求其它系统按照规定的接口参数格式重新开发一个，这样大大降低了系统互联的接入开发本钱。另外可以防止各子系统将和一个特定的不标准的ESB产品绑定。大洋ESB，能够保障效劳的使用方直接调用提供方提供的效劳，即使通过ESB平台也是直接调用效劳，不是需要统一转换为一个中间效劳＋参数的方式。如Import入库效劳，大洋ESB能够实现无论有没有ESB，都是Import效劳，而不需要转换成ServiseInvoeker〔效劳描述，参数描述〕的方式，这样大大减少了所有调用方和提供方的封装和拆解开发工作量和运行工作量。〔大洋ESB不要求效劳重复专门封装〕〔其它ESB要求效劳重复专门封装〕利用XSLT技术使得效劳代理和路由更加灵活ESB使用可扩展样式表语言转换〔XSLT〕技术，使得效劳的调用方和提供方互相透明。比方以前是A系统调用B系统提供的webservice，现在想通过ESB做代理来调用，那么A系统不需要修改代码，只需要修改调用的URL地址。这样充分的考虑了A系统的变更本钱，能实现外系统最低本钱的接入。更进一步的，如果将来B系统的效劳参数改变了，但是A系统不想做变更，那么ESB可以通过XSLT进行参数格式转换，使得A还是可以正常调用B的效劳。这个就是实现了B系统效劳对A系统透明。各个系统效劳的可重用性因为ESB支持动态调用，各个系统提供的效劳，并不是为系统互联定制开发的，所以是可以重用的。比方EMB提供的“添加拷贝、转码任务〞这个效劳，即使在点对点互联的时候，并不涉及到任何流程，也可以被第三方系统直接使用。业务流程可以重用性在各个系统的效劳接口统一的情况下，连业务流程都是可以重用的。比方有个业务流程是“素材从制作系统进入媒资系统〞，以后要加一个备播处理流程、备播入库播出流程，那么在ESB中定义新的流程的时候，可以使用拷贝的方式新建，使得流程的定义更加简单，也不容易出错。如以下图所示：ESB流程监控用户要求可以查询当前的流程实例、关键节点和实例的当前状态，并图形化显示。通过图形化显示方式，系统支持实时显示当前流程的动态变化。并且可实现运行流程进行重定向，挂起、结束等操作。在该界面下，通过图形化的流程配置，直接拖拽一个个效劳，用画Visio图一样连线完成一个数据流程的编排。图形化的监控：也可以通过Web方式监控流程实例的执行情况，对于某一个流程〔如备播流程〕，在该流程下运行的各个任务，只有某个任务的某效劳点故障，就会在流程图上报警，点击报警点可以查看任务的具体故障情况。大洋ESB的集成实现技术实现框架ESB平台技术框架ESB平台的根底平台是应用效劳器，主要包括Web构件容器、Web效劳〔Service〕容器、EJB构件容器、消息引擎、工作流引擎等构成。所以在我们的ESB集成中需要集成ESB引擎、消息中间件、流程中间件、应用效劳器等局部。ESB平台集成ESB平台主要有应用效劳器、WEB效劳器、流程管理监控工作站等组成。对于核心应用效劳器，部署ESB中间件，实现效劳之间的交互、整合编排、效劳的发布、查询以及异步调用等，所以核心效劳器需要被所有业务子系统访问和调用。图：核心ＥＳＢ效劳器与其他应用效劳器关系在WEBService的部署上，我们建议在各子系统边界部署应用效劳器，用于WSDL的暴露，因为将WSDL部署于业务系统边界的应用效劳器上有利于web效劳本身对子系统内部的数据库访问等封装。对于互连平台ESB来说只要能够发现和访问该WSDL即可。在核心ESB平台，我们建议配双机并行应用效劳器，实现核心交换数据的不间断；在应用效劳器平台上配置应用效劳的主备方式，实现软件级主备。大洋ESB平台的平安设计系统正式投入运行后，有大量的系统间交互信息都需要通过ESB来转发和传递，同时还有局部业务流程要通过ESB来组织，因此ESB集成的平安性也是一个不得不考虑的问题。ESB集成的平安性主要由效劳总线的平安性及效劳器的平安性构成，效劳总线的平安性主要通过信息的加密及对总线的访问控制来实现，效劳器的平安性那么要通过高可用设计或效劳器群集来实现。效劳总线的平安性在具体措施方面，效劳总线的平安性由许多组件组成，这些组件可以一起使用以确保用户经过认证、资源受平安性检查保护并且消息在从发送应用程序到接收应用程序的传输过程中是平安的，主要涵盖以下领域：当用户连接至总线以及使用总线资源时进行的用户认证和授权。客户机与消息传递引擎之间的以及消息传递引擎之间的平安通信传输。对参加总线的消息传递引擎进行的认证。对消息存储〔数据库〕用户进行的认证。消息传递平安性消息传递平安包括用户认证、检查用户是否有权访问资源以及确保消息在传输过程中的机密性和完整性。当创立与消息传递系统的连接时，可指定用户名和密码并认证用户名和密码。如果该认证成功，那么执行访问权检查来查看用户是否具有与总线连接的许可权。如果该用户没有许可权，那么拒绝连接。当连接访问目标〔发送或接收消息〕、创立临时目标或访问外部总线时，对用户名执行进一步的访问权检查。当连接访问主题时，将对包含该主题的主题空间〔目标〕执行访问权检查。如果还要求执行主题访问权检查，那么将对主题本身执行第二次访问权检查。要确保传输过程中消息的机密性和完整性，可为客户机与消息传递引擎之间、同一个总线中的消息传递引擎之间和总线之间的连接配置SSL或HTTPS平安传输。可配置消息传递引擎以要求它的所有连接使用平安传输，平安传输仅接受与来源的连接。也可禁用不平安入站传输链以确保仅平安链可连接效劳器上的消息传递引擎。以此方法，可以配置从源应用程序到目标应用程序的平安消息路径。认证在允许用户连接至总线之前，必须先检查它们的凭证。由于消息传递客户机可连接至总线上的任何消息传递引擎，所以必须确保客户机使用的用户名和密码存在于托管这些消息传递引擎的所有应用程序效劳器上的用户注册表中。EJB或Web容器中的应用程序代码可调用JMS客户机并将它作为JCA资源访问。通过是否已将应用程序代码配置为允许容器管理或应用程序管理的登录资源来确定认证检查。当认证失败时，抛出JMSSecurityException。在再次尝试之前，应检查总线上托管消息传递引擎的所有应用程序效劳器上用户注册表中的用户名和密码是否有效。基于角色的授权必须给予连接至总线的任何用户许可权，才能执行他们需要执行的操作。通过给它们指定一个或多个适宜的角色来完成此操作。当给用户指定角色时，会将该角色包含的所有许可权授予该用户。可以对以下对象上的所有操作进行授权：总线当用户连接至本地总线时，在允许该用户执行任何进一步的操作之前，将检查此用户是否具有连接至此总线的许可权。如果连接至本地总线的用户要发送消息至外部总线中的目标，那么该用户必须也获得授权访问外部总线。Web效劳用户需要权限以访问某个特定的web效劳。消息目标用户需要权限以发送、接收或浏览所有类型的目标。需要给创立临时目标用户授予对临时目标的创立许可权。消息主题要访问主题空间内的主题，用户必须获得授权以访问主题空间和此主题空间内的特定主题。Web效劳平安性用户必须具有许可权才能访问特定web效劳。如果需要通过路由将消息从一个web效劳传递至一个或多个其它web效劳，那么用户必须具有访问所有相关web效劳的许可权。要允许用户访问web效劳，那么必须通过根据他们需要执行的活动给他们指定适宜的角色，来给予他们所需的许可权。Web效劳的角色指定在注册了该web效劳的总线上定义，该总线上的所有web效劳路由引擎可以访问这些角色指定。消息目标平安性用户必须具有许可权才能访问目标，包括临时目标。如果需要将消息从一个目标传递至一个或多个其它目标，那么用户必须具有访问所有有关目标的许可权。要允许用户访问目标，那么必须通过根据他们需要执行的活动给他们指定适宜的角色，来给予他们所需的许可权。目标的角色指定在拥有该目标的总线上定义，该总线上的所有消息传递引擎可以访问这些角色指定。消息主题平安性用户必须获得授权才能访问消息主题。当连接访问主题时，将执行访问权检查，以确保与该连接相关的用户具有访问包含该主题的主题空间的许可权。如果启用了主题级别的授权，那么将执行此检查以确保用户也对访问主题本身具有许可权。创立预订时进行权限检查当用户创立预订时，需要进行权限检查以确保用户可接收指定主题上的消息。无论预订的消息何时到达，都将进行访问权检查以确保用户对访问特定消息主题具有许可权。另外，当为单个主题创立了预订时，当创立订户会话时将执行访问权检查。多总线的访问控制当将消息发送至外部总线中的目标时，将在两个阶段检查许可权：当发送消息时，检查发送方是否具有发送消息给外部总线的许可权。当消息进入外部总线时，通过检查外部总线上定义的许可权，检查是否允许发送方访问目标。通过使用外部目标本身的代理定义或外部总线的定义，将消息发送至外部目标。外部目标和外部总线定义都具有确定用户是否可将消息发送至外部总线的许可权。如果链接平安的总线，那么它们之间的链路应该是平安的。要通过使用SSL或HTTPS保护沿总线之间的虚拟链路传输的数据，需要定义必需的传输链然后引用传输链名称。平安性事件记录在事件日志中写入平安性事件记录。以下类型的事件应写入日志：为认证成功写入审计记录为认证失败写入错误记录为授权失败写入审计记录高可用性和效劳器群集由于ESB本质上是数据流通的总线，如果这些焦点出故障，那么与之相连、依靠这些焦点的各种过程也就会出问题。因此，与ESB相连的通讯根底设备是一个极其重要的因素。根底设备不运行，也就没法开展任何业务，这里可用性就成了关键问题。ESB所需的可用性水平要比它连接的各种应用所需的可用性更高。如果一个ESB的连续运行能力对其任务具有关键性的影响，其解决方法就在于群集和高可用性。高可用性是指一个软硬件解决方案从不可预知的中断中恢复的能力，这些中断情况包括：某个硬件出错，如某个处理器某个软件内部故障，如程序缺陷造成的不可恢复的程序崩溃系统无法应对某个处理的信息〔由于没有建立错误处理机制〕具备了高可用性，一个系统可以侦测故障并自动启动恢复过程，重启系统——不管是在同一硬件还是在备用设备上。ESB的高可用性涉及到使用一系列产品和操作系统设施，帮助确保在未预知的中断后数据的恢复。群集比高可用性还更进一步，它使用的是多个同水平系统并行，这样一来，即使其中任何一个系统故障，其它的系统仍然可以不间断地进行新的工作。在实际应用中，最为常见的平安性方案是将群集〔提供持续的效劳运行，进行新的工作〕和高可用性〔恢复某一队列管理器或ESB实例上的现有工作〕结合使用。这样一个群中故障的系统还可用通过高可用性设置进行重启。这种方式可以防止进行中的工作在故障发生时被搁浅或滞后使用高可用性恢复故障系统中运行的工作可以借助共享存储器，共享存储器保存有运行工作的状态，可以通过具有高可用性配置的另一台机器访问这些工作，从而从故障中恢复这些工作。除了防止未预知的效劳中断外，持续的可用性还有其它一些作用。例如有时需要将系统下线，以便进行常规维护或者安装新硬件，还可能需要备份系统和数据，或者对软件进行升级、测试或维护，这时候我们都不允许业务被中断。群集还可以让多个系统能够分担工作，这样可以更加有效地平衡工作量。例如，重要工作可以安排给功能最大的机器。再上一个级别讲，群集可以被用来动态、灵活地应对不断变化的工作重要性。如果某些类型的信息交互有时间限制，那么可以调用其它资源，帮助处理增加的工作量。消息存储的平安消息分为Webservice消息、JMS消息、MQ消息等类型。ESB接收到客户端发送的消息后，在效劳调用和路由的整个过程中应该负责消息的完整性和可靠性。ESB首先将消息存储到本地数据文件、内存数据库或者远程数据库等中，然后将消息发送给接收者，在效劳路由的过程中还可以通过格式转换或者协议转换得到中间数据也需要进行保存。为了保证消息的平安，如果只保存在内存中是远远不够的，必须对消息进行持久化处理。也就必须保证存储消息的文件或者数据库的平安。文件的平安由于在采用高可用方案时，消息数据文件通常存储在共享存储体上，共享存储体可以采用冗余读写模式，如RAID1/3/5等，以保证单个硬盘物理损坏时阵列中的媒体数据不丧失。数据库的平安ESB的数据库效劳器应采用双冗余配置，数据库数据采用高可用盘阵存储，可以定期备份到本地或全台网系统的中心备份盘阵上，形成多重备份，通过多种技术手段来保证数据库的平安。ESB网络的平安ESB网络的平安如上图所示，各应用系统通过自己的应用效劳器与ESB发生信息交互。为了确保ESB的平安，我们建议在各系统的应用效劳器上使用双网卡配置，一个网卡连接应用系统自己的交换机，另一个网卡连接到ESB的交换机。所有的ESB效劳器都接到ESB交换机上。在ESB交换机上将ESB效劳器与各系统的应用效劳器划分到一个VLAN内，从而实现ESB系统的逻辑隔离。VLAN是为解决以太网的播送问题和平安性而提出的一种协议，它在以太网帧的根底上增加了VLAN头，用VLANID把用户划分为更小的工作组，限制不同工作组间的用户二层互访，每个工作组就是一个虚拟局域网。虚拟局域网的好处是可以限制播送范围，并能够形成虚拟工作组，动态管理网络。大洋EMB设计大洋EMB平台架构模型EMB架构如上图的EMB架构，EMB系统包含了任务调度效劳器〔DY-EMBManager〕、任务执行工作站〔DY-EMBActor〕、系统配置模块〔DY-EMBConfig〕、系统监视器〔DY-EMBMonitor〕、模板编辑器〔DY-EMBTemplateEditor〕、消息中间件以及对外接口〔DY-EMBInterface〕等模块。DY-EMBManagerDY-EMBManager是整个EMB平台任务调度的中心，是EMB平台任务调度分发的中心。它主要负责任务的接收、拆分、Actor的管理、任务的下发和实现故障逻辑等多项工作。由于EMB平台采用多站点协同工作的模式，因此整体的组织调度的重要性就显得更加突出，而Manager扮演的是总指挥的角色。DY-EMBActorDY-EMBActor是EMB平台中迁移转换任务的具体执行者。当Actor效劳启动之后，首先向Manager进行注册，通知Manager该Actor已经上线，且当前状态为空闲，可以接收任务。此后，根据Manager的任务调度，Actor负责接受并执行数据迁移转换任务。Actor在执行任务过程中，定期向Manager汇报当前任务的信息，说明Actor工作状态正常。Actor可以执行的任务类型包括：跨系统媒体文件的传输〔在线到在线〕直接交换间接交换流方式传输高标清上下变换上变换支持PillarBox、FullWidth、Stretch等三种模式下变换支持LetterBox、EdgeCrop、Squeeze等三种模式根据不同的变换质量要求支持多种变换算法编码格式转换，支持所有主流高标清编码格式MPEG1、MPEG2、MPEG4DVSD、DV25、DV50、DVCProHDHDV、XDCAMHD、XDCAMHD422DNxHDAVCIntra50Mbps、AVCIntra100MbpsJ2KWMV、RM、MOV、H.264文件格式转换ODMLAVIMSVFWAVIISMAMP4TSMXFOP1a、OPAtomAAF、AAFRefrence支持在MXF文件中依据DMS-1标准进行元数据嵌入自动技审功能对源文件的MD5校验，支持编传输边进行源数据MD5校验对目标文件的MD5校验码生成DY-EMBConfigDY-EMBConfig是EMB系统的配置工具。主要功能包括Manager的注册、Actor的注册、存储区的注册、Actor与存储区之间访问能力的配置和任务执行规那么策略的制定等。EMBconfig界面DY-EMBMonitorDY-EMBMonitor是EMB系统的运行监控中心，包括设备状态监控、任务状态监控、存储区监控、日志管理等供功能。EMBMonitor界面EMB任务详细信息DY-EMBTemplateEditor模板编辑器TemplateEditor是EMB系统中用来预先设置转码参数的模块。当系统之间进行大量的媒体文件交换时，如果源和目标格式的格式相比照拟固定，那么就可以将源、或者目标的格式信息，保存为模板。之后再提交转码任务的时候，就不需要指定详细的视音频格式信息，而是只需要指定采用的格式模板即可。通过采用模板，不但可以简化外系统调用EMB接口的工作，也可以有效地防止出现参数填充不正确而导致任务失败。DY-EMBInterfaceDY-EMBinterface是EMB系统提供应外系统调用的一组标准webservice效劳，它是EMB系统暴露给外系统的唯一软件模块，是EMB与外系统的唯一交互接口。它提供了包括添加任务、任务进度查询等操作。外部系统通过访问EMB的接口，就可以获得EMB提供的传输、转码、校验、自动技审等各种功能。DY-EMB消息中间件消息中间件是DY-EMB的Manager和Actor之间通讯使用。采用标准的开源JMS消息中间件。大洋EMB设计关键点基于Linux平台的部署EMB的效劳器作为全台主干核心效劳器，其对平安和稳定要求比拟高，除效劳器配置的平安考虑外，操作系统的选择也是一个比拟重要的考虑，我们建议在Linux平台进行实现，Linux平台的优点是：平安，稳定，对盘符没有限制等，比拟适合核心效劳器的应用。存储区与访问路径对存储区的管理是EMB最为核心的功能之一，EMBManager需要了解有哪些存储设备可以被EMBActor访问和EMBActor能够以何种形式访问存储区。EMBManager依据这些信息作为路径转换和调度Actor执行传输任务的依据。在EMB系统中，存储区的定义根据系统ID和访问路径实现。存储区与访问路径如上图所示，每个应用子系统内部都包含了存储设备，而每款存储设备有可能对外提供多种访问路径。例如对系统A中磁盘阵列的访问可以基于SAN共享文件系统以本地磁盘X:\方式实现，也可以通过FTP效劳器以FTP://1/的方式进行。而且EMB系统内部对存储区的访问方式与系统外部的访问方式通常是不同的。如系统C，内部工作站基于SAN共享方式访问阵列，而EMB只能以UNC或FTP路径访问存储体。当在EMB系统中配置存储区时，需首先定义参与交互的多个系统，再为每个系统配置一个或多个存储区。每个存储区具有至少一种访问路径，也可以设置多条不同类型的访问路径指向同一的存储区。在一个系统内部，不同存储区的访问路径是各不相同的，而不同系统之间存储区的访问路径有可能是重复的。如上图所示，系统A和系统B内部对共享阵列的访问都是X:\，此时就需要根据系统ID和访问路径唯一确实定一个存储区。存储区的访问路径配置在配置存储区的访问路径时，除了需要包括EMB可以使用的路径之外，还需要将各应用系统内部对存储设备的访问路径注册在存储区之内。当应用系统按照内部使用的访问路径提交交互任务时，EMB就可以依据任务信息中的系统ID和内部路径信息定位存储区，再查找出该存储区的所有可访问路径，从中选择出EMBActor可以使用的访问路径用于任务执行。Actor对存储区访问能力的设置在EMB配置过程中需要为每个Actor设定其对各个存储区的访问能力，即允许或禁止选定Actor对特定存储区的访问。当存储区具有多种访问路径时，还需要确定Actor可以通过哪些访问路径对该区进行读写。当所有Actor全部配置完毕后，EMB系统中就建立出一张所有Actor与所有存储区之间的通断关系表。EMBManager就是根据这张路由表确定任务分配的原那么。路径优先级的设置在EMB系统中可以对一个存储区的不同访问路径设置默认优先级。例如对于FC存储设备来说，可以设置FC访问方式的优先级高于FTP方式。多条访问路径也可以设置相同的优先级，当一个存储设备对外提供多台FTPServer作为接口时，这几条FTP路径的优先级就是相同的。由于各Actor对存储区的接入方式不尽相同，因此不同的Actor使用同样存储路径访问存储区时的性能也是不同的。因此在设置EMBActor与存储区访问能力时，也可以设置该Actor对特定路径的访问优先级。当针对Actor的访问优先级设置与存储区的默认设置不同时，以针对Actor的设置为准。EMB路径选择逻辑在提交系统间交互任务时，源系统A按照会提供源文件的路径信息，目标系统B会设定目标文件的路径信息，这两条信息作为向EMB添加任务时的参数传入EMB系统之中。通常情况下，提交的任务中源和目标系统添加的路径信息都是按照本系统内对存储区的访问方式编写的，例如系统A提供的源路径为X:\abc.mxf，系统B提供的目标路径为M:\xyz.mxf。EMBManager在接收到此任务后，首先根据系统ID和路径信息确定源及目标的存储区，再根据存储区查找EMBActor能够使用的访问路径。例如A系统对外只提供了FTP接口供EMB访问，那么Manger会自动将X:\abc.mxf的路径转换为FTP://xxx.xxx.xxx.xxx/abc.mxf；系统B中设置了NAS网关将数据共享给EMB访问，Manager就会自动将M:\xyz.mxf转换为\\yyy.yyy.yyy.yyy\xyz.mxf。当某个存储区有多条可访问路径时，将首先使用优先级最高的路径以保证迁移性能。路径转换完成后，Manager会选择一台可以同时访问系统A和系统B存储区的空闲Actor执行此任务。盘符资源问题的解决由于EMBActor需要同时访问多个系统，每个系统内可能包括多个存储区，因此每台EMBActor有可能需要访问十几甚至数十个存储区。由于Windows操作系统平台存在最多26个盘符的限制，在某些极端情况下可能出现Actor盘符资源缺乏的情况。为此可采用以下几种方案解决。防止不必要的盘符占用对存储区的读写通常有多种访问方式可供选择，其中FTP访问、UNC路径访问等方式都不需要占用Actor的本地盘符资源。因此如果条件允许，可以尽量选用FTP、NAS共享等方式作为Actor访问存储区的手段，以尽量减少占用盘符的需求。动态Mount磁盘对于某些分布式文件系统来说，要想正常访问共享存储资源必须占用本地盘符，但如果Mount磁盘与Unmount磁盘的操作可以不经重启立即生效，那么可以实现EMBActor对盘符资源的动态使用。也就是说EMBActor在通常状态下不Mount这些磁盘，只有当执行需要访问该存储设备的任务时才自动Mount相应的磁盘，任务执行完毕后Actor自动Unmout该磁盘，释放盘符资源。减少文件系统数量如果业务子系统使用的共享文件系统软件为SNFS，且EMBActor使用FC接入或LANClient接入的方式，那么要想正常访问共享存储，必须分配本地盘符资源，且更改、释放盘符均需要重启主机。在这种情况下，EMBActor很可能出现盘符缺乏的情况。如果在系统规划设计阶段发现此问题，可以考虑通过增加单个文件系统容量的方法〔目前有实际案例的SNFS单文件系统最大容量为300TB〕减少系统中共享文件系统的数量，从而解决盘符缺乏的问题。而且，SNFS客户端每Mount一个文件系统，就需要占用一定的内存空间，因此通常情况下不建议一台SNFS客户端同时访问很多文件系统，这样容易引起性能下降和系统的不稳定。Actor分组如果Actor上的盘符资源确实缺乏，那么可以考虑将Actor按照对存储设备访问能力的不同分为多个组。每组Actor只访问一局部存储区，且保证任意两个存储区之间至少有一台Actor可以进行直接交换。这样EMB在执行任务时可以自动调度相应的Actor完成数据传输。使用Linux操作系统盘符资源缺乏是Windows操作系统特有的问题，与Windows文件系统管理机制直接相关。因此如果EMBActor使用Linux操作系统平台就可以彻底解决此问题。在Linux下根本没有盘符的概念，所有磁盘的Mount点只是一个目录而已，因此理论上可以Mount任意多个文件系统。传输性能的优化EMB执行的主要任务就是完成大数量媒体文件的跨系统传输，为此EMB采用了多种技术手段来提高数据传输的性能。数据块大小调整大量的实际测试数据说明，在进行大数据量传输交换时，应用程序使用的数据块大小对读写性能影响很大。以下图为我们针对FTP传输效率进行的测试结果，测试环境中FTPClient与FTPServer之间使用千兆以太网连接。可以看出当每次I/O使用的数据块较小时，FTP传输的性能很低，随着数据块的增大，FTP传输性能明显提高，当数据块大小到达1024KB时，FTP传输的性能已经接近100MB/s，到达了千兆以太网理论带宽的80%，此后继续加大数据块，性能的提升就不明显了。数据块大小调整大量在其他各种环境下进行的测试结果也说明，数据块大小在1M——4M之间时，数据读写的效率最高。因此在大洋的EMB产品中，默认每次I/O的数据块为1M，并且可以根据实际网络条件进行配置，以实现效率最优化。最优访问路径选择大洋的EMB产品支持为存储区的不同访问路径设置优先级，也支持针对EMBActor设置该站点访问存储区的优先级。根据这些信息，EMBManager在进行任务分发的过程中，将自动为Actor选择优先级最高的链路。根据这一特点，只要在配置时为高性能链路设定较高的优先级，EMB就可以自动实现使用最优路径进行数据传输。最优访问路径选择如上图所示，系统A和系统B都使用FC阵列作为核心存储体，EMBActor既可以通过FC直接访问两个系统，也可以通过FTP的形式实现IP接入。由于FC传输的性能明显高于IP传输，因此在配置时可以让FC路径的优先级高于FTP路径。此后当EMB接收到系统A、B之间的交互任务时，将优先选择通过FC路径进行，即使在提交任务时，源和目标的路径是FTP的形式，在EMB内部也会自动完成路径转换，Actor在执行任务时对存储的访问仍然基于FC实现。多等价路径负载均衡当某个存储区对外有多条同优先级的路径时，EMB在执行任务过程中会自动实现多等价路径的负载均衡，以防止传输压力集中在某一台效劳器上，形成性能瓶颈。如以下图所示，系统A和系统B均以FTP方式对外提供接口，每个系统中均部署了三台FTPServer，因此注册到EMB之中的访问路径也有三条，且由于三台FTPServer传输性能完全相同，这三条访问路径的优先级也相同。当有多条系统A、B间的数据交互任务提交时，EMB会自动将任务平均分配到所有FTPServer之上，即Task1通过FTPServer1传输，Task2通过FTPServer2执行。如果在提交任务时，所有的任务源和目标路径均指向的是同一个FTPServer，当EMB在执行任务时发现对于该存储区还有多条等优先级的路径存在后也将根据负载均分的原那么将任务分配到不同的FTPServer上完成。多等价路径负载均衡多Actor并发传输在某些特殊的应用场景对系统间素材传输的效率要求极高，而单台Actor传输的性能已经无法满足要求，此时可以采用EMB的多Actor并发传输方案，通过多台效劳器同时工作缩短文件传输时间。多Actor并发传输如上图所示，当某一任务需要多Actor并发传输时，EMBManager会查询当前空闲的Actor的数量N，并把整条传输任务均分为N段子任务，分别下发到所有当前空闲的Actor上，每台Actor只负责传输文件的一局部数据。此时由于多台Actor并行工作，数据传输的效率可以得到成倍的提升。但这种工作方式要求目标存储系统必须支持分布式文件锁定，即允许多台主机同时写入一个文件。如果目标存储系统只提供FTP的接入方式，那么无法采用这种并发传输技术进行效率优化。Actor同时执行数据传输和转码任务EMB承当的工作主要包括数据迁移和转码两类，这两类任务的特点有很强的互补性。传输任务是一个带宽密集型应用，通常对主机CPU占用率并不高；而转码应用因为涉及到复杂的编解码运算，CPU利用率经常会接近100%，但此时数据读写带宽并不大。因此，通常情况下每台Actor在同一时间只执行一条任务，但当EMBActor数量缺乏时，EMBManager会向正在执行转码任务的Actor分发数据传输任务，同时向正在执行数据传输任务的Actor分发转码任务。这样就充分利用了所有Actor的CPU运算资源和网络传输能力，缩短了任务排队等待执行的时间，提高了总体工作效率。传输带宽限制在绝大多数情况下，我们都希望EMB传输的速度越快越好，但也需要考虑到EMB传输带来的带宽压力对应用子系统自身的影响，不能由于EMB的传输导致业务子系统带宽缺乏或产生不稳定的情况。因此，对于某些系统间的交互，需要对EMBActor的传输速度进行限制。当进行了速度限制之后，EMBActor在执行任务时就会自动控制读写速度，防止占用过高的带宽。转码性能的优化提高转码效率的几类方法电视台内不同应用系统对视音频格式的要求可能不一样，EMB这时就需要进行编码格式的转换工作，通常简称为转码。转码任务的根本工作原理如以下图所示：原始格式的媒体文件输入解码器，得到无压缩的视音频数据，再进入编码器生成目标格式文件。由于视音频的编码和解码算法通常都比拟复杂，转码处理一般会消耗很长的时间。特别是对于高清视频来说，需要处理的数据量约为标清的5倍，为降低压缩码率往往采用一些算法更为复杂的编码格式，因此高清转码的效率问题尤为突出，如何高效高质的完成大量高清素材的格式转换任务，成为工程设计中的一个关键问题。传统的方法是建设一套转码中心，多台转码效劳器同时并行工作，每台效劳器执行不同的转码任务，虽然执行每条转码任务的时间没有缩短，但由于有多台效劳器共同工作，完成所有任务所需的时间可以得到显著的减少。这种方案比拟适用于系统中存在大量转码任务，每条转码任务时间较短，且对单条任务的执行效率要求不高的场合。而系统实际运行过程中，很多情况下会对单条转码任务的执行时间有很高的要求，在时间紧急的情况下，需要一条较长的素材在最短时间内完成转码。为此，除了选用性能更强的硬件平台进行转码计算之外，还可以采用以下三种方法在不降低编码质量的情况下优化转码效率。编解码算法本身的优化由于绝大多数编解码算法只是定义了框架结构，而没有具体的实现方案，因此在编解码的实现算法上通常有一定的优化余地，如应用CPU提供的SSE3指令集，选择一种高效的运动估计算法等。这种优化方法通常难度较大，而一旦在技术上有所突破，对性能的提升往往是非常明显的。但对于一些比拟成熟的编解码算法〔如MPEG-2〕来说，在算法本身上进行进一步优化的余地已经不大了。多线程优化当前计算机中央处理器开展最为明显的趋势就是主频增长根本停止，性能的提升主要依赖多核多线程技术。自从Intel推出P4以来，CPU的最高主频一直没有突破3.6GHz，但每个CPU中集成的核数却不断增加，从最初的单核超线程到目前的四核CPU，预计明年中还将推出Nehalem，第一款8核CPU产品。CPU核数越来越多意味着可以并行执行更多的任务，因此提高编解码算法的并行性，使其能够充分利用多个核心的计算性能成为提高转码效率的重要手段。对于Windows平台的应用来说，每个进程中可以包含多个线程，而每个CPU的内核在同一时间内只能处理一个线程的运算任务，因此要想充分发挥多核的性能，必须使用支持多线程的编解码器。对于编解码器的多线程优化，主要的措施是将不同帧的处理分配到不同线程中，并将每帧的不同宏块的计算拆分到不同线程完成。对于转码应用来说，还可以将编码器与解码器分配到不同线程执行，从而进一步提高并发性能。实践证明，经过多线程优化的编解码器比未经优化的编解码器在多核CPU之上运行的效率相差一倍以上。分布式转码经过多线程优化后的编解码器已经根本能够将单台Actor的性能发挥到极限，但以目前双四核PC效劳器的性能完成高清视音频的转码任务最高也只能到达2——3倍速，即一小时的高清节目至少需要20分钟才能完成转码，要想以更短的时间完成转码工作，就必须使用分布式转码技术，调动多台Actor的运算能力，同时执行一条任务，从而进一步提高转码效率。分布式转码任务拆分和Actor调度当Manager接收到一条分布式转码任务时，首先进行任务分解，将一条长时间的完整转码任务分割为多条时间相对较短的子任务，任务分解是实现并行计算的根底。而基于何种策略进行任务拆分对分布式转码过程中能否充分利用所有Actor的资源有重要的影响。比拟简单的任务分割方案是按照当前空闲的Actor数量将整条任务均分为多段，由每个Actor负责执行一段。这种方案逻辑最简单，在通常情况下处理的效率也较高，但也存在一些缺陷。首先是由于EMB中包括很多台Actor，各Actor的工作状态会随着任务的执行随时变化。因此在转码任务执行过程中有可能会出现新的空闲Actor，而由于此前任务已经分配完成，这些Actor的计算能力就无法被利用。其次是各Actor由于硬件配置不同、对存储的访问效率不同可能会导致转码速度不同，这样对于相同长度的片段转码时间可能产生不同，也就是说会出现有些Actor已经完成了转码而在等待其他Actor的情况，Actor的运算资源得不到充分利用。另外当转码过程中任何一个Actor发生故障时，它正在执行的转码任务需要进行重试，而如果每个Actor分配到的片段很长，就意味着失败重试时所需要的时间也会比拟长，从而影响整体转码速度。为解决以上这三方面的问题，在大洋的EMB系统中对任务的拆分方式进行了优化处理，采用了“蚂蚁啃骨头〞的策略，即将整条任务拆分成很多个小片段，片段的数量远大于Actor的数量。在任务下发时，按照片段的时间先后顺序分配给所有的Actor。Manager随时监控Actor的工作状态，一旦发现有空闲的Actor就将新任务分发过去，直到所有子任务全部执行完成。采用这种优化后的策略，可以有效的解决第一种策略的三方面问题。由于任务是动态指定的，只要出现空闲Actor的计算资源就可以得到利用。由于每个Actor执行完任务后就会自动获得下一条任务，实现了能者多劳，即转码速度快的Actor执行更多的转码任务，实现了转码能力的动态平衡，从而保证了总体效率不会被个别性能较差的站点制约。由于每个片段的时间较短，进行错误重试也不会消耗很长的时间。当然这种任务的拆分也不是越小越好，主要受到三方面因素的制约：第一是每个子任务的分发、启动和完成后的提交都要消耗一定的资源，因此如果任务数量太多，消耗在这局部处理上的时间会很可观，从而影响效率的进一步提升。第二是对于编码器来说，为进行码率控制也需要片段长度不能过短，否那么很难保证码率的准确。第三，假设果采用IBP作为目标压缩格式，还需要考虑GOP对齐的问题。即任务的拆分点需要在两个GOP之间，保证临时文件中每个GOP都是完整的。虽然按照标准定义，在一个文件中GOP的长度是允许可变的，而且大洋的应用程序已经完全可以支持变GOP素材的播放编辑，但我们也发现很多厂商对此的支持程度实际并不好，因此为保证兼容性，我们采取的策略是通过任务拆分策略保证生成的文件GOP固定。因此，在大洋EMB系统中，子任务粒度通常设置为1到3分钟左右，经测试这是一个