医学保障信息系统方案

1、医学保证信息系统方案医学保证信息系统方案1 / 33 医学保证信息系统方案目录1 项目概述 . 2 整体设计 . 2.1 设计原就 . 2.2 技术线路 . 2.2.1 J2EE技术 . 2.2.2 XML技术 . 2.2.3 Web Service技术 . 2.2.4 平台化、构件化设计 . 102.2.5 面对服务架构（ SOA）. 112.3 总体框架 . 2.4 规律架构 . 2.5 系统架构 . 2.6 应用支撑平台 . 3 数据采集与交换平台 . 3.1 数据统采集与交换平台架构 . 3.2 数据采集与交换方式 . 4 基于云运算的数据中心 . 4.1 网络子系统 . 4.1.1

2、概述. 4.1.2 网络拓扑结构设计 . 214.2 资源池子系统 . 4.2.1 概述. 4.2.2 运算资源池 . 4.2.3 储备资源池 . 4.2.4 网络资源池 . 4.3 本地备份子系统 . 4.4 云运算数据中心基础支撑系统 . 294.4.1 云运算资源治理系统 . 292 / 33 医学保证信息系统方案4.4.2 云储备资源治理系统 . 295 业务系统设计 . 5.1 健康治理与促进系统 . 5.2 数据监测与治理系统 . 5.2.1 数据抽取与整合 . 5.2.2 数据查询与统计 . 5.3 商务智能分析系统 . 6 安全体系 . 3 / 33 医学保证信息系统方案 1

3、项目概述4 / 33 医学保证信息系统方案2 整体设计2.1 设计原就1、有用性原就 以实际需求为基础,充分考虑进展的需要来确定系统设计；2、安全性原就 系统将供应安全手段防止非法入侵和越级操作,应用系统和软硬件都应遵 守相关的规定,符合国家有关电子政务系统安全的要求；3、牢靠性原就 系统将进行严格的牢靠性测试,保证系统中运行过程中能够连续、牢靠的 不间断的为用户供应业务服务；4、成熟和先进性原就 系统结构设计、系统配置、系统治理方式等方面采纳国际上先进同时又是 成熟、有用的技术；5、规范性原就 系统设计所采纳的技术和设备应符合国际标准、国家标准和业界标准,为 系统的扩展升级、与其它系统的互联

4、供应良好的基础；6、开放性和标准化原就 在设计时,将供应开放性好、标准化程度高的技术方案,系统的各种接口 满意开放和标准化原就；7、可扩充和扩展化原就 全部系统不但满意当前需要,并在扩充模块后满意可预见将来需求,保证 建设完成后的系统在向新的技术升级时,能爱护现有的投资；各功能模块间的 耦合度小,以适应业务进展需要,便于系统的继承和扩展；8、可治理性原就 系统应易于治理,易于爱护,操作简洁,易学,易用,便于进行系统配 置,能够很好的监控设备、安全性、数据流量、性能等方面内容,并可以进行 远程治理和故障诊断；系统应具有良好的结构,各个部分应有明确和完整的定 义,使得局部的修改不影响全局和其他部分

5、的结构和运行；5 / 33 医学保证信息系统方案2.2 技术线路2.2.1 J2EE 技术J2EE是当今最主流和先进的技术体系,已成为一个工业标准,环围着 J2EE 有众多的厂家和产品,其中不乏优秀的软件产品,合理集成以 J2EE为标准的软 件产品构建本项目信息化系统系统的软件平台,可以得到较好的开放性、稳固性、高牢靠性和扩展性；J2EE平台适用多层次分布式应用模型,采纳基于组件的方式来设计、开 发、组装和部署企业应用系统,以及基于可扩展标记语言（XML）的数据交 换、统一的安全模式和敏捷的事务掌握；凭借这些技术,不但可以面对快速变化的业务要求供应崭新的解决方案；而且,开发出来的是与平台无关的

6、 J2EE组件的解决方案,它不依靠于某个特定软件、硬件产品或者API；这意味着不管是开发商仍是最终用户都有最大的自由去挑选那些更能满意他们业务或技术需求 的产品或组件,不但有利于降低信息系统拥有成本,也有利于适用快速变化的 市场需求；图 J2EE架构J2EE技术的基础是 JAVA语言, JAVA语言的与平台无关性,保证了基于 J2EE平台开发的应用系统和支撑环境可以跨平台运行；6 / 33 医学保证信息系统方案 基于 J2EE技术的应用服务器（ Application Server）主要是用来支持开发基 于 Web 的三层体系结构应用的支撑平台,这一类的产品包括 IBMWebsphere,BE

7、A Web Logic,SilverStream Sxtend和 JBOSS等；设计方案采纳的核心产品就是完全基于 实现了系统的开放性要求；2.2.2 XML 技术J2EE的技术路线和技术架构,完全基于 XML 的新一代互联网网管已经成为当今网络治理进展的新趋势,越来 越多的设备、服务及平台都宣称支持 XML技术；XML（eXtensible Markup Language,可扩展置标语言）是由 W3C（World Wide Web Consortium,互联网联合组织）于1998 年 2 月发布的一种标准,它是一种数据交换格式,答应在不同的系统或应用程序之间交换数据,通过一种 网络化的处理机

