业务系统架构范文（精选12篇）
业务系统架构 第1篇
一、设计背景
众所周知,相对于有完善安全机制的演播室系统,单一的新闻制作网和文稿系统是节目直播流程中的薄弱点,系统故障容易造成整个业务的中断,解决这个薄弱点就能极大提高新闻直播中的安全性。另一方面,为避免高额的投资,我们需要共享演播室系统。所以我们与索贝厂方协商,提出了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网进行审查、送播等一系列流程。
审片设计
除了文稿,素材相关流程交互以外,A、B岛的审片软件也适应协同工作进行功能改进:
1、使用统一的登录TAB页面,使用户登录时无须区分登陆的是A部分或是B部分。
2、在A岛查询页中和B岛查询页中只能查到对应网的文稿节目信息。
3、但当用户需要查询或者审查另外一个网的节目时,切换TAB页,后台数据库访问会自动切换到另一网内。
4、审查站点可同时访问到A、B两岛的存储以满足审查需要。
四、其它问题
由于A、B两岛频繁浏览、交换素材节目等工作,以及全网的高清编辑业务,为缓解存储和网络的带宽压力,编辑网络码率设为高、中、低三档,分别对用于成片、编辑和浏览等不用情况。在两岛的栏目、用户分配上,最好将联系性强、共享性强的栏目放在同一个岛内,这样可有效缓解不必要的资源交换,节省资源和带宽。在以前的新闻制播网络建设上,多为配置单一存储体支撑全网编辑,一旦出现故障,节目制作、播出均会受到影响。在这个设计中,A、B两岛实现了这种双存储架构,再结合厂家提供的数据同步技术,实现了存储数据的有效互为备份和故障快速切换,更好地实现了数据安全。
小结
业务系统架构 第2篇
光缆网现状
移动运营商在长期发展过程中，已经从上至下建设起一个适应移动通信的光缆网。从覆盖范围上可将光缆网分为省际长途干线、省内长途干线和本地传送网三个级别。本地传送网按网络规模大小又分为核心层、汇聚层、接入层三个网络层次。本文将重点介绍全业务影响最大的本地光缆网。
核心（骨干）层光缆网是连接本地核心机房之间的光缆网。移动网络在核心层高度集中，核心机房数量少，一般在2～4个，少数发达地市在4个以上，机房多集中在市区，相互间距离短。核心机房内安装的设备是整个网络的大脑和心脏，机房间传输数据量大，业务密集。核心节点间传输的顺畅与否直接关系到整个网络的安全，一旦发生意外必定是重大事故。因此，核心层传送网的特点是容量大、冗余备份多、安全性极高。核心层光缆结构多为多环叠加的方式，核心节点4个以上的地区，逐步实现光缆网格化，核心光缆芯数一般在48～144芯之间，全程采用管道方式敷设。
汇聚层光缆是连接汇聚节点之间以及汇聚节点与核心节点的光缆，是介于移动基站与核心节点之间的光缆网络，用于将底层传送需求集中，提高网络传送效率，降低CAPEX和OPEX。由于汇聚节点数量多，分布广，环行结构是首选。在业务量大的地区，已建成独立的汇聚层光缆。在业务量较小的地区，汇聚层光缆与接入层光缆混合使用。汇聚层光缆的市区芯数在36芯以上，郊县、农村地区则在24～48芯之间。城区光缆敷设以管道方式为主，郊县和农村以杆路质量较好的接入层杆路或专用汇聚层杆路为主。
接入层光缆是连接移动基站之间或基站与汇聚节点的光缆，同时兼顾少量营业厅和集团客户。光缆网结构以环行为主，辅以少量的星型、树型。光缆芯数一般在24芯以下，敷设方式无特殊要求，各地根据实际情况决定采用管道、架空或直埋等多种方式。
移动运营商光缆网结构现状如图1所示。
图1 移动运营商光缆网分成结构示意图
全业务背景下业务和技术对光缆网的影响
全业务在国外又称为“多业务”或“综合业务”。全业务运营可以分为狭义和广义，狭义的全业务运营是基于政策管制角度进行定义，即移动业务、固话业务、宽带业务，还包括基于以上三种基本业务延伸和拓展的各类增值和信息化业务（VOD、视频监控等）。广义定义是基于多业务领域与通信的结合，即综合信息服务、通信+多媒体信息服务+综合信息解决方案。本文主要指狭义的全业务，它所对应的网络包括移动网络、固定网络及互联网络。
从整体来看，移动运营商向全业务转型的重点在于在现有以移动业务为主的网络中引入固定和宽带数据业务。业务网的融合转型催生了大量新技术，新技术的出现又反过来改变了网络架构模式，推动业务层面向全业务融合。网络架构模式的变化和新技术的发展，又对底层光缆网的建设产生较大影响，下面将分析全业务网络的主要变化特征对光缆网的影响。
1.3G
3G网络核心层设备集中设置在少数核心机房，大量数据通过大容量的局间中继传送系统疏导，对核心层光缆网影响不大。在接入层，3G移动基站对光缆网的需求与2G基本相同，应重点保障基站接入光缆的安全性和稳定性。在网络建设初期，大部分3G基站将与2G基站共址，但3G基站需要支持高速率的数据业务，在基站空口能力提升的同时，覆盖半径在逐渐变小，后期3G基站密度将较2G网络有所加大，光缆网密度在接入层也需要随之适当加大（即FTTM），网络结构仍然以环行为主。3G基站数据电路需求量大，类型复杂，可在传输系统层面通过更加智能高效的MSTP/PTN传送技术解决。
2.固定语音、互联网
固定语音和互联网接入服务是移动运营商网络中资源比较匮乏的部分。随着网络技术的发展，移动运营商建设传统固话网络的可能性很小，更可行的方式是利用软交换技术和IP技术的结合，在数据城域网平台上承载固网软交换业务，通过综合接入终端（PON+LAN+I）为用户同时提供固定语音和互联网服务。为能提供互联网业务，运营商需在核心汇聚层建设数据城域网，在接入层建设FTTｘ为主的数据接入网。在核心层，由于核心网元高度集中，对光缆需求不大；在汇聚层，应充分利用现有汇聚层光缆资源，数据城域汇聚点布局时应尽量与传输汇聚节点重合。但数据城域网汇聚设备与BRAS之间连接为双归星型，与汇聚层光缆环行结构存在一定差异，直接用现有的汇聚光缆网承载，不但会造成大量纤芯资源的浪费，而且中间跳纤点过多，还会增加网络故障点。因此要求光缆网需逐步由环行向网格型演进，需增建城域数据汇聚节点与数据核心节点之间的直达光缆路由，或在汇聚光缆网之上增加汇聚调度光缆，重新配置汇聚纤芯资源。在接入层，全面建设面向用户的FTTx光缆网，满足海量用户的接入需求是主要任务。
3.网络扁平化
网络扁平化是业务网转型的必然结果。网络扁平化后，核心层网络膨胀，核心节点之间连接更加紧密，跨片区、跨地市甚至是跨省的光缆路由需求增多。接入层由于可以方便地接入到核心网络，单个接入光缆网的覆盖范围缩小，整体网络规模加大，光缆网更加靠近用户，光缆网的接入能力和接入便利性得到提高。
4.网络IP化
对移动运营商而言，网络IP化最大的变化在于移动基站的IP化。但无论是2G还是3G，无论其电路形式是TDM还是IP化的，均要求承载层能够提供电信级保护，因此传送网的网络结构不会产生大的变化，在汇聚层和接入层，光缆网仍将以高效安全的环行结构为主，通过传输设备升级提供IP接口，应对网络IP化初期电路传送需求。
5.网络宽带化
随着IP业务的发展，普通移动个人用户和互联网用户对带宽的需求也越来越高。在接入层，无线接入的宽带化，使得移动基站IP化之前的电路需求由1～3个E1扩大到5个以上，IP化后电路接口将以10Mbit/s甚至100Mbit/s为主。随着高清IPTV等业务的普及，普通互联网用户带宽需求也将达到10～30Mbit/s。在汇聚层，上联带宽已经达到1GE，正全面向10GE升级。若仍采用传输系统解决如此大容量的传输电路需求，将会占用大量汇聚层和核心层带宽，系统复杂度和建设维护成本也随之升高，裸纤直连的优越性逐渐凸显，这就需要增大汇聚层光缆密度。
6.传送网技术发展
在核心汇聚层，传送能力强大的WDN/OTN技术大大降低了业务对光纤需求的压力，光缆容量无需大规模扩容。但技术的发展无法弥补光缆路由不足的缺陷，相反需要光缆网的网格化来支撑传送网系统向MESH升级。光纤路由的不丰富，将制约设备性能发挥。接入层MSTP/PTN技术与核心层相类似，利用设备的处理能力缓解了接入点电路需求增加造成的压力，网络结构也无需作大规模调整。
归纳以上分析，全业务技术环境下除数据城域网和用户接入网分别对光缆核心、汇聚层和接入层产生很大影响外，其他变化因素都可在现有光缆网基础上灵活应对。
全业务光缆目标网架构
综合未来网络发展需要，移动运营商全业务光缆网应分为核心、汇聚、接入三层。其中核心层、汇聚层为多业务共享的物理平台，接入层可再细分为主干（馈线）光缆、配线光缆和末端引入光缆。主干光缆可考虑多业务共享，而配线和末端引入由于基站接入和用户接入需求差异较大，建议独立建设。核心节点三个以上的大型本地网，核心光缆网结构以网格状为主，非数据核心节点之间与数据核心节点之间光缆芯数应适当加大，以满足数据城域网连接需要。汇聚层光缆仍然以环行为主，并逐步在汇聚层之上以数据汇聚节点为中心叠加汇聚调度层，增加数据汇聚节点与核心节点之间的直达光缆，推动汇聚层光缆网向网格化、扁平化演进。接入层解决2G、3G移动基站接入的光缆网应以环行为主，用户接入光缆网应以星型、树形为主，辅以少量环行光缆网，为重要客户提供更高质量的保证。光缆网的整体架构如图2所示。
图2 光缆网整体架构示意图
用户接入光缆网（FTTx）架构中，FTTx光缆网又分为主干、配线和末端接入三层。为提高接入效率，降低建设成本，降低线路衰耗，主干、配线光缆采用星型和树型结构，利用基站和光交递减配纤或非递减配纤。同时，FTTx网络应能支持为少数重要客户提供路由保护和后期扩容，因此，需保留部分公共光纤。FTTx主干、配纤光缆结构建议如图3所示。FTTx主干、配纤光缆结构示意图
光缆网发展策略
1.光缆网建设应统一规划，分区分步实施。光缆网是底层物理层，多业务共享，要综合考虑各种影响因素和所有业务需求，需要统一规划，避免重复建设和资源浪费。由于用户接入光缆网的特殊性，其分布面广，接入数量庞大，光缆若要一次到位投入巨大，投资效益比很低。因此，需要根据市场拓展情况逐步实施，先覆盖用户密集、业务发展好的地区，后逐步向周边渗透；先解决资源问题，后提高容量。
2.充分利用现有资源。移动运营商已经建成的大量汇聚光缆、汇聚节点和基站，是其光缆网向客户推进的基础，应以这些点为基点，向下敷设主干、配线光缆，覆盖周边用户。向上利用汇聚核心光缆，完成业务汇聚。
3.核心汇聚层扁平化，接入层纵深化。受业务网和传送网技术发展的影响，核心汇聚层光缆将逐步扁平化。随着汇聚层与核心层的连接光缆越来越多，层次间的界限也逐步模糊。而在接入层，为维持基站接入光缆网的稳定，应独立发展面向基站接入的光缆网和面向用户的光缆网。用户接入光缆数量庞大，若直接接入汇聚层，将会给汇聚节点周边管线和进出局管道造成巨大的压力，因此需要通过移动基站、光缆交接箱、接头盒等设施逐级汇聚，通过分光器汇聚节约主干光缆线芯资源，尽量避免末端接入光缆直接进入汇聚节点。
4.网络建设差异化。在光缆网建设过程中，也应对光缆接入对象进行等级划分，为不同的用户提供安全级别不同的接入服务，以有效控制网络建设成本，体现差异化服务（SLA）的服务特色。对于移动基站、集团大客户等，应使用安全级别高的环形光网络，普通用户使用成本低、效率高的星型和树型光网络。
5.积极采用新技术，推动FTTx光缆网建设。移动运营商作为固定接入和互联网接入的后进入者，基础资源相对匮乏。但同时又必须打造优于先进入者的光缆网，来吸引用户。要想达到目的，就必须利用新型光纤光缆和新的施工工艺，如微管微缆、浅槽光缆等，快速建设更加贴近客户的光缆网。
6.多运营商网络资源共享。在核心汇聚层，需要保障光缆网的绝对安全和稳定，以及在故障时的快速响应，因此，建议尽量确保使用自有管线资源。在接入层，情况复杂，管线需求数量庞大，应加大资源共享力度，节约投资。
光缆建设技术选型
1.光纤类型选择
目前最常使用的光纤类型主要有G.652和G.655光纤。对于通路非常密集的WDM系统，G.652光纤能有效抑制影响系统的主要因素——FWM效应，在技术上有更多的优势。高密度、大容量的WDM/OTN系统是未来干线和核心汇聚层光传送系统中的主流技术。因此，笔者建议干线、核心层、汇聚层选用G.652D光纤。在接入层，速率相对较低的传送系统对纤芯各项指标的要求除衰耗外，其他并不严格，仍然可以采用G.652B型光纤。
FTTx网络进入用户建筑物内后，因为特殊的施工条件，需要使用G.657低弯曲损耗敏感单模光纤。考虑到与本地光缆网G.652光纤的兼容性，应优先考虑使用G.657A型。G.657光纤在国内尚未得到大范围使用，价格仍然偏高，应尽量减少G.657光缆的使用量。
2.光缆结构选择
光缆结构设计已经非常成熟，并且经过了长期商用的考验。骨干、汇聚层大芯数光缆优先选择骨架式、层绞式光缆，接入层选用层绞式、中心束管式，末端引入层则可采用敷设简单、室内外通用的8字型和气吹架空型等各种新型干式、半干式光缆。
无线搜索三大业务架构渐显 第3篇
对于无线搜索市场下一阶段的发展，易观智库分析认为，随着社交搜索的快速发展，无线搜索市场形成了门户搜索、内容搜索及社交搜索为主的三大业务架构。
其中，门户搜索指的是无线搜索与各大手机门户网站合作，将搜索框预置到手机门户，从而获得入口优势。目前，前三大无线搜索都进行了相关布局，比如，腾讯手机搜搜已与手机腾讯网、3G门户等主流手机门户网站都进行了搜索框预置合作。
内容搜索(图片/阅读/视频等)主要根据手机网民特定需求，包括图片搜索、小说搜索、视频搜索等。目前，各大无线搜索引擎都在强化这些特定搜索项目。
业务系统架构 第4篇
1 OA系统中业务架构的设计与实现
工作架构的管理, 是指将工作活动的分工、任务、角色、目标和过程进行整体的监管与控制, 通过将工作分解、整合, 达到提高公司生产水平和工作效率的目的。现代化的企业中, 以互联网为核心的工作流程技术恰当地为企业提供了一种对工作的良好监管的现金手段。一个成功的现代化企业, 必然会有对工作流程的高效监管, 也必须对工作流进行管理, 才能达到可持续的企业结构优化。
流程管理 (process management) , 是一种以规范化和结构化为核心, 以持续优化、提高公司业务能力为目的系统化方法。作为一种公司监管手段, 它常常被定位为一种可操作的描述, 指对流程分析、重定义、资源分配、时间安排等等再生产销售环节中重要关键点的监管方式。在流程管理中, 最重要的核心是构建一个卓越的业务架构。但由于具体公司组织的行业、业务不同, 流程管理并没有一个可以一蹴而就的方式来实现, 这需要对工作流程进行长期的监控与管理, 才能从中找到可以优化的关键点。
在现代企业中, 信息化办公的程度在不断提高, 但企业的业务处理效率仍然取决于对工作流程执行的效率。实际上工作流程执行的总时间X, 与执行流程分步时间T、分步细致化程度n、复杂度k有着直接的关系, 如公式 (1) 所示:
由此可见, 在业务架构设计中, 提高分工细致化程度, 同时减少每一次分步的复杂度以及减少分步时间, 对于工作流程的执行效率有着直接的、重要的意义。
在分步过程中, 每一次分步的效率同样也受到工作流程总体设计的影响。分步时间效率j, 受到工作流程执行总时间X的影响为正向指数型影响, 同时将会收到执行流程分步细致化程度n和复杂度k以及流程信息传递效率u的影响。如公式 (2) 所示:
而流程设计的本质, 是在业务架构中信息传递的规则与效率。传递信息的规则越明确, 越简单, 工作既得效率将会越高。工作流程设计的好坏, 将会直接影响到工作信息的传递效率, 从而影响工作效率。流程的长期迭代也将会为工作方向提供一个科学决策的参考依据。
流程设计步骤如图1 所示:
在本系统中, 参考了事件过程链EPC (Event Process Chains) 模型的方法, 进行流程的设计。在借助实体关系 (ER) 模型和数据流图 (DFD) 模型方法的前提下, 对公司流程的基本事件、过程、规则、分支等元素进行统筹管理, 并引入组织和信息建模元素, 生成扩展事件驱动过程链 (EPC) , 使得与业务流程相关的工作流程在各方面均可同时被一个模型描述。应用该模型方法所产生的工作流程特点是具备跨职能的功能, 并在开发工作可控的前提下, 对已完成业务架构的动态改造改造具有支持能力。
2 OA系统安全性设计
从系统可应用性与安全性综合考虑, 系统架构风格采用了B/S架构, 该架构在具备维护与升级方式简单的优点的同时, 具备了优化成本, 更多选择的特点。通过B/S架构管理软件在服务端的的安装, 公司人员只需要通过客户端即可进行对数据的访问, 管理人员可以只进行服务器端 (Server) 的维护即可。客户端无需安装软件, 升级维护简单, 且易于传播使用, 这些特点对于公司要求的对效率与成本的限定有着至关重要的作用。
从系统安全性的角度出发, 将系统的不同功能根据其重要性分配权限是必要的, 同时将不同的系统权限分为自上而下的等级也是必须的。在系统的最高权限等级设计上, 管理员权限将对整个系统的工作人员账号、下级权限账号、系统关键信息拥有增加、删除、修改、查看的权限。系统管理员权限的设计, 使得系统安全性呈现阶梯式的权利释放。
系统权限自上而下分为:系统管理员权限、管理人员权限、服务人员及其同级权限。
其中管理人员权限以下交与公司使用, 涉及系统关键信息及数据的系统管理员权限, 由负责系统维护的专业人员使用。这样可以有效地避免数据的错误、重复及冗余, 也可以对系统安全性进行有效的保证。为了确保每一个用户在系统使用生命周期内的唯一性, 所有通过管理员注册的用户都将产生一个唯一的用户标识符——即每个系统使用者的用户名、密码、所属职位级别等。在用户登录时, 根据系统管理员给定权限, 采用受控式口令对后台进行访问, 后台使用更高强度的身份验证模式对用户进行身份的甄别, 并对用户登录的信息进行加密单向传输。在对系统的关键业务进行访问期间, 除了对用户身份鉴别的要求, 利息按操作时间超过规定值时, 用户会被要求重新进行身份校验。
在项目实践过程中, 系统的安全系数k会受到权限分级数s、数据交叉程度n、架构类别以及数据传输频率l的影响。其关系如公式 (3) 所示:
由此我们可以证实。系统安全系数与权限分级数正比例相关, 但是由于数据传输率和数据交叉程度的反比相关, 系统安全系数会成指数型下降。我们在设计系统的过程中有效避免了数据交叉与数据传输的高频率发生。
3 OA系统中的数据库设计
在系统数据库设计时, 应使用面向对象的方法对数据库进行建模, 在数据库建模期间应遵循以下几条原则:
(1) 一个对象类映射为一个表, 并为每个对象得设定主键 (PK) , 主键属性映射为表的主键, 其他属性映射为列;
(2) 强基础的数据映射为一个类, 提高存储效率;
(3) 对象间的关联关系为强关系, 根据关系紧密度需要添加非空外键。
在遵从以上设计原则的同时, 还需要对数据库先行绘制ER图 (模型) 。它为实体模式图形式的数据模型提供了图形信号。这一设计阶段也成为“物理设计”阶段。
在该阶段所所呈现的ER图, 一方面代表了数据库的设计方向和设计角度, 另一方面也从侧面呈现出数据库的复杂性高低。由于本系统内所涉及的表间对象联查数量多, 查询条件繁琐。对于数据库的主、外键设计具有较高的完整性要求, 需要把经常进行连接的表进行预链接, 预链接的好处是链接代价只产生一次, 但预链接通常只用于相对静态的数据。所以在本系统中, 登录的相关账户信息都采用预链接的方式与数据库进行连接。
经过优化的数据库对数据连接的紧密性会根据预连接的数量产生变化。在项目实践中, 系统连接数据库的速率L会根据预连接表数量s、数据交叉程度n、连接频率k产生变化。其关系如公式 (4) 所示:
由此可证实, 系统链接数据库速率与预连接表数量成正比, 但是数据交叉程度和链接频率的增长会造成链接速率的下降, 我们在设计数据库时避免了数据高度交叉与高频次的数据链接产生。
3 结语
本系统通过良好的技术平台及丰富完善的功能模块设计, 提高了企业的办公效率。通过良好的技术平台和丰富的经验对功能进行了模块化的完善, 该系统运行稳定、快件、简单、便利, 完全适应了现代化企业的办公标准与要求, 提高了企业的办公效率。
参考文献
[1]王利.企业OA系统的研究与开发[J].商业办公, 2008 (4) :31
[2]张然.基于移动终端的OA系统设计与实现[D].吉林大学, 2012 (4) :12
[3]郑茜.面向高校OA系统移动客户端设计与实现[D].中国地质大学 (北京) , 2013 (16) :121
[4]于洋.基于可定制工作流的OA系统的设计与实现[D].大连理工大学, 2008 (10) :121
业务系统架构 第5篇
1.1 模式描述
不管你选择哪种实现,有几个常见的核心概念都需要进行了解。第一个概念是独立部署单元。如图4-1所示，微服务架构的每个组件都作为一个独立单元进行部署，让每个单元可以通过有效、简化的传输管道进行通信，同时它还有很强的扩展性，应用和组件之间高度解耦，使得部署更为简单。
也许要理解这种模式，最重要的概念就是服务组件。不要考虑微服务架构内部的服务，最好是考虑服务组件，从粒度上讲它可以小到单一的模块，或者大至一个应用程序。服务组件包含一个或多个模块（如Java类），这些模块可以提供一个单一功能，例如为特定的城市或城镇提供天气情况，或也可以作为一个大型商业应用的一个独立部分，例如火车票的余票查询系统。在微服务架构中，正确设计服务组件的粒度也是一个很大的挑战。在接下来的服务组件部分对这一挑战进行了详细的讨论。
微服务架构模式的另一个关键概念是它可能是一个分布式的架构，这意味着架构内部的所有组件之间是完全解耦的，并通过某种远程访问协议（例如， JMS, AMQP, REST, SOAP, RMI等）进行访问。这种架构的分布式特性是它实现一些优越的可扩展性和部署特性的关键所在。
微服务架构另一个令人兴奋的特性是它是由其他常见架构模式存在的问题演化来的，而不是作为一个解决方案被创造出来等待问题出现。微服务架构的演化有两个主要来源：使用分层架构模式的单体应用和使用面向服务架构的分布式应用。
提示 : 单体应用, 即一个应用就是一个整体。
从单体应用到微服务的发展过程主要是由持续交付开发促成的。单体应用通常是由紧耦合的组件组成，这些组件同时又是另一个单一可部署单元的一部分，这使得它繁琐，难以改变、测试和部署应用。这些因素通常会导致应用变得脆弱，以至于每次有一点新功能部署后，如果由于这些新功能引发了异常，那么整个应用就不能运行。微服务架构模式通过将应用分隔成多个可部署的单元（服务组件）的方法来解决这一问题，这些服务组件可以独立于其他服务组件进行单独开发、测试和部署。
另一个导致微服务架构模式产生的演化过程是由面向服务架构模式（SOA）应用程序存在的问题引起的。虽然SOA模式非常强大，提供了无与伦比的抽象级别、异构连接、服务调度，并保证通过IT能力调整业务目标，但它仍然是复杂的、昂贵的,它很难理解和实现，对大多数应用程序来说它过于重量级。微服务架构通过简化服务概念，消除调度需求、简化服务组件连接和访问来解决复杂度问题。
1.2 模式拓扑
虽然有很多方法来实现微服务架构模式,但三个主要的拓扑结构脱颖而出，最常见和流行的有:基于REST API的拓扑结构,基于REST的应用拓扑结构和集中式消息拓扑结构。
基于REST的API拓扑基于REST的API拓扑适用于网站，通过某些API对外提供小型的、自包含的服务。这种拓扑结构,如图4 - 2所示,由粒度非常细的服务组件（因此得名微服务）组成，这些服务组件包含一个或两个模块并独立于其他服务来执行特定业务功能。在这种拓结构扑中,这些细粒度的服务组件通常被REST-based的接口访问，而这个接口是通过一个单独部署的web API层实现的。这种拓扑的例子包含一些常见的专用的、基于云的RESTful web service，大型网站像Yahoo, Google, and Amazon都在使用。
图 4-2
基于REST的应用拓扑结构基于REST的应用拓扑结构与基于REST API有所不同，它通过传统的基于web的应用或者客户端应用来接收客户端请求，而不是通过一个简单的API层。如图4-3所示，应用的UI层是一个web应用，可以通过简单的基于REST的接口访问单独部署的服务组件。该拓扑结构中的服务组件与基于REST API拓扑结构中的不同，这些服务组件往往会更大、粒度更粗、代表整个业务应用程序的一小部分，而不是细粒度的、单一操作的服务。这种拓扑结构常见于中小型企业等复程度相对较低的应用程序。
图 4-3
集中式消息拓扑微服务架构模式中另一个常见的方法是集中式消息拓扑，如图4-4所示。该拓扑与前面提到的基于REST的应用拓扑类似，不同的是基于REST的应用拓扑结构使用REST进行远程访问，而该拓扑结构则使用一个轻量级的集中式消息中间件（如，ActiveMQ, HornetQ等等）。不要将该拓扑与面向服务的架构模式混淆或将其当做SOA简化版，这点是极其重要的。该拓扑中的轻量级消息中间件（Lightweight Message Broker）不执行任何调度,转换,或复杂的路由;相反,它只是一个轻量级访问远程服务组件的传输工具。
集中式消息拓扑结构通常应用在较大的业务应用程序中，或对于某些对传输层到用户接口层或者到服务组件层有较复杂的控制逻辑的应用程序中。该拓扑较之先前讨论的简单基于REST的拓扑结构，其好处是有先进的排队机制、异步消息传递、监控、错误处理和更好的负载均衡和可扩展性。与集中式代理相关的单点故障和架构瓶颈问题已通过代理集群和代理联盟（将一个代理实例为分多个代理实例，把基于系统功能区域的吞吐量负载划分开处理）解决。
图 4-4
1.3 避免依赖和调度
微服务架构模式的主要挑战之一就是决定服务组件的粒度级别。如果服务组件粒度过粗，那你可能不会意识到这个架构模式带来的好处（部署、可扩展性、可测试性和松耦合）。然而,服务组件粒度过细将导致额外的服务调度,这可能会导致将微服务架构模式变成一个复杂、容易混淆、代价昂贵并易于出错的、重量级的面向服务架构。
如果你发现需要从应用内部的用户接口或API层调度服务组件，那么很有可能你服务组件的粒度太细了。同样的，如果你发现你需要在服务组件之间执行服务间通信来处理单个请求,要么是你服务组件的粒度太细了，要么是没有从业务功能角度正确划分服务组件。
服务间通信，可能导致组件之间产生耦合，但可以通过共享数据库进行处理。例如，若一个服务组件处理网络订单而需要用户信息时，它可以去数据库检索必要的数据，而不是调用客户服务组件的功能。
共享数据库可以处理信息需求，但是共享功能呢？如果一个服务组件需要的功能包含在另一个服务组件内，或是一个公共的功能,那么有时你可以将服务组件的共享功能复制一份，因此违反了DRY规则。为了保持服务组件独立和部署分离，微服务架构模式实现中会存在一小部分由重复的业务逻辑而造成的冗余，这在大多数业务应用程序中是一个相当常见的问题。小工具类可能属于这一类重复的代码。
提示 : DRY，即don’t repeat yourself.
如果你发现就算不考虑服务组件粒度的级别，你仍不能避免服务组件调度,这是一个好迹象,可能此架构模式不适用于你的应用。由于这种模式的分布式特性，很难维护服务组件之间的单一工作事务单元。这种做法需要某种事务补偿框架回滚事务,这对此相对简单而优雅的架构模式来说，显著增加了复杂性。
1.4 注意事项
微服务架构模式解决了很多单体应用和面向服务架构应用存在的问题。由于主要应用组件被分成更小的、单独部署单元,使用微服务架构模式构建的应用程序通常更健壮,并提供更好的可扩展性,支持持续交付也更容易。
该模式的另一个优点是,它提供了实时生产部署能力，从而大大减少了传统的月度或周末“大爆炸”生产部署的需求。因为变化通常被隔离成特定的服务组件，只有变化的服务组件才需要部署。如果你的服务组件只有一个实例，你可以在用户界面程序编写专门的代码用于检测一个活跃的热部署,一旦检测到就将用户重定向到一个错误页面或等待页面。你也可以在实时部署期间，将服务组件的多个实例进行交换，允许应用程序在部署期间保持持续可用性（分层架构模式很难做到这点）。
最后一个要重视的考虑是，由于微服务架构模式可能是分布式的架构，他与事件驱动架构模式具有一些共同的复杂的问题，包括约定的创建、维护，和管理、远程系统的可用性、远程访问身份验证和授权等。
1.5 模式分析
下面这个表中包含了微服务架构模式的特点分析和评级，每个特性的评级是基于其自身特点，基于典型模式实现的能力特性,以及该模式是以什么闻名的。
特性评级分析整体灵活性高整体的灵活性是能够快速响应不断变化的环境。由于服务是独立部署单元,因此变化通常被隔离成单独的服务组件,使得部署变得快捷、简单，云计算技术实现多业务云的架构设计 第6篇
前言
这几年，云计算越来越多的出现在大家的视野里，人们给予了云计算极大的关注，所以说云计算必然会代替旧的算法被认为是未来发展的必然趋势。随着市场一些人们的大肆宣传云计算被人们放大成无所不包无所不能而且是无所不在的万能的技术。所以对于云计算的描述出现了一些浮躁跟炒作的嫌疑。为了使大家能够更好的了解云计算模型以及它的发展的趋势，我们需要对云计算的概念跟云计算这门技术有一个更加深刻的了解。
一、什么是云计算
在互联网的技术条件下提供了云计算的一种技术形式，云计算可以提供动态变化的能够伸缩的并且可以虚拟的计算模式。云就是一种比喻，是一个抽象的概念，实际上是计算机网络和互联网在起作用。以前的云都是电信网现在才应用于互联网和基础设施等比较抽象的表达。
通过云计算把大量的数据都放在计算机上，这个计算机不是指本地的计算机或者是远程的服务器，企业可以根据自己的实际需求，对计算机的存储系统进行访问，企业可以把大量的信息资源都转换到客观应用上去。也就是说，计算机现在像水电一样作为一种商品在流通，这样不仅费用低而且利用起来也方便。因为它是按照互联网技术进行传播的。
二、云计算系统的组成
前端包括用户计算机（或计算机网络）以及云计算系统登陆程序。不同的云计算系统具有不同的用户界面。以网络为基础的邮件系统一般都借助IE或Firefox等网络浏览器登陆。其他云计算系统具有各自不同的登陆程序，用户可以运行登陆程序接入网络。
在讨论云计算系统的时候，可以把云计算系统分成两个部分，比如说前端跟后端，这两者之间是通过互联网进行传输连接的。前端指的就是用户的计算机跟用户的客户端后端指的就是系统中的计算机群也是云。
三、云计算的技术分析
3.1编程模型
通过编程模型的实现可以简化分布式编程和高效的任务调度，对于编程人员来说可以将精力放在程序的本身，这样使云计算环境下的编程变得十分的简单，通过Map程序将数据分成不相关的区块，这样就可以分配给大量的计算机进行处理，从而达到一种分布式运算的效果，然后再将结果进行输出，通过这个过程就可以对许多的数据进行有效的处理，而且速度还非常的快。云计算本身是一个灵活高效而且成本低并且可以节能的信息运作的一种新型的方式。通过编程的模型可以得出云计算是通过网络把庞大的计算处理程序分拆成无数个比较小的子程序然后再进行数据处理。
3.2海量数据分布存储技术
云计算系统通过采用分布式的存储方式来存储数据，可以通过冗余的存储方式来保证数据的可靠性。云计算系统可以广泛的采用数据的存储系统。通过分布存储技术可以提供容错的功能，并且可以给大量的用户提供一个总体性比较高的服务，对于主服务存储数据文件系统所有的元数据，包括一些名字的空间和访问的数据信息，可以从文件到块的映射以及块的当前的位置，而且还控制了系统相关的活动的范围。
3.3虚拟化技术
对于虚拟化技术来说，它是云计算的核心内容的组成部分之一，通过将各种的计算及存储资源充分进行整合并且可以高效的利用。从云计算的特征来说，主要体现在虚拟化和分布式以及动态的可扩展性，云计算中最主要的特点就是虚拟化技术，在云计算环境的构建中起着非常重要的作用。随着云计算技术的产生就出现了虚拟化的技术，虚拟化技术作为云计算的核心内容，起着非常重要的作用，并且为数据中心的部署和管理的方式提供了一种新的管理的方式。
四、云计算在当前多业务云的架构设计的重要性
4.1计算云的设计
业务的部署主要包括计算资源的分配和调度，相对来说是比较复杂的，但是从计算和存储之间不论脚本或者是API是否有标准的接口都可以通过脚本和API来进行关联。所以，对于多业务云的构架设计可以考虑把计算资源和存储资源分开。
在计算云的过程中，关于业务处理的关键是模块，需要人们进行快速的部署和动态的加载，可以考虑灵活的伸缩。在实际的运行过程中，业务处理仅仅是一个执行者，计算云真正核心的内容是管理中心和调度的中心，管理中心主要负责的项目是设备的管理、业务的管理、以及在线升级的管理，对于调度中心来说，需要根据系统的CPU、内存以及磁盘的空间和话务量这些资源，在一定的控制能力下，可以进行计算能力和存储能力的调度，对于云计算来说，它里面的资源是公共的，但是从调度中心和管理中心来考虑可以知道资源是私有化的。这就体现了厂商需要提供一定的技术水平，可以用来考验设备的稳定性。从逻辑上来说，管理中心和调度的中心是两个不同的功能，但是从物理上考虑却是可以合成的。
云计算还有一种设计方法是这样的，对于语音类的业务来说，它对实时性的要求是非常高的，需要在计算资源建设过程中解决网络的传输带宽，并且考虑处理流程增加方面带来的影响。对于数据类业务来说，更加接近于互联网的业务，对于设备的利用既不能过于均衡也不能充分。这种情况下就更加需要云计算技术，为了更好的利用云计算技术首先需要尽量的实现业务跟逻辑的分离。并且在引入分布式和分布式的文件系统之后，需要进一步的考虑各种应用的模块的独立性和并发性。对于分布式的物理数据库来说，这并不是所需要包括的一部分。
借助云计算技术进行业务的设计，需要考虑到利用多台的低端设备联合起来进行业务的实现，而且对于每一个层面来说，都需要考虑众多处理节点的横向以及可收缩性，这样从系统的模块来说，就可以随意快速的进行缩小或者是放大。对于多业务的总体的实施需要考虑到虚拟化的应用，虚拟化的技术能够有效的降低程序跨平台的需求，这样就可以对系统的快速的部署能力得到有效的提升，为了使计算资源的弹性和无限的镜像得以实现，可以考虑把计算的资源进行虚拟化。
4.2存储云的设计
实现多业务云的架构可以考虑在构件存储云的时候，做好预期，是希望可以像磁阵一样对外提供标准的存储接口还是希望像数据库一样对外提供标准的SQL。对于这两者进行最简单的区分就是存储云是否包含分布式数据库。通过以上的分析，由于一些应用需要运营商来进行提供，而对于应用的二次开发来说，则是需要专业人员来完成。
比如说电信业务，可以想到的最简单的办法就是通过云计算的处理技术对日志进行相关的处理。对于统计报表来说，由于统计源具有多样性，而且统计的数据跟时间也是紧密结合的，考虑到当前这个阶段不适合用云计算来实现了。
五、结语
在云计算技术实现的多业务云给人们带了了许多的方便，使用者逐渐的增加研发的领域，希望找到更优化的算法。通过对云计算模型的广泛应用，确实解决了一些比较实际的问题。云计算技术实现的多业务云的构架的设计可以解决在实际过程遇到的一些问题，通过这些有效的设计可以更好的实现计算机技术的发展。给企业和个人带了比较多的受益和方便。
参考文献
[1]欧阳新志，管天云，李世亮等.运用云计算技术实现多业务云的架构设计[J].电信技术，2009，（12）：85-88.
[2]何晓东.浅析云计算技术及其在企业信息工作中的应用[J].信息技术，2013，（2）：154-157.
[3]袁丹丹.针对云计算技术的安全问题进行相关探讨[J].城市建设理论研究（电子版），2013，（11）.
[4]庞伟伟.简述计算机“云计算”技术的实现[J].计算机光盘软件与应用，2012，（8）：172-173.
业务系统架构 第7篇
近年来, 随着信息技术的飞速发展, 全球正处于信息技术深度应用和新一轮技术革命孕育阶段, 技术创新渐趋活跃, 各国的技术竞争将更加激烈, 对技术标准、平台以及产业链主导权的争夺将成为竞争的焦点。
我国高度重视国家信息化工作, 党中央、国务院要求充分发挥科学技术在拉内需、保增长、调结构、上水平、惠民生中的重要支撑作用, 并将三网融合作为重要任务纳入国家发展战略。建设下一代广播电视网 (NGB) , 积极推进广电三网融合战略, 是国家新闻出版广电总局贯彻落实中央精神, 通过科技创新推进产业升级和发展方式转变、促进全面协调持续发展的重要举措。开发适合我国国情的、天地一体、有线无线相结合的中国下一代广播电视网技术体系, 突破NGB跨网络业务互联互通平台和智能内容分发核心技术, 建成示范网络, 对于加快构建现代传播体系、发展我国信息服务业、促进广电产业升级、提升行业核心竞争力, 具有十分重要的意义。
江苏有线作为全国广电行业技术创新发展先头兵之一, 基于江苏有线云媒体电视技术体系架构, 创新研发了有线无线卫星融合一体化的NGB业务互联互通平台及内容分发系统, 实现了跨网络业务互动、内容自动适配和智能流转, 形成一系列标准草案, 建成了试验平台和示范网络。本文着重探讨了江苏有线在NGB业务互联互通平台与内容分发系统总体架构研究方面的工作。
2 NGB业务互联互通平台及内容分发系统建设
2.1 技术架构
江苏有线基于平台化、水平化的理念, 整合江苏有线各类能力系统, 开放业务开发接口, 研发了NGB业务平台和内容分发系统, 提供业务公共运营支撑, 构建开放、智能、融合、安全的媒体云平台。通过媒体云平台聚合全社会的优秀内容提供商和业务运营商, 可以为用户提供:融合电视媒体、互联网媒体和平面媒体为一体的全媒体服务, 融合视频业务、互联网数据业务、多媒体通讯业务、开放的视频增值业务等全业务服务, 以及多屏统一的业务体验。
基于有线无线卫星融合一体化总体技术架构和“有线无线相结合、天地一体”的NGB技术路线, 江苏有线研发了多总线智能驱动的NGB业务互联互通平台及内容分发系统总体技术架构, 实现了跨网络、跨系统、多终端的统一业务运营和卫星、互联网、个人、业务基地等多来源内容的自动适配与智能分发。
图1为NGB业务互联互通平台及内容分发系统总体架构。
2.2 逻辑架构
江苏有线基于开放总线技术, 研发了多总线智能驱动的开放业务平台, 实现了跨网络统一业务运营和智能内容分发。根据业务特性和管理需求, 创新设计了业务驱动总线、直播流总线和点播流总线等多总线驱动架构, 实现了整个系统内部的内容与资源的高效流转和各业务之间的协同关联。
无线卫星信号、SDH信号、互联网内容和内容提供方的直播/点播内容经过融合一体化信源交换矩阵, 直播视频进入直播流总线, 点播视频内容进入点播流总线, 然后在系统中生成标准化的数据类型, 供上层业务调用。业务驱动总线打通能力资源系统与业务层, 实现各类型业务的快速部署与访问。
NGB业务互联互通平台和内容分发系统逻辑架构图如图2所示。
2.3 NGB内容分发系统
NGB内容分发系统采用分层模式, 对系统软件功能进行抽象分层, 使系统具有更高适应性和扩展性。系统主要包括内容采集模块、内容审核模块、内容管理模块、内容分发模块、视频文件关联模块、统计分析模块、工作流引擎和展现门户等核心功能模块, 并且自身具备或者可以调度使用其他内容管理系统的能力, 例如转码能力、自动技审能力、IP推流服务器内容注入能力等。
NGB内容分发系统提供从内容采集、入库、审核、加工, 到分发的完整内容管理流程, 并可提供全局的内容统计、内容查询、生命周期管理等集中的内容管理工具。系统向上承接多种内容提供商, 向下可以汇接多种业务平台。如图3所示, NGB内容分发系统架构大致分为展现层、服务层、数据链路层和工作流引擎四层, 对外接各个能力系统。
(1) 系统展现层
第一层为系统展现层, 主要为CP、运营商和合作商提供管理和展现门户, 为CP、运营商和合作商提供管理和操作界面。
(2) 系统服务层
第二层为服务层, 通过工作流引擎管理接口对下层的数据链路层进行管理和操作, 主要分为内容采集、内容审核、内容管理、统计分析、生命周期、内容分发和关联几个模块。内容采集模块主要负责采集运营商各业务系统或者CP和SP的内容元数据和实体文件;内容审核模块主要负责对采集模块采集上来的内容进行审核, 分为自动技审和人工技审两部分;内容管理模块主要负责对各内容文件的元数据和实体文件的管理和调度;内容分发模块主要负责导入平台的内容 (包括元数据和实体文件) , 在各级CMS、CDN、门户系统、业务协同系统和各类流推送系统之间的内容分发策略和分发管理;生命周期模块主要负责内容的生命周期管理;统计分析模块主要负责统计各项内容业务使用情况;关联模块主要负责关联同一节目的不同格式和码率的视频, 并根据内容ID和子ID来进行相同内容不同码率的视频文件关联。
(3) 数据链路层
第三层为数据链路层, 主要有存储管理、链路管理和数据管理三个模块, 并由数据库和文件库两个库进行支撑。
(4) 工作流引擎
通过工作流引擎, NGB内容分发系统还支持通过统一的接口封装和适配, 调度第三方内容管理系统或者第三方能力系统, 包括且不限于CDN能力、编转码能力、DRM能力、流推送能力、智能分析能力等。
2.4 内容协同关联
同一内容在不同格式、码率的码流之间存在对应关系, 通过规则匹配, 可满足多终端之间互操作的需求, 实现同一内容和业务在不同终端上的使用。
内容关联通过自动和手动两种方式建立完成。自动方式是指通过工作流引擎调度内容关联任务, 经过后台管理系统自动分析内容的元数据, 根据元数据信息对内容文件进行管理, 比如:根据影片导演、主演、年代、题材、热度、排行、推荐程度等, 自动建立关联机制, 在页面中显示这部影片的时候就会将相关影片显示出来。通过手动的人工建立关联的方式, 即录入、编辑影片信息的时候直接指定其关联的影片。同时, 也可以实现自动和手动相结合的方式, 即在手动指定影片关联的时候, 不是特别指定哪部影片, 而是指定这部影片相关联的分类, 这样在显示关联影片的时候就会以手动指定的条件作为优选条件进行关联显示。
内容关联模块主要实现四个层面的内容关联功能。
(1) 将批量导入的媒体文件与批量录入的元数据信息建立关联
批量操作可以减少数据录入、维护的工作量, 可以方便地检索查询到需要关联的媒体文件和元数据信息, 并进行关联操作。在关联的同时, 将系统分配给唯一的内容ID配置在媒体文件属性中, 同时将此内容ID插入元数据中。
(2) 将相关媒体关联
相关媒体可以是同一系列电影等, 关联的对象可以是剧情、导演、演员、编剧等, 信息受众将更加方便地获取与当前媒体相关联的媒体信息群, 从而最大范围地增加了信息受众点击下载媒体的可能性。
(3) 将相关的媒体文件关联
相关的媒体文件包括正片、预告片、片花、电影原声带等。关联的对象可以是预告片、片花、电影音乐等整个媒体影片制作过程中的方方面面, 实现真正意义上地为信息受众提供更加充实的、多维化的媒体内容。
(4) 将相同内容不同屏幕媒体文件关联
不同码率不同大小但是相同内容的媒体文件, 发布在不同的屏幕上, 需要建立关联关系, 方便用户在不同屏幕上切换或续看相同的内容。
2.5 内容安全管控
节目内容要经过一个完整的审批流程, 并在确认审核通过之后, 才可以进行发布。审核通过的内容才可进行内容分发。
NGB内容分发系统的整体流程如图4所示, 元数据流程与实体文件流程分离, 经过工作流引擎驱动, 将来源于各个不同CP的内容经过技审、编目等环节, 发布到各个能力系统和应用系统中去, 最后向各个业务系统提供服务。
元数据从采集、初审、复审、技审再到打点、编辑、编目、终审、发布等环节, 均可以做到流程自定义, 所有的环节均可以人工进行删减或者添加, 为跨屏内容的多流程做到自动适配, 包括调用外部编转码能力、IP推流能力、CDN能力等, 都可以根据使用需求的不同来进行不同的组合。
内容审核包括三级审核, 分别由入库技审、内容审核和发布审核组成。
(1) 入库技审
指内容实体文件上传至本系统后, 系统自动对其实体文件进行技审。其审核对象是内容的实体文件, 审核内容包括文件类型、时长、文件长度、MD5、清晰度、码率、内容连续性、内容完整性等。该部分工作由自动技审能力单元完成, 无需人工参与。
(2) 内容审核
内容审核是指操作人员在系统中对已经送审的内容进行审核, 其审核对象包括内容的元数据和实体文件, 审核内容至少应包括元数据的正确性、版权有效性、实体文件正确性等。
(3) 发布审核
发布审核是指业务门户运营支撑系统的运营人员向内容管理平台提交了内容申请以后, 内容管理平台根据申请进行内容制作和加工, 完成以后提交审核, 审核通过的内容才能真正发布给提交申请的业务门户运营支撑系统, 该环节可作为可选环节。
通过本模块, 内容审核人员可以方便地对通过、未通过、待通过审查的节目编排进行浏览、状态标注, 对不能通过审查的节目编排填写原因, 对审核的内容添加文字批注, 然后反馈给相应编排的负责人。审核人员可以对用户进行分角色定义, 灵活地对不同的角色授予权限。审核人员可以灵活地对审批流程进行定义, 还可以对审批流程进行追踪。
3 结语
回顾江苏有线NGB业务互联互通平台与内容分发系统研发历程和云媒体电视技术演进路线, 从总体发展趋势上来看, 主要有几个方面的技术推进:第一, 积极应用云计算、大数据、物联网等高新技术, 大力倡导技术创新、转变传播模式、转变运营模式、深挖价值链, 有效推动传统广电媒体与新媒体的融合与发展;第二, 深入推进智慧江苏、智慧广电建设规程, 打造智慧城市、智慧社区、智慧家庭三位一体的江苏有线智慧城市创新服务云平台;第三, 加快产业链上游4K、交互等新型视听内容的产业布局, 打造跨网、跨屏的云媒体内容集成服务平台。
技术和市场的发展是相辅相成、互相推进的, 云媒体电视作为江苏有线技术和业务融合创新的承载平台, 将随着技术的演进和市场的需求不断持续创新, 与时俱进, 成为广电有线行业创新发展的标杆产物。
摘要：有线电视的发展经历了从模拟到数字、从单向到双向, 以及目前"互联网+"时代传统媒体与新兴媒体的融合这三次重大变革。面对这些机遇和挑战, 江苏有线根据总局NGB技术体系标准, 着力研发了江苏有线NGB业务互联互通平台与内容分发系统, 实现了跨网络业务互动、内容自动适配和智能流转等功能, 本文主要探讨了NGB业务互联互通平台与内容分发系统总体架构研究。
关键词：NGB,云媒体电视,内容分发,互联互通
参考文献
[1]刘晓雪, 章文辉.浅谈下一代广播电视网 (NGB) [J].电视技术, 2009 (33) :150-152.
[2]张星昱, 杨凤娟.建设符合我国国情的NGB[J].中国有线电视, 2012 (2) :23-27.
[3]王厚芹, 丁颐.我国三网融合发展战略[J].电视技术, 2011, 35 (10) :63-67.
[4]谷虹, 黄升民.三网融合背景下的“全战略”反思与平台化趋势[J].现代传播, 2010 (9) :6-10.
[5]王伟, 李鑫.江苏有线云媒体电视平台研发与实践[J].有线电视技术, 2012 (19) :136-142.
[6]薛留忠, 王伟, 占亿民.江苏有线云媒体电视平台研发建设与推广应用[J].广播与电视技术, 2013 (40) :123-130.
业务系统架构 第8篇
重组后的中国联通进入了全业务运营时代, 还获得了3G运营牌照, 扩大市场份额, 提升客户满意度, 进而达到提高运营商收入的目的。这对新环境下的BBS系统而言, 从业务管理层面提出了更高的要求, 主要体现在以下几个方面。
(1) 整合固定网络和移动网络客户资源, 对不同阶层客户的消费习惯进行详细地分析, 推出符合客户要求的全业务组合套餐, 实现固话、GSM业务、宽带间的灵活捆绑。
(2) 能够完美支撑3G用户计费。3G业务的推出, 不仅是对用户使用手机方式的革新, 也是对BSS系统建设的一个挑战。中国联通的3G计费模式, 不再是单纯的按时长, 流量计费, 还要满足对多媒体内容下载量按M/T来计费, 同时还要实现用户包月套餐的自动升级。
(3) 能够实现与在线计费系统 (即OCS) 的交互。中国联通部分用户的计费在OCS平台, 但是客户的业务办理, 包括开户、查询、管理、缴费在BSS系统, 实现这一要求需要借助OCS系统与Biiling系统的交互功能。
2 联通BSS系统的建设现状
重组后的联通BSS系统在移动业务支撑系统上是以原联通的客户关系管理系统、综合计费系统、经营分析系统和伙伴关系管理系统为核心, 而固网业务支撑系统是以原中国网通的业务支撑系统为基础。
随着联通的不断发展及市场需求的不断变化, 联通在原有BSS系统的改造建设上投入了大量的精力, 主要体现在四个方面的建设上。首先联通将建设的主要目光投入到了如何快速的提高自身全业务支撑能力, 大力改善服务能力, 通过对融合业务进行深入分析, 从而确保联通BSS系统具备复杂融合业务的支撑能力;其次联通在发展的过程中非常重视宽带业务与增值业务的支撑工作, 因而在计费系统的建设上不断关注, 力争使计费系统更好地对宽带与增值业务预付费的经营模式进行支撑;然后是电子渠道支撑能力的建设上, 联通建立了电子消费客户群, 并针对这个客户群体进行联通3G的营销、联通形象展示等活动;最后是一卡充系统的建设, 中国联通为了实现业务的全网一卡充值服务, 不断地推进一卡充服务系统的建设进度, 力争使客户获得全新的体验。
近几年的时间里, 中国联通在原有BSS系统的改造建设上虽然取得了一定的成绩, 但是核心系统并没有真正实现移固业务支撑的融合, 这对于促进联通业务流程重组, 提高内控基础管理还有一定的影响。虽说如此, 但是在老系统的改造建设过程中, 积累了丰富的全业务运营支撑系统建设经验, 也为新一代BSS系统的建设奠定了坚实的基础。
3 联通新一代BSS系统技术架构
联通新一代BSS的目标应该是实现固移支撑系统的真正融合, 通过统一接口平台实现核心系统为外围系统提供业务能力。融合对象主要有核心系统、配套系统、外围系统三部分, 核心系统主要包括客户关系管理系统 (CRM) 、综合计费系统 (BILLING) ;配套系统包括市场营销、销售管理、客户维系挽留、大商客营销系统等;外围系统主要包括:OCS、一卡充、VAC、增值业务平台、收入归集、客服、经分、IOM、服务开通、号线资源、采集预处理等。
其中, 核心系统的架构至关重要, 对于CRM系统需要具备客户接触管理、订单处理、客户信息管理、产品管理、渠道管理、积分管理、业务资源管理等功能, 能够实现通过多种接入方式来满足客户的业务受理, 缴费、查询、咨询、推介、投诉、终端维修、信息发布等;对于BILLING系统需要具备费用计算、账单管理、账务管理、信用控制等功能。
4 联通新一代BSS系统的规划
新的环境为中国联通的发展提供了新的平台, 也为BSS系统提出了新的规划要求。
4.1 新环境下联通BSS规划的思路
明确了BSS规划的主要思路, 对于新环境下BSS的规划能否满足联通的发展去向有着重要的作用。联通坚持以标准化和产品化作为BSS发展的核心要求, 充分考虑公司制定的发展战略, 充分利用当前的先进技术, 对BSS系统进行总体的综合滚动规划思路。
4.2 新环境下联通BSS目标架构的规划
在新的环境下联通BSS目标构架的规划要严格进行, 同时要对当前的新技术包括网络、业务、组织结构等方面都有所把握, 还要对未来电信行业的发展有一定的认识, 这样才能保障新环境下联通BSS目标机构的规划真正具有开放性和灵活性的特点。此外在保障开放性和灵活性的同时还要注重适当稳定性的原则。
新环境下联通BSS目标结构的规划过程中要以公司的支撑能力和业务需求相匹配的原则来进行, 但要有适度的超前意识。要对中国联通的运营情况特别是运营需求进行深入地了解分析, 充分发掘原有规划中与当前条件、要求相适应的部分, 并将这些内容与实际建设相结合, 全方位的优化BSS系统的支撑能力, 要从系统的模型、功能、集成等几个方面着手。
新环境下联通BSS系统演进路线的制定方面, 需要对各个省份业务发展情况进行了解, 在统一规范、统一管理、统一版本的基础上, 制定不同的演进路线, 在今后的发展过程中, 要实现标准化建设, 确立的发展思路, 提升全业务融合捆绑能力, 简化跨省业务的开展, 方便集团对数据的透明管控。 (下转第274页) (上接第252页)
5 结语
目前, 通信行业正在从语音时代走向流量时代, 从固定接入互联网走向移动互联网时代, 中国联通在这样的形势下, 要想获得更大的市场份额, 建设集中化、一体化的IT支撑系统, 提升业务支撑能力势在必行, 相信新一代BSS系统的建设会给联通的发展带来新的辉煌。
摘要：BSS系统对电信企业的正常运营至关重要, 随着国家电信行业改革的深化, 市场客户需求的不断提升, 对电信运营商的BSS系统架构及建设提出了更高的要求, 作为我国三大电信运营商的中国联通, 通过建设新一代BSS系统, 整合企业资源, 全面提升业务支撑能力, 力争打造优质的电信业务品牌。
关键词：联通,BSS系统,架构,建设
参考文献
[1]张浩, 俞涛.浅析河北联通IT业务支撑系 (BSS) 系统的整合[C].中国通信学会信息通信网络技术委员会2009年年会论文集 (上册) , 2009
业务系统架构 第9篇
随着电信重组和3G牌照的发放, 中国电信行业进入了里程碑式的发展阶段, 奠定了新的竞争格局和方向。一方面, 在全业务竞争初期, 仍然以语音和短消息为主要业务, 以发展用户为重要手段, 如何在提供同类业务的基础上体现自身网络管理质量和服务质量的优势, 成为各个运营商竞争的焦点;另一方面, 全业务运营带来了业务的转型和多层次的融合, 3G时代业务种类日趋丰富, 产业链发展更加成熟和完善, 移动通信业务体现出更多的信息服务特征, 并越来越注重用户的业务体验。如何在做好网络设备维护的基础之上, 提供更高层次的服务支撑能力, 也对新一代运维支撑系统提出了更高的要求。
总之, 电信行业的持续发展要求OSS系统实现从过去的消防员角色, 被动维护的状态发展到主动维护, 提前维护的状态, 并进一步实现从支撑者到使能者的飞跃, 更好地帮助运营商实现资源整体规划、设计、预测、分析以及管理等能力, 提升客户服务水平 (SLA) 与客户体验度 (Qo E) , 明确定义运维生产与管理工作中的各种资源及角色, 优化运维业务流程管理, 扩展各种业务的价值链。实现IT和业务目标的紧密结合, 并引导业务创新和发展。
2、相关理论
2.1 运营支撑系统
TMF提出的NGOSS框架定义了下一代运维支撑系统的构成要素和覆盖范围, 该体系框架中的OSS是一个广义OSS的概念, 针对我国电信运营商的特点和现状, 可以对该体系框架进行进一步的映射如图1。
2.2 流程驱动
TMF的e TOM提供了流程驱动的OSS系统框架设计方法, 以SLA管理为例, 基于e TOM的流程设计如图2:
3、现有电信运营支撑系统的局限性
3.1 支撑能力方面的现状和不足
实现了核心运维工作的基本覆盖, 但是对细粒度运维工作支撑偏弱;缺乏对核心运维工作的深度覆盖:生产操作的便捷化、自动化、智能化等方面的能力仍然不足;实现对业务系统和网络设备的覆盖, 但缺乏端到端服务质量管控能力;基本支持集中化、综合性的需求, 但在跨专业生产调度、故障定位关联、业务监控和分析、集中网络优化管理等方面仍然欠缺;对外支撑不足, 在统一信息共享、资产管理、流程贯穿、市场和客服支撑等方面有待提升;功能系统方面来看, 面向客户, 业务端到端的系统管理不足, 快速相应不够;管理“监”强于“控”, 不能快速实现业务开通, 造成孤岛现象。
3.2 系统架构/技术方面的现状和不足
系统架构、实现技术研究不足, 架构或流于纸面, 或过于复杂, 难以实际落地;缺乏对信息/数据的共享、一致性、可管理性;集成技术 (EAI/ESB) 的采用较少, 主要通过一对一接口方式集成;缺乏对COTS软件的研究分析, 难以正确引导各省的引进策略。
4、对电信运营支撑系统的新要求
4.1 统一流程的综合业务保障
运营支撑系统对外提供综合业务保障的能力, 该能力的提供基于内部统一的流程整合与管理, 所以企业内部的业务梳理和运营流程的梳理在电信运营支撑系统建设过程中占有重要的地位, 是电信运营支撑系统成功的前提。
4.2 数据的整合与共享
数据融合的意义是同时存储、管理多个业务网的用户数据, 实现用户信息的集中化、个性化、定制化;可以完美的实现数据容灾功能, 大幅提升网络的业务能力和面向客户的能力。这不仅可以加强运营商统一开展融合业务的能力, 增强运营商的竞争力, 同时可以降低软硬件投资和运营成本。
4.3 新业务的快速设计和开通
随着3G时代的到来, 运营商需要向用户提供丰富多彩的新业务, 3G时代不存在像2G时代的杀手级业务, 与此相反, 3G时代是一个关注“长尾”, 发挥“长尾”效益的时代。这同时也以为着必须实现新业务开通的自动化, 降低新业务推出的成本。
4.4 精确、快速的计费支持
在3G时代, 实时费用查询, 计费通知, 对客户来说十分必要。而有效预防风险, 提升客户满意度, 本身就是优化业务成效的一个表现, 将大大增强运营商的竞争力。全业务产生了对融合了固网, 移动网络, 互联网业务的复杂帐户的复杂计费模式 (如集团代付等) 进行支持的需求, 对计费系统提出了更高的要求。
5、服务驱动的运营支撑系统框架
随着移动通信的发展和电信领域内竞争的逐步激烈, 电信运营商逐步认识到, 服务质量的高低是最终决定其竞争力的因素, 原来运营商赖以生存并得以获取垄断利润的网络等通信介质的重要程度也逐渐降低。伴随3G时代和全业务运营时代的到来, 整个电信产业链得到进一步丰富和增长, 涌现出大量新型环节, 如:平台提供商, 应用提供商, 服务提供商等, 为了避免在产业链中被“渠道化”, 电信运营商注意到必须牢牢抓住服务环节, 不仅需要提供消费级的服务, 而且需要提供产业级的服务。在此基础上产生了服务驱动的运营支撑系统框架。
6、结语
本文通过分析运营支撑系统在NGOSS系统中的定位, 明确了服务, 流程, 过程, 角色, 权限和资源之间的关系, 在此基础上提出了一套可行的服务驱动的运营支撑系统框架, 该系统框架可以有效地克服现有运营支撑系统的局限性, 适应3G和全业务的运营环境要求。同时在业务与流程映射的方法论方面仍需要进一步的研究, 是后续的研究方向。
参考文献
[1]TeleManagement Forum, GB921, eTOM The Business ProcessFramework (Public Evaluation Version 8.1) , 2008.
[2]Morrow M, Hazell M.Activity Mapping for Business ProcessRedesign.Management Acounting, 1992.
[3]Lundy Lewis, Pradeep Ray;“Service level managementdefinition, architecture, and research challenges”, Globol Tele-communications Conference-Globecom’99
业务系统架构 第10篇
中国下一代广播电视网 (NGB) 是由科技部和广电总局联合组织开发建设, 以有线电视网数字化整体转换和移动多媒体广播电视 (CMMB) 的成果为基础, 以自主创新的“高性能宽带信息网”核心技术为支撑, 构建的适合我国国情的、“三网融合”的、有线无线相结合的、全程全网的下一代广播电视网络。作为三网融合业务在广电的载体, NGB是有线电视网络实现三网融合业务, 为全国用户提供包括视频、数据和各种应用在内的综合信息服务的唯一载体。未来要根据需要组件全国性的机构, 搭建全国的综合业务平台, 构建全国有线电视网络互联互通平台, 运营和管理全国业务和跨域业务。
有电视网络业务支撑系统 (BSS, Business Support System) 是全国有线电视网络互联互通平台的关键支撑系统, 负责全国跨地域运营和统一结算支付, 全国数字电视用户收视率统计和发布。负责与各省本地业务支撑系统对接, 对全国直播、点播、信息服务和跨地区点播等业务提供业务支撑。
1 BSS系统功能描述
NGB业务支撑系统包含客户关系管理子系统、综合计费账务结算子系统、合作伙伴管理子系统、统一用户认证子系统和业务开通子系统。
1.客户关系管理子系统
客户关系管理子系统是以客户为中心, 提供面向客户的售前、售中、售后的服务和产品管理的综合系统。该系统整合客服、营销、销售/订单等功能, 提供统一的客户视图与产品闭环管理。
2.合作伙伴管理子系统
合作伙伴管理子系统对广电的各种合作伙伴信息、信用、合同等进行综合管理, 提供合作伙伴资质与资料、考核、结算等支持。
3.综合计费账务结算子系统
综合计费账务结算子系统包括综合采集、综合计费、综合账务管理、综合结算, 实现实时、集中、融合的计费能力, 和精确营帐的账务管理, 为内容分发交换提供结算服务。结算系统完成服务供应商、内容提供商、渠道商等合作伙伴之间以及公司内部根据结算规则的收入分摊、业绩核对和监管。结算规则、核对方式等内容来自合作协议或合同及公司内部的配套管理办法。
4.业务开通子系统
业务开通子系统实现在开通业务/服务层面的流程管理功能, 承接客户关系管理系统中的订单管理, 与资源开通、自动激活和施工调度共同建立端到端的开通能力。并对网元进行集中统一的控制, 并提供良好的异常处理和管理能力。
5.统一用户认证子系统
统一用户认证子系统为运营商的各类基础业务及增值业务使用用户提供统一的认证, 对于由多种业务组合、或捆绑销售的产品而言, 在支撑系统一侧完成统一的业务认证尤为重要。该系统除了提供统一认证外, 还提供针对用户所订购产品的鉴权。统一用户认证子系统和各个具体的业务 (服务) 提供平台共同完成对用户、业务的认证计费和授权:统一用户认证子系统侧重对用户身份有效性的验证, 业务提供平台 (如互动电视平台、游戏平台等) 的AAA (认证、授权和计费) 功能负责使用具体业务时, 对用户身份的认证, 以及对所使用业务的授权, 并提供最原始的使用记录作为计费依据。
各个子系统及相关数据交换关系图1所示。
2电信业务支撑架构研究
电信管理网络 (TMN) 是提供一个有组织的网络结构, 以取得各种类型的操作系统 (OS) 之间、操作系统与电信设备之间的互连。TMN的最主要的标准之一是ITU-T M.3010, 它是关于TMN的总体要求, 涉及总体原则、体系结构、逻辑分层结构及基本功能要求。M.3400是关于TMN的管理功能的标准。M.3200系列是关于TMN的管理业务及各种电信网上的TMN管理业务标准。M.3020是TMN的接口规范定义方法。M.60.2是TMN的基本术语定义。M.3100系列是TMN的通用管理信息模型。
电信运营图 (TOM) 用来替代电信管理网络模型, 定义电信运营的基本业务处理框架模型及其业务处理过程之间的相互关系。e TOM是电信运营图的增强型版本。e TOM对服务供应商所必需的业务流程作了完整描述, 并定义了关键元素以及各自间如何相互作用。e TOM已经被ITU-T国际建议采纳, 即M.3050建议。
下一代运营软件和系统 (NGOSS) 是“电信管理论坛 (TMF) ”提出的新一代运营支撑体系。NGOSS提出了基于组件的面向对象的分布式OSS解决方案。NGOSS架构主要包括企业流程抽象、共享信息服务和利用正式可交易的合同进行接口定义, 软件的组件化发展对NGOSS架构的形成有着重要的影响。
图1各个子系统及相关数据交换关系
基于对电信相关系统的研究和总结, 以及NGB业务支撑系统功能需求, 我们提出了NGB业务支撑系统的设计实现方案。
3系统架构设计
NGB业务支撑系统采用标准的多层结构体系 (图2) , 前台界面采用WEB方式;采用中间件实现数据倒换;后台服务采用C++语言实现, 数据库采用Oracle。
NGB业务支撑系统从逻辑横向层面来看, 大致可以分为三层结构, 分别为接入层、业务层、数据层。
接入层:提供客户接入服务, 实现多种方式的接入, 包括所有与客户产生联接和交互的手段, 还包括与外部系统的连接, 如VC充值系统、客服务系统、网上自服务系统、银行系统等, 业务实现在前端通常是以浏览器的方式具体表现。接入层展示各种业务数据, 并接收的各种业务操作, 向业务逻辑层发出进行业务处理的请求。
业务层:主要进行各种业务操作和业务规则处理, 涵盖所有的应用服务和业务处理。采用组件技术实现, 将所有的核心业务逻辑都封装在组件中, 并利用组件提供业务服务。
数据层:主要功能是存储核心数据, 如果帐单数据、资金数据、操作工单数据等。
从技术层面来看, 可以采用Browse/Application Server/Web Server多层结构设计 (图3) , 支持前端浏览器访问方式。整个体系架构为B/S架构, 分为四层, 最前面一层是客户端 (即浏览器端) ;第二层为Web Server层, 采用Struts架构, 通过相应的协议调用OBD接口和后台应用服务之间通信;第三层为应用服务层, 采用C++实现, 和Web Server之间通过OBD接口实现, 应用服务层之间还存在互相调用的情况, 此时同样采用PMGR或MGR OBD接口实现两个App Server之间的互联, 第四层为数据库层。
4关键技术研究
1.J2EE技术
NGB业务支撑系统一般采用基于J2EE体系架构的分布式企业应用。B/S的方式使用户免于安装、更新客户端, 使用浏览器即可访问操作。成熟的J2EE技术为项目提供了性能、可维护性、安全等各个方面的有力保证。
2.工作流平台
系统设计中订单处理、服务开通等流程性较强的模块建议采用采用了工作流开发管理平台作为流程开发与管理的工具, 从而达到对业务流程的灵活配置和管理监控。
工作流就是工作流程的计算模型, 即将工作流程中的工作如何前后组织在一起的逻辑和规则在计算机中以恰当的模型进行表示并对其实施计算。采用工作流技术实现某个业务目标, 在多个参与者之间, 利用计算机, 按某种预定规则自动传递文档、信息或者任务。工作流就是一系列相互衔接、自动进行的任务。可以将整个业务过程看作是一条河, 其中流过的河水就是待审核的表单。
3.ESB平台
系统设计中内部子系统间, 以及NGB业务支撑系统与外系统的互联中采用ESB平台实现, ESB平台是具备安全机制、可全程监控、支持集群化高性能的企业服务平台, 是企业联系各种外部系统服务的总线;一般支持二次开发扩展的通信接口协议、定制应用组件机制。使用高性能的内部调度模式并兼容业界标准的BPEL规范。
通过ESB平台的使用, 可以使NGB业务支撑系统内的接口以及BSS与外系统的接口能够可管可控。
4.内存数据库技术
内存数据库就是将数据放在内存中直接操作的数据库。相对于磁盘, 内存的数据读写速度要高出几个数量级, 将数据保存在内存中相比从磁盘上访问能够极大地提高应用的性能。同时, 内存数据库抛弃了磁盘数据管理的传统方式, 基于全部数据都在内存中重新设计了体系结构, 并且在数据缓存、快速算法、并行操作方面也进行了相应的改进, 所以数据处理速度比传统数据库的数据处理速度要快很多, 一般都在10倍以上。内存数据库的最大特点是其“主拷贝”或“工作版本”常驻内存, 即活动事务只与实时内存数据库的内存拷贝打交道。
整个NGB业务支撑系统使用内存数据共享区建立内存数据库, 由一个单独运行的服务程序来管理, 客户端通过SOCKET访问它, 它具有和数据库相似的访问特性, 但速度却和内存相当, 使用内存数据库的目的是为了提高系统的大数据量的处理能力。
5.安全接入技术
安全接入管理平台作为NGB业务支撑系统的组织、工号、岗位、角色、权限的统一管理平台, 可以将客户关系管理、服务开通、账务管理等子系统的单点登录和工号、角色、权限的统一配置。
安全接入管理平台提供以下功能:
单点登录:操作员只要登录一次, 即可使用多个系统下的功能。
统一管理:组织、操作员、角色、权限及赋权等功能, 全部在统一权限平台下管理, 不需要在不同系统下做重复的管理操作, 让管理员更注重赋权, 而不关心子系统。
统一验证:客户关系管理、服务开通等子系统, 全部通过调用统一权限平台提供的分布式服务进行权限验证, 各业务系统本身不再保留权限模块。
5总结与展望
本文着重介绍了基于NGB的业务支撑系统的功能需求和架构初步设计, 并阐述了在架构中使用的关键技术。为当前各大有线网络公司建设运维支撑系统提供一种思路。
随着技术的进步和企业内部分工细化, 基于NGB的运营支撑体系将由四部分组成:负责客户管理和计费的BSS系统;负责设备及资源管理的OSS (运维支撑系统) ;引进企业资源管理, 由ERP发展而来的MSS (管理支撑系统) ;以及为领导层提供数据分析和方向性指引的DSS (决策支撑系统) 。总之, 在广电运营支撑领域, 还有大量的科研任务待完成。对于具有信息系统集成和软件开发能力的IT企业, 这一领域具有广阔的市场空间。
参考文献
[1]戴卫平.下一代广播电视网 (NGB) 构建方式和发展规划[C].第十一届全国有线电视研讨会论文集.
[2]罗小布.浅谈NGB理论体系研究[J].中国数字电视2011年第7期.
[3]冀鸣.广电NGB运营支撑系统的构建和应用[C].2010国际传输与覆盖研讨会论文集.
[4]朱悦念.业务运营支撑系统在NGB战略下的发展思路[J].有线电视技术, 2011年03期.
[5]王璞, 刘海涛, 宫铭豪.基于交互系统BOSS的设计与实现[J].天津科技, 2011年03期.
[6]杜宇健, 张新伟.基于SOA的下一代电信业务运营支撑系统[J].中国科技论坛, 2010年11期.
微电网系统架构与求解方法 第11篇
关键词：微电网 系统 架构 方法
中图分类号：TM76 文献标识码：A 文章编号：1674-098X（2015）07（b）-0043-01
1 微型电网发展现况
微型电网整合分布式发电系统与储能组件于配电系统所形成之新的电力系统型态，可以并入大型电力系统运转或独里自主运转。目前，欧美与日本等先进国家，在微型电网的发展上皆属领先的地位，兹就其发展现况详述如下：
对于发展微型电网的概念与微型电网电源控制和建置示范系统之研究计划与论文，如微型电网系统架构概念[1]，在文献中，也对于实功率与虚功率之控制、电压调整策略、电力电子式之电源转换器接口设计、微型电源间功率分担、和应用静态开关（StaticSwitch）做运转模式切换等研究不管在理论上或实务上都有许多的贡献。
另外，由N.Hatziargyriou，H.Asano等人所发表之“MicroGrids”中[1]，将目前在欧美、日本和加拿大正进行的微型电网的研究、发展及示范系统做一综合探讨，在文中提到欧盟所资助的微型电网的两个主要研究计划。
第一个的计划（1998-2002）主题为“MicroGrids：LargeScaleIntegrationofMicro-GenerationtoLowVoltageGrids”，该计划已顺利完成相关研究工作，如ISET参与此研究所建构的微型电网实验室[1]。
第二个计划（2002-2006）主题为“MoreMicroGrids：AdvancedArchitecturesandControlConceptsforMoreMicrogrids”，该计划主要以实务性质为主，并分别在欧盟各示范点建置示范系统，的微型电网。
综观以上各国对微型电网的研究可使该文了解目前所要面对的问题与未来极需解决的问题及对环境所造成的影响。
2 系统架构
该文的研究乃以低压微型电网为主，首要的任务为系统架构的规划与设计，由于各国电力系统基础设施不尽相同，因此既有的配电系统型态再经整合分布式资源后自然形成各种不同型态的微型电网系统架构，综观相关文献所提的系统架构后决定以欧盟微型电网计划“ENK5-CT-2002-00610”设计的交流低压400 V微型电网作为模拟、分析的标的系统。
分布式资源并入微型电网前后的系统架构是由一台额定容量400 kVA、高压侧电压20 kV、低压侧电压0.4 kV、频率50 Hz的配电变压器，以及包括太阳能电池、燃料电池、蓄电池、风力发电机、微涡轮机等分散型资源所组成，因此非常适合本论文所欲研究探讨的议题「低压微型电网稳态运转研究」，是故，该文将以此系统为基础进行相关模拟与分析。
3 系统参数
本节主要的目的在介绍微型电网执行连续三相电力潮流程序时必须准备的相关资源与系统参数的设定，经整理后可得微型电网系统单线图，该系统包含高低压侧共有14个母线，线路长度最长处为345 m（自Bus1至Bus10），其中Bus1设定为摇摆母线（SwingBus），其余Bus8（住宅类）、Bus9（住宅类）、Bus10（工业类）、Bus12（商业类）及Bus13（住宅类）为负载母线；另外，分布式资源并入的母线分别为Bus14（30 kW蓄电池组储能系统）、Bus9（10 kW太阳能发电系统、10 kW风力发电系统）、Bus10（10 kW燃料电池发电系统）、Bus12（30 kW微涡轮机发电系统）及Bus13（3 kW太阳能发电系统）。
（1）配电变压器资料。
该系统的配电变压器相关参数资料，其额定容量为400 kVA、高低压侧额定电压分别为20 kV/0.4 kV、标么电抗及电阻值分别为0.04pu及0.01pu。
（2）负载资源。
各负载母线上的住宅类、工业类与商业类典型日负载曲线，各负载母线的尖峰（最大）负载量，将上述各类负载曲线及其尖峰负载量二者结合，即可绘制出各负载母线的实功及虚功日负载曲线[2]。
（3）线路阻抗资料。
导线规格及其对应的单位长度阻抗资源，所列的阻抗奥姆值将在系统统一基准值条件下标么化。
4 组件数学模型
举凡组成微型电网的分布式资源、导线、配电变压器、电电容器与负载等设施均为执行电力潮流所需的电路元件，上述组件在电力潮流分析过程中皆必须以适合的数学模型表示方可反应该组件的实际物理特性。兹就相关组件模型分述如下：
（1）分布式资源模型。
该文所探讨的低压微型电网中共整合微型发电系统及储能系统二大类，其中蓄电池组储能系统仅作为系统转态时支撑系统电压的用，亦即系统由并网运转状态转。为维持瞬时电压稳定的功能，因此，在稳态运转分析时不纳入电力调度输出功率的考量中，是故，执行电力潮流分析时仅就微型发电系统部分进行电力调度。一般而言，此一微型发电系统可依其特性与控制方式将其设定为输出固定功率因数与功率，因此，部分文献中将其视为定实功率-虚功率模型和定实功率-电压模型，就分析技术层面而言，各有其优缺点，本论文将其视为定实功率-虚功率模型[3]。
（2）导线模型。
该文的导线模型皆以型等效电力模型表示[3]。其中，对串联阻抗而言，原始三相四线式线路模型所示，将原始串联阻抗矩阵以克隆降阶法降阶，即可求得隐含中性线或接地线效应的三相线路等效模型，其原始导纳矩阵，降阶后的三相线路等效模型的母线组件关联矩阵，并利用推导公式[3]求出将三相线路解耦合后，即可得到的三相线路解耦合等效模型.
参考文献
[1]黄莉，卫志农，韦延方，等.智能用电互动体系和运营模式研究[J].电网技术，2013（8）：2230-2237.
[2]易锦，罗峋，凹建勋，等.基于马尔科夫链的软件故障分类预测模型[J]. 中国科学院大学学报，2013（4）：562-567.
业务系统架构 第12篇
1. 接入层设计。
针对郑州电视台新大楼各楼层信息点分布的特点, 在进行网络拓扑架构时, 将网络的接入层设备与集散层设备进行了统一的管理, 使得网络拓扑结构更加紧凑。在与核心网互联的上联链路方面, 采用了双链路上联的物理冗余设计方案。在链路协议配置方面, 采用了MEC多机箱以太网通道技术方案。经测试该技术是保证链路故障自愈能力和链路使用效率的关键技术。多机箱Ether Channel (MEC) 是一种L2多路径技术。这类Ether Channel形式允许相连节点在2个物理Cisco Catalyst 6500系列交换机之间连接Ether Channel, 从而创建简单的无环路L2拓扑结构。在VSS拓扑结构中使用MEC, 能使所有的链路得到激活, 并同时在不采用生成树协议的情况下, 提供高度可用的拓扑结构。
2. 集散层设计。
在传统有物理冗余的上联链路网络结构中, 根据上联链路接口工作网络层次的不同, 我们通常采用STP、PVST、MSTP和动态路由协议进行链路的故障自愈和负载分担工作。在采用这种网络协议的系统架构设计中, 链路的使用效率一般只有50%, 2条物理链路中只有1条是活跃的链路, 另外1条链路处于热备状态。就链路故障的切换时延而言, 当链路处于L2状态时, 采用STP技术可使链路的收敛时延控制在30s左右, 采用增强型的STP技术如RSTP MSTP等, 其时延也能控制在几秒以内。当链路处于L3状态时采用动态路由协议, 各种动态路由协议的收敛时间不同, 但是即便采用了链路状态型的路由协议, 其路由收敛时间也是秒单位级的, 同样会造成设备CPU瞬时高利用率的情况。
3. 核心层设计。
郑州电视台核心层设备采用了2台Cisco公司的Cisco Catalyst 6500系列交换机, 通过协议配置组成了一套VSS1440虚拟交换系统。VSS1440系统由2台采用Virtual Switching Supervisor 720-10GE的Cisco Catalyst 6500系列交换机构成。在一个VSS系统中, 可同时激活2个机箱的数据平面和交换阵列, 每个机箱各支持720Gbps的管理引擎, 每个VSS共有1 400Gbps的交换容量。其中只有1个虚拟交换机成员有激活的控制平面。这2个机箱通过机箱间状态切换 (SSO) 机制和不间断转发 (NSF) 机制保持同步, 即使某个管理引擎或机箱发生了故障, 也能提供不间断的通信。核心设备由于在逻辑上是1台独立的设备, 那么这时过去很多在单一设备上用于端口冗余和负载均衡的技术就可以在不同的物理交换机之间得以实施。在这里, 虚拟交换系统的L3端口就是1个逻辑上的以太网通道端口组接口。对于整个虚拟交换系统而言, 这就是一个独立的端口。因此, 不存在“端口间”的热备问题。其逻辑端口的健壮性和利用率问题是由下层的以太网通道决定的。因为, 以太网通道技术的设计初衷就是为了在2层链路上实现多端口的聚合与冗余, 所以其在流量均衡和故障切换方面拥有更高的效率。
二、网络安全防御设计
1. 在出口处。
郑州电视台依据业务子网对外提供服务的开放度区别, 将不同的业务子网放置在ASA防火墙的不同安全级别接口下, 通过ASA防火墙的安全算法以及协议端口的配置, 大大降低了外来非法链接的入侵能力。另外, 即使某个业务子网内部出现了安全问题, 由于采用了安全级别的层次化设计, 也使得其他业务子网受到的安全影响降到最低程度。
2. 在网络核心处。
由于内部办公终端易受病毒的侵扰, 因此郑州电视台在核心与服务器群之间设计了高安全区防火墙, 通过该防火墙的ASA算法, 在很大程度上保障了内部服务器的安全。另外, 因为内部网络的带宽很高, 数据交换量也很大, 所以在设计上要把内网高安全区防火墙独立出来, 而没有采用在出口防火墙上加载DMZ区的方式。这样做既保证了内部网络的安全层次设计, 又降低了出口防火墙的CPU利用率。
三、网络流量管理设计
1. 针对内部网络的流量管理设计。
深信服M5400-AC支持基于应用层的流量识别, 可以针对办公终端的应用程序定制带宽。对于办公终端应用程序的带宽占用情况而言, P2P下载程序是占用带宽最为严重的一个软件。为防止大量P2P下载进程耗尽Internet的出口带宽。郑州电视台通过在深信服M5400上配置不同的流量通道, 将绝大多数终端的P2P下载速度限制到了总出口带宽的2%, 而对于一些需要大量下载广播级视音频素材的办公终端则单独配置流量通道, 从而保证了重要业务的P2P下载有充足的带宽可以使用。
2. 针对对外提供服务的各个业务子网流量管理设计。