架构整合范文（精选6篇）
架构整合 第1篇
关键词：大型综合能源企业,信息整合,SOA架构
1 信息化建设现状
1.1 我国矿山企业信息化建设
20世纪80年代, 一些矿山企 业 、 大中专院 校 、 科研院所 开始研究计算机技术在矿山设计和生产中的应用, 并开发出了一些应用软件系统, 如矿井通风系统、 矿山资源储量计算系统等, 为推动我国矿山信息化建设起到了积极的作用。 进入90年代后, 随着国家信息化的快速 发展和市 场环境的 变化, 矿山信息化进入了快速发展阶段, 围绕着如何提高矿山生产效率和管理效率、 降低开采成本、 提高矿山开采技术水平等开展了大量的研究, 并取得了丰硕的成果[1]:
(1) 计算机辅 助矿山规划 与设计得到 普遍应用 。
在建立矿床三维地质数字模型的基础上, 进行地质储量计算, 优化开采境界, 编制矿山生产计划, 从而提高工作效率, 降低生产成本[20]。 如江西铜 业公司在全国 矿山率先采用 了国际上普遍应用的矿山规划与设计软件———MINTEC软件, 取得了较好的效果。
(2) 与矿山生产 相关的业务 系统得到广泛 应用 。
矿山企业广泛采用计算机技术、 数据库技术建立了不同层次的管理信息系统, 并且向着集成系统的方向发展, 等使得生产过程自动化、 管理信息化, 比较有代表的是伊敏露天煤矿建立了包括人事、 档案、 计划、 消耗、 供应、 销售等功能的管理系统, 安家岭露天煤矿生产调度管理系统等。
(3) 矿山企业加 大了网络通 信设施建 设的投资 , 基础设施建设的后发优势加快了信息化的进程。
虽然我国矿山信息化建设取得了一定的成就, 但由于缺乏规划以及盲目地上各种应用系统, 所以与国外先进矿山企业相比, 我国矿山信息化总体水平还不高, 还存在诸多问题:
(1) 大型能源企 业业务系统多 , 数据源头 分散 , 缺乏统一的数据规范, 系统集成性差, 可扩充性弱。
(2) 对信息化建设 存在误区 。
企业信息化建设中有种被广泛认可的说法:“三分技术, 七分管理, 十二分数据”, 系统的实施是建立在完善的基础数据之上的。“三分技术” 中的数据组织技术尤为重要,“七分管理” 中的人员组织管理、 制度管理是关键,“十二分数据” 是指数据的准确、 及时和完整, 统计指标的统一等, 但多数企业不重视数据组织技术, 忽视组织的制度管理, 从而阻碍了信息化的进程。
(3) 对数据整合存在 误区 。
很多企业数据的整合的概念就是通过建立数据接口把各业务系统集成在一起, 但是接口的数量会随着应用系统的增加成几何级数增加, 这不仅增加了信息化建设的投资, 而且使得整体系统的可扩充性差。
1.2 信息化建设
某公司是集煤炭开采、 坑口发电、 铁路运输及粉煤灰提取氧化铝为一体的大型综合能源企业, 全集团公司建有以千兆光纤为主干、 百兆交换至桌面的局域网络, 并在吊斗铲系统和供应仓库部署了无线网络传输系统, 计算机约有1500台左右。 现有小型机13台、 PC服务器20台、 交换机228台。
公司部门众多, 业务繁杂, 信息化程度各不相同, 现建有16个业务应用系统: EAM系统、 人力资源管理系统、 用友财务管理、 OA系统、 生产调度日报系统、 哈矿生产日报、 煤炭经销公司报表系统、 露天设备调度系统、 煤质分析 系统 、 档案管理系统、 煤矿本质安全管理体系、 露天矿GPS运输车辆监督管理系统、 医疗保险管理系统、 住房公积金管理系统、 铁路运营管理信息系统、 准能矸电生产管理系统。
(1) 统一用户管理和身份 认证的问题
现有业务应用系统相互独立运行, 每套系统都有自己的用户管理和权限认证方式, 都需要单独的登录认证才能使用, 导致用户信息冗余、 数据不一致的问题严重, 没有全集团统一的用户管理和身份认证控制机制。 用户存在多份, 且在多个地方维护, 不一致的情况严重, 而且各业务应用系统都建立了各自的组织架构, 没有全集团公司统一的组织架构和用户信息, 当集团公司组织架构调整和人员变动时, 必须分别维护各业务应用系统的人员信息和权限分配。
(2) 信息访问方 便性和系统 可维护性的 问题
现有业务数据分散, 孤岛现象严重, 工作人员必须清楚知道所需信息在哪一业务系统中, 访问不同的信息需要在不同系统间进行切换、 搜索, 而且数据不一致 , 信息不透 明 , 需要耗费大量的精力去查找信息。 由于操作复杂, 用户需要多次、 重复的培训, 系统需要很多不同专业的人员更新维护, 维护成本很高。
(3) 主数据的 甄别和数 据一致性 的问题
各业务应用系统都是各自为政, 独立的维护自己的数据, 造成大量的数据冗余和不一致。 主数据不明确, 业务信息在很多系统中都存在, 不清楚哪个系统中的信息是准确的、 最新的、 可用的。 因此使得本身从业务角度来看是有相互关系的数据不能发生 “关系”, 最直接的表现就是得不到一个综合的、 多维度的管理决策信息。
(4) 全局性信息搜索 和综合服务 能力的问题
虽然我公司现有系统经过多年的运行产生了大量的信息, 但这些信息并没有沉淀固化为企业的知识而发挥应有的价值, 提供数据服务的能力不足。 现有业务数据关联困难, 集成程度很低, 缺乏全局性的信息搜索, 对关键业务数据缺少综合分析和实时动态展现, 对业务管理和领导决策的支持力度不足。
(5) 实现业务数 据报表自 动化和智能分析 的问题
数据应以不同的方式为不同层面的 业务管理 提供服务 , 现有的业务应用系统以解决执行层面数据操作为主, 要求快捷、 方便、 准确, 而管理层关注的是业务管理的过 程信息 、 结果信息, 要求数据的及时性、 准确性, 并能实现业务报表的自动化。 决策层领导关注的是各职能机构的综合统计、 分析信息, 要求能够动态、 实时地反应集团运营状态的关键业务数据, 并能够以图表、 曲线、 管理决策信息仓库等多种的形式, 直观地展现在桌面上, 同时能够在专业工具支持下进行分析, 包括从积累的数据中寻找潜在的规律, 对生产效率进行比较分析, 对各种趋势性数据进行预测等。
2 系统建设目标
系统整合平台基于SOA架构, 采用松耦合、 模块化设计, 构建一个灵活的、 稳定的、 开放的、 可扩展的数据集成框架结构。 在保持现有业务应用系统功能和运行方式基本不变的前提下, 站在公司全局的高度, 将现有业务应用系统进行信息整合, 实现生产调度业务数据的逻辑关联和智能分析, 并实现业务报表的自动化生成和可视化管理, 为领导决策和综合业务管理提供信息化支持。 具体建设目标可概括为:
(1) 统一数据 视图 , 将不同数据 源进行集 成整合 , 其概念结构如图1所示。
(2) 构建数据 仓库 : 通过对各 业务数据 的抽取 、 清洗 、 转换, 从而形成数据仓库, 从而对数据进行多维度分析, 自动形成数据报表。
(3) 完善的报表系统 : 结合我公司 露天矿 、 选煤厂 、 发电厂、 铁路运输、 维修中心及辅助生产环节的实际需求, 完善满足各级生产调度需求的报表系统。 根据现有各级单位生产调动工作需求, 系统应满足三级报表编制需求: 第一级为公司各二级生产单位调度使用; 第二级在第一级报表数据的基础上进行汇总形成, 供公司总调及相关领导使用; 第三级为集团公司生产调度报表, 经公司生产指挥中心调度人员或统计分析人员审核确定后, 可直接上传集团产运销信息系统。
3 系统规划方案比选
3.1 开发系统间接口程序
通过开发接口程序实现系统间的数据 交换 , 是最传统 、 最简单的方式。 但这种方式并不适合公司这样复杂的信息系统和众多的数据交换需求, 而且还无法实现跨系统、 跨平台、 跨部门的流程整合, 制约了信息化建设的可持续发展。
这种方式的接口开发数量非常多且复杂, 若将全公司的业务应用信息全部进行集成, 其接口程序的软件开发工作量不可想象, 而且这种方式将导致IT系统结构越来越复杂, 可扩展性差, 灵活性差。 数据和流程整合是由于跨系统、 跨平台业务协同需求而产生的, 是公司全局性、 整体性的 问题 , 只能从全局层面、 整体结构上去解决。 而开发接口程序的方法只是站在应用层面试图从局部去解决业务协同这个全局性的问题, 这不仅仅是一个技术上的差异, 更是一个分析和解决问题 “方法论” 的差别, 所以, 很多单位试图以OA系统或ERP系统为核心 去整合其他应用系统 , 不但旧的 问题没有从根本上解决, 反而将结构越弄越复杂, 新的问题也层出不穷。
3.2 重建一个“大一统”的业务系统
新建一个 “大一统” 的业务系统, 代替现有的业务应用系统, 这是一种理想主义的设想。 因为要想把公司所有业务涉及到的所有IT信息系统都整合在一起, 这不仅技术难度大、 建设成本高, 而且也无法满足未来业务扩展的需要。
3.3 基于 SOA 架构实现信息整合
面向服务体系架构 (Service-Oriented Architecture) 是一种以业务为驱动的全新的IT架构方式, 能够在保持现有业务应用系统功能和应用模式不变的前提下, 实现公司整体、 全局性的信息集成与整合。 SOA将应用程序细分为不同功能单元———服务, 一个服务定义了一个与业务功能或业务数据相关的接口, 以及约束这个接口的契约。 接口和契约采用中立、 基于标准的方式进行定义, 它独立于实现服务的硬 件平台 、 操作系统和编程语言, 这使得构建在不同系统中的服务可以以一种统一的和通用的方式进行交互、 相互理解。
SOA是一种架构 、 方法 、 思想 、 标准 , 它能使公司业务 标准化、 服务化、 组件化。 SOA实现的目的在于 “随需应变” 和 “灵活应对”。 这就能够将公司内部各组织之间, 以及各厂矿、 各子公司等关键要素整合在一起, 能够对瞬息万变的需求做出敏捷的反应。
通过对上述3种方案的概述, 结合公司的实际情况, 最终确定SOA架构作为最终的方案选择。
4 数据整合平台构建
数据整合是按照统一指标、 统一数据概念的要求, 对不同应用系统提供的数据源, 按照问题领域和指标设 计规范 , 将分布在不同应用系统的原始数据转换为要求的 “目的数据” 的过程, 公司数据集成整合平台从逻辑上由生产调度门户平台、 生产调度报表平台、 公司统一用户平台、 生产调度报表数据4大部分构成, 其总体架构设计方案如图2所示。
4.1 生产调度门户平台
基于IBM PORTAL构建生产调度门户平台, 在门户平台上使用表单配置工具STS为各二级单位开发配置 报表提报 、 审核、 批准界面, 并提供用户管理、 以及与其他应用系统的单点登录、 业务应用集成等功能。
4.2 公司统一用户平台
基于标准的LDAP产品构建公司统一的用户数据库, 根据公司的实际情况, 选择使用IBM Directory Server (IDS) 来实现。 统一用户管理需要考虑统一用户数据库的建立、 用户数据库的管理维护、 初始化, 统一用户数据库账号与已有系统中账号的映射, 统一用户数据库的使用等情况。
4.3 生产调度报表平台
(1) 基于IBM Data Stage开发和运行 报表数据 采集作业 , 实现从各 二级单位 的系统数 据库中采 集报表数 据 。 IBM Data Stage是一套专门对多种 操作数据 源的数据 抽取 、 转换和维护过程进行简化和自动化, 并将其装载到指定数据集或数据仓库的集成图形化开发工具。 传统的数据整合方式需要大量的手工编码, 而采用Data Stage进行数据整合可以大大减少手工编码的数量, 而且更加容易维护。 Data Stage数据采集功能图如图3所示。
(2) 基于IBM DB2构建门户数 据库 , 作为运行生 产调度门户平台的支撑环境, 并临时存储各二级单位的通过门户平台填报的报表数据。
(3) 基于Oracle数据库构 建报表数 据仓库 , 作为报表平 台的数据源。
(4) 基于IBM COGNOS构建报表 平台 , 报表平台分 为数据建模和报表制作发布两个部 分 , 使用其DATA MANAGER DEVELOPER工具进行报 表建模 , 使用其BI CONSUMER工具进行报表制作与发布。
4.4 系统各平台间逻辑关系
(1) 在生产调 度门户平台上使 用表单配置 工具STS为各二级单位开发配置报表提报、 审核、 批准界面, 各二级单位的报表数据暂存在门户数据库。
(2) 从门户数据 库 、 以及各二 级单位已 有系统的数 据库中采集报表数据。
(3) 把采集的 报表数据 , 进行数据加 工 、 转换最后 存储到报表数据仓库中。
(4) 生产调度 报表平台使 用报表数 据仓库做 为报表建 模的数据源。
(5) 生产调度 报表平台中的 报表集成到生 产调度门户中 进行集中访问。
5 结语
通过基于SOA架构的数据整合平台的建设, 可以为公司构建一个高效、 灵活和易扩展的企业级IT集成架构, 既能充分利用现有业务应用系统, 提升现有业务系统的应用 价值 , 又能方便地与未来信息系统集成, 有效降低公司的IT投资和系统整合风险、 成本, 本平台的构建所带来的价值表述如下:
(1) 能够为员 工提供一 个 “ 一站式 ” 的协同工 作中心 , 实现所需信息的方便查找、 获取及展现。 减少技术培训和系统重装、 升级、 维护等工作量, 实现业务数据的自动交换和充分共享, 达到无纸化办公的目标。
(2) 使IT架构适应 “智能准能 ” 业务模式的 变化 , 真正做到随需应变, 快速实现SOA体验。 操作简单, 动态配置, 较好地解决生产企业缺少软件开发人才和经验技能的问题。
(3) 可为决策层 领导直观 、 动态地展 现关键指标 , 以提供决策支持, 为各级管理人员和管理层领导提供自动化业务报表。
(4) 能够实现 跨部门 、 跨系统的业务流程 的自动流转 和监控, 具有完整的信息反馈, 全面支持多部门、 多项目的协同工作, 从而提高业务处理效率, 降低生产管理成本。
架构整合 第2篇
达芬奇曾指出：一个好的设计应该是简单的。
这种观点容易理解，但当企业面临IT基础架构的简化问题时，他们应该往什么方向走，却是一件不易办到的事情。而IDC从全球众多大企业的CIO或企业主管了解到的情况显示：简化毫无疑问是帮助大家面对企业变化、市场变化的应用之道。
IDC也注意到，在众多其他需求跟基础设施满足简化要求的过程中，最主要的问题在于：怎样解决企业里信息孤岛问题，怎样让管理的数据变成可知性的业务信息，让CIO作更理想的评估和应急反应。
如果把企业想像成“泰坦尼克”，企业已经看到冰山了，那么CIO是否具备了快速反映市场需求变化的工具，是否能够帮助企业作出快速、有效的调整？
今天市场上有两个因素，一个是灯塔，一个是冰山。灯塔是引导企业作出相应变化的因素，这包括企业很多IT产品的商品化；另外一个因素是市场上还有很多冰山。很多企业面临的现状是， IT开支不断减少，IT预算也不再增加了。企业希望“少花钱多办事”。然而，在欠缺行业标准化的产业环境里，这似乎是一种“不可能的任务”。
提升服务，对专有操作系统的投入以及对安全性的顾虑，一直都是IT主管考虑的问题。怎样满足客户的需求提高效率，正在影响CIO作IT设施投入的相关决策。
在2004年，IDC就提出了整个企业转型的构想。在IT部分，IDC提出动态IT的转型。从整个动态角度来讲，是IT如何提供更多的业务战略自动化以及执行上的支持，帮助企业具备更好的市场反应能力，这部分涵盖的范围相当广，包括相关业务监测的分析、业务的流程和自动化，以及信息技术和接入界面的服务等，都在这个范畴里。
从另一个角度来讲，管理上强调IT运营的自动化，以及怎样达到更好的营运效率，这部分包括服务水平、管理、自动化、安全、基础架构的虚拟化、基础架构的设置乃至管理平台的监测，还有战略方面自动化的支持，像SOA，面向服务的架构，提供整体的支持；实现端到端的管理，帮助企业具备更好的市场反应能力；提供更多自动化执行上的支持；对整个IT运营来讲，使有效的管理自动化。
企业面临这些问题，到底应该作什么样的选择？很多企业在考虑，IT企业怎样降低成本，做有效的节约。从内容的技术和流程来讲，我们看到有的企业做主机托管和系统整合，借此实现更多的应用，采用更先进的系统管理，以达到资源共享与共用的IT虚拟化。当然有些企业选择了另外一条路，比如企业IT的外包，这也是一种降低成本的方案。
不管是整合也好，公共化也好，更多的是采用商品化途径。第一是通过整合的方式来实现企业IT的简化。不管是服务器上的整合，或者根据不同操作系统的情况，不同存储的应用进行整合，都会有不同的影响。我们看到企业上的整合，一般都可以做到30%的成本降低。有的企业通过适当的整合可以实现更多的成本降低。
另外是通过公共化进行整合，此时也要考虑到操作系统的数量，支持厂商的数量，还有通过商品化实现简化的过程，通过商品化的产品引用到IT上，可以达到比较好的成本降低。
目前很多企业都在谈虚拟化。为什么虚拟化渐渐成为市场上讨论的一个主流议题？也是因为在虚拟化过程中，通过对IT基础设施投入的调整，可以有效地、比较大限度地降低成本，最大限度可以达到80%。
IDC还注意到，在简化或整合过程中，很多CIO不知道数据中心到底怎样管理，进而提出各种不同的需求。
那么，怎样更有效地管理数据中心？第一，要明白哪些技术能够改变，或者是从面向服务基础设施中获益。例如刀片式服务器、多核技术的微处理器、存储和网络应用的技术，IT主管不能忽略这样的转变。
除了更有效地掌握IT技术，IT主管还必须同时了解企业业务运营模式将会作什么样的改变。因为企业运营模式的改变会影响他们在IT架构上怎样提供更有效的支持。从另一个角度来讲，系统集成商将发挥更大的作用。
五行理论与网络安全架构的整合 第3篇
计算机网络安全技术包含有包过滤技术、状态检测技术、应用代理网关、端口扫描技术、数字签名与加密技术等等,在拓扑结构和布局上也形成了以防火墙为主要防线的“围城”结构,然而现有网络还是不断遭到数据窃取和网络攻击,现有网络安全体系还存在固有的缺陷,导致网络的强壮性仍然不足。
1 目前计算机网络安全体系
目前的网络防范体系基本上是以“围城”为基本思路的,在被保护的网络边界设置数据包进出的“必经之道”,作为“军事要塞”。在主机上基本也采用这种思路,采用单机防火墙保护主机系统。
根据采用的技术不同,防火墙分为以下类型:包过滤防火墙;代理服务器;电路层网关;混合型防火墙;应用级网关;状态/动态检测防火墙;网络地址翻译NAT;个人防火墙;智能防火墙。
防火墙“围城”架构虽然在一定程度上有效保护了内部网络不受外部攻击,但也日益显示它的脆弱性:
(1)防火墙的操作系统不能保证没有漏洞;
(2)防火墙的硬件不能保证不失效;
(3)防火墙软件不能保证没有漏洞。防火墙软件也是软件,是软件就会有漏洞;
(4)防火墙无法解决TCP/IP等协议的漏洞;
(5)防火墙无法区分恶意命令还是善意命令;
(6)防火墙无法区分恶意流量和善意流量;
(7)防火墙的安全性与多功能成反比;
(8)防火墙的安全性和速度成反比;
(9)防火墙的多功能与速度成反比;
(10)防火墙无法保证准许服务的安全性;
(11)限制有用的网络服务;
(12)无法防护内部网络用户的攻击;
(13)Internet防火墙无法防范通过防火墙以外的其他途径的攻击;
(14)Internet防火墙不能完全防止传送已感染病毒的软件或文件;
(15)不能防范新的网络安全威胁。
2 五行理论框架
五行系统包括组成事物的五种基本物质(对象),五行,一曰水,二曰火,三曰木,四曰金,五曰土。五行的基本性质,水曰润下,火曰炎上,木曰曲直,金曰从革,土爰稼穑。
水有寒凉、滋润、向下、闭藏、终结等特性;火有温热、光明、变化、活动、升腾等特性;木有生长、兴发、生机、条达、舒展等特性;金有变革、禁制、肃杀、敛降、洁净等特性;土有生长、承载、化生、孕育、长养的特性。
五行学说利用五行的关系来取象类比,表现事物的关系和发展变化。就这种理论本身来说,是一种朴素的统一辩证法,在这个矛盾统一系统中,没有绝对的角色定位,没有绝对的攻击者,也没有绝对的防范者,角色是可以互相转化的,也是可以互相配合的,还可以互相钳制。五行生克关系如图1。
五行相生关系:木生火,火生土,土生金,金生水,水生木。
五行相克关系:木克土,土克水,水克火,火克金,金克木。
五行亢乘:物盛极为亢太过。凡事物亢极则乖,强而欺弱,这叫做乘。相克的两行,克人者太盛为亢乘。
五行反侮:事物亢极则乖,强而欺弱,被克者太盛为反侮。
五行生克关系是对事物的长期观察和经验积累的矛盾统一认识。广泛应用于古代的医学、建筑、政治、军事、文化等多种学科,是古代各学科的理论基础之一。
3 时空结构的整合
五行理论中互相制约的组件架构可以有效地解决现有防火墙系统的大部分局限性,这就要把现有的“围城”安全架构和传统五行理论进行整合,以得到新的网络安全体系。
3.1 网络安全与五行理论的术语对应
首先,网络安全技术中的哪一些技术分类到五行这五大组件中呢?这是人为的划分,主要目的是方便功能细化。网络攻击的技术要进行分类,并入五行之中;防范技术也要进行分类,并入五行之中。
划分大致如下:
(1)攻击技术划分:水式(旁路、陷门、信息泄露);火式(计算机病毒、完整性破坏);金式(授权侵犯、非法使用);木式(假冒、篡改);土式(拒绝服务)。
(2)防范技术划分:土部(数据加密技术、入侵检测技术、黑客防范技术);水部(病毒诊断与防治技术、安全审计技术);火部(访问控制技术);金部(数字签名技术、鉴别技术、攻击源阻塞技术);木部(网络嗅探技术、端口扫描技术、防火墙技术)。
3.2 安全技术“各自为阵”变为“有机集成”
传统网络安全技术基本上处于分立工作,互无往来的状态。比如实现审计技术的主机和防火墙主机并无关系。
五行架构将网络安全技术统一纳入系统中,分工合作,互通有无,协同作战。在五行架构中运用了所有的安全技术手段。
3.3 变阻止攻击为设置陷阱
传统的防火墙架构中,如果判断出现网络攻击数据包,就竭力阻止入侵。一旦防范失败,没有检测到恶意数据包,则这类攻击如入无人之境,城门洞开。
五行架构的安全体系,防范重点不在城门处,而是分布在系统的五个部分,形成一个互相制衡、相互援助的体系。
五行架构体系要先判断攻击的类型,或者说是网络访问的类型,再将访问数据包交由相应的“行部”处理。如果首先遭遇攻击的“行部”被瘫痪,则安全防范由体系中的其它“行部”接管,其它“行部”不仅要继续处理攻击数据包,而且要恢复被瘫痪的“行部”正常工作。这种思想来源于中医中的五脏相生的关系。
现有防火墙体系不能检测和处理内部网产生的网络攻击,新的五行架构将内部网数据包捕获功能、攻击源检测和阻塞功能加入五行之中,利用五行“生克”关系“克住”内部攻击源。攻克的方法可以采用现有的黑客攻击技术包括ARP攻击技术。
把判断网络访问类型并交由其它“行部”处理的过程称为“设置陷阱”。
3.4 变围城结构为五行递归结构
如前所述,传统的防火墙架构一旦防范失败,则城门洞开。
五行架构(参见图2“五行网络架构图”)中,一个“行部”不能对付的网络攻击,由另一个与之“相生”的“行部”而与外部访问“相克”的“行部”处理。当然,对于正常的网络访问也是这样,正常的网络访问通过五行系统验证就可以正常访问。
网络数据包在五行架构中流转的过程称之为“五行递归”。如果遇到网络攻击将首先遭遇的“行部”瘫痪,五行递归结构具有优良的自恢复特性,如前所述,安全防范工作由体系中的其它“行部”接管,其它“行部”可以恢复被瘫痪的“行部”正常工作。
3.5 变主机独立对抗为五行组合对抗
传统的网络安全体系一般为主机独立对抗,如果出现恶意攻击,主机孤立无援。防火墙也是一台主机,它没有向其它主机求援的功能,主机之间也没有互相援助的功能。
五行架构的思想是分工负责,协作对抗,互相援助,循环往复。“木部”生“火部”,克“土”式攻击(或者检验“土”式网络访问);“火部”生“土部”,克“金”式攻击(或者检验“金”式网络访问);“土部”生“金部”,克“水”式攻击(或者检验“水”式网络访问);“金部”生“水部”,克“木”式攻击(或者检验“木”式网络访问);“水部”生“木部”,克“火”式攻击(或者检验“火”式网络访问)。循环往复,生生不息。
“木部”生“火部”,就是“火部”是“木部”的后继者,当“木部”处理了网络访问后,就交由“火部”处理,还有一个意义,当“火部”瘫痪,由“木部”来负责恢复运行;
“火部”生“土部”,就是“土部”是“火部”的后继者,当“火部”处理了网络访问后,就交由“土部”处理,当“土部”瘫痪,由“火部”来负责恢复运行;依此类推。
3.6 大五行与小五行
网络中的五行架构同样适用于一台主机内部,主机内部的“小五行”组成最后一道防线,共同防范越过“大五行”的网络数据包。当大五行系统配置不阻止未知类型的数据包时,这个“小五行”主机防范系统保障主机得以安全运行。
3.7 网络安全五行结构的类定义
为了说明实现的大致框架,用Rational Rose做了框架的类定义。如图3、图4所示。
4 总结
用五行理论整合的新的网络安全架构协作性更强,将大量的网络安全技术集成到这一体系中,运行机制循环往复、井然有序,能更有效地防范网络攻击,网络安全系统的强壮性大大提高。同时,将内部网络攻击的检测和阻塞功能加入五行体系中,保证内部网的相对纯净,使内部网络主机不再疲于应付大量恶意的内部攻击数据包,提高网络运行效率,保障网络安全。
参考文献
[1]杨云江.计算机与网络安全实用技术[M].北京:清华大学出版社.2007.
[2](美)Chris Hare.Internet防火墙与网络安全[M].北京:机械工业出版社.1998.
架构整合 第4篇
为了解决政府、企事业单位多个应用系统的互连互通、数据共享、业务流程协调统一的问题,企业应用集成解决方案就应运而生。ESB总线集成方案出现以前信息系统间的交互、共享主要采取的是点对点和HUB/SPOKE的方式。
点对点应用集成模式
最早两个独立的信息系统之间出现交叉联系,主要是基于某项特殊需求实现的。随着时间推移和业务发展,这种交叉联系越来越多,并频繁出现在多个系统之间。交叉需求的增长导致各系统连接数量成倍增长,管理无序、网络负载和错误率等指标都急剧增长。更重要的是,节点间缺乏必要的协同能力。如图1所示。
HUB/SPOKE形式应用集成模式
为了解决传统点到点应用模式中的问题,出现了HUB/SPOKE形式的集成解决方案。该解决方案将所有交叉联系简单地进行了集中开发和管理,从而一定程度上减少了用户业务管理复杂度和出错概率。
但在HUB/SPOKE的方式中,进行信息交互时,每次都需要经过中心节点,导致整个系统的效率严重依赖于中心节点,出现效率瓶颈。
更重要的是,这种解决方案只是简单地进行接口服务的集中、缺乏灵活性和可重用性,也就是说同一个功能的接口对应不同的技术应用特点都需要做不同的开发;同时这种集中管理缺乏一整套的管理配套保证其可靠性和安全性。如图2所示。
ESB总线的应用集成方案
ESB是企业应用集成在SO A时代下的一种形态。区别于传统的企业集成技术,ESB不仅支持高度的分布式部署,同时支持异步消息交互,强调为服务消费者提供符合标准的服务。
通常情况下各信息系统对外提供的访问接口所采用的技术不尽相同、形式各异,该方案将其进行封装、转换、编排成统一的服务纳入总线(即服务库)对外发布、共享。通过配套的资源管理以及监控管理降低集成开发难度,提高重用,增进系统开发和运行效率,使系统重构更灵活,快速适应业务及流程变化需要。如图3所示。
实现ESB方案的关键技术
1.适配器
适配器是外系统接口纳入ESB总线的桥梁,是多种异构系统之间互连互通及互操作的关键,遵循JCA标准。一般ESB总线类的集成开发环境都附带多个常见适配器,如结构化及非结构化文件适配器,Oracle、DB2、MySql、Lotus、Access等数据库适配器,FTP、SMTP/POP3、JMS等通讯类适配器等。
除了系统本身集成的适配器之外,它还提供了适配器开发工具,便于用户开发适合自己需要的定制适配器,并无缝集成到ESB总线中。
2.数据转换
在跨系统整合中,数据转换一定是集成中会碰到的问题。包括简单数据类型之间的转换,例如不同开发工具开发的系统A与系统B之间整型、浮点型、字符型及日期型等数据转换;还有格式复杂的数据对象之间的转换、过滤,例如系统A的数据对象“稿签”与系统B中对象“稿件”。
对于复杂数据转换,ESB提供了XSLT服务进行支持,XPATH在数据筛选和过滤上是非常强大且易于掌握。
不管是对简单数据类型转换或者复杂的对象型数据,ESB都提供了数据转换器,集成用户只需要在其上做些简单的映射就可以完成跨系统的数据转换。针对用户自己的需求,ESB方案也允许用户编辑修改这些转换器或者自定义数据转换器,这些转换器能够无缝纳入ESB平台中进行重用。
3.合成编排
所谓合成编排,是指将简单服务按照某种流程组合成新服务的过程。合成后的新服务被称为复合服务;用于合成复合服务的简单服务称之为构件服务。ESB服务合成分为静态合成和动态合成两种类型。在设计阶段就定义了复合服务流程的合成方法是静态合成;与此相对应,在运行时刻所需服务才被选择和调用的服务合成则是动态合成。
在静态合成中,复合服务在设计阶段就被定义。合成过程对于服务请求者来说并不可见;服务请求者可以像调用简单服务那样调用复合服务。
动态合成是指,在运行时刻选择和调用所需简单服务并将之合成为一个复合服务的过程。例如一个商务旅行管理系统,它通过与路线管理、租车服务、机票预定、酒店管理等系统的协作为客户安排旅行事宜。像这样的一个复合服务不可能事先就定义好所需的构件服务以及它们之间的工作流程。将一个复合服务设计成动态的还是静态的,取决于复合服务的性质及其应用域。
ESB方案提供了对WSFL(Web服务流语言)的支持,它既支持复合服务的静态配置,也支持在ESB总线内动态查找简单服务。
4.WEB服务
信息系统对外提供服务的方式是各种各样的。在现今互联网无处不在的时代,将信息系统的服务封装为WEB Service已是主流方式。已出现的ESB产品化平台都已提供了快速开发WEB服务的工具和向导,能够将用户现有的应用接口或第三方提供的Web服务快速接入服务总线,并由服务总线统一对外提供服务。采用Web方式对外发布服务将使系统的扩展性极大提升,为在互联网中跨企业、跨地域协作打下基础。如图4所示。
5.资源、监控管理:
将大量服务纳入总线对外统一发布,将不可避免的面对各类服务请求者以及对服务的分类管理。管理对象包括服务、组件及其它各种系统资源,为开发者和运维人员提供用户管理、权限控制、资源目录服务等功能。
ESB监控管理基于JMX标准,其功能可扩展,并允许用户编程定制访问。ESB提供各种监控工具方便用户查看系统运行状态,跟踪服务、业务流程运行信息,并对监控对象进行分析、诊断。
ESB方案的特点
1.松耦合:服务请求者与服务提供者之间,根据约定的协议,通过服务接口进行交互。服务接口封装了所有的实现细节,对服务请求者透明;
2.可重用:服务是总线中的基本元素。一个业务服务可以在多个业务流程中得到复用。并且随着业务要求的改变,仅需对其实用服务进行重新编排,并不修改服务本身,服务在变化后的新的业务流程中能够继续使用;
3.高效率:通过组合现有服务以快速创建新服务或应用,使开发者集中精力于数据共享而非底层实现;
4.基于开放式标准:基于J2EE规范实现,保证了总线本身以及创建的服务、组件、业务流程能够跨操作系统平台部署和运行;遵循JCA,保证了异构系统在集成平台上的连接;支持JMX为方案,植入跨平台管理框架,方便对总线中的服务运行状况进行监控;支持SOAP、WSDL为服务封装、编排提供不同力度的支持,大大提高了服务的的灵活性和可重用性;支持WEB Service访问,使各类服务请求者都能够方便地使用集成平台中的服务。
探讨ESB集成在采编系统中的应用
采编系统业务现状
新华社新闻产品分为文字、图片和音视频三类,由于历史原因,这些产品无论是素材采集或加工处理都分布于不同的部门和信息系统。随着新闻业务的发展,图、文以及视屏的混合产品已成为常态,原本相互独立的系统为满足需求逐渐建立起了非常复杂的交互进行协作。这种交互是典型的点对点模式,新增一项需求,就对原有的相关系统进行一次改造。这些联系缺乏统一的规划,在新闻业务快速发展的情况下,系统的升级改造、运行维护的难度和复杂度加倍提高。如图5所示。
目前业务系统交互存在以下瓶颈:
1.数据扩展瓶颈。虽有CNML作为稿件交换的统一规范,但在新闻报道阵地前移的趋势下,对CNML的扩展提出更多要求。例如由内网向互联网发送带链接信息的微博稿,CNML就没有对链接信息的定义,这就需要在不改变原有规范情况下,增加新的数据转换定义及转换满足需求;管理数据的格式没有规范,例如稿件发送回执,在各系统间的定义各异,未纳入统一管理。
2.系统间数据交换方式多样。既有FTP文件Get/Put方式、也有JMS消息传递,还有通过跨系统接口直接访问对方数据库获取数据的方式。这些分布零乱的的交互大大增加了系统复杂度。
3.系统间访问接口受各自原有系统采用技术限制,灵活性和可重用性非常差。例如,同样功能的传稿业务,使用Notes技术的编辑系统向使用C/S方式的移动报道系统传稿接口就不能被分社系统调用。同样单个系统内部的访问接口也不能被外系统所重用。
4.数据转换以及访问接口上的瓶颈不仅在二次开发和管理维护上增加了各种成本,也大大限制了新华社业务向外的衍生扩展。在全媒体时代,系统集成不应只把焦点放在提升新华社内部几个系统整合效率,还要为与社外机构系统间协作留有扩展的空间。
ESB集成在新闻系统整合中的构想
采用ESB集成方案对现有系统进行整合能在不影响现有系统运行的情况下进行。可分为以下几步展开:
1.首先对现有的系统间接口和数据定义及转换进行梳理,通过数据适配器或将接口封装成Web服务纳入总线。完成前面的工作后,各系统就可在总线上获取新的数据或接口。这一步将实现对分散部署的接口或数据转换统一管理。
2.对单个系统进行分解,生成一个个独立的简单服务,并把它们封装成Web服务。只要遵循ESB方案的各项规范,这些简单服务既可以直接调用,也可以通过合成编排生成各种复合服务。
3.完成以上工作后,各系统展现层就可调用以上服务实现原来的功能,实现向ESB集成的平滑过渡,原系统中间层被取代。这时原系统各部门的注意力将放在总线上与其业务相关的各类子服务以及复合服务的开发管理上。如图6所示。
架构整合 第5篇
关键词：面向服务,消息总线,建模
0 引言
20世纪90年代中和本世纪初,中国IT经历了一个迅速膨胀的10年,在这10年里,各大公司为了提高工作效率,降低工作成本,使用各种方法和技术疯狂地搭建起了各种各样的平台,大量相似的或者有关联的数据被分散到了各个系统里。近些年,高效经营大行其道,各大公司开始将目光投向了全方位数据分析和挖掘。但是每个系统都是独立运行的,数据都是不能共享的。比如银行的客户数据存在CRM系统中,账户数据存在交易系统中,贷款数据存在信贷系统中,如何将这些独立的有关联的数据整合起来做全方位的实时分析,成了最近几年一个比较热门的技术问题。
本文所述的异构数据库的整合框架是以SOA为基础,ESB为消息传递总线,通过两级建模,将不同数据库系统、不同操作系统、不同语义结构的数据资源进行整合,用户通过统一管理平台能够对多个数据库资源进行访问,如同访问一个数据库系统一样。从而提高信息资源整体使用效率,有利于实现信息资源的共享。
1 相关技术
1.1 SOA
面向服务架构(Service Oriented Architecture,SOA)是一种灵活的、松散耦合的系统架构。在SOA的架构里,功能被封装成了可以相互调用的服务提供给外部系统。这些服务可以位于不同的地方,采用不同的数据库,采用不同的编程语言。这些服务具有定义良好的接口,可以灵活地组合成各种各样的应用,在提高灵活性的同时,也最大程度上提高了代码的复用率,减少了开发和维护的工作量。
1.2 Web Services
Web Services是一种支持机器间通过网络相互交互的分布式计算技术,是一种使用标准的XML语言和SOAP信息格式的全新的技术架构,主要包括用于进行服务描述的Web Services描述语言(WS2DL);用于用户服务的发布和集成的统一描述、发现和集成规范(UDDI);用于服务调用的简单对象访问协议(SOAP)。Web Service一旦部署以后,其他Web Service应用程序可以通过HTTP发现并调用它部署的服务。因此Web Services按照角色可以分为Service Registry、Service Requestor和Service Provider,Service Provider可以通过Service Registry发布服务,Service Requester可以通过Service Registry查找到Service Provider发布的服务,并且调用Service Provider发布的服务。
1.3 企业服务总线
企业服务总线(Enterprise Service Bus,ESB)就是在SOA架构中实现服务间智能化集成与管理的中介,是网络中最基本的连接中枢,是构筑企业神经系统的必要元素。ESB是逻辑上与SOA所遵循的基本原则保持一致的服务集成基础架构,它提供了服务管理的方法和在分布式异构环境中进行服务交互的功能。ESB提供了如下五个基本功能:服务的元数据管理、传输服务、中介、多种服务集成方式、服务和事件管理支持。
1.4 已有框架分析
由于在企业里存在着大量的系统,数据就有可能分散在不同的数据库里,甚至是不同的服务器,不同的机房,对这些数据进行统一管理和分析成了一件异常困难的事情。比较传统的集成方法主要有下面三种:
(1)中间件编程。通过中间件编写程序连接到不同的数据库上,调用该数据库的语法取出想要的数据到中间件,然后进行分析。这样做的缺点是不够灵活,管理复杂,并且中间件负载较大。
图2基于中间件编程(参见下页)
(2)搭建数据仓库。将数据通过ETL工具抽取到一起,进行分析。这样做虽然可以克服掉方法(1)里的一些缺点,但是本身的缺点是数据仓库庞大,实施复杂并且时间较长,很难实现数据的实时运行。
图3基于数据仓库(参见下页)
(3)XML。通过中间件编写程序,使用XML技术,屏蔽掉异构数据库的差别,通过配置文件控制数据库信息。这样做虽然可以克服方法(2)的一些缺点,但是本身的缺点是所有数据都需要经过中间件服务器的中转,是系统的瓶颈,同时增加删除数据库时往往要停止服务,会产生一段时间的停机。
2 整合框架
2.1 系统架构
本方案在方法(3)的基础上对系统架构作了一个全新的改进,引入了SOA的概念和技术,可以解决复杂不灵活、非实时和性能瓶颈等诸多问题。该方案的外部表现如图5所示。
该结构的最大特点是引入企业服务总线,将各种异构数据通过建模→转换→发布三个步骤连接到这条总线里,对外提供服务。同时其他外部应用也通过Web Services连接到这条总线上,通过发送SOAP消息调用不同的数据库服务,进而拿到想要的数据进行各种分析处理。由于Web Services技术已经应用非常成熟,现行几乎所有的编程语言都已经支持这种技术,因此几乎所有外部应用都可以连接到总线上,比如网页程序、手机程序、分析挖掘程序等。
2.2 系统的主要模块
本文所介绍的框架主要包含三大部分:a.数据层,负责数据库节点的管理,模型的封装和服务的发布等。b.事务层,负责请求的接受,身份的认证,请求的处理等。c.企业服务总线,负责服务的管理,消息的传递,第三方工具的集成等。
该框架所涉及的主要模块的作用如下:
(1)节点。每一个数据库表示成一个节点,节点对内通过使用模型封装了不同的数据库实现,对外统一发布成Web Services接口供主集成引擎调用。
(2)节点管理器。负责节点的发布、删除和监控。
(3)模型管理器。通过建模工具,将异构数据库表示成统一的实体模型,再将实体模型封装成业务模型,供不同节点和数据库交互时使用。
(4)主集成引擎。接受请求管理器发过来的SOAP请求,解析SOAP请求,根据请求类型实例化成session bean或者普通java bean,根据元数据模型将请求分解成更细力度的请求交给ESB总线,等待然后接受节点返回的XML数据,返回给请求管理器。
(5)请求处理器。接受外部系统的请求(可以是SOAP/RMI),负责将这些不同类型的请求解析成统一的格式后,转发给主集成引擎。
(6)认证和授权。控制用户的登陆和授权。
(7)事件管理器。事件管理器通过队列服务器来管理消息请求。事件请求者将请求作为消息放到请求队列里,事件管理器定时监控请求队列,取出消息请求,然后将处理结果放回结果队列。是一种异步的相应方式。
由于所有的模块都是通过ESB总线进行交互,所以它们的物理拓扑就非常的简单。中间一条服务总线作为消息传递的媒介,其他各个模块将服务注册到服务总线上,由总线进行消息的路由。
图7系统的物理结构图(参见下页)
3 框架实现
3.1 用例图
该框架包括如下功能:
(1)增加数据:用户可以为所有异构数据库同时插入数据,或选择部分数据库同时插入数据。
(2)修改数据:用户可以为所有异构数据库同时修改数据,或选择部分数据库同时修改数据。
(3)删除数据:用户可以为所有异构数据库同时删除数据,或选择部分数据库同时删除数据。
(4)分库查询:用户可以选择部分数据库查询数据。
(5)联合查询:用户可以同时查询所有数据库数据。
(6)管理节点:用户可以增加、修改、删除节点信息。
(7)监控节点:用户可以监控每个节点的状态。
(8)管理模型:用户可以修改业务模型和实体模型。
该框架的基本用例如图8所示。
3.2 数据流
假设外部系统通过Web Service发送了一个查询消息给请求处理器,请求处理器会对消息做一个一级解析,解析后将消息通过Web Service转发给主服务器引擎的请求/响应模块。请求/响应模块进一步对消息进行解析,根据解析出来的消息类型确定初始化哪种处理器,然后初始化后的Bean去调用一级模型层里的业务对象,业务对象模块根据元模型定义,查找到应该调用哪些实体对象,然后通过发送Web Service请求到不同的数据库节点,由各数据库节点的实体对象模块通过O/R Mapping工具访问数据库取出所需要的数据,然后再逐级返回。对于增加/删除/修改的操作,业务对象会通过两级提交的方式来保证事务特性。
返回时首先由数据库返回行数据给O/R Mapping工具,O/R Mapping工具将行数据转成对象数据。实体对象模块将对象数据序列化成XML格式,封装成SOAP响应消息返回给业务对象模块。业务对象模块接收到所有节点发来的SOAP响应消息后解析成统一的业务对象返回给处理器,处理器继续将业务对象返回给请求/响应模块。请求/响应将业务对象序列化成XML格式,封装成SOAP响应消息返回给请求处理器。请求处理器接受SOAP响应消息,将数据转换成外部系统所要求的格式返回给外部系统。
该系统的流程图如图9所示。
该系统各模块之间的调用关系如下面的序列图所示。
4 结论
本文在传统异构数据库整合架构的基础上,通过引入SOA思想、Web Services和企业总线基础,不但可以屏蔽掉异构数据库的差异,而且可以解决老系统的复杂不灵活、非实时和性能瓶颈等诸多问题,可以成为企业进行全方位数据分析和整合的基础数据平台。
目前的工作尚且针对框架的设计,在实现的过程中会有诸多困难,比如安全性、并发行、如何设计模型等,下一步将就如何实现该框架做进一步的研究。
参考文献
[1]易建湘.Web Service及其在异构数据库环境中的设计[J].广西轻工业,2008(7):75-78.
[2]齐艳珂,肖连,高洁.异构数据集成技术综述[J].福建电脑,2007(6):39,63.
[3]侯占伟,莫林,郑华,等.基于SOA的数据库中间件的研究与设计[J].计算机应用研究,2007,24(6):284-286.
[4]Endre IM,Ang J,Arsanjan IA.Patterns:service orientedarch i2。tecture andWeb services[EB/OL].(2004,2,04).http://www.redbooks.ibm.com/redbooks/pdfs/sg246303.pdf
架构整合 第6篇
关键词：云计算,视频监控,边防管理
0 引言
近年来,全国公安边防部门已建成较大规模的边防视频监控联网共享平台,在视频指挥调度、执勤区域管控、内部管理等领域得到了广泛应用。但总体而言,视频监控系统应用层次还比较低,主要表现在:①视频监控实战应用深度不足。主要用于区域防范、事后查证等,缺乏与边防实战紧密结合的功能深度挖掘;②视频图像存储能力需进一步提升。由于视频录像占用存储空间巨大,目前主要存储方式还是以前端DVR、NVR存储为主,未实现分级分类存储的规范化管理;③视频图像价值信息未得到有效提取。大量视频图像资源价值信息沉淀于系统中,发现、检索较为困难,并且连续视频流等非结构化信息难以与边防业务应用系统信息直接进行关联分析和碰撞比对,从而产生有价值的结果;④视频图像信息智能化应用水平低。由于视频图像数据量大、价值密度低,传统的数据处理分析技术不能满足海量视频数据分析处理的需要。
随着视频编码技术、视频存储技术、视频内容分析以及信息技术的发展,视频监控正向网络化、高清化、智能化方向发展。目前,公安边防各级都在进行视频监控高清化、智能化改造,但大规模高清智能化给系统设计、部署带来一系列现实问题:网络带宽紧张、存储空间庞大、对计算机性能要求成倍增加等。因此,采用云计算、智能视频分析等技术升级改造现有视频图像监控系统,利用云计算的分布式存储、分布式计算优势,建设云架构下视频监控数据整合和应用平台,可有效解决视频图像数据采集整合、价值信息提取、数据结构化处理及存储应用模式变革等问题,以实现视频监控深度智能化应用。
1 关键技术
云计算是分布式计算、并行计算、网格计算、多核计算、网络存储、虚拟化、负载均衡等传统计算机技术发展到一定阶段,与互联网技术融合发展的产物[1]。在视频监控领域使用云计算技术,可以将各类视频监控接入到统一的云平台,在后端通过发动网络内闲置节点进行智能化分析,从而以较小的设备投入换回更多的智能化工作回报。
1.1 视频图像云存储
随着网络化、高清化视频监控的逐渐普及,视频监控图像的存储系统成为整个系统中的重要支撑产品,因此一个安全、稳定、可靠的视频监控存储平台,成为监控报警、智能分析等关键工作的重要支撑。随着网络视频监控应用范围的逐步扩大,要求进行省级乃至全国范围内跨区域的大联网,以实现视频数据共享,但传统分散存储模式的DVR、NVR给视频数据的共享带来了技术上的阻碍,集中存储模式的云存储将成为视频监控存储的主流模式。
云存储[6]是在云计算概念上延伸和发展出来的一个新的概念,是指通过集群应用、网格技术或分布式文件系统等功能,将网络中大量各种不同类型的存储设备通过应用软件集合起来协同工作,共同对外提供数据存储和业务访问功能的一个系统。云存储可以实现存储完全虚拟化,大大简化应用环节,节省客户建设成本,同时提供更强的存储和共享功能。
高清视频监控存储是一种以大码流多并发写为主的存储应用,对性能、并发性和稳定性等方面有很高要求。视频云存储系统对分布式存储节点(云服务器)进行集群化管理,视频监控系统前端采集的图像资源通过网络方式传输并存入云存储系统,为视频图像的深度应用提供了数据支撑。
1.2 视频云处理
视频云处理采用分布式计算、并行计算处理等云计算技术,依托视频智能分析技术,通过人工或前端智能识别与后台智能分析处理相结合的方式,开发视频自动结构化描述功能,从非结构化视频中提取、应用结构化信息。
视频云处理系统主要包括分布式文件系统、分布式数据库、全文搜索引擎、分布式协作服务等模块。
1.3 智能视频分析
视频监控的数据量非常大,而用户真正需要的信息只是少部分,或者说真正需要监视的只是发生概率很小的某些事件。智能视频分析技术通过从海量的视频数据中获取有价值的信息,能够将视频监控从静态的事后取证变成动态的实时预防和告警。随着技术的发展,智能化的监控系统将要求事发前能够识别并作出正确判断,为人们提供最为有效、及时的快速反应措施。
通过云计算平台,可为智能视频分析提供超强的存储和计算能力,视频数据存储在云存储文件系统(如Hadoop的HDFS)中,可以使用Map/Reduce大规模并行计算处理图像识别、人脸识别、行为检测、移动跟踪等需要进行大量CPU计算的任务。
智能视频分析的关键是目标特征的提取,并对目标特征的视频数据进行结构化描述。在边防视频系统建设过程中,需重点探索视频图像中的人、车(船)等目标自动化特征提取,为业务系统应用提供数据来源。
1.4 视频云搜索
视频云搜索技术,是基于大数据服务、视频图像库,实现海量数据的快速检索,采用分布式多节点并行处理技术,提高搜索反应效率,高效生成透明、多维的检索结果,并可按照互联网搜索引擎模式展示给用户,对检索结果进行动态、多维呈现,支持多种检索方式。①关键字检索功能:通过关键字信息对视频图像信息进行检索;②模糊检索功能:通过配置同义或同音词典,提供对输入的关键字的同义或同音词进行模糊检索,从而得出较多的检索结果;③高级检索功能:高级检索可根据自定义检索关键字或多字段组合进行数据检索。
2 平台模型
边防云架构视频数据整合与智能化应用平台应以构建边防立体化防控体系、有效提升边防部门社会管理能力为目标,实现边防内部图像信息资源、边海防图像信息资源、社会面图像信息资源等数据整合、处理分析和深度挖掘,构建云框架下的视频监控应用体系,开展边防视频图像大数据技术研究与智能化应用,为边防指挥调度、情报研判、边境管控、治安防控、社会服务等工作提供强有力支撑。平台技术框架模型如图1所示。
2.1 视频数据采集整合
该层的主要任务是统一组织管理平台涉及的各种物理资源,包括前端摄像头、网络视频服务器、数字硬盘录像机、各种服务器、集中式/分布式存储设备、网络传输设备、传感设备、定位设备等,将硬件资源封装成服务,汇聚整合来自视频监控联网共享平台、社会面图像监控、边海防监控系统、各类无线图传系统以及移动警务通、移动图像终端、执法记录仪等图像终端采集录入的视频图像资源,以及通过智能分析处理获取的信息资源等非结构化、半结构化和结构化数据信息,包括视频、音频、图像、文本、日志、记录等。
该层依次解决如下两个问题:①建立以广域网络技术为基础的、低成本、高效能的数据中心,采用高带宽、高可靠性、兼容大量异构设备和计算节点的二层网络结构,连接各种异构硬件资源,存放海量数据;②应用虚拟化技术,为系统整体管理、配置、检索所有的设备提供统一的标准,保证品牌繁多、架构各异、视频码流格式不同的众多设备被抽象成相同的接口,使上层调用可忽略底层的复杂物理特性,透明地访问各种类型的设备,从而为上层提供弹性、可靠的基础设施服务。
2.2 视频数据存储处理
视频监控系统一般具有监控点多、视频数据流大、存储时间长、24小时连续不间断作业等特点,视频存储设备在数据读写方式上也与其它类型系统不同。
(1)视频云存储。面对海量视频数据,采用具备大容量、高性能、大数据融合等特性的云存储架构,与边防信息资源库协作配合,实现海量数据的高速转发与计算。视频云存储架构同时应用于视频、图片混合存储,承担整个系统内视频和图片的数据写入、读取工作。云存储系统采用基于云架构的分布式集群和虚拟化设计,在系统内部实现多设备协同工作以及性能与资源的虚拟整合,最大限度地利用硬件资源和存储空间,将云存储的存储及管理功能进行打包,通过开放透明的应用接口和简单易用的管理界面,与上层应用平台整合,为监控系统提供高效、可靠的数据存储服务。
(2)视频图像信息数据库。从视频图像信息中筛选出有价值的视频线索或证据,并对有价值的信息进行集中存储和管理,分原始库和处理库两级存储。原始库主要用于存储有价值的视频图像原始文件,处理库主要用于存储经过视频摘要处理、图像处理工具处理、标注描述、智能化应用的与主题相关的视频片段、图片及其它信息等。视频图像信息数据库应采取云计算技术,利用分布式文件系统或分布式数据库,以支持存储容量和存储管理的平滑扩容、升级。
2.3 视频数据服务
通过采用分布式文件系统、分布式数据库、分布式资源管理、分布式计算、全文搜索引擎等新技术,为海量数据的存储、检索、分析、统计、挖掘等服务提供强大的技术支撑。根据当前边防实战业务需要,采用图像智能化分析处理技术与人工相结合,与边防其它信息系统对接,开展图像信息深度应用。
2.4 数据服务接口
依托边防一体化平台服务总线,提供统一标准的应用服务接口,实现与其它业务系统的关联对接,为指挥调度、治安防控、情报研判、边境防控、图像侦查等其它系统提供应用支撑。
2.5 系统运行管理
建设视频信息资源运行管理和监管系统,配置网管服务器、网管终端、维护工具等设备,承担对系统内所有节点网络与传输设备、前端监控设备、编解码与硬盘录像设备、计算机与数据存储设备等各类设备的日常运行状态监测、故障处理响应、资源分配、调度控制以及入网管理和考核管理等功能,承担对各类图像监控资源图像质量的分类巡检和考核管理功能。
2.6 系统安全管理
包括设备物理安全、入网设备安全、主机服务器安全、数据安全、应用安全、边界安全等内容。
3 平台应用
云架构视频监控数据整合与智能化应用平台的各项功能,可让视频监控从人工抽检、查看,发展到高效事前预警、事后分析,实现智能化的信息分析、预测,可为边防业务工作带来深刻变革。
在边境重点部位、重要出入通道、港口码头和领海(3海里)渔船(民)聚集等地点,充分利用视频监控开展区域内人员、车辆、船舶等的搜索、捕获、识别和报警等应用,提高边(海)防智能管控能力。利用平台的云存储技术特性,可以实时存储、调用大容量的视频、图片、声音、传感器信息等监测数据,也能够快速响应支持各信息处理节点的数据调用需求。利用平台的云计算技术,可以调动、均衡和充分利用系统资源,及时完成各类数据的智能分析和数据挖掘等功能。
(1)智能区域检测。综合利用视频监控、雷达等多种方式,对指定边防管理区域实施智能检测,按照预定策略实时检测指定区域的进入、离开、越过、滞留等行为进行智能判定,并针对违规行为产生报警信号。
(2)身份识别。对通过智能卡口或口岸的人员实施智能身份识别,按照智能策略实施警示;采用牌照识别技术手段,自动识别车辆相关信息,按照智能策略实施警示;结合AIS、GPS、北斗等传感器信息,对海面、港口船只进行身份识别和筛选。
(3)运动目标智能分析。对运动车辆、船舶的运动轨迹进行智能预判,及时发现特定区域出现的徘徊、滞留等行为,并加以预警。
(4)群目标/单目标智能检测。对于边境区域的人群聚集活动,采用群目标/单目标检测技术,给出人员数量,完成目标区分。
(5)早期预警。通过多传感器的探测数据进行有效融合和智能分析,甄别威胁目标情报,对陆海边界以外的威胁目标进行不同级别的预警;在陆地边界、港口、海岸线上采取物理手段延缓目标进入,并通过光电手段给出警示;当目标已经进入指定威胁区域内则给出告警,并生成目标威胁度评估值,再根据上级指挥所的命令、指示、计划或自主制定的作战方案,通过话音、图像等态势共享手段,指挥协调附近的部队前往进行拦截。
4 结语
云计算技术的出现和逐步成熟,为信息化建设提供了新的思路和方法。公安边防视频监控系统建设中遇到的视频数据整合、视频智能分析与搜索以及资源共享等问题都可以通过云计算的方法得到很好的解决。但目前云计算在边防部门的应用才刚刚起步,实际应用案例还比较少,为了真正将云计算的思路和方法更好地应用到视频监控系统建设中,还需要持续开展大量的研究和尝试。
参考文献
[1]高枫,刘洋.浅谈“云计算”[J].电脑知识与技术,2010(33):9454-9456.
[2]王俊修.基于云计算架构的视频监控系统应用研究[J].中国安防,2011(8):93-96.
[3]高大志,孙庆超.基于云计算技术的视频实战应用平台[J].中国安防,2015(1):71-76.
[4]李敬.基于云计算的视频监控平台的研究[J].现代计算机,2014(13):65-69.
[5]任文植,邓玲玲,马君毅,等.常州市视频大数据实战应用平台建设[J].警察技术,2015(5):60-63.