8、构来遍历数据,每个网络节点储备或处理数据并且将结果传输 给相邻的节点；它是一组用于设计数据格式和结构的规章和方法,易于生成便 于不同的运算机和应用程序读取的数据文件；XML 是一种使用标记来标记内容以传输信息的简洁方法；标记用于界定内容,而 XML的语法答应我们自行定义任意复杂度的结构；这使得XML 具有以下特性：. 通过使用可扩充标记集供应文档内容的更精确说明. 可用标准化语法来验证文档内容. 使用户与应用程序之间文件交换更简洁. 支持高级搜寻. 将文档结构与内容分开,易于用不同形式表现相同内容. XML改进用户响应、网络负载和服务器负载. XML支持 UnicodeXML仍有其他很多优点,

9、比如它有利于不同系统之间的信息沟通,完全可以充当网际语言,并有期望成为数据和文档交换的标准机制；由于 XML 具有以上诸多特性,使得它的实际应用范畴特别广泛；采纳基于XML的网络治理技术采纳XML 语言对需交换的数据进行编码,为网络治理中复 7 / 33 医学保证信息系统方案杂数据的传输供应了一个极佳的机制；XML文档的分层结构可以对网络治理应用中的治理者代理模式供应良好的映射,通过 XSLT（Extensible Stylesheet Language Transformations）样式表可以对 XML数据进行各种格式的重构和转换,加上 XML 已经被广泛应用于其它领域,各种免费和商业的

10、XML开发工具发展反常快速,因此使用 XML来定义治理信息模式和处理治理信息特别便利；XML能成为网络治理中值得争论和使用的工具,必需具备一些其它网络管理技术所不能供应的特性,主要表现在如下几个方面：1、复杂数据处理优势XML是一种结构化数据,它简洁的编码规章使得可以使用 ASCII文本和类似 HTML的标记来描述数据的任何层次,通过DTD或 XML Schema来定义元素的次序和结构, DTD和 XML Schema供应了一种发布数据转变的正规机制；使用 XML 对比工具来比较新、旧两个XML Schema文件,就能得到数据的哪些特征、选项或是输出标记发生了变化的具体情形；2、使底层数据更具

11、可读性和标准性 目前网络中传输的底层数据通常依据网络协议的不同,而采纳的编码规章 不同,虽然最终在传输的时候都转化为二进制位流,但是不同的应用协议需要 供应不同的转换机制,在协议所能懂得的数据与二进制数据之间进行转换；这 种情形导致网络治理站在对采纳不同协议发送治理信息的被管对象之间进行管 理时很难实现兼容性；但是假如这些协议在数据表示时都采纳 XML 格式进行描 述（ XML的自定义标记功能使这一需求成为可能） ,这样网络之间传递的都是简单的字符流,可以通过相同的XML解析器进行解析,然后依据XML的标记不同,对数据的不同部分进行区分处理,使底层数据更具可读性和标准性；3、使用 XML 模板

12、构建被管网元模型,可最大限度地增强网络治理软件的 敏捷性和可扩展性 通过 XML 模板构建被管网元模型,可以满意网元对象建模的以下要求：. 用最少的对象模型来描述最多种类的网元对象；. 尽量防止特殊化,模糊各厂家产品自身的可管特性；8 / 33 医学保证信息系统方案. 对象的层次结构无论复杂仍是简洁,都可以用相同的数据结构来表示；. 通过该模型能便利地得到网络治理的五大功能模块所需的治理数据；. 有足够的扩展空间,使得显现新的被管网元对象时,该模型同样也能适应；4、增强了基于 WEB的网络治理方式XML在 WEB应用上的优势,同样表达在基于WEB的网络治理方式中；将 XML应用于网络治理是网络

13、治理领域的必定进展趋势,因此本文所争论的 SNMP治理者和转换代理系统,在这方面做了大胆的尝试,主要在以下几个方面运用了 XML 技术：.可解析采纳 XML来描述治理对象的MIB 文件XML 接口,使系统可以.从 GUI/API中接收到的输入数据一律采纳统一的特别便利地采纳不同模式实现用户数据与系统的交换.数据在系统内部的处理以XML数据流为主,一方面通过成熟的XML解析器,可以削减数据处理的复杂度,另一方面,由于只在最终要向传统SNMP Agent发送 BER编码时,才进行格式转换,所以假如 Agent 支持XML格式报文治理,去掉转换层就可以达到XML 治理的目标；. 转换代理中需代理的设

14、备模板,通过 XML 描述导入系统,因设备的多样性,很难估计需要导入的参数形式和个数,采纳 XML 文件描述模板,既可以特别敏捷地设置参数,又可以在基本不转变代理核心模块的前提下,增加对不同种类设备的 SNMP转换；. 通过 XML 配置文件对系统进行初始化配置；2.2.3 Web Service 技术Web services是为了让地理上分布在不同区域的运算机和设备一起工作,以便为用户供应各种各样的服务；用户可以掌握要猎取信息的内容、时间、方式,而不必像现在这样在很多个信息孤岛中浏览,去查找自己所需要的信息；利用 Web services,公司和个人能够快速且廉价地通过互联网向全球用户供应服

