分布式平台（共8篇）
分布式平台 篇1
1 引言
中国制造业历经多年的信息化建设,国内的工业企业在各类信息系统中存储了大量数据,这些系统包括OA、HR、CRM、MES等。这些系统帮助企业优化资源配置、减化业务流程,极大地提升了企业的经营管理水平。伴随着数据的快速增长及新需求的不断涌现,原有系统越来越难以满足要求,如何将分散在各个系统中的数据整合起来,充分发挥数据对生产的指导作用,提升效率,优化生产流程,优化经营效率,己成为中国制造业的新挑战。
随着大数据技术在互联网行业中蓬勃发展,涌现了大量大数据处理框架,如Hadoop、Spark、Storm等,如何选择并整合各大数据处理框架,在其上开发、运行、维护处理海量数据的应用程序,成为制造业企业IT部门新的挑战和难题。分布式实时分析计算平台就是为了解决这一问题,帮助企业技术人员可以轻松架构,搭建适用于自身业务形态的分布式实时计算应用。
2 关键技术
本文提到的分布式实时计算平台,选择了多个优秀的开源构件作为平台的基础构件。整个技术平台自下而上主要包括:分布式文件系统层、分布式数据库、分布式数据分析、数据展示等基础功能模块。针对各个基础功能模块的功能要求及特点,筛选优秀开源构件,主要选择了以下开源构件。
2.1 Hadoop
Hadoop实现了一个分布式文件系统,为海量数据提供分布式存储。在此之上,Hadoop提供了Map Reduce分布式计算框架。该框架通过Map和Reduce两个步骤并行处理大规模的数据集。首先,Map会对由很多独立元素组成的逻辑列表中的每个元素执行指定的操作,原始表不会被更改,其会创建多个新的列表来保存Map的处理结果,这也意味着Map过程会产生大量的新数据,有大量的写磁盘操作。Map工作完成之后,会对新生成的多个列表进行shuffle和排序,之后完成Reduce操作。Map Reduce框架的最大不足在于,对于需多次迭代的复杂计算,会产生大量的中间结果,需频繁读写HDFS,无法满足实时应用的需求。
2.2 Hbase
Hbase是运行在Hadoop上的分布式、面向列的No Sql数据库,它是一个分布式可扩展的大数据仓库。它提供高可靠、高性能、列存储、可伸缩、实时读写的数据库系统,主要用来存储非结构化和半结构化的松散数据。它很好地融合了key/value存储模式带来的实时查询能力,以及通过Map Reduce进行离线处理或批处理能力。
2.3 Spark
Spark是开源的类Hadoop Map Reduce的通用并行框架,拥有Hadoop Map Reduce所具有的优点,但与Map Reduce不同的是,Job中间输出结果可以保存在内存中,从而不再需要读写HDFS,因此Spark能更好地适用于需要多次迭代Map Reduce的算法。相比Map Reduce,Spark在做重复计算时可以重复使用相关的缓存数据,无需不断地读写磁盘。
2.4 ANTLR
ANTLR是一款强大的语言识别工具,提供框架通过语法描述来构造语言识别器、编绎器和解释器。通过解析用户自定义的上下文无关描述语言,自动生成词法分析器、语法分析器和树分析器。
3 分布式工业数据实时分析计算平台
3.1 基本架构
本文中的分布式工业数据实时分析计算平台底层基于Hadoop、Hbase、Spark等构件。Hadoop为平台提供了分布式存储HDFS,在此之上是Hbase分布式No Sql数据库,由它组织和管理用户数据表。选用分布式实时计算框架Spark作为计算平台的基础计算框架。由yarn负责整个平台的系统资源调配。
计算平台主要包括Job Server、FCS(Function Compulation Service)、RESTful API等模块。Job Server负责与yarn协调申请资源,为特定应用启动单独的计算服务,管理各计算服务的计算任务。Job Server对外提供RESTful接口。FCS提供UI,供用户编排计算任务,并根据用户计划执行计算任务。平台架构如图1所示。
3.2 Job Server
Job Server主要由Context Manager、Job Manager、RDD Manager等子功能模块组成,对外提供RESTful API,用户可通过浏览器查看Job信息,如图2所示。
●Context Manager:为客户端应用管理应用上下文,每个应用可根据需求启动一个或多个Application Context,不同的Application Context均是独立的yarn应用,相互之间资源隔离。Application Context可分为长驻Context和一次执行Context。
●Job Manager:管理Application Context中的所有Job,包括创建Job、执行Job、保存Job处理结果,异步Job模式中,客户端可根据Job ID获取处理结果。
●RDD Manager:负责管理计算中生成的Spark RDD、客户端申请的有名RDD以及RDD缓存,方便客户端在Job之间共享RDD,以提升计算效率。
3.3 表达式计算引擎
分布式分析计算平台针对工业数据,抽取定义实现了适合工业计算的表达式计算引擎,主要有行计算和列计算两种模式。行计算对Hbase表中的记录行中各属性值执行表达式计算;列计算是纵向的,对表中某一列执行统计计算。两者间可嵌套执行。
海量数据计算中,同一表达式可能执行数以亿计的计算,如图3中所示,Expression parser(表达式解析器)对表达式进行词法以分析,并解析表达式,Expression compiler(表达式编绎器)将解析后的表达式编绎为可以直接执行的算子,RDD执行并行计算时,对每行数据提取算子中所需的列值,传输给表达式算子,多个算子运行结束后,由Result collector(计算结果收集器)收集、合并运算结果。RDD计算过程中无需重新解析表达式,极大地节约了计算时间,提升了计算效率。
3.4 FCS
FCS提供Web UI供客户端编排计算任务,可指定计算任务的执行模式,周期执行或符合条件的特定时间执行。可自定义计算表达式,并通过FCS提交计算任务至Job Server。
3.5 分布式工业数据实时分析计算平台与传统实时数据库对比
分布式工业数据实时分析计算平台与传统实时数据库对比如表1所示。由于传统实时数据库一般单机或多机冗余热备使用,对服务器的硬件要求高,且服务器数量有限,因此,存储容量最大为TB级。与之相比,分布式工业数据实时分析计算平台底层基于Hadoop,普通的服务器即可,群集支持数以千计的服务器,支持超大数据集,能存储PB级的数据,且在群集中维护多个工作数据副本,确保能够针对失败节点重新分布处理。从性能角度看,传统实时数据库由于架构简单,数据多缓存于共享内存,速度明显快于分布式工业数据实时分析计算平台,读写性能可达到十毫秒级。分布式工业数据实时分析计算平台因数据分布存取,存储最快可达到百毫秒级。可扩展性方面,分布式工业数据实时分析计算平台明显优于传统实时数据库,在可用的计算机集簇间分配数据并完成计算任务,可以方便地扩展到数以千计的节点中。而传统实时数据库可添加新节点,但节点数目到达一定规模后,对性能无提升。
4 结语
分布式工业数据实时分析计算平台为企业IT技术人员提供了一个支持分布式实时计算的开发平台,使得企业IT技术人员无需关心计算平台的底层架构,无需编写代码,仅通过FCS编排计算任务,即可快速完成业务计算的编写,进而对海量数据进行业务分析和处理。
参考文献
[1]朱江.基于云计算的数据挖掘平台架构及其关键技术研究[J].计算机光盘软件与应用,2015(19):53-56.
[2]梁九妹,卢忠田.一种基于云计算技术的实时业务服务模型[J].计算机与现代化,2013(07):160-163.
[3]王水萍,王方.一种基于云计算数据挖掘平台架构的设计与实现[J].信息安全与技术,2014(08):64-66.
[4]Michael Armbrust,Amando Fox,Rean Griffth,et al.Above the Clouds:A Berkeley View of Cloud Computing[R/OL].UC Berkeley Technical Report,UCB/EECS-2009-28,2009.http://www.eecs.berkeley.edu/Pubs/Tech Rpts/2009/EECS-2009-28.html.
分布式平台 篇2
关键词：大型网络游戏；平台架构；集群；多层
中图分类号：TP393文献标识码：A文章编号：1009-3044(2007)12-21579-02
A Four-tier Large Network Game Platform Architecture Based On Distributed Cluster Technology
FU Dong-lai,KUANG Hua
(Department of Computer Science & Technology, North University of China,TaiYuan , 030051)
Abstract:there are two factors which determine the success or failure of the game. One is Interesting game itself .Another is a stable, efficient network game platform structure Based on the analysis of large-scale online games network of the actual operating environment, this paper proposed a technology-based clustering of large multi-tier network game platform architecture and introduced the layers of detail design and server deployment scenarios. Finally this paper give a 20,000 people simultaneously online server deployment program.
Key words:Large network game;platform structure;clustering;multi-tier
1 课题研究背景
网络游戏就是以互联网为媒介，可以多人同时参与的电脑游戏，人们通过互动达到交流、娱乐和休闲的目的。当前，大型多人在线角色扮演类游戏是最受玩家喜欢游戏类型，这种游戏构筑了一个有基本健全的社会体制和经济系统的虚拟世界，玩家在游戏虚拟世界中扮演特定角色，通过自己的游戏技能及其它各方面投入实现自己所扮演的角色在游戏虚拟社会中的生存和成长并参与游戏虚拟世界的人际沟通及社会活动等。市场上知名的《魔兽世界》、《传奇》系列等游戏都属于这一类型。近几年，随着社会生活节奏的不断加快，越来越多的人选择通过“网游”的形式缓解压力。上海征途网络科技有限公司在2006年10月28日宣布，旗下大型角色扮演类网络游戏《征途》最高同时在线人数达到63.42万人。于是，面对如此庞大且仍在飞速增长的网络用户群，如何架构能适应海量用户访问的游戏平台，就必然成为网络游戏开发商的重点研究的对象。本文就是研究这种大型多人在线角色扮演类游戏平台架构设计的核心技术。
2 平台整体架构解决方案
2.1大型游戏的实际运行环境
在大型游戏中，实际需要处理的玩家数量往往过万甚至几十万，一台普通的服务器是无法完成所要完成的工作。因此，通常是要由一组多台服务器共同完成一个完整游戲世界的功能，即“战区”的概念。一个战区实际上就是由多台服务器构成的一个集群系统，每个玩家所处的游戏世界就是一个战区。由于一个战区所能容纳的玩家数量是有限的，因此，针对海量级的玩家，我们可以把玩家分散到不同的战区中去，以满足玩家数量的增长。同时，为使玩家体验到更快的响应速度，对服务提供商来说节约网络带宽，降低成本。服务器群必须分布式部署。大量的服务器群构成一个完整庞大的分布、协作的游戏系统，这样一个复杂的系统必然会涉及到服务器间复杂的数据通信与管理。因此，构架一个安全、稳定、高效的游戏平台有着非常重要的意义。
2.2平台整体架构方案描述
平台总体上采用基于集群技术的分布式四层网络游戏平台架构，具体描述如下：
(1)表示层：用户接口部分，担负用户与应用间的对话功能。检查用户从键盘或其它终端设备上输入的数据，接收应用服务输出的数据。用户输入的数据通过通讯平台传入功能层。
(2)通信层：负责游戏服务器和客户端之间数据交换的服务器，管理所有的玩家和游戏服务器连接，并且负责客户端的登陆登出，记费校验等工作。
(3)功能层：实现网络游戏世界中的所有业务处理逻辑，而处理所需的数据是从表示层或数据层取得的。在这一层的设计中，我们尽可能保持表示层和功能层之间的数据交换的简洁，避免进行一次业务处理，在表示层和功能层进行多次数据交换。在功能层中包含有确认用户对应用和数据库存取权限的功能，以及记录系统处理日志的功能。该层可分为数据库和游戏服务模块。游戏服务模块设计为一个个单独的子系统，即游戏的战斗系统、任务系统、寻路系统等等，用来处理游戏世界中的业务。数据库服务模块是网络游戏连接数据库读取玩家信息和战区信息、存取玩家档案的接口，并且肩负着监视战区运行状态的任务，提供与数据库连接管理、数据读写等功能。游戏服务模块实现具体的应用逻辑。平台的通信服务器收到玩家的操作请求后，转换成对数据库或游戏服务模块的请求，调用相应的服务模块处理请求并将结果返回给通信服务器。
(4)数据层：负责存放并处理所有玩家资料及其相应的数据，采用通用的大型关系数据库系统。从处理能力和容错的角度考虑，硬件应该采用高可用性系统。
2.3平台功能结构划分
平台功能从网络结构的角度可以分为三个部分：系统服务模块、受控安全模块和启动平台模块。系统服务模块包括数据库、数据库接口、游戏场景服务器、网关服务器、列表服务器、入口服务器、角色存盘接口及存盘服务器、第三方合作接口和游戏计费系统；受控安全模块包括数据库接口服务监控端、存盘服务器信息查询工具、游戏管理员工具、计费系统监控、平台配置系统和WEB服务（帐户站、玩家论坛和游戏官方网站）；启动平台模块包括平台初始启动程序、列表程序、游戏客户端和下载工具。
2.4数据存储层设计
数据库设计是很大程度上决定应用程序的质量和成功与否，并关系着整个平台的功能和效率。平台根据网络游戏的逻辑功能要求，可将数据库系统分为游戏数据库、用户数据库、游戏日志数据库三个数据库。其中游戏数据库主要处理游戏业务逻辑，存储游戏内容相关的数据，像角色信息、战区配置信息等，同时也处理与角色相关的计费问题；游戏日志数据库主要处理日志数据和外挂数据，存储外挂封停记录、日志数据，像外挂封停名单、封停日志等；用户数据库主要处理玩家帐号信息和费用管理。
3 具体模块设计
3.3系统服务模块
系统服务模块就是一个服务器集群，在网络游戏中称为战区，服务器群内的服务器按照功能可划分为数据库、网关服务器、游戏服务器、角色存盘接口及存盘服务器、列表服务器、入口服务器等。每组战区服务器根据战区人数的多少可以灵活的改变战区的逻辑结构。系统服务模块各服务器功能描述如下：
(1)数据库：为战区提供数据存储空间和数据操作的特定环境，是其他一切服务的基础。
(2)数据库接口：是战区连接数据库读取玩家信息和战区信息的接口，并负责监视战区运行状态的任务。
(3)网关服务器：是整个游戏的网关，玩家和游戏世界的消息通过网关服务器传递，并且由其判断消息的正确性和过滤非法消息，负责客户端的登陆登出，计费校验等工作。该服务器处理的消息量很大。
(4)游戏服务器：负责打开游戏场景，并处理玩家在游戏过程中的操作。通常该服务器的实际承受人数在千人左右。
(5)角色存盘接口：根据游戏服务器的需求存取玩家档案。目前角色存盘接口服务器常用于存储帮派信息、玩家在游戏中的活动记录等。这是整个游戏世界的核心部分，其数据需要重点保护。
(6)入口服务器：负责引导寻找列表服务器，具有分压功能，能自动寻找较闲置的列表服务器，分担玩家请求战区列表的压力。
(7)列表服务器：游戏世界的入口，它的作用是从数据库中读取列表信息，显示战区列表。维护人员可通过开关列表服务器或更改数据库中的开关来控制玩家登陆游戏。
3.4受控安全模块
网络游戏平台的特点有两多，一是服务器多，并且分布在全国各地；二是服务多，有数据库服务、web服务、平台的DBI、Gate服务等。平台管理员要管理这些服务器主机和起停主机上的服务等一些繁琐的工作，当服务器达到一定数量的时候，这些工作会变得庞大而且容易出错。并且对主机的资源状态、性能和服务的负载等等情况都没有很好的办法获得。所以在这样的情况下，就需要监控管理界面来完成实时监控和自动化操作。
同时网络游戏平台需要给玩家提供一个注册、交流、帐户操作的地方，给第三方提供开展业务合作的接口。这些需求通过WEB来实现。受控安全模块就包含这些功能，主要分为WEB应用、管理和监控这两个部分，此处不再详细描述。
3.5启动平台模块
游戏启动平台是指启动游戏的一些客户端和服务器程序其中包括启动界面、显示列表服务的界面、升级程序、升级提示程序、列表服务器、入口服务器。其主要流程：用户通过启动界面访问入口服务器，由入口服务器通知界面应该连接的列表服务器；确定列表服务器后，通过列表服务器列取战区列表；选择战区后，界面可获得其ip和端口，并进行版本升级控制，并引导玩家登录；登录成功后界面将启动游戏客户端；游戏客户端根据参数连接网关服务器并进入游戏世界开始游戏。
3.6容灾与安全方案
作为大型网络在线系统必须考虑容灾及安全方案。平台中采用的容灾方案的基本思想是：生产环境的两台服务器，组成一个本地的双机热备环境，热备份实现交易日志双机备份。当本地的一台服务器发生故障时，应用会自动切换到本地另外一台服务器上。在备份地点，由一台服务器作为备份服务器。当生产环境中的两台服务器都不能工作时，灾备中心的服务器自动启动应用，恢复正常的生产环境。
本平台从以下几个方面保证平台的安全：统一管理登陆服务器的用户，记录用户登陆服务器的详细信息，将所有服务器设置安全策略，限制只有VPN服务器的IP地址才可以登陆。用来阻止除VPN服务器以外的计算机登录平台；对非法外挂、帐号盗用提供投诉管理机制；对数据核查，通过全面完整的日志纪录，平台系统可以对业务、操作等进行核查工作，及时发现管理问题，保证系统安全；在各个环节的任何两点之间都采用加密算法保护数据安全；对于像通讯平台这种接入的关键节点，对客户端连接进行安全性检查，验证身份的有效合法性；在数据的存储过程中，对于高安全性数据，采用加密存储的方式进行存储，以最大程度地保证客户交易的安全性和員工操作的安全性；内置的双机热备份功能和建立专门的灾备中心，保证系统可靠运行；应用服务器、通讯服务器、数据服务器以集群方式运行，保证系统不应单点故障失效；将对用户、员工、游戏管理员等所有对系统进行操作的权限控制集中到数据中心；实时监控网关服务器、数据库接口、异常事件等等的，及时发现处理机和应用服务器故障，减少停机时间，防止业务管理问题。
4 方案的特色
稳定、可靠：平台设计采用分组的方式，用一台角色存盘接口服务器、二台游戏服务器、一台网关服务器组成一个网络组，用很多不同的小组分散开满足前端的游戏请求，对集中计算的一些工作，可以被分配到后端不同的小组中，这些小组共同组成一个功能强大的系统平台。而在每一个小组中，不同的服务器各司其职，前端的网关认证服务器负责接入、经过负载均衡算法后把用户引入到合适的游戏服务器，最大限度地发挥设备的功能，满足在线用户的游戏需求。
可扩展性、可维护性：由于玩家数量的多少关系到一款网络游戏的成败，因此平台就要有可扩展的机制来满足越来越多的在线人数。平台通过采用同时开放多个战区或者改变战区的逻辑结构以提高承载在线人数。
高安全、易管理：系统设置为内、外网。外网主要实现与网络上用户的互连，提供一个基础的认证、游戏平台。内网则主要是对系统文件的管理、游戏内容管理、用户信息管理、系统的维护，甚至是收费方面的管理和内部的信息化管理、自动化管理等。
5 结论与讨论
基于集群技术的分布式四层网络游戏平台体系结构属于松耦合集群系统，不需要在集群中部署特殊的中间件层或者OS扩展，对服务器结点OS的兼容性比较好。对于其内部结点而言，基本上可以兼容多数的IP应用，不需要做复杂的移植和安装工作，该方案具有很好的稳定性、可靠性及可扩展性。经测试，10台网关服务器＋20台游戏服务器＋10台角色存盘服务器＋2台数据库接口服务器＋存盘节点服务器2台。最高可支持20000人同时在线。
参考文献：
[1]陈志刚,李登,曾志文.分布式系统中动态负载均衡实现模型[j].中南工业大学学报,2001,32(6):635-639.
[2]王晓川,叶超群,金士尧. 一种基于分布式凋度机制的集群体系结构[J].计算机工程,2002,28(8):232-234.
[3]赵水宁, 邵军力. 多web服务器负载均衡技术的研究[J].电信科学,2001,(7):6-8.
[4]章文嵩.Linux服务器集群系统(四)[DB/OL]. http://www-900.ibm.cora/developerWorks/cn/linux/cluster/lvs/part4/in-dex.Shtml.2002-05-10/2003-02-18.
[5]李东.IBM金融行业灾难恢复解决方案.软件世界,2001(12).
[6]李虎雄,徐贯东,张燕姑. 网络游戏数据平台数据通讯的实现方案.计算机工程与设计,2005.11.
[7]梁健,董德存.基于IMS的游戏平台构架研究.广东通信技术,2005.7.
[8]荣钦科技.著.游戏设计概论.北京科海电子出版社,2003.6.
分布式平台 篇3
随着移动互联网时代的高速发展, 海量数据的存储及处理成为当下的热门议题。分布式计算这个概念的提出, 为海量数据的处理提供了可能, 而这种全新计算框架最优秀的代表是Hadoop。Hadoop可以将海量数据存储在普通PC集群中, 利用分布式计算对海量数据做处理, 极大降低了分布式系统的成本。
二、分布式计算平台Hadoop概述
作为一个开源的分布式计算平台, Hadoop以分布式文件系统 (HDFS) 和Map Reduce计算框架为两大核心组件, 实现了系统底层透明的分布式基础架构, 具有良好的扩展性和容错性。HDFS为分布式任务提供了海量数据的存储支持, Map Reduce在集群上实现了分布式计算和任务处理, 在HDFS基础上实现了分发、跟踪和执行任务等操作, 二者相互支持, 构成了Hadoop集群的核心内容。由于对硬件的要求相对较低, Hadoop框架可以运行在廉价的PC上;HDFS的备份恢复机制协同Map Reduce的监控任务功能确保了分布式系统的可靠性;HDFS数据交互的高效实现以及Map Reduce分任务处理模式, 为海量信息的高效处理提供了有利条件。谷歌最早是为了海量数据分析提出的Map Reduce, Hadoop则最适合计算海量离线数据, 通过将数据分割于多个节点, 然后将每个节点计算的结果合并输出, 同时上一阶段的输出可以作为下一阶段计算的输入, 形成树型的计算图, 同时串、并行结合利于在分布式集群下更高效的处理数据。虽然Hadoop具有先天的优势, 但在处理小文件、实时计算等方面仍有缺陷。
三、HDFS及Map Reduce的技术分析
Map Reduce和HDFS是组成分布式计算框架Hadoop的两大核心组件。按照时间顺序, Map Reduce可以分为输入分片 (input split) 、map、combiner、shuffle和reduce五个阶段。在执行map任务之前, Map Reduce根据输入文件做分片处理, 一个分片对应一个map任务;map函数都是在本地的数据节点上操作的;combiner是一个可选阶段, 也是在本地的数据节点上执行的, 类似于reduce过程;将map的输出作为reduce的输入过程就是shuffle;reduce就是将最终计算的结果做存储。由于map和reduce的过程都需要大量的I/O操作, 使得Hadoop更适合做离线计算。
HDFS (Hadoop Distributed File System) 是以谷歌发表的有关GFS (Google File System) 论文翻版的, 它是Hadoop底层的文件存储系统, 可以支持超大文件的存储。HDFS具有高容错机制, 可以设置副本的保存数量, 在某个数据节点出现问题的时候, 可以调用其它数据节点上保存的数据块;可以部署在海量廉价的机器上, 可以大大地降低企业成本;可以处理海量数据。HDFS采用master/slave的架构模式, 主要由namenode和datanode组成。Namenode是master节点, 具有热备份功能, 负责集群的客户端的读写请求及数据映射, 即保存datanode存储的数据块的信息, 管理HDFS的副本存储和名称空间。Datanode是slave节点, 负责存储客户端发来的数据块及对数据块执行读写操作。写1T文件, 需要3T存储空间和3T流量带宽, 执行读、写过程中, 为确定数据节点活着, Master和Slave通过心跳机制保存通信。如果发现某个datanode挂掉了, 就将写入该datanode上的数据, 写入其他datanode;读取时, 相应的读其它datanode。一个datanode挂掉, 还有其他备份datanode;某一个机架断电, 其它机架上, 也有备份。
四、总结
本文介绍了新一代分布式计算平台Hadoop的框架原理, 给出了HDFS的文件存储策略及Map Reduce的计算过程, 使海量数据的存储和计算成为了可能, 同时为以后将Hadoop平台运用到各种场景打下了基础。
参考文献
[1]朱珠.基于Hadoop的海量数据处理模型研究和应用[D].北京邮电大学, 2008.
分布式平台 篇4
本文的安全管理平台是基于信息安全的角度, 充分考虑到业务支撑系统不同主机、网络设备、应用、数据库等信息安全资产, 对网内的信息安全资产进行分级, 并实现对不同安全级别信息资产的安全告警监控。平台建成后, 可实现对业务支撑系统的设备安全监控、安全预警、以及整体系统安全状况评估, 极大地提升了业务支撑系统的安全性。
1 总体设计
1.1 系统的设计目标
整个系统采用J2EE的架构完成网络安全管理平台的研制和开发工作, 核心子系统采用UML进行建模, 实现模块化设计思想, 各个逻辑功能模块均能动态加载和独立运行, 满足未来扩展的需求。网络安全管理平台用于管理来自多种网络安全设备的安全事件, 基本的原理是对从网络安全设备上采集来的原始网络安全事件进行分类、关联、风险评估等分析处理, 通过该平台对运行在各种操作系统和硬件平台上的网络安全产品实施统一的配置、统一的策略、统一的日志和统一的报告, 以便用户进行相关的响应处理, 过程如图1所示:
1.2 系统的设计原则
系统采用目前业界流行的B/S结构, 分为客户层、控制层、业务处理层、数据访问层四层。系统主要基于Struts框架, 结合J2EE设计, 采用Oracle数据库存储数据。系统从可扩展性、高性能、系统的松耦合性、安全性等角度进行了充分的考虑。遵循的主要原则包括:系统采用面向对象设计思想, 系统遵循J2EE 2.0标准系统, 遵循SUN Java编程规范。
1.3 系统的部署方案
为了满足本项目的需求, 在业务支撑系统湖东机房局域网部署SOC管理平台, 其中包含HA工作模式的台SOC应用服务器与2台SOC数据库服务器、1台WEB服务器与1套2TB带库系统, 三台安全信息收集分析服务器, 分别部署在湖东、金山与乌山三地机房中, SOC应用服务器通过网络方式从三地安全信息收集分析服务器中获取数据。同时异常流量分析采集服务器部署在湖东, 通过NETFLOW与SNMP方式进行全网网络设备的智能关联分析, 将分析之后的数据统计提交到SOC应用服务器进行集中处理, 同时保存到SOC数据库服务器中。整体部署如图2所示。
2 网络架构设计
参照上述的部署方案, 我们可以看到架构设计从总体上可分为数据采集层、应用服务层、应用展现层 (终端显示) 3个逻辑层次, 如图3所示。
(1) 数据采集层:
根据要求采集各种安全信息。负责从已经汇总了福建移动业务支撑系统网络上的安全信息的网管和服务器上收集汇总后的安全信息。
(2) 数据处理层/应用服务层:
负责对采集到的原始数据进行聚并处理, 完成数据的智能关联分析, 为应用展示层提供数据支持。
(3) 应用展现层:
实现安全运维管理平台的统一界面展示。通过统一的图形化管理界面, 安全运维管理平台实现了安全监控、维护、管理、展示的全部功能。
2.1 数据采集层
数据采集层负责根据要求采集各种安全信息。针对福建移动业务支撑系统网络, 从福建移动业务支撑系统各个局域网上的网络设备、安全设备、服务器系统和主机系统收集汇总安全信息。
数据采集是整个安全管理的核心, 数据采集的关键是:首先要支持丰富的采集对象, 保证即插即用;其次是采用开放的架构, 方便体现环境和需求的特殊性。
本系统数据采集主要包括安全事件数据采集, 安全漏洞数据采集, 安全配置采集。其中实时采集安全事件和告警, 便于实时告警、分析和响应。采集安全漏洞数据用于主动防御和风险管理。收集各个安全产品、路由器的安全配置, 用于审计。必要时可以实现配置的一致性。
2.2 应用服务层
应用服务层负责对采集到的原始数据进行分析处理。将从不同来源采集到的数据进行关联分析, 为应用展示层提供数据支持。
应用服务层在应用展示层和数据采集层之间起到承上启下的作用, 完成了除收集安全信息以外剩余的所有功能。如:资产管理、安全信息监控、脆弱性管理、安全事件处理、安全知识管理、安全策略管理、安全状况评估、安全预警等。
2.3 应用展现层
应用展现层实现了安全运维管理平台的统一界面展示。通过应用展现层, 能够查看资产分布状态、关注区域的安全状况、安全事件发生的趋势、各类资产的脆弱性状况等;通过应用展现层, 完成对资产管理、安全信息监控、脆弱性管理、安全事件处理、安全知识管理、安全策略管理、安全状况评估、安全预警功能模块的配置;通过应用展现层, 完成报表的生成、输出 (保存和打印) 等。
2.4 网络架构设计的特点
数据采集采用了开放的架构设计, 将安全设备被管理的能力视为设备对外提供的一类服务——管理服务。SOC安全运维平台的主要功能就是对安全设备进行统一监管, 也就是集中使用这些服务。采用这样的架构设计系统很好的反映了现实的问题, 体现了SOC安全运维平台的实质。
通过对服务的集中管理实现对设备的统一管理, 由于安全设备的多样性和异构性是统一管理的难题, 应用服务层实现了在各种异构的安全设备和SOC安全运维平台之间搭建的一个统一的中间层——服务。服务屏蔽了各种安全设备, 在SOC安全运维平台看来, 管理活动实际上是以服务请求者的身份使用一个个的管理服务, 而无需考虑服务建立在何种硬件或操作系统上以及服务涉及的接口。
3 软件体系结构的设计
在网络架构设计的基础上, 本课题提出了如下的概念模型。整个SOC系统分为SOC界面、应用服务器、采集层和数据库服务器4个部分。此概念模型的设计理念为:鉴于网络安全管理平台在体系结构和业务功能方面都比较复杂, 本设计对系统分层, 各个层次相对独立和分离, 其中应用服务器的安全事件处理模块以及采集层的各个模块可以根据用户的需求进行平行扩展, 在采集层还可以根据业务的发展和新的要求进行功能的扩展, 并通过统一消息系统完成数据的标准化。本设计降低了应用服务器和SOC界面之间的相关性, 降低了应用服务器各个模块之间的耦合度, 便于积木式构建系统。由于这两层软件独立开发, 通过开放式接口连接, 降低了开发的难度, 提高了系统的稳定性和可维护性, 方便系统扩容、新业务开发以及为其它系统的用户提供开放式接口连接。
3.1 SOC界面
在建移动业务支撑系统安全管理平台SOC的设计中, 主要采用了面向对象的设计方法, 使用了J2EE技术, 进行基于J2EE的多层B/S结构设计。
SOC界面采用浏览器/服务器模式软件体系结构。这种三层B/S (浏览器/服务器) 体系结构是把传统的两层C/S结构的业务逻辑从客户机的任务中分离出来, 用户通过浏览器向分布在网络上的许多服务器发出请求, 服务器对浏览器的请求进行处理, 将用户所需信息返回浏览器, 而其余如数据请求、加工、结果返回以及动态网页生成、对数据库的访问和应用程序的执行等工作全部由中间层完成。B/S结构减轻了客户机的负载, 降低了客户机的性能要求, 而且使系统的管理更为集中, 成为目前业务系统采用的主流结构。
3.2 应用服务层
应用服务层主要是完成对采集来的各类资源数据的处理, 形成对风险、策略、知识等的综合管理, 同时按照安全问题的处理流程、依照相关的规则和安全风险管理模型来实现对防火墙、入侵检测、防病毒、主机、网络等构成的安全防护体系的统一监控和管理, 该层在系统实现时主要依靠基于消息通信的后台程序来支撑。应用服务器上安装了SOC界面服务器和SOC后台处理程序, 主要包括安全事件处理、安全状况评估、脆弱性收集分析、风险值计算等功能。
3.3 安全信息收集代理层
安全信息收集代理层主要是完成资产自动发现和收集日志信息生成安全信息, 主要功能是根据要求采集被管理资源 (包括各种安全设备、网络和主机设备) 的原始信息, 包含事件信息、漏洞信息、流量信息和安全和操作日志信息等, 将对所管理资源 (硬件、软件等) 中与安全相关的信息按照一定格式进行预处理 (如过滤、标准化、关联等) , 同时要求遵循标准的通信协议进行输出或被访问。例如, 安全事件的采集需要不断侦听本地主机端口, 接受安全设备发送来的安全事件, 再将其转换成标准的安全事件信息存入安全事件数据库中, 状态信息和配置规则信息主要是根据安全设备所支持的管理接口编写合适、高效的调用程序调用管理接口。
在安全信息收集代理层中, 安全事件的采集主要是运用了JAVA的一个很重要的特性, 即多线程。在客户端向服务器端发出请求时, 客户端把发来的请求放在一个消息队列中, 服务端依次从这个消息队列中取出请求来处理, 但是如果遇到单线程, 那么消息队列中的下一个请求就要等到前一个请求完全处理完后才会响应, 从而导致客户端的长时间等待;而如果采用多线程, 则服务端处理可以同时多个请求, 提高系统的性能。新线程完成的工作主要是通过调用函数readline () 读取一行的安全事件记录, 利用可重用的安全事件分析类从各式各样的安全事件格式中提取与安全统一管理有关的信息, 建立起与数据库服务器的连接, 将这些关键信息保存在数据库中。
3.4 数据库服务器
数据库服务器采用ORACLE 10g, 需要对数据资源或中间数据进行管理, 还需要具有完备的通讯、应用日志功能。按照请求命令的优先级提取用户数据 (并保证同一用户按照时间排序) , 交给通信进程处理, 并接受通信进程的应答将结果返回数据库, 属于非数据的原因造成的指令执行失败可以自动重新处理。
数据库服务器选型确定之后, 就开始数据库的设计。数据库设计分为4个步骤。
首先, 确定建立数据库的目的并收集数据, 即进行需求分析。通过详细调查要处理的对象来明确用户的各种需求, 并且通过调查、收集和分析信息, 了解数据库中需要存储哪些数据以及完成何种数据处理功能。确定了建立数据库的目的之后就需要根据目的收集相关信息。
数据库设计过程的第二阶段是建立概念模型。根据应用的需求, 画出能反映每个应用需求的E-R图, 其中包括确定实体、属性和联系的类型。然后优化初始的E-R图, 消除冗余和可能存在的矛盾。概念模型是对用户需求的客观反映, 并不涉及具体的计算机的软、硬件环境。这一阶段的工作重心是如何表达出用户对信息的需求, 暂时不考虑具体的实现问题。
数据库设计过程的第3阶段是建立数据库模型。将概念模型中得到的E-R图转换成具体的数据模型, 实际上是使用关系数据模型把实体、实体的属性和实体之间的联系转换为关系模式。
分布式平台 篇5
配电网高级应用软件 (DPAS) 作为配电自动化系统 (DAS) 的主要组成部分, 一直是研究人员和工程技术人员关注的热点。目前, 智能电网建设的侧重点已经从输电系统部分转向智能配电网建设[1,2]。主网的高级应用软件 (PAS) 已很成熟, 但是相比之下, DPAS中的突出问题是电网结构复杂、节点规模巨大, 因此, 无法复制PAS的体系结构和计算技术来解决DPAS的问题。按照坚强智能电网建设中的统一规划、统一标准、统一建设原则, 国家电网公司颁布了一系列配电自动化的相关标准。为了提升DPAS系统的整体性能, 本文设计并实现了一个基于ZeroMQ消息中间件的分布式通信架构, 主要解决了以下两个问题。
1) 异构系统数据通信问题。DPAS需要获取电网静态数据和断面数据。静态数据是指电网的模型数据, 包括一次设备的电气参数、连接关系和二次设备的配置、整定参数等;断面数据是指遥信、遥测等数据采集与监控 (SCADA) 系统数据。长期以来, 由于各个厂家配电网建设标准不一, 产生了大量的异构系统, 而已经建设好的各种配电网应用系统又不能直接抛弃, 因此, 异构系统的数据通信问题亟待解决[3]。
2) 大规模节点计算问题。通常配电网节点规模巨大, 配电网高级应用的算法如潮流计算、状态估计等往往都伴随着大矩阵运算、循环迭代等过程。这导致了DPAS的计算时间较长, 直接复制PAS的架构, 在计算速度上已难以满足工程需求, 更达不到国家电网公司智能配电网建设的相关标准要求[2]。
针对以上分析, 本文提出了一种基于ZeroMQ消息中间件的分布式架构, 旨在解决以上两个问题, 支持搭建配电网高级应用的分布式通用计算平台。该通用计算平台主要工作集中在以下两点。
1) 分布式通信架构设计。采用ZeroMQ消息中间件设计出配电网分布式通信架构, 解决跨机器、跨系统、跨语言的异构系统数据交互问题。根据实际工程需要, 该配电网分布式架构需要满足以下需求:异构系统的数据交互、数据传输的实时性要求、对基于数据级任务分解的分布式计算的支持、系统架构可伸缩、系统功能可扩展、任务负载均衡、无单点故障。
2) 分布式通信消息格式设计。该计算平台采用基于消息的分布式架构, 系统之间的数据交互、模块之间的互相配合等均由消息完成。为了满足实际工程应用的需求, 本文设计了一种可灵活扩展的消息格式, 支持传输消息类型多样化以及消息体数据复杂化。
1 分布式通信架构设计
随着配电网自动化、信息化、智能化的不断推进与发展, 新上线的应用系统与以往开发的应用系统将共存[4,5]。如图1所示, 智能配电网调度支持系统分为调度管理类应用、调度计划类应用、配电自动化主站系统3个部分[6]。DPAS将从SCADA、图资、电能量计量系统等获取计算所需的数据;DPAS内部各个模块也存在相互调用, 拓扑分析是所有高级应用的基础, 状态估计和调度员潮流也会被诸如网络重构、解合环分析等高级应用反复调用[7]。传统的高级应用软件往往采用单机模式, 本文选用ZeroMQ消息中间件重新设计DPAS架构, 以解决跨机器、跨平台数据交互问题, 以及数据传输的实时性问题[8]和基于数据级任务分解的分布式计算问题。
1.1 分布式关键技术介绍
ZeroMQ (ØMQ/ZMQ) 是近年来兴起的一款优秀的轻量级消息中间件。ZeroMQ不是简单的点对点交互, 而是定义了整个分布式系统的全局拓扑。ZeroMQ是网络栈中新的一层, 它是一个可伸缩层, 可在多个线程、内核和主机之间弹性伸缩。ZeroMQ消息中间件有以下几个特点:交互是面向消息的、套接字与传输协议无关、套接字能感知路由和网络拓扑、缺省情况下所有的交互都是异步的[9]。
ZeroMQ包含REQ-REP, PUSH-PULL, PUB-SUB, DEALER-ROUTER, PAIR-PAIR这几组套接字[10]。REQ-REP是一对步调严格同步的套接字, 使用REQ的相当于客户端, 使用REP的相当于服务端, 称为请求—应答模式。DEALER-ROUTER与REQ-REP有些类似, 是ZeroMQ所有套接字中唯一一对需要自己管理路由信息, 由程序员自己进行路由的套接字对。与REQ-REP相比的一个重要区别是DEALER-ROUTER不是同步套接字对, 每个DEALER可以无限制地发送请求给ROUTER, ROUTER也可以无限制地发送回复给DEALER。PUB-SUB是一组异步模型, 称为发布—订阅模式, PUB发布的消息会被所有与之建立连接的SUB接收。PUSH-PULL被称为管道模式, PUSH可以推送一组任务, 均衡地分发给PULL, PULL也可以收集若干个PUSH推送的任务, 非常适合于分布式应用程序。此外, ZeroMQ还有一个PAIR-PAIR套接字对, 是一对类似于Socket的点对点模式。
1.2 分布式通信架构
根据DPAS系统的功能需求和实际工程需要, DPAS平台由DPAS客户端、服务实例、执行进程、管理模块4个子系统组成, 与DPAS系统进行数据交互的统称为外部数据源。整个DPAS平台内部及外部数据源均通过ZeroMQ消息中间件搭建的通信架构进行数据交换、数据通信、模块间的协调等。
如图2所示, 从各子系统的功能上, DPAS客户端主要功能包括后台服务的启停管理、计算参数设置、计算请求发起、计算结果展示。外部数据源包含DAS、能量管理系统 (EMS) 、图资等系统, 提供电网模型数据、断面数据、负荷数据等。管理模块包含负载均衡中间件和实例心跳的管理两个模块, 主要负责任务和数据的全局负载均衡、服务实例的心跳管理、分布式后台服务管理等。服务实例是基于FastDB内存数据库的数据平台, 支持按照IEC61970标准建模的公共信息模型 (CIM) 文件导入, 可以向外部数据源请求特定时间断面或者实时的电网断面数据、接收外部数据源推送的动态更新的遥信遥测数据, 该子系统包含计算任务切分、计算结果回收、拓扑分析等功能模块。执行进程是包含若干算法模块的程序, 如短路电流计算、遮断容量扫描、消弧线圈整定、潮流计算、状态估计、解合环分析、网络重构等。
目前电网调度自动化系统均包含多态应用[11], 如实时态、未来态、历史态, 其中未来态和历史态统称为研究态应用。对于不同模态的计算流程、算法都是完全一致的, 唯一区别就是服务实例的数据平台所加载的电网数据不同。实际部署中, 通常有两台DPAS服务器, 每台服务器各部署一个管理模块 (Master) 、一个实时态实例和若干研究态实例、若干执行进程、若干DPAS客户端, 外部数据源通常包含一主一备。为此本文利用ZeroMQ设计了图3所示的分布式通信架构, 以满足各子系统交互及分布式计算的需要。
如图3所示, 服务实例通过REQ-REP从外部数据源主动请求电网数据, 通过PUB-SUB被动接收电网实时更新数据;客户端通过DEALER-ROUTER向服务实例发起计算请求, 服务实例经拓扑分析、任务切分后生成子任务及计算所需数据, 子任务和数据集中PUSH至管理模块, 管理模块通过PUSH-PULL均衡派发给执行进程, 执行进程调用相应算法模块进行计算后通过PUSH-PULL返回给对应的服务实例, 服务实例将子任务计算结果进行组装后通知客户端计算完毕。客户端可以通过管理模块对后台服务程序进行管控, 通过REQ-REP套接字向管理模块发送启、停信号, 管理模块判断实例状态之后再对实例进行服务的启停。所有实例在启动之后必须向管理模块“注册”自己的实例信息, 包括加载的断面数据信息、所在机器的IP、绑定的端口号等。在注册之后, 所有实例将和管理模块通过REQ-REP进行心跳互检测。
由于DPAS需要获取电网静态和动态数据, 因此, 外部数据源 (DAS和EMS) 需要基于ZeroMQ进行少量改造:利用REP响应DPAS的数据请求, 利用PUB向DPAS主动推送数据。
该通信架构不仅满足了DPAS平台分布式集群的数据交互、分布式计算需求、模块间的相互配合。而且利用ZeroMQ消息中间件的特点, 通过不同套接字对间的配合, 使得整个分布式系统具有架构可伸缩、系统易部署、功能可扩展、健壮性提高等特点。
1) 架构可伸缩性设计
系统部署前, 用户可以根据需求配置管理模块、服务实例个数 (执行进程和客户端可任意部署) ;系统部署后, 管理模块、服务实例、执行进程可动态增删。
由于ZeroMQ的自动恢复连接机制[10]使得管理模块、执行进程运行时可动态增删。实例的动态增删则是通过管理模块的服务管理实现。每个服务实例在启动之初, 会将自己的绑定信息注册至管理模块。执行进程在启动后, 首先通过REQ-REP向管理模块请求连接实例, 再根据管理模块返回的实例绑定信息连接至所有实例。当有实例状态发生变化时, 如启动、停止了一个实例或者实例发生异常, 管理模块会通过PUB-SUB通知所有执行进程实例发生变化的消息, 执行进程随后会刷新本地连接, 从而达到系统运行时实例动态增删、执行进程动态连接的目的。
2) 架构健壮性设计
通过管理模块、服务实例、执行进程冗余的方式, 既提高了整个系统的计算能力, 又提高了系统的健壮性, 主要表现在消除系统单点故障、故障执行进程的删除、失败计算任务的重新派发3个方面。
由于ZeroMQ采用缓存、异步的方式处理消息, 可能出现任务丢失、结果未按时回收的情况。为此, 每个执行进程在收到管理模块派发的任务后, 首先通过REQ-REP与实例进行同步, 如果该执行进程未按时返回计算结果, 则实例可以通过PUB-SUB发送杀死信号删除此执行进程, 并重新启动一个执行进程, 再根据未返回子任务的任务号重新派发。如此一来, 对于一个复杂的计算任务, 如其中一个子任务计算失败, 该机制可以重复计算该子任务, 从而避免整个任务重新计算。
2 分布式通信消息格式设计
在整个DPAS平台中, 所有模块之间的配合与数据交互都是基于消息的。不仅消息类型多样化, 如控制消息、通知消息、计算请求与回复、计算数据、计算结果, 而且每种类型的消息所包含的数据也很复杂, 如潮流计算任务消息包含任务描述信息、参数配置信息、电网模型信息、电网断面信息, 每种信息又由若干种结构体构成。因此, 统一的通信消息格式的设计显得尤为重要。
ZeroMQ封装了zmq_msg_t类型的消息单元, 并支持多帧技术[10], 每一帧都是一个zmq_msg_t, 多帧传输具有整体发送、整体接收、分帧解析的特点。按照ZeroMQ消息的特点设计了如图4所示的消息格式, 整个消息由消息帧头、消息体、附加信息3个部分组成。
在数据帧头部分, 应用类型包含历史态应用、实时态应用、未来态应用。数据类型主要包含各类高级应用计算请求、各类结果回复、连接请求与回复、查询请求与回复、Hello消息、心跳消息、通知消息、错误告警消息、启停控制消息、遥信数据、遥测数据等。
在消息体部分, 消息体标识部分包含消息体各种数据块的类型及个数。消息体数据则与消息体标识一一对应起来。整个消息体在数据类型及数据个数上都是可扩展的, 适用于所有高级应用需要传输的数据。
附加信息部分则包含了附加信息类型和附加信息数据, 该部分可以用来传输告警信息、数据校验信息等。
3 应用实例
图5描述了整个DPAS系统服务器集群的初始化、计算任务请求的数据流向及时序关系。
如图5所示, 服务实例在启动后首先初始化电网模型数据 (CIM) 和断面数据 (SCADA) , 再向管理模块注册实例信息, 注册成功之后将持续不断地与管理模块做心跳互检测。执行端在启动后首先从管理模块获取实例绑定信息, 再连接至实例完成初始化。客户端首先连接至管理模块, 获取可用服务实例信息, 连接至实例以后即可在该实例的数据平台上做高级应用分析。服务实例收到计算请求之后完成任务分解, 再将数据和子任务发送至管理模块, 管理模块均衡派发至各个执行端, 执行端按照应用类型调用相应算法模块计算, 计算完毕直接返回至相应实例。实例在子任务结果收集完毕后进行结果组装, 结果写入Oracle后通知DPAS客户端计算完毕。
本文的设计及开发立足于工程实际, 以下是实际的验证结果。
1) 数据交互性能模拟测试
利用实验室15台PC机及百兆交换机测试了架构的通信性能, PC机的操作系统包含Red Hat (Linux 6.4) , Solaris 10, Win7, Windows XP。每台PC机处理器2.0GHz, 2GB内存空间。消息中间件为ZeroMQ 3.2, 内存数据库为FastDB 3.73。测试结果如图6、图7所示。
图6、图7测试了数据平台在复杂环境下的数据交互性能。图6显示了该数据平台进行大数据块通信时, 随着数据块大小的变化其通信速率的变化曲线, 当数据块大小超过1 000kB时, 通信速率已经接近局域网通信的上限。图7显示了大量小数据频繁交互时架构的通信性能 (单个数据块为100kB) 。在进行压力测试时, 通信时间随着交互次数的增加而线性增加, 证明在频繁交互时仍能保持较好的稳定性与通信性能, 这也是ZeroMQ可以支持任意大分布式程序[10]的良好体现。
2) 高级应用模块工程测试
配电网高级应用模块包括潮流计算、状态估计、短路分析、遮断容量扫描、消弧线圈整定等, 不同模块的算法特点不同。例如:遮断容量扫描算法由于仅仅是校核开关, 所以算法极其简单;状态估计预处理数据量较大且算法较为复杂;潮流计算核心算法由于迭代导致算法时间复杂度较高。限于篇幅, 本文以遮断容量扫描、状态估计和潮流计算3个模块为例, 测试DPAS与DAS的电网实时数据交互性能, 以及高级应用任务在分布式环境下的通信和计算性能。测试中采用济南市配电网数据, 包含249个电气活岛、27 905个节点, 测试结果如下。
实际工程应用中, DPAS服务器维护电网的实时断面数据, 需要与当前电网实时数据保持一致, 通过高级应用计算分析为调度人员提供实时、准确的决策信息。
表1为系统获取全断面数据所用时间及SCADA推送变化数据的时间。由于全断面数据获取由DPAS触发, 因此, 在测试中计时区间还包括了请求消息通信时间和SCADA服务器准备数据时间。系统全断面数据初始化可以在2s内完成, 动态更新时间为毫秒级, 保证了数据的实时性, 基本可以满足实际工程需求。
图8显示了不同高级应用算法和集群规模下的通信代价与核心算法用时分布图。
当集群中仅有一个执行端时, 所有子任务都是串行执行, 没有任何并行效果。随着集群规模的不断增大, 遮断容量扫描模块总计算时间维持在2~3s, 几乎没有变化, 而全网状态估计和全网潮流的计算时间随着执行端规模的增大而明显减少。全网潮流由串行的50s降至5s左右, 全网状态估计计算时间由串行的近60s降至9s, 加速后的效果满足实际工程需求。图9显示了通信代价换取的加速时间。
遮断容量扫描核心算法简单, 单个任务计算时间非常短 (通常在执行端单任务计算仅需0.001s) , 时间消耗大部分集中在全网拓扑分析、任务分解以及网络传输中, 多执行端并行计算时加速效果不明显。状态估计和潮流计算由于核心算法较为复杂, 串行计算时大部分时间均消耗在算法模块, 采用分布式计算时, 微小的通信代价可以换取非常大的加速时间。以全网潮流计算结果为例, 可并行化计算项包括不同馈线的普通潮流计算、损耗计算 (包括线路损耗和配电变压器损耗等) 、安全性分析 (包括线路重载检查和节点越限检查) ;不可并行化计算项包括计算任务请求、子任务派发、结果回收、通知客户端的通信代价, 以及服务实例端全网拓扑分析、任务分解、数据准备、结果组装 (统计馈线潮流和区域潮流) 、结果映射 (节点支路潮流映射为开关潮流或配电变压器潮流或区间潮流) 、结果写库等算法辅助部分, 其中不可并行化计算耗时约2s, 核心算法并行化计算时间约3s, 总耗时约5s。
综合上述测试结果可知:对于时间复杂度较高的高级应用算法, 该分布式架构可以大大降低算法的执行时间;对于遮断容量扫描这样较为简单的算法, 由于可并行化计算的时间很小, 所以几乎没有加速效果, 这也符合Amdahl定律。
4 结语
本文立足于工程实践提出了一种基于ZeroMQ消息中间件的分布式通信架构, 并且设计了满足各模块间交互的通用消息格式, 解决了配电网高级应用异构数据库的数据获取问题, 满足了配电网高级应用分布式计算平台的数据通信及模块间相互配合的需要, 为配电网高级应用分布式计算提供了支持。该框架的设计思想和方法不仅满足了当前配电网高级应用平台的建设需求, 同时也可以应用于其他基于数据级任务分解的分布式计算平台中。
参考文献
[1]冯永青, 李鹏, 梁寿愚, 等.南方电网面向智能调度高级应用软件的设计思想[J].南方电网技术, 2010, 4 (1) :29-34.FENG Yongqing, LI Peng, LIANG Shouyu, et al.The design concepts of power analysis software for smart dispatching in China southern power grid[J].Automation of Electric Power Systems, 2010, 4 (1) :29-34.
[2]余贻鑫, 栾文鹏.智能电网述评[J].中国电机工程学报, 2009, 29 (34) :1-7.YU Yixin, LUAN Wenpeng.Smart grid and its implementations[J].Proceedings of the CSEE, 2009, 29 (34) :1-7.
[3]唐良瑞, 盛洁, 祁兵, 等.面向智能配电的异构融合通信网络动态负载均衡[J].中国电机工程学报, 2013, 33 (1) :39-48.TANG Liangrui, SHENG Jie, QI Bing, et al.Dynamic load balancing in heterogeneous integrated communication networks oriented to smart distribution grid[J].Proceedings of the CSEE, 2013, 33 (1) :39-48.
[4]程时杰, 李兴源, 张之哲.智能电网统一信息系统的电网信息全域共享和综合应用[J].中国电机工程学报, 2011, 31 (1) :8-14.CHENG Shijie, LI Xingyuan, ZHANG Zhizhe.Entire-grid-area information-sharing and integrated applications in united information system for smart grid[J].Proceedings of the CSEE, 2011, 31 (1) :8-14.
[5]张之哲, 李兴源, 程时杰.智能电网统一信息系统的框架、功能和实现[J].中国电机工程学报, 2010, 30 (34) :1-7.ZHANG Zhizhe, LI Xingyuan, CHENG Shijie.Structures, functions and implementation of united information system for smart grid[J].Proceedings of the CSEE, 2010, 30 (34) :1-7.
[6]徐丙垠, 李天友, 薛永端.智能配电网与配电自动化[J].电力系统自动化, 2009, 33 (17) :38-42.XU Bingyin, LI Tianyou, XUE Yongduan.Smart distribution grid and distribution automation[J].Automation of Electric Power Systems, 2009, 33 (17) :38-42.
[7]李璟.配电自动化高级应用软件及其状态估计的研究[D].济南:山东大学, 2005.
[8]王磊, 陈青, 高湛军, 等.基于网格平台的电网故障诊断架构[J].电力系统自动化, 2013, 37 (3) :70-76.WANG Lei, CHEN Qing, GAO Zhanjun, et al.A framework of power grid fault diagnosis based on grid platform[J].Automation of Electric Power Systems, 2013, 37 (3) :70-76.
[9]董诣.基于函数式语言的网络消息服务器的构建方法研究[D].上海:上海交通大学, 2012.
[10]HINTJENS P.MQ—the guide[EB/OL].[2012-04-01].http://zguide.zeromq.org/page:all.
分布式平台 篇6
系统日志是分布式系统在运行过程中对其运行状态进行实时记录的文件, 该文件通常用于故障排查, 会使用一些工具进行记录和保存, 随着时间的推移, 这种分布式系统日志的数量会越来越多, 由于这些日志文件中对系统所有的操作、机器行为及用户行为进行了大量记录, 因此, 这种系统日志文件成为系统中最复杂但也最有价值的数据, 通过对大量的日志文件进行挖掘分析, 可以找出系统的性能瓶颈, 并有针对性地进行合理优化。
在大数据到来之前, 分布式日志的处理和分析通常是由经验丰富的工程师采用人工查找方式完成, 这种工作方式完全依赖人的工作经验。同时, 也是非常浪费时间、耗费人力的工作, 效率不高, 也极易出错, 而且, 在目前数据呈指数级增加趋势的情况下, 仍然采用人工的方式进行处理已越来越不可能。因此, 必须利用新技术新手段来构建新的日志分析系统。本文提出一种基于云平台的分布式日志分析系统, 对系统的构建进行需求分析, 并设计了基于云平台的存储策略、日志清洗流程等, 实验证明该日志分析系统可行有效, 具有一定的实践意义。
1 云计算概述
云计算的出现是信息技术领域的一大变革, 云计算的基本思想是将网络上的计算资源作为一种公共资源, 通过管理和控制, 用户可以像公共资源一样根据自己的需求进行获取, 用户不需要了解相关的技术和细节, 所有的控制由云平台实现。这种云计算的思想为互联网带来了新的生机, 是一种全新的信息服务模式。
实际上云平台综合了两大典型的分布式系统, 分别是Hadoop和Spark, 这两大系统是目前应用最广泛的基础性云平台, 包括云平台文件存储层、数据仓储、数据挖掘及分布式执行引擎等。
2 系统设计与实现
2.1 需求分析
随着互联网的需求量不断增加, 站点的用户访问量也不断增多, 系统日志的数据量呈海量增加, 为保证系统能利用分布式日志进行数据挖掘分析, 提供决策支持, 保险系统应该具有稳定的数据存储和处理功能, 同时具备较高的执行效率和较强的容错能力。
基于云平台的分布式日志系统还需要通过对日志数据进行分析, 挖掘有用信息, 了解和掌控站点的使用质量, 了解用户的行为习惯, 因此, 日志系统应具有独立且完整的统计指标, 如用户的页面停留时间、页面访问量、独立IP等。同时, 系统应具有灵活的数据清洗转换功能, 能够进行不同类型的数据处理, 具有高效的数据处理流程。由于不同的日志系统采用的格式可能不完全一致, 因此需要设计标准统一的结构化数据格式, 提高数据格式转换功能的灵活性, 保证不同类型的日志数据能够得到兼容处理。
2.2 系统架构设计
如图1所示, 系统从上至下分别是用户界面层、接口层、核心功能层以及平台层。其中, 平台层主要包括云平台和关系型数据库, 大量的数据存储由HDFS完成, 资源的管理和调度则利用YARN实现, 计算引起采用结合Spark和Map/Reduce的分布式计算框架构成, 为保证系统的稳定性, 设计了数据的冗余备份功能。
核心功能层主要包括数据交换模块、工作流调度模块、格式转换模块、并行ETL模块、云平台数据仓库模块及指标统计模块六个功能模块。
接口层和用户界面层都是对界面的设计与实现, 其中, 用户界面层是包括了核心功能的用户界面, 并提供了多种执行方式, 接口层则是提供了界面和具体功能代码接口。
2.3 数据处理流程
首先系统根据实际需要设置日志格式, 为方便对日志数据进行处理, 将全部日志数据转换为定长的格式, 然后, 将系统产生的原始数据进行ETL数据清洗转换, 转换为中间格式, 这种中间格式将更方便日后的分析处理, 然后, 在这种中间日志格式上进行日志分析, 并获得日志分析的结果, 该结果可以从数据仓库中进行查询。通常数据仓库由两个部分构成, 分别是传统的关系型数据库和云平台下的仓储工具, 即Database和Hive/Shark。
2.4 数据模型设计
数据模型设计主要包括日志数据分类、中间日志数据模型设计和数据仓库数据模型设计三个部分, 本节主要对中间数据模型进行说明。
由于原始日志数据通常是不规则的数据, 数据格式并不一致。为方便日后的日志分析统计处理, 需要将原始的日志数据利用ETL清洗转换和格式转化, 最终将其转换成标准的日志格式, 并提取出需要使用的字段, 因此, 在此过程中需要有一种中间形式的数据。
2.5 并行数据挖掘模块
在本文所设计的日志分析系统中, 并行数据挖掘模块是重点难点之一。利用该模块可以对大量的数据进行分析处理, 获得有价值的决策信息, 本系统的数据挖掘模块包括两个部分, 分别是开源算法库Mahout和自主开发的DM模块。
这种基于Spark的方式效率就较高, 但是, 其稳定性还有所欠缺, 因此, 本设计中的数据模块采用DM和Mahout结合的方式进行补充, 从而保证系统的处理能力和性能更稳定。
3 日志分析系统测试
本文的研究基于云平台, 设计日志分析系统, 为验证该系统可靠性, 必须进行系统测试, 本文以独立访客统计为例对日志系统进行测试。
测试从原始的日志数据开始, 根据2.3节中说明的数据处理流程进行处理, 数据为国内某搜索网站的日志数据, 数据格式如图2所示。
如图3所示, 利用UV统计组件进行计算后可以获得时间分布示意图。从该图中可以看出, 系统每天的访问量情况为:每天10~18时段的用户访问量最大, 之后逐步降低, 显然这一统计分析结果符合日常生活中人们的习惯, 从而证明了系统流程的正确性。
4 结语
本文针对目前网络应用不断增加, 日志系统所获取的数据量越来越大的情况, 通过对日志系统挖掘分析可以获得有价值的信息, 为决策提供支持。本文基于云平台开发了一种分布式日志系统, 该系统基于Map/Reduce和Spark编码设计了指标统计、数据挖掘、ETL清洗转换等功能, 通过实验证明了该系统能基本符合系统的功能需求, 具有一定的实践意义。
参考文献
[1]赵莹莹, 韩元杰.Web日志数据挖掘中数据预处理模型的研究与建立[J].现代电子技术, 2007 (4) :103-105.
[2]刘永增, 张晓景, 李先毅.基于Hadoop/Hive的web日志分析系统的设计[J].广西大学学报 (自然科学版) , 2011 (S1) :314-317.
分布式平台 篇7
视频渲染是当前视频应用相关的核心技术之一。然而, 长期以来, 由于受到设备性能、成本等方面的限制, 如何实现大规模、高效率、高质量的视频渲染始终是一个视频处理必须面对的问题。随着云计算技术的成熟, “云渲染”作为一个全新的分布式渲染技术应用模式, 已经成为下一代视频渲染的重要技术基础。基于云计算的视频渲染服务, 将充分利用云计算的虚拟化、可伸缩、高性能计算的优势和特点, 实现海量级视频处理能力, 并支持用户依据需要的计算资源定制, 从而降低用户成本, 极大地提升视频渲染服务的效率。
传统视频渲染架构依赖于计算机或服务器集群开展, 其主要缺点如下:渲染单位以物理机为基础, 处理能力依赖于物理机本身的能力, 在物理机单机弱或物理机集群能力过于强大的前提下, 将会造成处理时间过长或物理机资源大量浪费的情况;处理机制以串行方式为主, 无法实现多个处理任务的高并行处理;渲染处理设备必须由各需求者自主建设, 无法促使处理设备的获得高度共享, 从而确保各类资源的高效利用。
针对上述问题, 本文提出了一种视频云渲染处理服务平台, 该平台引入云计算技术, 通过“基础资源服务”、“视频数据服务”、“平台服务”和“门户服务”, 实现海量视频的分布式并行云渲染, 从而全面提升视频渲染处理的工作效率。
2云渲染服务平台设计原则
云计算技术为当前高复杂度、高成本、大数据量的计算任务提供了有效的解决方案。本设计中, 为了满足云渲染的高并发、多任务、计算资源弹性分配的需求, 提出了如下设计原则。
(1) 资源虚拟化原则
云渲染服务平台中的所有资源, 包括服务器资源、网络资源、存储资源以及其他设备资源等, 均通过虚拟化技术进行管理, 使其由若干物理分散的资源虚拟化为逻辑统一的巨大资源。
(2) 平台服务原则
云渲染服务平台为各类视频渲染需求提供统一、无缝的平台接口, 并在各类接入设备之间提供服务协议和接口, 满足不同设备终端的访问、查询、展示以及任务管理相关平台需求。
(3) 按需服务原则
云渲染服务平台依据用户提出的渲染服务进行资源动态分配, 依据渲染任务的预期资源实现虚拟机的配置, 从而按用户的需要进行资源分配, 优化用户服务的成本。
(4) 多任务并行原则
云渲染服务依据用户视频渲染的实际工作流程, 利用并行计算技术, 将任务进行智能规划和分配, 保障多任务的并行渲染, 大幅提升服务效率。
3系统架构及设计
分布式视频云渲染平台的核心在于在通过统一的资源整合, 打造功能强大且弹性灵活的视频渲染服务平台, 实现视频渲染过程中依据用户、渲染任务和资源现有情况等信息的灵活调度;构建统一平台服务, 实现不同终端的接入、不同格式视频的兼容、第三方渲染器的部署等, 建设功能强大的系统平台;通过任务分配实现视频渲染的分布式、高并发处理, 大幅提升渲染效率。
依据云计算的基本提点, 我们将视频云渲染平台分为基础资源层、视频数据层、平台管理层和应用服务层。系统架构如图1所示。
3.1基础资源层
基础资源层核心在于高效率的资源整合, 完成底层计算资源服务器和存储资源设备集群, 以及各种网络接入整合, 引入虚拟化、聚合网络等技术, 形成统一的虚拟资源池, 构建整个云渲染服务平台的底层保障, 从而将单位各种物理分割、独立工作、各自为战的设备实现逻辑上的统一, 以便于优化调度。同时, 在该平台引入动态资源管理模块, 实现虚拟资源池中各类资源的弹性分配, 即依据要求分配虚拟机, 对虚拟机的使用情况进行监管, 并在虚拟机完成任务后进行资源回收, 使其回归资源池。
3.2视频数据层
视频数据层主要实现视频数据接收、清洗、格式识别、存储、管理、防灾等工作, 同时也需要完成视频渲染数据规则的定义、主数据和元数据管理等工作。主要包括视频数据存储模块、视频数据管理模块和视频数据规则模块。
(1) 视频数据存储模块
该模块负责接收来自用户提交的视频渲染数据、任务数据、中间状态数据等, 并将这些数据依据不同的格式、平台兼容性等特征进行分类存储, 并且负责完成日常数据备份, 以及故障恢复和数据防灾等工作, 实现视频渲染所需要存储和查询工作。
(2) 视频数据管理模块
该模块为视频渲染处理提供管理服务。主要包括:依据视频的格式、渲染规则等知识支持, 实现视频渲染过程必需的知识推理;视频渲染数据的日常更新、修改和维护, 保障不同视频渲染任务中数据的独立性、安全性和完整性;同时, 提供视频数据的访问提供统一的协议和接口等。
(3) 视频数据知识模块
定义视频数据的知识服务, 包括视频云渲染平台中的数据格式知识、渲染规则、处理规则、访问规则、任务规则等方面知识内容。
3.3平台服务层
平台服务层为视频云渲染服务平台提供支撑环境, 从而在底层资源、数据资源与顶层渲染应用服务之间构建一个支撑手段, 主要包括作业模块、并行调度模块、服务管理模块。
(1) 作业模块
主要包括云渲染服务所需要的作业创建、任务动态规划、资源分配、作业监管等方面功能。
(2) 并行调度模块
主要针对视频渲染处理所需要的计算环境进行管理和配置, 提供包括智能渲染任务调度、渲染环境配置、冲突检测和处理等服务, 为视频渲染处理的计算任务提供高效智能的并行计算环境, 自动配置并行计算过程, 按需配置计算资源。
(3) 服务管理模块
主要针对云计算平台中所有云渲染器、计算服务模块等提供管理能力, 包括对服务运行所需要的负载均衡、智能响应、动态扩容等服务, 对服务的接口、访问、响应、负载等进行管理, 应对访问量的突变及负载的不均衡, 保障服务效率。
(4) 第三方平台模块
提供可由第三方开发的视频渲染处理模块的部署平台, 允许第三方开发者在其上部署其符合本平台格式要求的视频处理服务, 并接受本平台的管理和调度。
3.4门户服务层
门户服务层中定义了视频云渲染处理的各类功能模块。
(1) 视频云渲染的用户管理服务
针对用户进行登录管理、资格认证、权限管理等。
(2) 视频云渲染任务处理服务
实现海量视频渲染任务的提交、确认、撤销等管理功能、渲染器定制、任务进度查询、目标管理等。
(3) 视频云渲染展示服务
通过用户定制的播放器为提供视频渲染效果的展示服务, 并支持用户自定义渲染过程中的相关参数设置等。
(4) 视频云渲染平台支持服务
提供用户在云渲染平台上的操作手册、历史记录查询、售后反馈等支持服务。
4视频云渲染处理技术
视频云渲染处理技术主要包括任务接受、资源分配、渲染处理和任务反馈四个关键环节。
4.1任务接受
如图2所示, 该环节中, 用户登录视频云渲染服务平台, 将所需要的渲染任务提交给云渲染平台。云渲染平台将依据用户身份、渲染任务描述信息、所提交视频格式等, 评估视频渲染的相关任务, 形成平台内部可接受和自动处理的任务封装;进一步, 接受用户提交的视频数据, 在平台内实现分类存储, 并将该任务提交给作业模块、资源分配模块进行处理。
4.2资源分配
该环节中, 平台依据任务相关信息进行任务分解、虚拟机配置、任务分发、运行环境配置、负载评估等工作。在该环节中, 视频渲染任务依据时间、逻辑等维度进行有序分解, 产生可并行处理的不同子任务序列;进一步, 平台依据不同子任务规划, 进行作业创建、虚拟计算单元配置、环境配置等工作;继而将各并行子任务分发到不同的计算单元中, 依据Map Reduce技术思路, 实现分布式并行渲染的环境配置。
4.3渲染处理
该环节中, 各虚拟计算单位依据子任务的渲染需要, 选择适合的处理模块对任务进行处理计算, 形成各子任务的渲染效果。
4.4任务反馈
该环节中, 任务监管模块在各子任务完成后, 对任务处理进行校验、反馈和展示等, 将最终结果反馈到用户;最后, 任务监管模块在得到用户确认任务结束后, 撤销对应生成的作业任务, 并回收各已分配的虚拟计算资源, 使其回到资源池, 等待新的资源分配。
5结束语
视频渲染是当前视频处理中非常重要的技术环节。利用云计算技术的优势提升视频处理能力, 是提升当前我国视频技术的重要关键技术基础。本文引入云计算, 提出一种基于云计算的视频渲染服务平台设计基本方法, 充分利用云计算优势, 通过构架基础资源、数据、平台和服务四个层次, 优化视频渲染过程, 致力于提升视频处理的质量和效率, 探索视频服务平台建设的创新之路。
摘要：本文提出了一种基于云计算的分布式视频渲染服务平台设计方法, 利用云计算技术实现基础资源虚拟化管理, 从而整合分散物理计算资源, 实现资源动态分配和弹性管理;同时利用云计算的并行处理能力, 实现视频渲染的任务并行渲染, 为其分配相应的虚拟计算处理单元, 达到视频渲染的效率优化。
分布式平台 篇8
笔者曾在某全球500强企业供职多年,负责其北京分支机构的办公自动化及个性化需求研发。这家企业拥有完善的Intranet环境及先进的B/S结构业务系统,经营业务及日常办公均依靠Intranet。但对于其分支机构来说,日常办公主要依靠总部现有系统,相对于核心业务系统而言,办公系统建设较为薄弱,功能也比较单一,无法满足机构多样化的个性需求,也没有充分利用机构自身的局域网络。鉴于这种情况,为在其机构实现无纸化办公,推动办公的信息化、自动化,同时合理利用机构网络资源,为主干业务网络减负分流,笔者结合多年开发经验,根据实际工作需求,主持开发了为这家机构量身订做的基于分布式结构的企业办公平台——机构网络公共平台(以下简称“平台”),以满足机构日益高涨的办公需求。
二、平台定义及整体架构
应用程序有C/S、B/S两种模式。C/S模式是客户端/服务器模式,C/S程序需要在每台客户机上独立部署、运行。而B/S模式就是浏览器/服务器模式,B/S程序在服务器上部署一次后即可在任何客户机上通过浏览器来运行。对比传统C/S模式系统,B/S模式系统具有维护简便、覆盖范围广等诸多优点,能够很好地应用在Intranet中,成为越来越多的企业的选择。B/S模式系统又称Web应用系统。
笔者所研发的平台是一组Web应用系统的集合,主体使用Microsoft ASP.NET技术开发,是一个用于机构Intranet的综合性办公平台。截止到日前,平台下共包含1个中控系统和4个应用系统等5个Web应用系统。
平台采用分散式架构管理,各应用系统相互独立,使用独立的Web虚拟目录,但数据共享,统一使用一个公用的数据库(见图1)。即保障数据统一性又体现了系统独立性。从多年的应用经验来看,这种方式可以给系统维护和迁移工作带来极大的便利。
三、应用系统的分布式结构
由于机构Intranet中共有4台Web服务器和1台独立的数据库服务器,均使用Microsoft Windows2003 Server操作系统,数据库软件使用Microsoft SQL Server2000,为充分利用服务器资源,提高系统扩展和移植能力,平台中的应用系统均采用分布式结构设计。
三层体系结构是最基本的分布式结构,三层是指逻辑上的三层。三层体系的应用程序将业务规则、数据访问、合法性校验等工作放到了中间层进行处理。通常情况下,客户端不直接与数据库进行交互,而是通过COM、SOAP等方式与中间层建立连接,再经由中间层与数据库进行交换。
三层结构分为:
1、表示层(UI):通俗讲就是展现给用户的界面,即用户在使用一个系统的时候他的所见所得。
2、业务逻辑层(BLL):针对具体问题的操作,也可以说是对数据层的操作,对数据业务逻辑处理。
3、数据访问层(DAL):该层所做事务直接操作数据库,针对数据的增添、删除、修改、更新、查找等。
平台下各应用系统均统一使用三层体系结构,其中:
表示层主体使用Microsoft Visual Basic.NET或Microsoft Visual C#.NET开发,使用ASP.NET、Ajax、脚本语言和样式表技术,表示层专注于系统外观、用户交互、信息验证等方面,完全不访问数据库,通过自身的配置文件Web.config定位所使用的业务逻辑层。
业务逻辑层使用Microsoft Visual C#.NET开发,以Web Service方式表现。Web Service是一个应用组件,它逻辑性的为其他应用程序提供数据与服务。各应用程序通过网络协议和规定的一些标准数据格式(Http,XML,SOAP)来访问Web Service,通过Web Service内部执行得到所需结果。Web Service可以执行从简单的请求到复杂商务处理的任何功能。一旦部署以后,其他Web Service应用程序可以发现并调用它部署的服务。业务逻辑层无前台界面,专注于算法,数据层访问,请求响应等方面,通过自身的配置文件Web.config定位所使用的数据库。
数据访问层以存储过程(Stored Procedure)和视图(View)形式直接构建在数据库中,专注于数据的增、删、改、查等操作。
迁移或切换环境时,只需修改相应层的Web.config文件即可,完全不需要重新编译、部署应用系统。
四、应用系统与数据库的交互
应用系统通过Web Service与数据库交互时,遵循以下3个原则:
1、任何情况下,Web Service均不直接访问数据库中的表(Table)。
2、对数据的增加、删除、修改通过Web Service访问相应存储过程(Stored Procedure)实现。
3、对数据的查询通过Web Service访问相应视图(View)实现。
每个Web Service均通过一个统一的集成其中的公共类来统一规范访问数据库的行为。其部分代码如下:
五、平台的权限模型
由于平台下存在多个平级的应用系统,每个应用系统均有自己独特的权限系统,用户同时对多个应用系统拥有权限,为处理平台中复杂的用户权限关系,笔者建立了一套SPRU权限模型(见图2),根据此模型构建出平台的权限系统。
在SPRU模型中:
●S代表系统(System),具体的一套Web应用系统,平台中存在多个系统。
●P代表权限(Power),系统中可使用功能的范畴,每个系统中存在多种权限。
●R代表角色(Role),装载一组权限的容器,其中的权限既可以来自单一系统也可以来自多个系统,既可以是多个权限也可以是一个权限。
●U代表用户(User),系统的使用者,可能需要在多个系统中拥有不同的权限。
SPRU模型通过为用户分配不同角色来实现不同用户在多个系统中拥有不同权限。在图中:
●User1的角色是Role1,拥有System1、System2两个系统的Power1权限
●User2、User3的角色是Role2,拥有System1系统的Power2和Power3权限;
●User4到User7的角色是Role3,都拥有System1系统的Power3权限和System2系统的Power2权限。
六、平台中的单点登录
单点登录(Single Sign On),简称为SSO,是目前比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中,用户只需要登录一次就可以访问所有相互信任的应用系统。
企业应用集成(EAI)。企业应用集成可以在不同层面上进行:例如在数据存储层面上的“数据大集中”,在传输层面上的“通用数据交换平台”,在应用层面上的“业务流程整合”,和用户界面上的“通用企业门户”等等。事实上,还用一个层面上的集成变得越来越重要,那就是“身份认证”的整合,也就是“单点登录”。
单点登录的技术实现机制:当用户第一次访问应用系统1的时候,因为还没有登录,会被引导到认证系统中进行登录;根据用户提供的登录信息,认证系统进行身份效验,如果通过效验,应该返回给用户一个认证的凭据--ticket;用户再访问别的应用的时候,就会将这个ticket带上,作为自己认证的凭据,应用系统接受到请求之后会把ticket送到认证系统进行效验,检查ticket的合法性。如果通过效验,用户就可以在不用再次登录的情况下访问应用系统2和应用系统3了。
可以看出,要实现SSO,需要以下主要的功能:
所有应用系统共享一个身份认证系统;
所有应用系统能够识别和提取ticket信息;
应用系统能够识别已经登录过的用户,能自动判断当前用户是否登录过,从而完成单点登录的功能。
在平台中,就使用了这种SSO机制。用一套公共的登录、验证模块,统一处理平台各应用系统的用户验证请求。具体过程为:在平台中注册的应用系统都会获得一个SID,用户登录某一应用系统时,使用此应用系统的SID作为入口参数访问SSO模块,SSO模块的出口参数为UID(登录成功)或者错误信息(登录失败),SSO模块处理完成后返回该应用系统。SSO中的ticket为UID。(见图3)
由于各应用系统均使用分布式结构,在Web服务器上使用独立的虚拟目录部署,所以使用Cookie作为SSO中ticket的载体。
七、域环境中的免密登录
笔者所在的企业使用域(Domain)方式管理Intranet。
域是一种管理边界,用于一组计算机共享共用的安全数据库,域实际上就是一组服务器和工作站的集合。
域和工作组(Work Group)相比较,如果说工作组是“免费的旅店”,那么域就是“星级的宾馆”。工作组可以随便出出进进,而域则需要严格控制。在工作组上一切的设置在本机上进行包括各种策略,用户登录也是登录在本机的,密码是放在本机的数据库来验证的。而如果计算机加入域的话,各种策略是域控制器统一设定,用户名和密码也是放到域控制器去验证,也就是说一个账号密码可以在同一域的任何一台计算机登录。
由于在生产环境中,每个用户使用唯一的域账号登录电脑。平台在设计上本着尽可能让用户少记忆密码的原则,利用域账号的唯一性,由平台获取访问电脑的域账号(不含密码)信息与数据库中的账号信息匹配,从而实现访问平台时不需用户名、密码即可获取用户身份,极大的方便了用户访问平台。
当然,这种模式仅限与使用域管理的Intranet中,如果Intranet属于工作组方式管理,则访问平台也只能依靠传统的“输入用户名密码”方式访问。
八、用户的新增和管理
结合机构实际工作情况及管理模式,综合考虑时效、工作量等方面因素,平台采用用户自行注册,管理员补入必要信息的管理模式(仅限于内部网在域管理方式下)。
当一个新用户(在平台中没有任何信息)访问平台中任何一个应用系统时,均会被引导进入注册页面,平台直接获取他的域账号作为在平台中的用户名,由用户自行补充中文姓名、联系电话等其他信息。注册后,这个用户成为平台的原始用户(Original User),即拥有用户名和一个公共角色,无部门归属等信息,但可以访问平台中所有授权为公共的内容。
原始用户可以请求本部门的部门管理员将其设置为本部门成员,设置后他将可以访问授权给相应部门的内容(权限不变,访问范围增大)。如果需要,用户也可以请求平台的超级管理员为其分配其他角色,以获得更多的访问权限(权限增大,访问范围增大)。
在过去三年的使用过程中,平台中先后容纳了2000余名用户,实践经验证明,这种管理模式清晰高效,在处理时效和维护工作量间达到了一个较好的均衡。
九、平台的中枢控制系统
平台通过一套Web应用系统来设置、维护平台中的事务,同时处理平台中单点登录的SSO模块也集成在这套系统中。由于历史原因,这套系统被命名为用户管理系统(以下简称UM系统),它是平台的中枢控制系统,本身也使用三层结构开发。(见图4)
在UM系统中,包含这样几大功能模块:
●单点登录模块,用于处理平台中所有的登录请求。
●系统信息模块,用于维护平台中应用系统的信息,SPRU模型中的S。
●权限信息模块,用于维护平台中权限的信息,SPRU模型中的P。
●角色信息模块,用于维护平台中角色的信息,SPRU模型中的R。
●用户信息模块,用于维护平台中用户的信息,SPRU模型中的U。
●权限配置模块,用于设置权限、角色、用户之间的关联关系。
●组织架构模块,根据机构实际的组织结构在平台中设置出的信息,如部门、科室。
UM系统目前下设3级权限,分别为:
1、超级管理员,最高级别权限,可以使用UM系统中所有功能。
2、部门管理员,可以设置用户信息中的部门归属信息,可以根据部门管理员的部门信息,将一个原始用户设置为部门成员,或者移除某部门成员的部门信息,使其再次成为原始用户。
3、普通用户,可以设置用户信息中的自身信息,如联系电话,手工登录密码等信息,也可以查看到所有部门管理员列表,以便联系相应的部门管理员设置部门信息。
十、平台中的其他应用系统简介
根据机构中一些具体的办公需求,在平台下先后开发了红头文件系统、信息发布系统、工作计划系统及员工绩效测评系统等4个应用系统。
1、红头文件系统(RHF)
用于发布机构级经营决策、架构调整、人事任免等方面公文,以红头文件形式发布,公文被封装为PDF格式,不可复制及打印内容,发布时带有审核机制,通过审核的公文才能为公众所见,文件授权级别统一为“公共”,并且支持指定条件的模糊查询。
2、信息发布系统(P S)
用于发布机构日常的工作通知、部门公告、内部新闻、手册文档等综合信息,与红头文件系统相比,信息发布系统发布的内容安全级别有所降低,除PDF格式外,还支持DOC、XLS、PPT、TXT、HTM、RAR等多种常见格式文件的发布。相对的,在信息发布系统中对发布内容的查询和控制要灵活很多,除支持更多条件的模糊查询、复合查询外,发布者可以自行选择文件授权级别为“公共”、“本部门”和“自定义部门”。此外,信息发布系统的发布格式全平台通用,可以轻易扩展为各种前台信息应用。
3、工作计划系统(WP)
用于管理日常工作计划,由部门领导或员工本人在系统中制订阶段性工作计划,并可以随时查看下属或自己的工作计划完成情况,同时支持工作计划报表下载。
4、员工绩效测评系统(EA)
用于机构年中、年终的员工绩效测评,按人力资源部门需求,按360度绩效测评模型构建,在考核前,由管理员进行考核人群、考核组、考核工具、考核关系、考核权重、考核区间等设置。在考核期间(考核区间开始,普通用户可以使用系统),用户可以通过考核工具中的相关描述对在自己考核关系范围内的人员进行评价(不可见计量分值),系统会根据考核工具中的计量分值,自动计算被考核人的单人考核得分,当考核结束后(考核区间结束,普通用户无法使用系统),管理员可以让系统自动汇总每个被考核人的所有单人考核得分,根据算法、权重综合算出被考核人的最终考核成绩。同时,在考核期间,管理员还可以实时监控考核进度,并且可以在考核结束后生成单项绩效报表和汇总绩效报表。
这套系统算法先进,结构严谨,控制完善,早在2006年,其前身系统就曾在某企业分布在河北、天津、沈阳、哈尔滨等10家二级机构推广使用,广受好评。是机构在办公自动化研发方面的重大突破之一。
参考文献
[1]Erich Gamma,Richard Helm,Ralph Johnson,John Vlis-sides.设计模式:可复用面向对象软件的基础[M].机械工业出版社,2004.
[2]Frederick P.Brooks.Jr.人月神话[M].清华大学出版社,2007.
[3]karli Watson,Christian Nagel.C#入门经典(第四版)[M].清华大学出版社,2008.
[4]萨师煊,王珊.数据库系统概论(第二版)[M].高等教育出版社,1991.