关键词：
部署架构设计（精选七篇）
部署架构设计 篇1
但是，伴随企业的不断发展和壮大，企业的规模也日趋庞大，在不断发展的过程中，新的分部的建立很可能带来新的ERP数据中心的建设，整个企业的ERP系统架构也就很可能从集中的模式发展成为分布的模式。企业可以按照地域或者行业进行ERP系统的分布部署，无论按照何种划分模式，其部署架构都会转变为图1右半部的模式。在这样的模式下，企业ERP接续的BI系统的建设以及为之服务的数据仓库BW系统，将会有不同的架构方案。
方案一：构建企业级BI平台(或者叫企业级数据仓库平台，见图2)
企业级数据仓库，按照数据仓库领域的权威W.H.Inmon给出的定义：数据仓库是一个面向主题、集成、时变、非易失的数据集合，是支持管理部门的决策过程。数据仓库是一种解决方案，是对原始的操作数据进行各种处理并转换成有用信息的处理过程，用户可以通过分析这些信息从而作出策略性的决策。
构建企业级数据仓库平台即在统一的技术思想的指导下，采用统一业务数据模型标准并且共享数据模型标准，采用统一的编码标准和数据仓库模型标准，运用统一数据仓库技术架构及软件，从而搭建统一安全架构、运维架构。这个平台，统一将所有运用于分析的ERP等业务系统作为数据源，抽取相应的数据到数据仓库的数据集结区，而总部和分部将在这些数据的基础上各取所需，根据不同的分析需求，将数据进行转换和汇总，建立多维度分析模型，通过报表展示工具和企业级门户输出分析结果，协助企业高层的决策分析。这个平台统一面向各数据中心，是为各数据中心服务的平台，各个数据中心的BI应用都架构于这个平台之上。
这个架构的特点是：
1)总线结构;
2)数据来源统一，数据分析颗粒度一致，不会导致多统计口径而数据不一致的情况发生;
3)流程上可形成统一业务流程，操作流程，建立同一入口的报表平台，实现数据的自动传递，减少不必要的手工操作，提高数据的质量，提高出具报表的效率;
4)平台为总部、分部各数据中心提供级别一致的服务，总部管理平台本身，平台之上应用的管理则由应用所属单位进行管控;
5)平台一旦建成，即可形成系统、权限管理以及运维方面的指导性的规章，接续扩展建立的BI应用都可以遵循，管理上整齐划一。
方案二：构建分布式BI平台(见图3)。
分布式的BI平台顾名思义就是每个数据中心各自为战，面向各自的ERP等业务应用建立相应的BI分析应用，各个数据中心根据自身业务特点构建符合自身需要的BI应用系统业务，在管理上允许百花齐放，财务分析视角也更加灵活多样。分布式架构的特点是：
1)树形结构;
2)数据来源多样，数据分析颗粒度多样，总部数据中心的数据源既可以是ERP等业务系统，也可以是各分部的BI系统，总部数据统计口径会和分部的统计口径产生不一致的情况;
3)每个数据中心分部都可以制定符合自身要求的业务流程和操作流程，各数据中心对数据质量的要求不一致，这取决于业务分析需求;
4)对总部的管理来说既可以下放到下属公司去管理，也可以部分收回到总部来管控;
5)由于不是通盘考虑，在早期的实施上更为快速便捷;各分部数据中心建立的BI系统的生成成果可以直接为总部所用;总部可以抓大放小，突出层级管理的优势;分部可以在自己的权限内完全制作符合需求的BI应用。
这两个方案没有优劣之分，视企业发展的进程而选择是采用什么方案。两个方案也可以嵌套存在。无论哪种方案中，构成BI应用系统核心的BW数据仓库的建设都遵循几方面的必要因素，一是源系统，就是提供数据供企业级数据仓库抽取存储集成的系统，可以是前端操作型的、完成数据收集的业务系统，也可以是完成数据分析结果输出的BI系统;二是保存从源系统抽取过来的原汁原味数据的抽取层，供以后的应用及分析;三是数据合并及处理层，即由于业务需求需要对抽取层的数据进行加工转换或者抽取层的数据来自于不同的系统和不同的地点而需要把数据合并起来进行操作的部分;四是数据分析层，就是按不同分析主题以及部门等对数据进行多维度汇总分析;五是数据展现层，即出具各种报表供用户查询提供数据访问的界面，这个展现层可以根据不同的部署模式，存在于企业级BI平台之上或者存在于各分部数据中心BI应用之上。
企业通过前端业务系统完成原始的数据收集后，如何利用这些数据提高企业的竞争能力，扩大企业的利润，降低企业的成本都成为决策层所面临的问题。另外市场全球化，顾客需求多样化、个性化、变化频率加快，竞争范围和激烈程度逐渐加大和加剧，企业要想生存就必须迅速反应，实施管理信息化和决策智能化，商务智能(BI)不断进入企业也就顺理成章。企业ERP以及BI项目的实施是一个长期而艰巨的任务，我们做好系统架构建设的愿景就是能为企业提供技术和数据的支持服务，做到信息触手可及、关键指标可以进行各方面的分析、各方面的信息可及时发布到相应的信息披露平台甚至是到企业管理层的移动设备上，各级管理者可以通过包含报表工作平台在内的一切途径，了解管辖的业务状况，缓冲沟通歧义并且节约沟通等成本，从而作出有利于企业生存发展的重要决策。
参考文献
[1]陈永杰.SAP商务智能完全解决方案[M].北京:机械工业出版社,2008.
部署架构设计 篇2
近年来, IT、IP、互联网发展迅速, 媒体、通信等产业也随之呈现出跨界融合的趋势。其中, 以OTT视频/TV为代表的OTT及信息娱乐服务蓬勃发展, 已经开始对传统媒体的市场份额产生冲击。Over The Top (OTT) 业务最典型的特征是其运营者利用网络服务提供商 (ISP) 的网络开展新媒体业务[1], 其本质是利用统一的内容管理与分发平台, 通过开放的互联网, 向智能机顶盒提供高清的视频、游戏和应用, 是全球性的“云电视”技术系统架构[2]。
目前, OTT应用模式主要有两种:一种是采用C/S (客户机/服务器) 模式, 客户端软件装在终端上, 所有应用在终端上直接运行, 不通过浏览器;另外一种是Web应用, 其优势在于统一浏览器发展应用对不同操作系统及终端的良好适用, 应用软件运行在Web上, 以Web为中心的模式又回归互联网, 促进平等竞争。
本文提出的面向OTT业务的应用部署及更新管理系统, 其依托的多层架构混合模型融合了B/S模型及C/S模型两者的优势, 且该系统可提供独特的应用路由映射及扩展管理功能, 极大地方便了OTT业务中大量应用部署管理, 并明显简化后续升级操作。
2 混合模型介绍
B/S (浏览器端/服务器端) 与C/S (客户端/服务器端) 是当前应用开发部署的主流模型。如果将浏览器看作特殊的客户端, 两者在一定程度上是相似的。从软件工程的角度来看, 两者均建立在表现层、程序执行及数据管理逻辑分离的多层架构基础之上[3]。
三层架构是多层架构中最广泛使用的, 它由表现层、逻辑层及数据层组成。其优势在于可以在需求变动时对三层结构中的任何一层进行独立更新或替换。因此, 该结构被广泛应用于B/S模型与C/S模型中。图1所示为B/S模型中三层架构的结构图。
尽管如此, 两种模型仍存在重要区别。问题集中于客户端功能界限的争论, 即分为瘦客户端 (浏览器) 和富客户端。通常来讲, 浏览器作为瘦客户端仅需要对来自Web服务器的资源进行加载, 使其正确提取并利用浏览器端语言, 如JavaScript处理用户交互行为[4]。
剩余的工作将转交给服务器端, 服务器端可以利用服务器的计算能力执行信息处理过程, 并根据特定业务逻辑访问专有数据库或其他数据源。对跨平台兼容性的原生支持以及Web浏览器的普及, 使基于B/S模式的应用无须在成千上万的计算机上分发和安装软件而实现更新和维护。典型的富客户端是一个独立可执行程序, 包含由用户控件组成的图形界面。由于其能够通过操作系统调用更多本地资源, 该典型富客户端有很好的快速响应性能。但是由于多的逻辑嵌入, 一旦需要升级, 系统将面临相对较高的维护费用。
随着高级Web应用的出现, 浏览器开始承担越来越多的工作量。同时, 与C/S模式中的应用相比, 一些运行在浏览器中的应用需要充分调动本地计算能力与资源以应对特殊需求。为满足以上需求, 本文提出一种基于多层结构的新型混合模型, 该结构包含基于WebKit的表现层[4]、新添加的第三方服务提供层、逻辑层和数据层。第三方服务提供层是本混合模型的特殊之处, 它是引领表现层与逻辑层通信的中间件。上述所有组成部分构成如图2所示的多层架构体系。
比较图1与图2可以看出, 混合结构的表现层有一个比较直观的修正, 即地址栏被取消。新添加的第三方服务提供层管理控制表现层所要加载的应用以及所需的扩展。
3 逻辑层与数据层
混合模型中的逻辑层、数据层与在B/S模型中相似, 都是整个应用的核心部分。Web服务与数据库服务分别在这两层中。Web服务包含于应用相应的逻辑与服务规则中。
由于数据库可以提供数据读取逻辑, 处理存储、检索及数据更改, 同时验证数据完整性, 因此, Web服务作为数据库服务的客户端有足够的数据保证。通常来说, 由服务器变为Web服务器必须要有RDBMS (关系数据库管理系统) 。包含Apache, IIS, lighttpd以及nginx在内的主流Web服务器通过整合服务器端程序语言操作环境实现了应用逻辑与进程数据库数据。服务器端的程序设计有多种选择, 如PHP, Python, Ruby on Rails, .NET和Java。以上语言有编译也有解释, 采用何种语言的主要依据是性能与开发成本的权衡。一般来说, 编译语言的性能要高于解释性语言, 但前者在开发成本和维护费用上花费较高。因此, 解释性语言如PHP, Python或者Ruby on Rails更适用于快速开发和迭代, 而编译性语言如C# (.NET) 或者Java则广泛应用于金融业或其他对性能安全性较为敏感的领域。
除了如MySQL and PostgreSQL等开源数据库以外的商用实例数据库有Oracle, DB2, Microsoft SQL。在所有的备选数据库中, MySQL对基于读取的应用程序是最好的选择, 这些应用程序需要从数据库中频繁读取数据。但是如果需要使用事务处理或其他高级功能, 数据库的选择更倾向于Oracle, DB2或者Microsoft SQL Server。
Web服务器、数据库服务器与操作系统协同合作, 共同构成完整的开发环境。LAMP是一个很著名的配置平台, 其字母分别代表Linux (操作系统) 、Apache HTTP服务器、MySQL以及PHP (有时也指Perl或Python) 。
4 第三方服务提供层
4.1 主要功能介绍
最初的表现层是一个基于WebKit普通的纯展示框架, 只有在配置完成且添加扩展之后才可应用。下文基于WebKit的表现层部分将详细阐述WebKit的技术细节。对于混合模式中的表现层, 需要添加一个额外的层来指挥表现层和逻辑层的通信过程。因此本文提出第三方服务提供层 (Third-party Service Provider, TPSP) 以管理所有应用配置及随后的升级信息。应用程序路由映射及扩展库是TPSP的主要功能。图3所示为TP-SP的操作原理图。
4.1.1 应用程序路由映射
应用程序路由映射负责维护关系映射表, 该表记录了序列号与TPSP预先分配的特殊值的对应关系, 以及应用的名称、图标、存取地址等信息。
客户端在安装步骤中会提示用户输入序列号。由此, 安装程序将携带序列号向TPSP发起请求, 并通过解析JSON格式化文本响应初始化配置文件。
不同的应用程序有不同的序列号及配置信息, 但是它们都有相同的表现层。表现层作为不同平台上应用程序的通用壳, 简化了自定义开发的难度。
4.1.2 扩展库
最初的表现层功能是有限制的, 本文提出应用以下扩展库来增加其功能。扩展开发且依附于表现层使其生效。扩展库可看作扩展的托管云提供两方面的服务:扩展管理与扩展分配。所有的扩展无论是专用还是通用都会预先被存储在库中, 然后与应用程序产生关联。为响应应用程序路由映射, 扩展库中包含描述所需扩展的附属关系及其介绍等信息。由响应信息指引, 安装文件从扩展库中取出扩展交给客户端的响应层。此外, 随后的升级版本也通过相同途径接收响应并获取新扩展。
4.2 应用部署及更新管理系统
混合架构的应用部署及更新管理系统作为第三方服务提供层的实现形式, 主要由网络、信息资源库和部署情况管理模块和扩展管理模块组成。这些内容及它们之间的关系构成系统体系结构如图4所示。该系统由特定管理员管理, 负责维护应用路由映射信息及扩展库关联信息, 是实现第三方服务提供层功能的主要力量。
本应用部署及更新管理系统在Brower端采用HTML+CSS+JavaScript实现界面显示和用户交互功能, Server端采用PHP完成功能组件及绝大多数功能的逻辑实现。采用软件站集成包XAMPP搭建运行环境, 发挥其优异的跨平台能力。
系统中部署情况管理模块有数据库调出已有服务器的部署地点情况, 允许有权限的管理员更改已有的部署地点、添加新的部署情况。在指定部署地点, 相应的服务器将被调出以供查看、更新、删除以及增加新服务器。对于已部署的服务器, 其内部应用程序的相关操作在下一级模块中实现。扩展管理模块负责上传新扩展以及更新、删除已有扩展。
5 基于WebKit的表现层
5.1 WebKit基础
WebKit作为执行基于B/S架构应用的核心, 其优点在于清晰、稳固、高效以及对于网页标准的可维护性和可兼容性。本文采用它作为稍作改建后的混合模型中表现层的基础。从WebKit工程角度来看, 它由WebCore和JavaScript引擎构成。WebCore是一个布局、渲染及文件对象模型 (以下统称为DOM) , HTML和SVG的文库。JavaScript引擎包含脚本解释器、分析器以及执行程序, 支持解释和执行JavaScript (或ECMAScript) 。通过研究与转变WebKit及其核心组件, 将其与表现层结合, 作为通用的壳托管所有基于混合模型的应用。
5.2 扩展机制
扩展机制是为优化处理、延伸JavaScript引擎的技术途径。其主要目的在于提高表现层处理复杂应用需求的能力, 这方面是原生JavaScript所不具备的。一种直观的方式是直接在WebKit内核中实施功能模块并添加附加功能, 并在JavaScript引擎的全局对象初始化阶段绑定模块到变量链接列表中。通过调用全局变量, 扩展模块可在JavaScript代码中直接存取。但是在升级内核时这种方法的可用性很低。除少量基础模块, 其他模块都应由特定机制实现, 这些机制确保了WebKit内核代码的完整性与独立性。
WebKit内核较高的代码量导致了较高的理解和修改成本。为扩展进行的源代码修改的直接方式并不适用于所有情况。根据软件工程的可扩展性理论, 扩展机制应具有很强的可塑性和可扩展性。每一个扩展都映射到一个JavaScript对象, 安装在如原生对象的window对象 (DOM树根) 下。这种方法可称为对象映射, 并且这种方法有以下4个必要条件:
1) 映射对象必须挂载到window对象;
2) 必须实现原型对象;
3) 应能提供构造函数;
4) 成员变量与映射对象功能应适用于不断变化的JavaScript引擎 (即JavaScript引擎的适应性) 。
除对象映射之外, 变量映射是另外一种扩展JavaScript的简化方法。
QtWebKit是一个相对成熟的WebKit包装库, 它提供一些JavaScript接口来实现Qt的QObject对象与JavaScript变量之间的映射。这一方法是通过在JavaScript解释器中将QObject的指针安装到全局变量中实现。
可以肯定, 变量映射的缺点显而易见。QtWebKit依赖于相对一些轻量级应用过大的Qt库, 并且由于此方法并不满足上述的2) 与3) 两种情况, 其灵活性也较差。
5.3 性能优化
考虑到由于字节码解释而产生的JavaScript代码的性能缺陷, JavaScript引擎效率是影响应用性能的主要因素, 这对理解JavaScript基准的架构执行特点非常重要[5]。主流的JavaScript引擎包括WebKit中的JSC、谷歌浏览器中的V8、IE9.0中的Chakra、Opera 12.0中的Carakan以及Firefox 13.0.1中的JaegerMonkey等。上述的JavaScript引擎的性能参数已经测试, 包括OS内核模拟基准 (Richards) 、单向约束求解基准 (DeltaBlue) 、加密和解密基准 (Crypto) 、Ray Tracer基准 (RayTrace) 、经典方案基准 (EarleyBoyer) 、从50个最受欢迎的Web页面提取正则表达式操作进行的正则表达式基准 (RegExp) 、处理splay树和行使自动内存管理子系统的数据操作基准 (Splay) 、解决Navier Stokes方程、大量操作双精度数组 (NavierStoke) 。最后的分数是个体结果的几何平均数以独立于个体基准与参考系的运行时间。
测试环境如下:操作系统为32位Windows 7;CPU为Intel Core 2 Duo T6670 2.20 GHz;内存为3 Gbyte。
表1显示了QtWebKit的JSC、QtWebKit的V8、Chromium 20、Safari 5、Opera 12、IE 9以及Firefox 13的单项分数以及总分数。
图5展示了总分数中基准测试结果的对比, 结果显示, V8 JavaScript引擎相比其他引擎效率最高。
通过对比多种JavaScript引擎性能, 选用V8来支持表现层的应用, 其实现了ECMA-262 5th edition的ECMAScript、能够编译和执行JavaScript源代码、处理对象的内存分配并回收处理不再需要的对象。V8引擎能够使任何C++应用提供其对象和函数给JavaScript代码。
6 结论
在三网融合与新媒体趋势的共同推动下, 下一代电视逐步走向以互联网为基础而形成的OTT业务模式。本文针对当前发展迅速的OTT业务应用部署及更新管理问题, 提出了一种基于多层架构的新型混合模型, 该架构在应用开发部署方面兼具B/S模型与C/S模型的优势, 并简化了不同区域应用定制开发的困难。它可以维持低成本、敏捷迭代升级、跨平台支持及其他B/S模型下的优点, 为OTT业务发展提供了创造性的技术支持。
在这种基于多层架构的新型混合模型中, 添加第三方服务提供层来指导表现层与逻辑层的通信, 本混合模型采用修改后的WebKit (包含扩展机制和性能优化) 作为的表现层的基础。
目前, OTT业务的发展面临前所未有的机遇和挑战, 希望本文提出的混合模型可以作为今后相关应用开发部署的有效参考, 为OTT业务发展提供强有力的技术支持, 扩展网络功能和业务范围, 实现广播电视行业的长远发展。
参考文献
[1]马骁, 马立铭, 曹三省.面向OTT业务的智能电视系统架构设计[J].电视技术, 2012, 36 (12) :32-34.
[2]百视通获国内首张OTT牌照[EB/OL].[2012-12-10].http://www.isc.org.cn/hydt/listinfo-23179.html.
[3]MA Liming, MA Xiao, CAO Sanxing.A hybrid model for application develop ment and deployment[C]//2012IET国际会议论文集.Shenzhen:[s.n.], 2012:493-497.
[4]STEIERT H P.Towards a component-based n-Tier C/S-architecture[C]//Proc.International Workshop on Software Ar chitecture.Orlando, USA:Association for Computing, 1998:137-140.
[5]The WebKit Open Projects[EB/OL].[2012-12-10].http://www.webkit.org/.
[6]TIWARI D, SOLIHIN Y.Architectural characterization and similarity analysis of sunspider and Google’s V8Javascript benchmarks[C]//Proc.IEEE International Symposium on Performance Analysis of Systems and Software.[S.l.]:IEEE Press, 2012:221-232.
信息系统在线状态检修部署架构研究 篇3
随着国家电网公司信息系统实用化进程的不断深入, 用户对信息系统的依赖程度不断增强, 信息系统已成为必不可少的手段和工具融入企业的各个业务环节。一方面, 用户访问量的激增, 要求信息系统不断扩充规模, 搭建冗余架构, 提升系统承载能力和可靠性;另一方面, 用户对信息系统的实用化要求导致缺陷修复、版本升级等信息系统检修次数增多。如何在庞大复杂的系统环境下尽可能地减少检修时间, 实现信息系统在线状态检修, 保证业务应用的连续性, 成为亟需解决的课题。
1 安徽电力信息系统部署架构现状
国家电网公司统一推广的信息系统大多采用“程序包—中间件—数据库”架构, 即使用Java等语言开发信息系统并打包成程序包, 通过Web Logic中间件发布后运行, 后台以Oracle数据库作为程序数据交互的支撑。
安徽省电力公司严格遵循“架构坚强、性能优良、资源整合”的原则优化信息系统架构, 核心信息系统均按照Web Logic官方规范搭建标准集群, 集群由物理服务器或虚拟机组成, 数量可根据信息系统用户规模动态扩充, 前台使用负载均衡器动态分摊负载, 后台接入由小型机搭建的网省集中式综合数据库集群[1]。Web Logic标准集群部署架构如图所示。
Web Logic标准集群部署架构要求在所有服务器上均部署相同的信息系统应用程序包, 所有程序包均属于同一个应用域[2], 管理端部署在其中一台服务器上, 任何一台服务器或程序包出现故障时, 集群可通过负载均衡器保证对外业务应用不中断, 避免单点故障, 该架构可提高应用可用性, 增加吞吐量, 提高数据处理能力。但信息系统检修时, 应用程序包需要由管理端通过域推送至所有服务器[3], 并需要重启相应的Web Logic使新程序包生效, 整个过程中信息系统对外业务应用停止, 时间一般较长, 且如果推送发布过程中出现异常很难判断原因, 需要全部重新发布。
2 信息系统在线状态检修部署架构
2.1 架构搭建
安徽省电力公司与中间件和负载均衡器技术支持厂商合作, 以公司现有核心信息系统为研究对象, 通过几个月的试验, 最终完成信息系统在线状态检修部署架构的可行性论证并逐步付诸实施, 该架构可实现信息系统检修时对外业务应用不间断, 提高系统检修的灵活度和信息系统的业务支撑力度。
信息系统在线状态检修部署架构区别于标准集群部署架构, 每台服务器上的中间件实例独立对外提供服务, 每台服务器上的程序包独立成域, 每台服务器配置独立的管理端, 各服务器节点间没有共享的程序发布区域, 动态分配用户访问需求。信息系统在线状态检修部署架构如图2 所示。
架构搭建过程中必须保证一些关键技术细节, 包括:1每台服务器上必须分别部署完全相同的信息系统应用程序包;2每台服务器的中间件启动参数必须完全一致[4];3每台服务器的数据库访问设置必须完全一致;4会话保持策略必须采用Cookies insert方式, 保证Session的粘滞性, 使用户访问信息系统内容一致;5搭建完成后通过访问应用程序对所有的业务功能点进行检查, 对查询业务时各节点缓存数据是否同步进行检测。
2.2 架构优缺点分析
2.2.1 架构优点
信息系统在线状态检修部署架构继承了标准集群部署架构的所有优点, 有效提升了系统性能, 消除了单节点隐患, 增强了系统冗余性和可靠性。由于该架构中每台服务器上的中间件实例独立对外提供服务, 在信息系统检修时, 可以通过多台服务器的相互配合, 实现分机分实例检修, 保证对外业务应用服务不间断。
2.2.2 架构缺点
通过对核心信息系统逐个开展架构部署试验和业务功能测试, 发现部分信息系统在使用过程中出现业务流程混乱和业务查询返回结果不一致问题, 说明并不是所有的信息系统均适用在线状态检修部署架构, 需要通用测试方案确定适用性, 架构的应用存在一定的局限性。并且架构要求每台服务器配置独立的管理端, 相对标准集群部署架构, 每台服务器需要增加相应的硬件资源用于运行管理端, 资源消耗更大。
3 架构适用性通用测试方案
在开展信息系统的在线状态检修部署架构试验时, 如果信息系统使用了二级缓存机制, 会造成进程范围内或集群范围内缓存同步存在问题。为保证架构改造工作稳步开展, 经过大量的研究与试验后, 探索出一套通用的测试方法, 在架构改造前能够确认信息系统能否适用于信息系统在线状态检修部署架构。
当应用程序部署到多节点服务器时, 存在数据同步问题, 为验证应用程序对多节点服务器的支持, 将应用程序使用的所有数据分为数据库数据、硬盘数据和内存数据分别进行验证。
3.1 数据库数据同步测试
当使用多节点服务器访问数据库数据时, 需要配置相同的JDBC URL (包括IP地址, 数据库SID, 访问方式) 、相同的用户名和密码连接数据库, 保证访问的数据库一致性。使用用例进行验证:
1) 用户登录服务器1, 通过业务操作向数据库插入数据data;
2) 用户登录服务器n, 通过业务查询刚插入的数据, 若查出, 说明使用的是相同的数据库, 也就是当访问数据库中数据时, 通过任意节点不会产生不同结果。
3.2 硬盘数据同步测试
当应用程序需要在硬盘中写入数据、读取数据时, 可能产生不一致问题。例如用户甲通过服务器1 在硬盘中写入数据data, 通过服务器n可能无法正常访问data。可以通过进行所有业务操作之后查看硬盘中新产生的文件, 之后根据这些文件涉及的业务进行测试。使用用例进行验证:
1) 通过服务器1 操作产生文件的业务;
2) 通过服务器n访问使用该文件的业务, 如能访问, 说明数据已同步。
3.3 内存数据同步测试
根据内存中的数据的使用情况, 将内存中的数据分为以下4 类。
1) 用户访问时生成、访问结束时消失的数据。这是内存中最多的一类数据, 但是该类数据因为无论访问哪个节点都需要新生成数据, 所以不存在多节点不同步的问题。
2) 针对用户的访问信息保存在内存中的数据。该类数据在应用程序中保存为Session形式, 此类信息主要为了保证用户操作的连续性, 保存用户操作的必要信息, 此类信息在没有配置Session复制的情况下, 不会同步到另外一台服务器。使用用例进行验证:1用户分别登录服务器1、服务器n, 都会出现要求登录的界面, 说明现阶段2 台服务器中都不存在Session中的数据 ( 注意此时不要进行登录操作) ;2用户第一次登录时, 会按照分配算法分配给一台服务器, 假设此用户被分配到了服务器n上, 此时, Session中保存了用户的登录信息;3用户直接访问服务器1, 未配置Session复制情况下, 用户会被要求重新登录, 如果未要求重新登录, 说明用户的访问数据是存放在cookie中, 也就是放在客户端浏览器中 (注意此时不要在服务器1 上登录) ;4用户通过登录服务器, 进行多次重新访问测试, 如果出现要求重新登录界面, 新开浏览器直接登录服务器n却不用重新登录, 说明在请求路由上出现了问题;若不出现重新登录的界面, 说明对于此Session的支持是正确的。
3) 为了访问数据库、JMS等外部服务器时提高性能, 信息系统开发者会在内存中添加二级缓存, 但开发时却未考虑多节点问题, 在没有进行相应配置的情况下, 会出现数据库中数据与缓存中数据不一致, 导致业务查询结果错误[5]。使用用例进行验证:1用户登录服务器1, 发起一个流程向数据库记录data中插入数据data1 ;2利用DBA查询数据库记录data是否为data1 ;3 用户登录服务器1, 查询data的值是否为data1 ( 结果应为data1, 若非data1 则说明应用的业务逻辑出现问题) 。在DBA中查看在进行业务查询的时间点数据库端是否进行了select查询, 若没有进行过select查询则说明应用使用了缓存机制。如果出现此问题, 需要跟厂商沟通确认该缓存是否影响多节点部署, 是否需要额外的配置;4用户登录服务器n查询data的值是否为data1 ( 结果应为data1, 若非data1 则说明应用的业务逻辑出现问题) ;5用户在服务器n发起一个流程, 将记录data的数据更新为data2 (data1 被data2覆盖) , 此时DBA可以验证数据库中的数据是否被同步为data2, 否则需要进行分析;6用户在服务器2 中查询data的值是否为data2 ( 结果应为data2, 若非data2 则说明应用的业务逻辑出现问题) ;7用户在服务器1 中查询data的值 (如果结果为data2, 则说明在服务器n中进行的更新操作同步到了服务器1 中, 或者是该业务使用的是事务级别的缓存, 在事务结束后会清空缓存, 当用户在服务器1 中进行查询时会查询数据库而不是缓存;如果结果为data1, 说明服务器n中的更新操作并未同步到服务器1, 并且原有的缓存未被清空, 部署为多节点在查询时会出现问题, 需要联系开发厂商进行修复后重新验证) 。
4) 内存中还有一部分主要是为了避免重复新建内存对象而存在的静态数据, 此类数据会随着内存的消失而消失, 不会存储在数据库或者文件中, 而且此类数据不属于客户信息, 虽然不能进行内存同步, 但不影响业务的逻辑[6]。
4 应用效果
安徽省电力公司已成功完成经济法律、农电管理等信息系统在线状态检修部署架构改造, 改造后系统运行稳定, 通过中间件实例与负载均衡器的配合, 可实现分机分实例检修, 保证信息系统对外业务应用不间断, 增强信息系统的可用性, 减少检修工作的人力资源投入, 提高业务应用用户工作效率, 增加业务产出值。本文总结的信息系统在线状态检修部署架构适用性通用测试方法, 已作为安徽省电力公司信息系统上线必经测试, 测试通过的信息系统均要求完成在线状态检修部署架构改造, 提升系统可用性。测试过程使运维人员对庞杂的系统有了更加深刻的理解和掌握, 提高了系统化的架构能力和对信息系统的掌控力度, 为系统的可靠运行打下坚实基础。
5 结语
信息系统在线状态检修部署架构在安徽省电力公司应用效果良好, 巩固了信息系统运行基础, 完善了信息运行管理水平, 提高了信息运维人员技能。应用后信息系统运行安全稳定, 系统在业务高峰期与同期相比, 紧急故障和临时抢修发生频率都有了大幅降低。
参考文献
[1]CHEN L C, CHOI H A.Approximation algorithms for data distribution with load balancing of Web servers[C]//Proceedings of IEEE International Conference on Cluster Computing, 2001:274–281.
[2]ARTIGES M.BEA WebLogic Server 8.1大全[M].袁毅, 谈莉娅, 宋燕红, 译.北京:机械工业出版社, 2005.
[3]李双庆, 古平, 程代杰.Web集群系统负载均衡策略分析与研究[J].计算机工程与应用, 2002, 38 (19) :40–42.LI Shuang-qing, GU Ping, CHENG Dai-jie.Analysis and research on load balancing strategy in web cluster system[J].Computer Engineering and Applications, 2002, 38 (19) :40–42.
[4]柏海寰, 蒋俊杰, 汪为农.基于分散式查找的Web服务器集群[J].计算机工程, 2006, 32 (2) :96–116.BAI Hai-huan, JIANG Jun-jie, WANG Wei-nong.Web servers cluster based on decentralized location[J].Computer Engineering, 2006, 32 (2) :96–116.
[5]李定锁, 郭成诚, 晏蒲柳.Web服务器集群中的文件优化分配[J].计算机工程与应用, 2004, 40 (16) :79–81.LI Ding-suo, GUO Cheng-cheng, YAN Pu-liu.Optimizing allocation of files in web server cluster[J].Computer Engineering and Applications, 2004, 40 (16) :79–81.
企业信息网络安全管理架构部署探析 篇4
关键词：企业,网络安全,管理,部署
1 引言
随着信息化进程的提速, 越来越多地企业信息被披露于企业内外部网络环境中, 如何保护企业机密, 保障企业信息安全, 成为企业信息化发展过程中必然需要面临和解决的问题。对于企业信息网络安全管理需要部署的内容, 首先要明确企业的哪些资产需要保护, 确定关键数据和相关业务支持技术资产的价值, 然后在此基础上, 制定并实施安全策略, 完成安全策略的责任分配, 设立安全标准。
2 企业网络信息安全需求分析
对企业网络信息安全的网络调查显示:有超过85%的安全威胁来自企业内部;有16%来自内部未授权的访问;有11%资料或网络的破坏。可以看出:来自于企业内部的安全威胁比来自于外部的威胁要大得多, 必要的安全措施对企业是非常重要的。安全风险分析通常包括对系统资源的价值属性的分析、资源面临的威胁分析、系统的安全缺陷分析等等。分析的目标就是确定安全系统的建设环境, 建立信息系统安全的基本策略。
2.1 企业信息网络安全需求
企业对信息网络安全方面的需求主要包含: (1) 业务系统与其它信息系统充分隔离。 (2) 企业局域网与互联的其它网络充分隔离。 (3) 全面的病毒防御体系, 恢复已被病毒感染的设备及数据。 (4) 关键业务数据必须进行备份, 具有完善的灾难恢复功能。 (5) 管理员必须对企业信息网络系统的安全状况和安全漏洞进行周期性评估, 并根据评估结果采用相应措施。 (6) 关键业务数据和敏感数据在公网上的传输必须加密, 防止非法获取和篡改。 (7) 加强内部人员操作的技术监控, 采用强有力的认证系统, 代替一些不安全的用户名/口令系统授权模式。 (8) 建立完善的入侵审计和监控措施, 监视和记录外部或者内部人员可能发起的攻击。 (9) 对整个信息系统进行安全审计, 可预见管理和总拥有成本控制。
2.2 企业信息网络安全内容
从企业整体考虑, 它的信息网络安全包括以下六个方面:
(1) 企业信息网络安全策略建设, 它是安全系统执行的安全策略建设的依据。 (2) 企业信息网络管理体系建设, 它是安全系统的安全控制策略和安全系统体系结构建设的依据。 (3) 企业信息网络资源管理体系建设, 它是安全系统体系结构规划的依据。 (4) 企业信息网络人员管理建设, 它是保障安全系统可靠建设、维护和应用的前提。 (5) 企业信息网络工程管理体系建设, 信息安全系统工程必须与它统一规划和管理。 (6) 企业信息网络事务持续性保障规划, 它是信息安全事件处理和安全恢复系统建设的依据。
3 企业信息网络安全架构
3.1 企业信息网络安全系统设计
安全系统设计是在信息系统安全策略的基础上, 从安全策略的分析中抽象出安全系统及其服务。安全系统的设计如图1所示。安全系统设计的目标是设计出系统安全防御体系, 设计和部署体系中各种安全机制从而形成自动的安全防御、监察和反应体系, 忠实地贯彻系统安全策略。
3.2 企业信息网络安全系统组建
安全系统设计关心的是抽象定义的系统。具体系统组建是建立在设计基础上的实现。通常系统功能组件的实现方式是软件、硬件和固体等。安全系统组建的另一项重要内容是配制安全系统, 并将安全系统与整个信息系统形成一体。
4 企业信息网络安全工程的部署
信息系统安全是信息系统服务质量的要求, 网络安全系统应当融于信息网络服务系统之中, 其建设与维护应当与信息网络系统的建设和维护保持一致, 遵循系统工程的方法。网络安全工程就是应用系统工程建设和维护网络安全系统。
4.1 工程环节
系统工程总是与被建设的系统特性紧密结合, 工程环节与系统生命周期保持同步。安全系统的生命周期也是基本如此, 因而安全系统工程典型的基本环节包括信息系统安全需求分析、安全系统设计、安全系统组建、安全系统认证、系统安全运行维护和安全系统改造等, 如图2所示。
(1) 安全的互联网接入。企业内部网络的每位员工要随时登录互联网, 因此Internet接入平台的安全是该企业信息系统安全的关键部分, 可采用外部边缘防火墙, 其内部用户登录互联网时经过内部防火墙, 再由外部边缘防火墙映射到互联网。外部边缘防火墙与内部防火墙之间形成了DMZ区。
(2) 防火墙访问控制。外部边缘防火墙提供PAT服务, 配置IPSec加密协议实现VPN拨号连接以及端到端VPN连接, 并通过扩展ACL对进出防火墙的流量进行严格的端口服务控制。
内部防火墙处于内部网络与DMZ区之间, 它允许内网所有主机能够访问DMZ区, 但DMZ区进入内网的流量则进行严格的过滤。
(3) 用户认证系统。用户认证系统主要用于解决拨号和VPN接入的安全问题, 它是从完善系统用户认证、访问控制和使用审计方面的功能来增强系统的安全性。
拨号用户和VPN用户身份认证在主域服务器上进行, 用户账号集中在主域服务器上开设。系统中设置严格的用户访问策略和口令策略, 强制用户定期更改口令。同时配置VPN日志服务器, 记录所有VPN用户的访问, 作为系统审计的依据。
(4) 入侵检测系统。企业可在互联网流量汇聚的交换机处部署入侵检测系统, 它可实时监控内网中发生的安全事件, 使得管理员及时做出反应, 并可记录内部用户对Internet的访问, 管理者可审计Internet接入平台是否被滥用。
(5) 网络防病毒系统。企业应全面地布置防病毒系统, 包括客户机、文件服务器、邮件服务器和OA服务器。
(6) VPN加密系统。企业可建立虚拟专网VPN, 主要为企业移动办公的员工提供通过互联网访问企业内网OA系统, 同时为企业内网用户访问公司的SAP系统提供VPN加密连接。 需要注意的是, 由于VPN机制需要执行加密和解密过程, 其传输效率将降低30%～40%, 因此对于关键业务, 如果有条件应该尽可能采用数据专线方式。
(7) 网络设备及服务器加固。企业网络管理员应定期对各种网络设备和主机进行安全性扫描和渗透测试, 及时发现漏洞并采取补救措施。安全性扫描主要是利用一些扫描工具, 模拟黑客的方法和手段, 以匿名身份接入网络, 对网络设备和主机进行扫描并进行分析, 目的是发现系统存在的各种漏洞。 根据安全扫描和渗透测试的结果, 网络管理员即可有针对性地进行系统加固, 具体加固措施包括:关闭不必要的网络端口;视网络应用情况禁用ICMP、SNMP等协议;安装最新系统安全补丁;采用SSH而不是Telnet进行远程登录;调整本地安全策略, 禁用不需要的系统缺省服务;启用系统安全审计日志。
(8) 办公电脑安全管理系统。企业应加强对桌面电脑的安全管理。主要有: ①补丁管理:主要用于修复桌面电脑系统漏洞, 避免蠕虫病毒、黑客攻击和木马程序等。 ②间谍软件检测:能够自动检测和清除来自间谍软件、广告软件、键盘记录程序、特洛伊木马和其他恶意程序的已知威胁。 ③安全威胁分析:能够自动检测桌面电脑的配置风险, 包括共享、口令、浏览器等安全问题, 并自动进行修补或提出修改建议。 ④应用程序阻止:用户随意安装的游戏等应用程序可能导致系统紊乱、冲突, 影响正常办公。管理员可以通过远程执行指令, 阻止有关应用程序的运行。 ⑤设备访问控制:对用户电脑的硬件采用适当的访问控制策略, 防止关键数据丢失和未授权访问。
(9) 数据备份系统。企业应制定备份策略, 定期对一些重要数据进行备份。
4.2 持续性计划
(1) 架构评估。
企业网络信息安全管理架构的评估应由IT部门、相关责任部门以及终端用户代表来共同参与, 确保所有的部门都能纳入安全框架中。
(2) 系统安全运行管理。
要保障信息系统安全, 就必须维护安全系统充分发挥作用的环境。这种环境包括安全系统的配置、系统人员的安全职责分工与培训。
(3) 安全系统改造。
信息系统安全的对抗性必然导致信息安全系统不断改造。导致安全系统改造的因素可以归结为4个方面:技术发展因素;系统环境因素;系统需求因素;安全事件因素。
(4) 网络安全制度建设及人员安全意识教育。
企业应当采取积极防御措施, 主动防止非授权访问操作, 从客户端操作平台实施高等级防范, 使不安全因素在源头被控制。这对工作流程相对固定的重要信息系统显得更为重要而可行。
需开展计算机安全意识教育和培训, 加强计算机安全检查, 以此提高最终用户对计算机安全的重视程度。为各级机构的系统管理员提供信息系统安全方面的专业培训, 提高处理计算机系统安全问题的能力。
参考文献
[1]赵迪, 赵望达, 刘静.基于B/S架构的安全生产监督管理信息系统[J], 中国公共安全 (学术版) , 2006, (04) .
[2]周敏文, 谭海文.浅析我国安全生产信息化建设的现状与对策[J], 露天采矿技术, 2005, (06) .
[3][美]Harold F.Tipton, Micki Krause著, 张文, 邓芳玲, 程向莉, 吴娟等译.信息安全管理手册 (卷III) (第四版) [M], 北京:电子工业出版社, 2004年6月, 237-264.
部署架构设计 篇5
关键词：高职院校,云计算,桌面云,技术架构
一、桌面云技术概述
桌面云的定义是: “可以通过瘦客户端或者其他任何与网络相连的设备来访问跨平台的应用程序以及整个客户桌面。”也就是说,我们只需要一个瘦客户端设备,或者其他任何可以连接网络的设备,通过专用程序或者浏览器,就可以访问驻留在服务器端的个人桌面及各种应用。
二、桌面云的技术架构
桌面云的技术架构主要由瘦终端、网络接入、身份认证、操作系统及应用程序、应用服务器等6个部分组成,在具体应用中应该根据客户的具体情况作架构中的各种决定,决定时的考虑因素主要有客户的类型、客户的规模、客户的工作负载、客户的使用习惯、客户对服务质量的要求等,这是一个较为复杂的过程。
桌面云所使用的核心技术一般是基于RDP实现的,而RDP设计是以国际电信联盟T. share协定 ( 又称为T.128) 为基础,是一个多通道的协议,让多个使用者通过RDP协议连上后端服务器所提供的终端服务的计算机桌面。最常见的就是微软的Terminal Services,而Linux、Free BSD等其他操作系统,则是以监听TCP 3389端口的数据方式传送接收。而桌面云则是将原本运行在私有网络的瘦终端架构转移到公有网络上。但是,因为公有网络质量不易控制,无法像私有网络可以控制网络的品质,所以这成了桌面云推广的最大障碍,这个议题也一直持续至今。
随着当前科技产业各项技术的提升,这类问题都一一被克服,而现在随着网络信息技术的飞速发展,许多过去的技术都被加以再开发应用,RDP协议版本到目前已经升级到7. 0版本,采用此技术的如Citrix公司的Xen Desktop、Microsoft公司的VDI、Vmware公司的Vmware View这一类产品的虚拟桌面服务,其核心技术都是通过RDP协议所延伸出来的产品。
三、桌面云在湖南科技职业学院部署的实例
1. IDC网络设计
( 1) 网络设计。桌面云相对传统终端模式,网络数据流量和流向有所改变,在进行带宽设计时需要充分考虑这些改变。接入带宽用于终端与云桌面平台之间的显示、输入输出和外设数据交互,即云桌面协议所需带宽,接入带宽在两类情况下产生明显差距: 一是日常教学带宽,二是有特殊音视频需求发生时的视频/音乐/PPT/Vo IP /大图片带宽。总的TC的接入带宽Mbps = ( 日常教学带宽需求×终端用户数×日常业务并发概率 + 视频/音乐/PPT/Vo IP /大图片带宽需求×终端用户数×大带宽业务并发概率) /冗余因子 ( 一般预留50%作为冗余) 。
( 2) 带宽测算。正常情况下,单个云桌面的带宽需要1000Kbps,如有特殊的视频语音需求,最高带宽需要达到2Mbps,按照二八原则,80% 的用户使用的是正常的云桌面业务,即不涉及视频及大量文件传输,20% 的用户需考虑特殊应用,按照10个业务终端技术:12Mbps,也就是说最少需要12M的带宽,建议使用20M的带宽。
2. 云平台设计
由于桌面云平台在IT系统中所处的位置十分敏感,其将分散的终端用户系统整合到统一平台,平台的整体架构安全稳定性关系到所有前端用户的操作。因此云桌面的架构设计要充分考虑系统的可靠性。
我们选用的终端配置如下: CPU:AMD FUSION T40N 1. 0GHz ( 双核) /内存: 2G DDR3/512M DOM/ /1个网卡/5个USB接口 / 外置电源,LINUX操作系统,内嵌VMware、Citrix及RDP客户端软件,开机即用; DVI/VGA视频输出、支持音频输出; 支持PCOIP协议、RDP协议; 支持USB映射功能、多媒体映射功能。
良好的桌面云终端管理系统应支持服务器端的集中管理功能,能够远程、统一、批量进行管理操作。管理操作包括但不限于参数配置、状态监控、统计、开关机、查询固件版本、升级固件、监视等。
部署架构设计 篇6
计费系统是电信运营商业务支撑系统的核心系统, 主要负责对用户使用的各种电信服务进行计费, 为电信运营商的业务收入提供保障。根据计费效果的实时性, 计费系统分为在线计费系统和离线计费系统两类。目前在线计费系统的组成主要由在线消息网元、在线计费引擎、BDS服务、内存数据库和物理数据库等组成, 如何合理的部署各个服务组件, 对外提供最优的系统处理性能, 是本文研究的重点。本文主要研究和对比了不同的在线计费系统部署架构的性能情况, 通过性能测试, 对比不同架构下, 系统整体的处理情况和指标, 为后续在线计费系统的部署和资源配置, 提供依据。
二、在线计费系统概述
移动互联网时代要求计费系统从后端支撑系统向实时的生产系统转变, 并在流量计费及控制、处理实时性、用户体验优化等方面提出了新的要求。实时计费是相比传统离线计费方式而言, 更加注重计费处理时效性和对用户使用情况的授权和及时控制的计费方式。
2.1功能模块
在线计费系统是参与通信过程控制的计费系统, 能够解决用户实时信用控制、预付费使用数据业务和增值业务实时计费等问题。
功能模块主要分四层, 在线接入层、计费应用层、BDS服务层和数据存储层。在线接入层, 主要负责在线计费消息的接入, 将其转换为内部消息, 提供给计费应用, 并接收计费应用层返回的业务使用额度等结果消息, 将其转换为DCC协议响应消息, 转发给相应的在线计费请求方;计费应用层依据计费资源、产品资费、用户资料信息实现个人客户计费过程, 对在线计费请求进行预处理, 业务识别和相关业务信息的补充, 根据业务识别结果, 对业务控制网元发送的监控用户业务使用额度请求, 根据在线计费引擎计算结果进行可用业务使用额度的授权;BDS层实现业务数据的统一访问和业务流程的统一控制, 以及计费核心的数据集中和统一存放, 为BOSS内部计费、帐务及其周边子系统提供数据存储支持;数据存储层, 是用户数据、批价数据的存储, 为了达到快速高效的访问用户数据, 一般采用开源的内存数据库存储数据。
2.2程序实现
程序设计框架按照分层要求:1、OCI接入层:接入程序, 负责在线消息的模拟发送;2、APP应用层:接入控制、会话管理、批价等应用服务;3、BDS数据服务层:帐务数据访问的原子服务和组合服务;4、Redis数据层:使用开源内存数据库Redis, 负责用户资料数据的内存存储。
由于分层部署, 在各层之间增加通信模块程序;对于多线程并发访问, 构建连接池及管理;对于主机管理, 增加心跳检测;各处理环节还增加了日志输出和管理等模块。
2.3部署逻辑架构
业务数据服务BDS, 向应用提供数据封装服务, 屏蔽底层数据的存储对应用的影响, 实现数据与应用低耦合。作为连接应用和数据两层的中间桥梁, 其可以有以下三种部署方式:1、BDS服务同Redis内存数据库部署在同一台主机;2、BDS服务同APP应用层部署在同一台主机;3、BDS服务独立部署在一台主机;
三、测试结果
验证三种部署方式, 在相同消息压力和用户数据量情况下, 对比三种部署方式消息平均处理时长和资源占用情况, 确定哪种部署架构, 系统的处理能力最优。
测试步骤:三种部署架构下, OCI消息并发数800条/秒, 记录不同架构下的测试结果;1) 发送消息总条数;2) 记录小于200ms和超时百分比;3) 系统的处理能力。
测试数据:
测试结论:
BDS和内存部署的方式, 超时百分比最小, CPU资源占用最低;同时, 三种部署方式的系统处理能力相差不大550条/秒左右。随着并发数增加的情况下, 其性能表现和资源占用情况优势更为明显。
四、结束语
本文从系统架构角度初步研究了BDS业务数据服务层对在线计费系统部署架构的影响, BDS和内存库部署同一台主机的方式, 降低了BDS与内存库的交互和网络开销, 但这种方式耦合度较高。同时, 系统的部署架构需要视系统规模、用户数、资源配置等条件进行具体分析, 选择最优的系统部署架构。
参考文献
[1]李福庆, 李良.在线计费系统云化部署架构研究[J].邮电设计技术, 2013, 12:17-19;
部署架构设计 篇7
HTTP Live Streaming是Apple公司针对i Phone, i Pad等移动终端设备开发的一种基于HTTP的自适应流媒体协议[1], 将媒体源编码为不同编码速率的多个流, 客户端根据网络带宽状况的变化选择不同编码速率的替换流, 实现带宽波动时的流媒体自适应切换[2,3,4]。
由于数据通过HTTP协议传输, 所以完全不用考虑UDP套接字、防火墙或者代理的问题, 而且分片文件的时长很短, 一般长为几秒至十几秒, 前后的分片之间没有依赖关系, 以线性方式从服务器获取, 再以线性的顺序组合播放。HLS支持通过普通Web服务器提供接近实时的音视频流媒体服务, 包括直播和点播[13]。目前得益于Apple终端的市场占有率, HLS点播系统尤其成为各大视频网站的移动流媒体客户端的主流技术。
本文根据HLS协议原理, 设计一种基于HLS流封装和切片系统, 在Wi Fi和3G网络环境下都具有较好的播放体验。文中对TS流封装和切片过程进行详细研究, 描述服务器与客户端之间的交互传输过程。
1 HLS协议原理及系统结构
HLS移动流媒体视频点播系统由3部分组成:服务组建、视频分布存储和客户端软件部分, 服务组建由编码器和流分割器组成。首先对视频数据进行存储、编码和流封装, 然后服务器软件的流切片程序将媒体视频流分解成一系列简短的流媒体文件和索引文件[14,15,16,17,18,19,20,21,22,23,24,25,26,27], 索引文件的URL发布到Web服务器上, 客户端软件即可读取索引, 请求媒体文件, 并将其显示出来[5,6,7,8]。点播系统中, 流文件和索引文件固定不变[9]。
1.1 编码器
TS码流的组成过程是将原始的音频和视频信息按照合适尺寸划分成ES流, 之后附加信息形成PES包, 再按照一定规则将PES包附上系统信息而成为TS包, 进而组成完整的TS码流。MPEG-2复用结构见图1。
多路ES流的复用和多路节目传输流的复用均采用时分复用 (TDM) 方式, 图像、声音的ES流和辅助数据被分配在不同的TS包内, TS包的长度为188个字节 (188×8=1504比特) 时隙, 具体的码流、包结构如图2所示。
TS包头中负载单元起始指示符用于指示该TS包中带有PES包或PES数据的情况, PID指示TS包中净荷的数据类型, 调整字段控制 (AF控制) 表示在包头后面是否有调整字段、净荷, 连续性计数器用于在解码端检测包是否丢失。净荷中的调整字段 (AF) 主要用于包对齐 (不足188Byte) 和插入一些扩展信息[28,29,30,31,32,33,34,35]。调整字段中PCR的插入至关重要, 该字段用于系统解码过程中进行系统时钟恢复。系统时基的同步可以通过在传送流包中间断地插入PCR来实现。
TS包中净荷所传输的信息包括两种类型:1) 视频、音频的PES包以及辅助数据;2) 描述节目复用信息的节目映射表 (PAT) 和节目映射表 (PMT) 、其他PSI表格和SI表格。
1.2 流分割器
流分割器将编码器输出的MPEG-2 TS流分割为一系列连续的、长度均等的小TS文件, 并依次发送至Web服务器进行存储。流分割器同时还创建一个索引文件, 该索引文件包含元数据以及一个.m3u8媒体文件的列表, 如表1所示。
之所以采用MPEG-2 TS格式对编码后的媒体流进行统一封装, 是因为能够将音视频媒体流严格按照时序进行交织复用, 任意截取和分段后, 每一个分片都不依赖与之前的分片而独立进行解码和播放。为此, TS文件中必须仅包含一个MPEG-2节目, 在每个文件的开头应包含一个节目关联表 (PAT) 和一个节目映射表 (PMT) , 包含视频的文件中还必须含有至少一个关键帧和其他足够信息 (如序列头) 用以完成解码器的初始化。与直播不同, 视频点播 (VOD) 的索引文件是一个不随时间而更新的静态文件, 其中包含一个节目从头到尾所有分段文件的URL列表, 并以#EXT-X-ENDLIST标签结尾。
1.3 视频分布存储
视频分布存储任务由Web服务器或者是Web缓存系统组成。HTTP客户端读取页面文件中的URL, 指向了.m3u8文件位置, 几乎不需要对Web服务器做任何特殊配置。推荐配置仅限于对.m3u8和.ts文件的MIME类型关联, 如表1所示。
1.4 客户端软件
客户端软件要求是必须支持HLS协议, 一般是i OS3.0、Safari4.0及其以后版本自带的软件, 也可以在Android移动操作系统上进行开发[36,37,38]。首先根据提供的URL获取索引文件, 解析其中的媒体文件已经加密的密钥信息, 然后按顺序请求索引文件中的TS文件[10]。客户端需要下载一个完整的TS文件后才能开始播放, 因此这将带来客户端相对于服务器的时延。
2 TS流封装与切片
MPEG-2中定义了两种复用信息流:传输流 (Transport Stream, TS) 和节目流 (Program Stream, PS) 。TS流采用固定长度的包结构, 可以从视频流的任一片段进行独立解码, 非常适合基于网络传输的节目, 具有动态带宽分配、可分级、可扩展、抗干扰以及接收机成本低等优点。
2.1 TS流封装
实现TS流封装即编码器功能, 可以通过两种方式。一是ffmpeg命令行工具, 它是一个开源跨平台的视音频流方案, 支持超过90种解码器和协议, 提供了录制、转换以及流化视音频的完整解决方案。调用格式是:ffmpeg-<命令1><参数1>…-<命令N><参数N>。其主要命令的含义如表2。
第二种方式是通过已有软件工具转换, 本例中采用ts Muxer GUI。打开软件界面, 图3加载要进行混流的文件, 配置适当参数, 可以得到转码以后的文件。这种方式简单方便, 非常适合于大批量文件的转码流操作。
2.2 TS流切片
经过流封装操作仍没有完成构建HTTP Streaming的过程, 需要将视频文件切成小片, 这里要通过流分割器, 本例中使用苹果的segmenter命令行工具。创建HTTP Streaming命令格式为:segmenter<input MPEG-TS file><segment duration in seconds><output MPEG-TS file prefix><output m3u8 index file><http prefix>。
下面是一个使用的例子, 从视频文件创建一个流, 每个切片文件10秒:segmenter sample_low.ts 10 sample_low stream_low.m3u8 http://www.hlstest.com/。
3 服务器与客户端传输过程
经过上述的流封装和流切片, 已经产生多个视频流的切片文件, 这些文件需要上传至Web服务器。本例为方便验证传输过程, 采用简易Web服务器即Easy Web Svr。在Easy Web Svr设置好主目录文件夹、端口号、网络连接数等参数, 便可以使用HTML5的video标签。例子如下,
下面以服务器和客户端之间的交互传输为例详细分析其过程, 在这里采用网络数据分析仪来实现分析和检测。
如图4所示, 客户端首先向服务器发送一个请求html页面, 服务器立刻发出回应并把html页面文件发送客户端。客户端会申请包含.ts视频流索引的.m3u8文件, 服务器给出回应并把.m3u8索引文件发给客户端, 此时若需要传输序列号为1的.ts视频流片段, 那么客户端就会再次发送申请, 服务器回应并给出其播放地址, 从而可以播放该序列号的视频段内容, 上述过程如图5所示。[11,12]
图5所示是“192.168.2.111”地址的客户端向“192.168.2.101”地址的服务器申请.m3u8索引文件, 并读取索引文件中指向的序号为1的.ts片段, 加载几帧后, 重新申请第26个.ts片段。这是针对用户在退出视频后, 短期内又重新点播该视频, 系统默认将从退出点继续播放。
4 结论
HLS是基于HTTP的系统, 协议特性决定了它能更好地支持复杂的网络环境, 服务部署和网络扩展简单, 还可以方便地制定缓存策略提高服务性能。随着移动互联网、新兴4G业务的发展以及移动设备的普及, 对多媒体信息的需求会越来越多, 简单又易部署的移动流媒体服务器点播系统方案还是非常具有可行性, 将有很广泛的应用前景。
摘要：介绍利用HLS协议实现移动流媒体视频系统的部署架构, 提出除了采用ffmpeg和segmenter工具外, 还可以选择ts Muxer GUI开发工具, 通过适当参数配置实现TS快速流封装和切片功能。利用网络分析仪测试并记录服务器和客户端流传输交互过程, 解决移动播放过程中简单性、灵活性、可扩展问题, 可以广泛地用于移动互联网络环境。