15、务,建立全球范畴的联系,在广泛的范畴内查找可能的合作伙伴；随着 Web 服务技术的进展和运用,我们目前所进行的开发和使用应用程序的信息处理活动9 / 33 医学保证信息系统方案 将过渡到开发和使用 Web services；将来, Web services将取代应用程序成为 Web 上的基本开发和应用实体；Web 服务是采纳标准的、规范的XML 描述操作的接口,这种服务描述被称为 Web 服务描述； Web 服务描述囊括了与服务交互需要的全部细节,包括消息格式、传输协议和位置；Web 服务接口隐匿了实现服务的细节,答应独立于软硬件平台的服务调用 Web 服务； Web Service是独立的、

16、模块化的应用,能够通过因特网来描述、发布、定位以及调用；从而实现面对组件和跨平台、跨语言的松耦合应用集成；易的正确体系结构；Web 服务是分布式环境中实现复杂的集合或商业交Web Service具有以下特点：.良好的封装性： Web 服务是一种部署在Web 上的对象,具备对象的良好封装性,对于使用者而言,他看到的仅仅是该服务的描述；.松散耦合：当 Web 服务的实现发生变更时,只要Web 服务的调用接口不变,调用者是不会感到这种变更,Web 服务的任何变更对调用他们的接口来说都是透亮的； XML/SOAP是 Internet 环境下 Web 服务一种比 较适合的消息交换协议；.协议规范：Web

17、 服务使用标准的描述语言来描述（比如WSDL）服务；其次,通过服务注册机制,由标准描述语言描述的服务界面是可以被发觉的；同时,标准描述语言不仅用于服务界面,也用于 Web 服务 的聚合、跨 Web 服务的事务、工作流等；其次,Web 服务的安全标准 也已形成；最终, eb 服务是可治理的；.高度可集成才能：由于Web 服务实行简洁的、易懂得的标准Web 协议作为组件界面描述和协同描述规范,完全屏蔽了不同软件平台的差异,无论是 CORBA、DCOM仍是 EJB都可以通过这一种标准的协议进行互操 作,实现了在当前环境下最高的可集成性；2.2.4 平台化、构件化设计系统设计将采纳神州数据统一的开发平

18、台,神州数据统一开发平台已经用 于多个项目的实施,整体架构、性能等都特别成熟；10 / 33 医学保证信息系统方案各模块的设计将采纳构件化设计,构件化开发,使系统对各地可能存在需 求和流程方面的略微差异具有较强的适应性,通过系统治理员的配置即可轻松 应对；随着多层结构应用的日益流行,基于构件对象的开发技术也日趋成熟,构件作为集中处理各种复杂业务规律的应用单元,大大提高了软件的开发效 率；由于它具有更强的独立性,更好地支持软件的重用,软件的重用仍可使软 件的质量得到极大的提高,同时提高了应用系统的质量和牢靠性；本项目是基于 SOA体系架构设计,通过构件搭建应用系统功能适应了软件 架构对复用性、扩

19、展性、爱护性的要求；构件设计的核心思想就是“ 松耦合、可复用” ,最大程度地提高代码的重用率,提高系统的可爱护性；构件化的设计思想：明确规律封装的边界：构件具有高度抽象的特点,从技术层面的划分力度 更明确,构件之间处于松耦合的关系；在面对构件的框架下,软件的构成不再 是由一行行的代码来描述,而是由一个个具有独立功能构件,通过过程化、参 数化、可视化的配置和组装完成；进行组装发布：以组装的形式进行发布运行,易于爱护,适用于复杂的软 件开发过程；基于统一的规范标准：构件的接口、运行发布标准统一,易于扩展,适应 软件更新升级；基于领域分析设计应用：通过领域分析将构件分类,实现业务功能合理搭 建；采纳

20、多层次的构件体系：构件设计带来了良好的可服用性,节约了开发资 源；通过构件组合构造新的协作新功能的力度更大的构件；2.2.5 面对服务架构（ SOA）面对服务的体系结构（ service-oriented architecture,SOA）是一个组件模 型,它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的 接口和契约联系起来；接口是采纳中立的方式进行定义的,它应当独立于实现11 / 33 医学保证信息系统方案 服务的硬件平台、操作系统和编程语言；这使得构建在各种这样的系统中的服 务可以以一种统一和通用的方式进行交互；基于 SOA来构建的 IT 系统具备如下特点：1以业务为中心S

21、OA更多关注于用户业务,通过业务人员参加SOA系统的规划、设计和管理,使得 IT 系统能在对业务的深刻懂得的基础上进行构建,实现 IT 系统与用户 业务的亲密结合；在具体实施中,通过把完成实际业务流程中的一项任务所需 的 IT 资源组织为服务进行封装,从而达到以业务为核心,通过业务挑选技术,防止技术制约业务的问题；2敏捷适应变化IT系统环绕用户业务构建,用户业务在实现层通过表现为一系列松散耦合 的服务 来实现,这些服务可以依据用户需求随需组合,使得 IT系统对于业务 的适应才能明显提高；3重用 IT 资源,提升开发效率SOA强调对 服务 的重用,对原有 IT 资源的重用度提升是 SOA带来的关

22、键 成效之一,大量具有高重用的服务资源,为快速构建新的业务功能和业务系统 奠定基础,使得 IT 系统的开发和软件生产效率得到提升；同时,重用过程有利于爱护用户前期的信息化投资和 信息化的可连续性建设与进展；4更强调标准IT 资产积存,节约 IT 系统开发成本,实现用户SOA的实现强调基于统一的标准,SOA系统建立在大量的开放标准和协议之上,以实现系统及信息的互联互通和互操作；因此,施,标准都至关重要；2.3 总体框架12 / 33 SOA系统从规划到实医学保证信息系统方案基于云运算技术建立总医院的医疗数据中心,通过专网将总院、练习场 地、疗养院、其它医院、船舶等机构接入到总医院数据中心,并将体

23、检、监测 设备、医疗机构业务系统等的数据采集到总医院数据中心进行统一储备和管 理；2.4 规律架构13 / 33 医学保证信息系统方案本项目中涉及到多个机构之间的数据通讯与业务协同问题,可采纳分布式 部署的方式,在总医院、训练场、船上和其它医院内物理上部署相同的治理系 统,之些系统与总医院之间通过统一的数据采集与交换平台实现互联互通；各机构与总医院无法联网时,可完全独立运行,为服务对象供应完整的健 康治理服务；当接入网络时,系统将自动与总医院的系统进行通讯,实现数据 的采集与交换；2.5 系统架构14 / 33 医学保证信息系统方案用户医务人员治理人员争论人员服务对象其它相关人员层业务应用健康

24、治理与促进系统数据监测与治理系统商务智能系统其它业务系统层标应服务容器组合业务基础业务基础构件基础服务其它服务服务构件 /开准运规服务 储备 库监 控 管注册范用构件容器服务服务行库发体支维工系撑J2EE平台JDBCJNDIJMSJMXJCA护理具与层管JTA信理数业务资源库决策支持资源库非结构化数据息体安系全体据系资源健康档案资源库设备监测资源库体检数据资源库其它业务库ODS库数据仓库统一运维治理层云运算云运算资源治理云运算安全治理云运算运营治理基平台础基础设施服务器储备网络及安其它数据库系统、中层资源设备全设备间件、操作系统等SOA技术理念,整本项目整体的技术架构采纳了先进、成熟的分层结构

25、及体技术架构共分为六大部分；采纳用分层结构主要考虑到,能够降低系统间的依靠,增加系统整体的扩展性、敏捷性和牢靠性；整体技术架构的六大部分主要包括五个层次和一个标准规范和运维治理机制；五个层次包括基础层、数据资源层、应用支撑层、应用系统层、用户层；1、基础层基础设施层是整个项目的基础支撑,供应各类业务系统的远行环境,包括硬件环境、网络环境和软件环境等,包括服务器、储备设备、网络设备、安全设备、数据库、操作系统、中间件、负载均衡等；2、数据资源层数据资源层建立数据资源中心,为上层应用供应数据支撑服务,数据资源层包括结构化数据和非结构化数据,结构化数据包括从各医疗机构业务系统、监测设备治理系统等所采

26、集到的体检、实时监测、诊疗等数据信息；非结构化数据主要包括影像、心电图以及其它文档类资源数据；15 / 33 医学保证信息系统方案3、应用支撑层应用支撑层是通过总线技术,封装各类通用服务和组件,为项目建设供应 应用支撑框架和底层通用服务,以应用系统和应用构件为基础,主要由服务总 线、通用服务组件和业务服务组件等组成,各类组件包括统一认证服务、统一用户治理、日志服务、数据推送服务、元数据治理、信息资源目录服务、查询 服务等；4、应用系统层依据项目要求,建立各类与数据处理相关的业务信息系统,主要包括人口 健康档案治理系统、监测数据治理系统、统计分析系统等；5、用户层用户层是主要包括使用各业务系统的

27、用户,本项目中涉及到的用户包括医 务人员、治理人员、争论人员、服务对象等；全部用户使用浏览器方式使用各 类业务系统；6、标准规范本项目需要处理各类不同源的数据,且各类数据源的数据结构和数据储备 方式等都不太相同,因此,本项目中将建立统一的元数据标准、数据字典、以 及数据采集、交换等的标准规范,满意系统标准化治理的需求；7、运行爱护机制项目建设完成后,需要有完善的运行爱护治理机制,才能保证各系统交付 后能够为用户供应连续的、牢靠的业务服务；本项目将帮忙用户建立一套完整 的后期运行爱护的机制,并建立运行爱护团队,为各系统供应日常爱护、故障 处理、应急保证的运维服务；2.6 应用支撑平台本项目采纳神

28、州数码SmartFrame5.0框架技术做为项目通用框架基础层平台, SmartFrame5.0是基于 J2EE平台,采纳容器模式,并且全部的功能都以构 件和服务的形式表达； SmartFrame通过容器来供应对构件的生命周期治理,并16 / 33 医学保证信息系统方案 通过服务注册库和构件 / 服务储备库供应服务注册、查找、绑定机制解耦服务 /构件之间的依靠关系,从而实现构件/ 服务的功能实现与生命周期治理分别；本项目建立通用框架基础层平台,集成各类通用服务组件,为本项目中建 设的各类基于平台的应用系统供应基础服务,提高各业务系统的建设速度和效 率；SmartFrame5.0的容器基于 SC

29、A容器和 IOC容器的集成,分别负责服务和构 件的生命周期治理； SCA容器主要关注业务服务 /构件的治理,为服务实现屏蔽 了 SOA相关的技术复杂度； IOC容器关注业务服务 / 构件的实现；在 IOC容器 中,可以采纳传统的 UI、长久化、事务治理、面对方面等技术和开发习惯；在物理上,容器治理的构件内部与传统的 包括呈现层、业务层和资源层：J2EE N-Tiers架构风格相同,任然呈现层：主要包括业务构件的 Web 页面、 Web 恳求响应规律,及其依靠的Struts、JSF、Webflow 等 Web 框架和相关 UI 组件,负责用户界面的呈现；业务层：由 SCA形式的组件组成,负责业务

30、服务和业务规律的实现；在业务层的服务实现,既包括了通过IOC容器治理的服务Bean实现的原子服务,也包括以流程编制或编码等形式组合原子服务而实现的业务流程等粗粒度服务；17 / 33 医学保证信息系统方案 IOC容器中通过面对方面的模式分别安全、事务、缓存等公共质量要求,既 简化了业务服务的实现,有促进了复用；资源层：包括 RDBMS等数据资源,以及注册在 企业应用资源；ESB（服务总线）上的其他这些层分别负责界面呈现、业务运算和资源拜访等不同技术层次的应用逻 辑,各司其职,实现了关注分别,同时为部署时的敏捷性和水平扩展奠定了坚 实基础；18 / 33 医学保证信息系统方案 3 数据采集与交换

31、平台3.1 数据统采集与交换平台架构 数据统采集与交换平台是信息共享与互联互通的基础平台,融合消息流、服务中介、消息转换、消息路由、消息传输、协议转换、应用 /服务接入等功能于一体；支持面对服务的应用架构（Service-Oriented Architecture,SOA）和企业服务总线（ Enterprise Service Bus,ESB）,含有符合业界标准的消息交换、业 务流程引擎,使用统一的服务调用和业务表现模型,并遵循业界的开放标准；数据统采集与交换平台采纳J2EE架构,保证系统可移植性和可扩展性,使用基于 XML和 SOAP的 Web Service技术,能够实现 XML 到数据库

32、、数据库到 XML和数据库到数据库之间的数据交换和共享,完全实现了跨平台操作、支持 各种异构系统的动态数据交换功能；数据统采集与交换平台分为四部分,由治理掌握台、消息传输中间件、消 息处理器、数据处理模块组成,实现了数据加工、数据传输、数据监控等数据 交换的功能；如下图所示：管队列治理器治理消消消息处理器数据抽取数队列治理标准接口理据控通道治理消消息内消息分License数据转换处制理复原消息治理台息息息拣治理路加监验证数据装载容缓冲器路由表治理由工控适配器治理基础环境配置全局配置文件服务器连接治理数据源治理任务治理 数据处理监控系统监控全局变量配置消息传输中间件（Queue）治理掌握台：是数

33、据交换组件的配置、治理、监控的平台,实现了数据传 输的队列配置、通过配置、路由表配置、适配器配置等功能,通过界面治理和 配置数据交换的节点信息；通过系统监控、复原消息治理实现数据交换平台节 点和消息传递的监控；19 / 33 医学保证信息系统方案消息处理器：负责消息路由、消息加工、消息缓冲和消息分拣等工作,基 于消息传输中间件实现消息的传递功能,并对消息进行监控；消息传输中间件：负责消息的传输,数据统采集与交换平台中消息传输中 间件部分需要基于消息队列中间件来实现,消息传输中间件的配置完成后,消 息处理器通过传输的调用进行数据的传输；数据处理：数据统采集与交换平台中对预传输的数据进行数据抽取、

34、转 换、装载的组件,实现数据的抽取、装载、转换,并对数据源进行统一治理,对数据处理过程进行监控；3.2 数据采集与交换方式为了实现数据采集与交换,在数据采集与交换方式方面,本项目供应两种 主要的数据采集与交换方式,基于接口服务的数据交换方式和基于前置机的数 据交换方式；1、接口服务的数据交换方式基于接口服务的数据交换方式,是指数据通过Web Service接口依据标准的格式传输到服务器上,在服务器端程序对上传的数据进行处理,并在对应的数 据集库中生成一张新的业务数据集之后,将执行结果返回到 Web Service调用前 置客户端；2、前置机的数据交换方式 前置机主要负责数据的采集和标准转换工作

35、；为了适应不同医疗机构的业 务情形,数据采集可采纳三种方式：一是前置数据库方式,即由资源供应单位 开发接口,将需要共享的数据统一转存在前置机上,为平台供应服务；二是虚 拟数据库方式,即在资源供应单位的业务数据库上建立所需的数据表,前置机 拜访虚拟库取得信息；三是适配器方式,资源供应单位将业务数据封装,直接 为平台供应服务；20 / 33 医学保证信息系统方案4 基于云运算的数据中心4.1 网络子系统4.1.1 概述云运算支撑环境面对本项目供应全面的服务,其直接服务对象主要是医务人员、治理 人员和服务对象等,供应运算、储备、运维等基础服务支撑之上的云服务,构建满意整体 信息化建设需求的云运算服务

36、平台；网络系统建设属于基础设施建设,云运算中心云运算支撑环境各个业务系统均需通过 网络进行数据传输,规划一张合理的、高效的网络子系统能够有力地保证云运算中心相关 业务系统能够安全、稳固、高效地运行；依据云运算支撑环境的总体架构,作为整个系统的基础设施支撑部分,网络系统采纳 模块化、层次化的结构设计,在追求性能优越、经济有用的前提下,本着严谨、谨慎的态 度,从系统结构、技术措施、设备挑选、系统应用、技术服务和实施过程等方面综合进行 系统设计,保证网络系统本身的高性能、高安全、高牢靠、可扩展性以及与其它各个系统 模块良好的兼容性；数据中心实现按功能区域隔离,分别实现对不同客户供应不同定制化服务；依

37、据实际业务的不同,数据中心的服务区划分如下：. 云运算资源池区 主要为供应统一的云运算服务,促进资源共享、信息共享和业务协同,实现各应用系 统的云运算中心部署；. 云储备源池区 主要为云运算中心内部的各业务系统的数据供应高质量、高性能的储备服务,确保关 键业务数据的完整可用；4.1.2 网络拓扑结构设计21 / 33 医学保证信息系统方案如下列图,云中心内部网络架构分为五个区,分别是：网络接入区、核心交换区、计 算资源池区、旁路核心治理区、储备资源池区；整个网络采纳扁平化,全冗余的架构设计,为用户供应高效信息拜访服务,供应安全 牢靠的信息数据托管、容灾服务；4.2 资源池子系统4.2.1 概述

38、云资源池子系统通过对服务器、储备、网络的池化和有效治理,为整个云平台供应按 需获得、即时可取的运算、储备、网络、操作系统及基础应用软件等资源；可实现云平台 网络资源的综合监控、治理,实现对外供应虚拟主机资源、储备资源,达到提高服务器存 储利用率、运行爱护效率和业务系统牢靠性,降低整体建设与整合成本；资源池采纳统一运算资源、储备资源、数据库集群资源、负载均衡资源进行支撑,后续扩展方案变得特别简洁,只需要依据需要向对应的资源区增加硬件即可；22 / 33 医学保证信息系统方案 4.2.2 运算资源池 数据中心资源池供应虚拟主机资源、储备资源,配置虚拟化软件及结构化和非结构化储备系统；虚拟主机资源池

39、供应两路或四路服务器的压力支持,同时储备可以供应结构化（数据块级）和非结构化（应用级）数据的支持,并充分考虑IO 压力、储备容量；基于对调研结果,将具有相关性的业务进行整理、合并,将传统分散数据整合为统一的数据库架构,以便应用系统的治理和效率提升；举荐在虚拟化部署的应用.基础设施应用 比如：Email 服务,域服务 , 文件或者打印服务器 , 防病毒等 ；. 开发或者测试应用服务；. 数据库系统：建立完善的治理和运维流程,才举荐迁移到虚拟化平台；. 关键业务系统,比如 ERP,CRM等：自动化运维治理工具建立并娴熟把握的情形下进行虚拟化迁移工作；不适合在虚拟化平台运行的应用. 应用程序需要超强

40、的运算才能,超过虚拟化环境限制 比如 . 8 路 SMP, 255G 内存 , 10NICs, 等.,运算才能和 IO 需求剧烈的应用,当前最强 PC服务器都无法满意需求的； 数据仓库； 大规模使用的数据库, 比如 10 万人同时在线拜访.应用程序需要用到特殊的外围设备的,比如传真,调制解调器等比如.任何需要客户端特殊配置或者需求的应用,特殊安全策略的DMZ ,例如数据治理区和数据交换区的平台和储备建议采纳分布式4.2.3 储备资源池各种类型的组织都依靠准时的信息检索来促进交易和作出决策；尽管典型的组织正在经受两位数的数据成长,但IT 预算、人员配备和传统的储备容量却跟不上步伐；因此,IT 部

41、门不断承担着庞大压力：使用更高效的储备策略和加大员工可以治理的数据量但不增加员工；客户正在查找储备供应商以供应创新方法来解决这些难题,就像采纳服务器虚拟化让效率大大提升一样,服务器虚拟化是依据业务需求池化服务器资源并对运算机处理才能23 / 33 医学保证信息系统方案进行动态资源调配来实现这一点的；而储备要求不仅仅是依据业务活动动态移动信息,而 且可使该过程完全自动化和自我治理；储备系统通过可扩展的易用解决方案,供应处理文件、数据块和对象储备的行业领先 的创新型和企业级功能；这种新一代储备平台将强大、敏捷的硬件与高效率、治理和爱护 软件结合在一起,能够满意当今企业的严苛要求；简洁、高效和功能强

42、大 储备系统应是一种强健的平台,整合了原有的数据块储备、文件服务器和直连应用程 序储备,使组织可以动态增加、共享和经济高效地治理多协议文件系统以及多协议数据块储备拜访；储备系统的操作环境支持Microsoft Windows. 和 Linux/UNIX 客户端在多协议（NFS 和 CIFS）环境中共享文件；同时,它仍支持高带宽和对推迟敏锐的数据块应用程序 的 iSCSI、光纤通道和 FCoE 拜访；轻松治理、监控和调整储备资产借助储备系统治理平台,可以通过分布式储备环境的 简洁、集成的用户界面从任何地方治理储备系统；储备系统治理平台掌握面板应是一个可 进行一览式治理和报告的屏幕,治理员可利用其

43、快速查看并明白整个环境中正在执行的操作以及可实行的措施；储备系统的单点登录应自动发觉环境中的全部软件及模块安装,以 便进行无缝配置；使用闪存进行优化提高系统性能 储备系统应特地设计为利用闪存驱动器技术的最新创新成果,最大程度提高储备系统 的性能和效率,同时将每 GB 成本降至最低；即使只有数个闪存驱动器（一款无与伦比的 强大软件,可对各异构驱动器中的数据进行分层,全自动储备分层套件并将活动最频繁的数据放入缓存中）结合使用,客户也可以体验到FLASH 1st 策略带来的正确优势；FLASH 1st保证客户绝不会因成本和性能而发愁；活动高度频繁的数据由高达 2 TB 的闪存驱动器供应服务,该驱动器

44、带有FAST Cache,可以动态吸取系统工作负载中的意外“ 高峰” ；随着数据过期并且活动随时间变得不再频繁,FAST VP（针对虚拟池的全自动存储分层）会以 1 GB 为增量,将数据从高性能层分到高容量驱动器层中,这样整体成本较低,而且不用考虑应用程序类型或数据过期问题；而最令人称道的是,这一切都是基于客户定义的策略自动发生的,通过智能地执行与任务资源调配前后关联的工作,大大节约了应用程序和储备治理员的时间与费用；通过自动化更高效地使用储备容量储备系统应包含内置的功能,有助于确保冗余、非活动或预期数据不占用珍贵的储备24 / 33 医学保证信息系统方案资源；数据块压缩功能（旨在处理相对不活

45、动的LUN,例如备份副本和静态数据储备库）会自动压缩数据,使客户可以重新捕捉容量,并将数据的占用空间削减高达 50%；文件级重复数据排除 / 压缩功能通过对非活动文件进行有挑选地压缩和重复数据排除,从而可将所使用的磁盘空间削减高达 50%；由于这些功能是作为后台任务运行的,所以可将系统性能开销降至最低；适合虚拟环境的正确储备储备系统应适合虚拟化应用程序环境的抱负中端系统；无论客户环境是基于VMware 、Microsoft Hyper-V 仍是基于Xen,储备系统都可通过全部支持协议的完全认证,确保在实施的全部阶段都能够胜利地部署虚拟化基础架构；这样储备和服务器治理员就不会再盲目地执行操作；通

46、过VAAI（用于阵列集成的vStorage APIs）将储备系统治理平台与虚拟化治理平台紧密集成,治理员可洞悉整个环境的 情形（端到端） ；每个人都可以使用其熟识的治理界面查看虚拟资源和物理资源,透亮地对 储备进行资源调配、集成复制、拜访全部储备功能并将其卸载到阵列上；只要单击两下,便可通过虚拟化治理平台对储备进行资源调配；针对虚拟化平台的储备系统插件利用正确做法可确储储备与虚拟化平台之间获得正确 利用率和复原才能；可加速硬件的 Fast 克隆能够在数秒内快速对新虚拟机进行资源调配；针对 NFS 数据储备区的按需虚拟磁盘压缩功能可将储备消耗量削减高达 50%；与虚拟化厂商联合开发的体会证的解决

47、方案和参考体系结构可加快关键应用程序虚拟 化的速度；系统全面的储备治理软件 储备系统软件应以两种综合性程序包的方式供应,可确保客户拥有爱护和治理其信息 的全部必需功能；软件包应包括复制功能、时间点复原功能（例如快照和克隆与自动应用程序复制结合使用可确保复原）以及与爱护策略法规遵从性相关的监控和警报；同时包含 全部爱护功能以及“ 一次设置、永久使用” 性能优化功能；全部储备系统软件都可通过管 理平台进行治理；储备系统软件应当包含功能：. 自动优化,可获得最高的系统性能,同时可将储备成本降至最低；. 保持数据安全,免受更换、删除和恶意活动的影响；25 / 33 医学保证信息系统方案. 安全数据爱护

48、功能并重新调整用途；. 爱护数据免受本地故障、停机和灾难的影响；. 自动执行应用程序复制并证明符合法规遵从性；. 连续可用性保持业务正常运营储备系统应设计为可在关键业务环境中供应“冗余功能包括：5 个 9” 的可用性；储备系统可用性和. 高达 12.8 GB 的镜像写缓存,在镜像写缓存中,每个储备处理器都同时包含 LUN 的主缓存数据及其对等储备处理器的缓存的帮助拷贝；. 备用电池能够在显现电源故障时按次序执行关机,缓存会转储到储备区磁盘,以确保数据得到爱护；.RAID 爱护级别0、1、1/0、3、5 和 6,全部这些级别都可以同时并存于同一阵列中,以适应不同的爱护要求；. 主动热备盘增强了系

49、统稳固性并供应最大的牢靠性和可用性；. 冗余数据路径、电源、驱动器连接和储备处理器,全部这些都具备无中断现场更换才能；. 供应连续的系统监控、呼叫总部通知和高级远程诊断功能；云储备支持协议及储备内容4.2.4 网络资源池网络系统建设属于基础设施建设,云运算平台各个业务系统均需通过网络进行数据传26 / 33 医学保证信息系统方案输,规划一张合理的、高效的网络子系统能够有效地保证云运算平台相关业务系统能够安 全、稳固、高速地运行；依据云运算平台的总体架构,作为整个系统的技术设施支撑部分,网络系统采纳模块 化、层次化的结构设计,在追求性能优越、经济有用的前提下,本着严谨、谨慎的态度,从系统结构、技

50、术措施、设备挑选、系统应用、技术服务和实施过程等方面综合进行系统 设计,保证网络系统本身的高性能、高安全、高牢靠、可扩展性以及与其它各个系统模块 良好的兼容性；数据中心的职能分区划分如下 . 储备资源池区 依据料用系统建设的要求,供应为应用系统支持的数据库和储备方面的服务；. 运算资源池区 主要为数据中心的运算资源池供应安全服务,运算资源池区的主要功能包括：拓扑管 理,设备治理,设备监控,用户认证,机房环境监控,视频监控等；开发测试区 .新上应用要先进行测试,在测试稳固后再迁移到内部系统；在服务器系统的整合中,将有很多服务器、储备设备剔除；开发测试区的建设主要以这些服务器为主；. 网络接入区

51、数据中心为外部网络供应接入的区域,云运算平台需接入网络,在数据中心出口部署 两台或两台以上高性能多业务模块化路由器供应接入服务；网络资源池设计要求 . 牢靠性要求 必需满意 7 24 365 小时连续运行的要求；在通信故障发生时,网络设备可以快速 自动地切换到备份链路或设备上；. 安全性要求 系统设计依据严格的安全体系进行设计,分布式部署,使网络具有统一的安全防护能 力,支持全网的安全联动；网络安全建设能有效防止网络的非法拜访,爱护关键数据不被 非法窃取、篡改或泄漏,使数据具有极高的安全性 . 先进性要求 在本项目的建设过程中,所使用的技术、设备和架构体系要是行业内认可、有运用前 景和胜利运用

52、的先进技术；27 / 33 医学保证信息系统方案. 集中式治理要求 全部治理功能和模块 如系统治理和网络治理 集成在统一的治理平台上,供应统一的 治理对象模型,统一的治理数据库；网络治理、系统治理能以统一的视图集成治理；. 可扩展性要求 在技术上特殊要考虑到随着应用的逐步完善和业务系统的逐步增加,系统要能够满意 系统治理功能的扩充及应用软件的集成的需要；. 规范性和标准性要求 整个设计方案从网络协议、操作系统到各个设计细节,应当全部遵循通用的国际或行 业标准,符合国家有关标准规范的要求；. 易操作和易爱护要求 系统设计应具有良好的界面,削减各种特殊培训,并具有在线帮忙功能；同时必需须 具备良好

53、的可爱护性,在升级和整合投入正式运行后,爱护成本较低；. 爱护投资要求 在保证网络整体性能的前提下,云运算网络设计充分爱护用户投资,利用现有的网络 设备或做必要的升级,在原设备的基础上,进行网络建设,防止用户投资的重复铺张,在 满意用户需求和将来进展趋势的情形下,采纳性价比高的设备,构筑经济牢靠的云运算平 台；4.3 本地备份子系统作为云运算支撑环境,需要防范可能的灾难发生造成的数据丢失和系统问题；本地备 份子系统的主要用途是为了供应数据的牢靠性和安全性方面的保证,从而对以下 3 个等级 的灾难状况进行复原：一级：受到攻击和分析的威逼；假如有人声称知道业务系统里有后门可以进入或者准 备用病毒发

54、动攻击,我们就认为正在受到攻击和分析的威逼；遇到这种情形,用户需要加 强安全戒备,截击攻击者；此时,企业或机构仍没有受到缺失,攻击行动仍没有开头；二级：这一情形不会对数据系统产生冲击,但是它仍旧是企业必需解决的问题；例 如,即使安全漏洞让入侵者获得了敏锐的信息,但是数据系统仍旧在运行；但是,你必需 立刻扭转这一局面；三级：单个系统故障,单个系统故障造成其离线时间超如干分钟或者任意长时间,离 线时间取决于系统受到威逼的程度；这种情形需要立刻进行应用转移,假如可能的话,要 28 / 33 医学保证信息系统方案转移到本地的备用系统上；否就,必需把系统从备份介质上复原到备用的硬件上；一般来 说,这种情

55、形不会对商业运行造成庞大影响,但是必需尽快解决问题；本地数据备份和复原是指利用技术、治理手段以及相关资源确保既定的关键数据、关 键数据处理系统和关键业务数据备份在与源数据不同的位置,并在灾难发生后可以复原的 过程；在我们所面临的以上多种级别的灾难中,对于上述的三级灾难,数据中心的基本环境 并没有受到严峻的损害,在数据中心体系架构设计合理和系统爱护较完善的前提下,基本 可以复原业务运行；4.4 云运算数据中心基础支撑系统4.4.1 云运算资源治理系统云运算资源治理系统是供应全面的运营治理功能,支持底层异构的虚拟机架构,完善 的 API 和参考文档可供二次开发,高效的治理监控,解决了用户虚拟机过多治理繁琐、多 厂家 Hypervisor 无法治理、运维复杂、云平台建设费用昂贵等问题,更