网上客户管理系统投标书技术部分358页.docx

网上客户管理系统投标书技术部分 目录 1 目录 ii 1 平台系统概述 1 1.1 平台建设背景 1 1.2 平台定位和战略目标 1 2 总体方案 3 2.1 技术架构 3 2.2 建设思路 23 2.3 系统开发环境 23 2.3.1 网络环境硬件拓扑图 23 2.3.2 平台技术开发环境 24 2.3.3 编程框架 32 2.3.4 业务封装拓展 33 2.3.5 系统测试 33 2.4 系统拓扑结构 34 2.5 系统部署 35 2.5.1 概述 35 2.5.2 系统拓扑结构 35 2.5.3 具体系统部署 36 2.5.4 系统部署的优点 44 2.6 数据库空间规划、存储规划、索引规划、备份规划 45 2.7 点对点详细设计 49 2.8 主要技术选型 50 2.8.1 遵循国际标准规范协议 51 2.8.2 利用 XML 技术实现数据间的传输交换 51 3 功能规划方案 53 3.1 预期目标 53 3.2 系统整体架构 54 3.3 功能架构 55 3.3.1 集团端和企业端分工概述 55 3.4 多业务场景数据流转分析 56 3.5 企业端功能规划 57 3.6 集团端功能规划和实现 84 3.6.1 三户模型概念 84 3.6.2 集团端数据库设计 87 3.6.3 权限管理 94 3.6.4 集团端和企业端客户数据交 换逻辑 95 3.7 集团端门户统一认证与单点登陆 96 3.7.1 设备功能说明 97 3.7.2 接口功能说明 98 3.7.3 业务流程 98 3.8 网上商城 116 3.9 数据挖掘 118 3.10 典型业务场景原型设计 122 3.11 统一接口平台 142 3.11.1 统一接口平台概述 142 3.11.2 统一接口平台集成关系图 143 3.11.3 与 TCIS 系统的接口 143 3.11.4 与网上商城的接口 144 3.11.5 与支付平台的接口 144 3.11.6 与第三方平台的接口 145 4 IC 卡在线充值解决方案 165 4.1.1 概述 165 4.1.2 读卡器功能和性能介绍 166 4.1.3 读卡器安装方法 167 4.1.4 读卡器操作方式 167 5 系统安全服务 171 6 安全性和数据灾备方案 174 6.1 系统安全性 174 6.2 灾备概述 175 7 系统运行管理方案 179 7.1 监控管理 179 7.2 运维管理 224 8 项目实施管理过程 269 8.1 总体计划 269 8.2 项目计划 269 8.2.1 获取约定 269 8.2.2 编制项目计划 269 8.2.3 项目跟踪 270 8.3 软件开发 271 8.3.1 组织标准软件项目生命周期 ----- 研发项目 272 8.3.2 组织标准软件项目生命周期 ----- 工程项目 274 8.3.3 组织标准软件项目生命周期 ----- 维护项目 278 8.4 项目执行与控制 279 8.5 项目验收与结束 281 8.5.1 系统投入使用验收 281 8.5.2 系统初验 282 8.5.3 系统终验 283 8.5.4 项目结束 283 8.6 项目文档资料 283 8.7 软件配置管理 284 8.7.1 配置管理计划 284 8.7.2 基线库管理 285 8.7.3 配置管理实施流程 287 8.8 质量保证 291 8.8.1 参与制订和评审项目的软件项目计划、标准和规程 292 8.8.2 制订项目 SQA 计划 292 8.8.3 评审工作产品 292 8.8.4 过程审核 293 8.8.5 SQA 报告机制 293 8.9 风险管理 294 8.9.1 风险管理约定 294 8.10 项目总体进度安排 294 8.11 本项目存在的风险分析和控制方法 295 9 系统功能测试和质量保证方案 297 9.1 概述 297 9.2 质量管理内容 297 9.3 质量管理责任分配 298 9.4 质量保证措施 300 10 系统性能及压力测试方案 304 10.1 系统性能 304 10.2 系统结构及流程 305 10.3 性能测试环境 306 10.4 性能压力测试 307 10.5 测试过程及结果描述 310 10.6 测试报告 312 10.7 类似项目案例 312 11 培训计划和培训方案 313 11.1 核心业务支撑系统培训方案 313 11.2 高级培训 313 11.3 初级培训 318 12 上线实施方案 322 12.1 前言 322 12.2 组织与安排 322 12.3 总体计划 323 12.4 应急处理 324 13 系统和数据迁移方案 326 13.1 TCIS 数据库生产环境 326 13.2 创建表空间 326 13.3 用户 327 13.4 数据迁移具体流程 328 13.5 类似项目案例 329 14 系统交付部署和验收方案 330 14.1 系统部署方案 330 14.2 项目验收方案 331 14.3 验收需提交的交付物清单 335 14.4 类似项目案列 337 15 系统上线后续服务 338 16 格式 12 技术条款偏离表 343 格式 12 技术条款偏离表 343 17 格式 13 业务需求与解决方案应答对应表 350 格式 13 业务需求与解决方案应答对应表 350 18 格式 13 业务需求与解决方案应答对应表 353 格式 13 业务需求与解决方案应答对应表 353 1平台系统概述 平台建设背景 从增强老百姓便捷性，提高客户满意度，提升港华燃气自身信息化水平等多层面出发，需要建设一套网上营业厅系统，我们的目的是实现在网上完成线下实体客户中心可以完成的大部分主体业务，提升用户服务能力，提高客户满意度。 平台定位和战略目标 网上营业厅服务平台平台 普通燃气 消费者 互联网 便民应用 平台系统建设集成商 IT 供应商、电信运营商 后台管理者 政府，企业，直属部门等 网上营业厅服务平台平台 普通燃气 消费者 互联网 便民应用 平台系统建设集成商 IT 供应商、电信运营商 后台管理者 政府，企业，直属部门等 图 1-1 网上营业厅价值链 针对客户不断增加的便民查询，业务受理等实际需求，我们将积极整合国内外人才、技术、产品资源，打造港华最便捷的网上处理平台。在平台建设和运营基础上，持续探索各种创新模式，发展多种有针对性的衍生技术服务，为企业持续创造节能服务价值。 港华网上营业厅平台的建设从起步、发展到系统成熟将经历不同的战略阶段，公司将本着务实审慎的原则，力求结合港华自身的特点以及市场的成熟，逐步扩展平台服务范围和服务空间，在平台建设和市场发展之间形成良性互动，最大限度地实现资源投入效应最大化 总体 方案 技术 架构 系统技术原则 系统实现过程中，应该遵循如下技术原则： 先进性 系统的实现 应参考国际标杆 并结合现状，采用先进可靠的设备和技术，确保系统的先进性和成熟性，保证投资的有效性和延续性。 安全可靠性 系统必须要 达到 较高 的安全标准 ，提供良好的安全可靠性策略，支持多种安全可靠性技术手段，制定严格的安全可靠性管理措施。 开放性 系统应基于国内外业界开放式标准，进行全国统一规划，为未来的业务发展奠定基础。 可扩展性 系统应具备灵活的可扩展性，具备方便地适应业务需求的变化、迅速地支持新业务的能力。 可伸缩性 系统应具备良好的可伸缩性，系统性能及并发处理能力对主机设备具备平滑的扩展能力，支持业务量快速发展的需要。 易使用性 系统应易于使用与维护，具备良好的用户操作界面、人性化的管理工具和完备的帮助信息。 IT与业务协同 在企业信息化能力建设的过程中，不仅要重视IT 技术体系建设，同时要高度重视对端到端业务管理流程、规则的理解和梳理，有效实现对流程和规则的固化，保证对企业业务运营和经营管理的有效支撑和高效原则。 系统架构技术原则 在技术原则的指导和约束下，系统设计实施必须遵循以下总体设计思路与原则，保证系统在性能、可靠性、易使用性等质量要素间的综合平衡，保证技术原则各项目标的顺利实现。 面向服务的模块化系统架构 服务接口定义稳定：应充分考虑服务间接口稳定性，建议使用XML或者类似的结构，以保证接口传输参数与内容的可扩展性。 服务粒度合理确定：应综合考虑系统性能、扩展性等方面的因素，同时兼顾系统在部署、维护和管理等方面的要求，合理确定服务粒度。 多实例运行：应该尽量满足对每一个服务都可以同时运行多个服务实例的需求，以保证系统的高可靠性与可伸缩性。 分布式、面向服务访问 每个服务均可以承担服务提供者和服务使用者两种角色，服务使用者通过访问服务提总线的接口获取相应的服务。 系统必须实现服务的分布透明机制。组成系统的服务实例可以部署在一台或多台主机上。服务总线提供的服务访问对分布地点、位置透明，服务使用者通过服务的逻辑名称即可获取服务而与服务所在主机的物理位置无关。 松耦合、高内聚原则 系统设计须遵循松耦合、高内聚原则。服务之间保持松耦合状态，服务的具体实现方式对服务使用者透明。在服务内部所实现的功能与结构保持高度逻辑相关性的同时，保证服务间的相互独立性。 业务流程与业务组件分离、应用与展现分离 应综合考虑业务流程与组件实现的分离的原则，建议利用流程管理、规则管理和门户技术，动态地定义系统的行为以实现系统功能。在应用此种技术获得灵活性与可扩展性的同时，也要充分考虑到其对系统性能带来的影响。 业务流程的实现往往会涉及多个系统的多个功能模块，为了降低系统间耦合程度，提高流程管理的灵活性，应该实现分层次的流程管理机制，各系统内部实现自己的工作流管理服务。 数据与功能分离 系统必须提供独立于业务的信息存取层，信息存取层遵循企业的数据模型规范。外部系统通过对业务服务的访问来使用信息存取层的功能。 基本概念 在技术架构中，会涉及到以下一些概念，先分别做描述。 业务组件 组件 是实现特定功能，遵循某一个组件模型的约定并可独立部署与运行的软件单元。 业务组件代表了一组业务逻辑相关的，高内聚的业务功能，如图2-1中层次一所述； 它实现了人机界面无关的业务逻辑相关的处理功能； 业务组件的功能可以被封装为业务服务，如图2-1中层次一可以直接封装为服务，也可以为层次二中封装为服务。 图2-1 组件层次示意图 业务服务 服务是组件实现并对外提供的功能与操作集合。 每个服务均可以承担服务提供者和服务使用者两种角色，服务使用者通过访问服务提供给总线的接口获取相应的服务； 组成系统的服务实例可以由一个或者多个业务组件的功能进行封装； 业务服务有标准的接口； 可以被注册到服务总线上被其它业务服务调用； 在服务内部所实现的功能与结构保持高度逻辑相关性的同时，保证服务间的相互独立性。 图2-2 服务组件关系图 面向服务的 体系 架构 SOA SOA面向服务的体系结构，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口联系起来。接口是采用中立的方式进行定义的，它独立于实现服务的硬件平台、操作系统和编程语言，这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。 从业务人员角度来看，它使得我们能够更加容易地对客户和合作伙伴提供业务服务； 从架构师角度来看，它提出了更加松耦合、更强调重用性、可封装性的一种架构风格； 从开发人员角度来看，它提出了一些编程模型以及相应的一些规范，包括标准、工具、方法； 从运维人员角度来看，存在于服务请求方和服务提供方之间的一套协定和契约，它们规定了服务的质量。 商业创新和优化服务 开发服务 IT 服务 管理 基础结构服务 合作伙伴服务 商业应用 程序服务 访问服务 交互服务 流程服务 信息服务 连接性服务 --- 企业服务总线 商业创新和优化服务 开发服务 IT 服务 管理 基础结构服务 合作伙伴服务 商业应用 程序服务 访问服务 交互服务 流程服务 信息服务 连接性服务 --- 企业服务总线 图2-3 SOA架构图 业务对象 系统用业务对象来表示业务逻辑和业务流程中涉及的实体（例如订单、客户、用户）；业务对象以面向对象的方式进行设计，是一组属性和操作的集合；业务对象相关的数据可以以库表的方式存放在数据库中，系统通过数据存取的方式来完成业务对象和库表数据之间的双向转换。 业务流程 业务流程特指为了完成特定的业务功能，通过相应的规则与流程技术，将一个或多个服务进行编排而形成的业务流；例如订单调度流程、故障处理流程等。对于一些易变的应用逻辑，也可以流程化，例如客户认证与鉴权就是一个业务流程，它是通过业务流程组合了客户查询、客户认证、用户信息查询、客户信息过滤、燃气销售查询、推荐信息查询等多个业务服务。 界面集成 界面集成是对不同界面展现组件之间的集成。通过合理的规划和设计，界面集成可以重用已有的企业内外界面资源、提高开发部署效率、迅速满足客户和业务的需求，从而提高界面开发的灵活性和简易性。 分层技术架构 系统采用分层结构开发和设计，将界面、业务流程、服务、数据分离，实现系统内部松耦合，以灵活、快速地响应业务变化对系统的需求。系统层次结构划分为信息资源层、信息存取层、业务服务层、业务流程层、展现层，各层次间通过直接调用或者通过ESB进行调用，实现系统功能。 原则上信息资源层不允许信息存取层之外的层次对其进行调用，信息存取层不允许业务服务层之外的层次对其进行调用。 各层的应用组件利用系统支撑服务框架所提供的基础服务实现系统公共设计、运行与管理机制。 以下各小节将分别对这些系统内部层次进行说明。 图2-4 系统技术架构图 前台界面展示 层 展现层是系统与用户进行信息交互的平台，通过界面集成将界面展现组件组合成用户界面。用户通过用户界面调用业务流程来实现业务功能。 即系统的服务对象层，包括各类通过该系统获取服务的人员，如港华燃气的客户，营销人员，系统管理人员，高层决策人员，合作伙伴，渠道服务人员等，各类服务对象可以通过多种接入方式获取服务，包括面对面的方式，呼叫中心方式，Internet登录方式，自助终端等方式。不同角色，不同岗位的服务对象在接入系统后将获得不同的服务功能视图。 界面展现组件 界面展现组件由一组基本并紧密相关的界面展现单元组成，并通过这些界面单元调用与之有较强内聚性的业务服务实现一个独立的、带人机交互界面的业务功能。 界面集成 界面集成是对不同界面展现组件之间的集成。通过合理的规划和设计，界面集成可以重用已有的企业内外界面资源、提高开发部署效率、迅速满足客户和业务的需求，从而提高界面开发的灵活性和简易性。 界面集成有静态和动态两种集成方式。 静态集成方式 ：开发人员以固化的方式集成各类界面展现组件，提供人机操作界面，实现系统的业务功能。 动态集成方式 ：采用界面集成工具，通过简单灵活的配置来定义各个界面组件之间的关系，组成用户界面，并定义界面的流程。在规则管理和流程管理的控制下，在系统运行过程中动态地决定界面的外观、行为和人机交互过程。 动态集成方式的实现有利于提升系统的配置能力、界面的个性化、可扩展性，保证系统迅速适应业务需求的变化和发展。系统建设时应尽可能实现动态集成方式。 业务流程层 业务逻辑层将主要本系统中的商业逻辑的实现和业务流程的控制集中，将表示层和数据层从业务逻辑中解耦出来，而专注于其所擅长的界面表示和数据存储访问。业务逻辑层采用基于组件模型的面向对象的设计思想，并基于成熟的应用服务器平台而实现和运行。 业务流程 业务流程特指为了完成特定的业务功能，通过相应的规则与流程技术，将一个或多个服务进行编排而形成的业务流；系统业务流程可以作为子流程被其它业务流程调用，也可以被展现层直接调用。 实施建议 将业务需求中易变的业务逻辑及相关的业务规则剥离出来，通过流程与规则技术进行编排整合，保证系统的灵活性、可配置性、可管控性． 对数据量大、实时性高的业务流程可通过业务服务层进行封装，可以不通过动态的业务流程实现。 业务服务层 业务服务以面向服务的方式对一个或者多个业务组件的功能进行封装，它具有明确的接口描述，可以被其它业务服务调用，也可以被业务流程或展现层调用。 业务服务是展现层、业务流程层和ESB调用的对象。 业务服务的功能由业务组件来实现，服务原子服务和复合服务，某个服务也可调用其它服务来完成更复杂的业务功能。 业务服务具有高内聚、可重用的特征，可通过标准的、明确的服务接口描述将具体的一个或多个组件中的功能按一定的规则和标准进行封装，可以被发现、绑定和调用。 后台处理层 涵盖了整个系统中的后台处理系统，其特征是不直接面向客户，客服人员和市场营销人员，其主要的使用和操作对象为系统管理员和业务管理员，后台系统的可靠运行是港华燃气业务能够正常运行，尤其是客户服务和各类营销活动能够正常展开的有效保障。 信息存取层 是系统的数据存储中心，按照业务和功能将系统的数据划分为如下几个数据库，在实际部署和运行中，考虑到实际容量和性能等原因可以进行适当的调整。 应用数据库 港华燃气 数据库 日志数据库 数据存取 数据存储层专为业务逻辑层中业务组件提供数据资源操作和访问功能，包括对关系型数据库的CURD操作和文件系统的读写操作等。 完成业务对象(Business Object）的封装，以及业务对象到底层数据库结构之间的转换，实现对原始数据的存取访问，从而帮助业务组件层实现对业务对象的处理，使得业务组件层对数据的访问不受数据库物理设计、物理分布的影响。 能对数据库、操作系统文件或其他形式存储的数据进行操作，保证数据的完整性、一致性和准确性。 屏蔽信息资源层上数据模型和数据格式方面的差别，例如当数据定义的语义和语法不同时，可以在必要时进行语法转换和语义解析。 数据集成功能，屏蔽信息资源层上数据分布的差异性和分散性，例如实现跨表、跨库、跨地域的数据操作和访问。 信息资源层 信息资源层负责系统的数据存储及维护数据的完整性与一致性。数据可以根据需要存储在数据库管理系统、文件、外部存储设备中。信息资源层数据的组织按照企业业务概念模型在应用软件上优化实现的要求形成各个主题域，并支持《数据模型规范》中定义的概念模型和逻辑模型。 外部接口层（ 统一接口平台 ESB ） 系统的统一接口平台，面向不同外部系统的特征和要求提供不同的接口模式，包括实时接口模式，文件模式，基于消息的接口模式等。面向的外部系统主要包括财务系统，港华燃气TCIS系统，各支付接口，其他合作伙伴系统等。 服务总线的概念是从面向服务体系架构发展而来的，是所有基于面向服务的体系结构解决方案的核心组成部分，是SOA架构中应用整合的骨干。 服务总线功能如下： 服务总线是所有跨系统服务的注册中心，各系统的业务服务层甚至业务流程层提供的服务都可以在E SB 上进行注册，从而对企业各系统的所有服务进行统一管理和查询；解耦域内各个子系统之间的调度。 实现对所有服务的管控，包括对服务调用权限的定义和控制以及对服务全生命周期的管理，即管理每个服务从需求提出-〉开发-〉发布-〉部署上线-〉维护更新-〉下线的全过程。 基于J2EE 的软件层次结构 客户端 在基于J2EE平台的系统架构中，这里的客户端目前仅指Internet浏览器。 Web层 运行于Web Server上，用于实现各类静态，动态页面展现，页面跳转控制等，在网站Web层主要采用MVC的设计模式。 View 视图。实现各类信息的展现，接受客户端的输入，并将输出信息通过页面反馈。在J2EE应用中，View层的表现形式一般为各类htm,jsp文件，以及各类资源和属性文件。 Controller 控制器。是MVC中的枢纽。用户各种类型的HTTP请求都将通过Controller进行处理，并将处理结果通过JSP（view）推向前端，因此控制器也可以说是控制了各类页面之间的流转。Controller以Servlet的方式来实现。 MVC Framework 这是实现了MVC模式的基础框架，可以采用目前较为成熟的struts,也可以自己开发。具体框架选用可后续根据实际情况与用户讨论确定。 业务层 在这一层实现了主要的业务逻辑和流程，其运行的主要上下文环境是EJB容器，并充分利用容器所提供的安全，事务，持久性，连接池等基础服务，按照功能的不同又可以分为如下几个层次： Model 是MVC中负责业务逻辑访问和实现的层次，也是对业务封装并向应用的上层开放的层次，其一般的表现形式是Java Bean，通过bean来调用相关的业务逻辑实现。 业务控制层 系统的业务流程的实现层，其实现方式可以是根据业务流程对底层业务组件并行组合和包装形成更上层的应用组件；也可以是通过工作流引擎来驱动流程的实现。 业务组件层 实现了从系统中抽象出来的各类系统和业务基础组件，其基本特点是可重用，可扩展，相互之间耦合度小，可以采用JAVA Class的方式来实现，并向上层提供Interface以供调用。 数据访问层 对数据层访问的接口层，在J2EE平台中对数据库的访问可以通过JDBC直接建立连接或者通过连接池共享连接的方式进行数据访问。对于一些简单的数据访问也可以在JDBC层次上通过实体Bean实现数据持久层，其好处是数据的持久性和事务的管理由容器来负责。 数据层 存放系统中的各类数据，通过JDBC进行本地数据库的访问，与核心TIS系统的数据交互通过webservice方式获取。 关键设计考虑 可靠性设计 港华燃气 系统是一个基于在线生产系统派生系统，直接关系到客户服务的质量以及企业运营的效率与收入，因此要求系统能够达到7X24小时不间断稳定运行。由于 港华燃气 系统模块功能复杂，系统间结构与层次较多，在系统建设时需要对系统未来运行稳定型进行全面考虑与设计，并纳入系统设计的关键考量。我们将主要从主机与平台软件的可靠性、网络可靠性、应用软件可靠性三个方面来考虑并设计： 平台可靠性 平台是指整个系统运行的基础硬件与软件环境，包括主机、网络、数据库、交易中间件、J2EE应用服务器、流程引擎等基础软件。平台是构造先进而实用的应用系统的物理基础。江苏移动将几个方面来保证平台的可靠性： 从系统的先进性、业务容量、成熟性、实用性、可靠性出发，综合以上考虑与未来的扩展因素，同时考虑本期工程的资金投资，选择具有成熟应用案例与经验的软硬件平台，构造应用系统稳定的基础； 充分考虑系统关键网络节点、网络链路、关键应用平台等的在线热备份，包括核心交换机与路由器、数据库服务器、关键应用服务器等，适当考虑平台的冗余性，避免单点故障的产生，保证关键平台故障发生时的透明快速接管。 应用软件可靠性 应用软件的可靠性是系统不间断运行的能力。应用软件可靠性需要从软件架构设计部署与在线系统应用备份设计两个方面来考虑以提高系统的稳定性与容错性。 软件架构设计与部署 为了能够从软件体系架构上提高软件的可靠性， 港华燃气 系统采用了运行核心平台与上层业务系统分离的设计模式，所有的业务应用都基于稳定的基础业务运行平台而构建，基础业务运行平台独立于应用开发并统一演进，提供上层应用运行所必需的基础引擎与环境，以保证应用的稳定性与可靠性。 分布式应用软件的部署也是关系到系统稳定性的重要因素之一。我们在进行本系统应用部署设计时将充分考虑一下原则与方法： 区分关键应用与非关键应用考虑部署，一方面减少应用间的相互影响，另一方面提高未来根据系统运行情况进行部署调整优化时的灵活性与伸缩性。 区分快速联机交易与批量业务考虑部署，这也是提高系统性能并保证核心业务稳定运行的主要策略。 考虑硬件平台的处理能力，并结合预计业务的发展情况，根据相关资源的消耗情况涉及足够的处理能力冗余，以降低由于出现性能瓶颈进而导致系统稳定性下降的可能性。 在系统上线之前将进行充分的、具有足够业务冗余的业务量测试，并根据测试结果合理调整应用的部署。 应用备份设计 为了能够降低系统故障导致应用处理中断给业务运营带来的影响，必须在系统规划与建设初期对应用软件的备份进行设计。应用的备份根据是否存在人工干预、备份切换时间等可以分为在线热备与冷备份两种，而从应用的分布与层次则主要考虑各类应用服务器的备份，而应用服务器则又可以分为交易应用服务器、WEB应用服务器、后端处理应用服务器等类型，设计时需要结合应用的特点与重要性考虑不同种类应用备份的实现方式。在本次系统建设中建议对关键应用包括计费应用、前台业务受理应用、服务开通进行在线热备份，保证系统故障时的自动切换；对其他应用采用独立服务器进行冷备份。各种类型应用服务器的在线热备方式考虑如下： 后台处理服务器 后台处理服务器采用基于主机的HA cluster方式进行，在平台或者应用故障中断运行时由备机快速接管应用，保证不间断运行。考虑到业务量与投资规模，在本系统可以采用一台应用服务器备份多台机器的策略。 交易应用服务器 交易应用服务器需要接收客户端的请求并进行业务逻辑的处理，因此该应用服务器的备份需要同时考虑远程客户端的接入切换与后台服务器的应用接管。在 港华燃气 系统中，主要考虑以下可能的在线交易的应用备份策略： IP映射技术。这种方式通过网络设备（如交换机或者路由器）对内部的在线应用服务器与备份应用服务器位置进行映射，对客户端提供统一的IP地址。并可以由网络设备自动检测应用的状态，在线应用发生故障时，可以自动把客户端请求转发至备份应用服务器，整个过程对客户端透明，同时这种方式在系统正常运行时也可由网络设备根据预定义的策略实现负载分担，且缺点是需要网络设备支持（需要四层交换功能）。 通过主机cluster集群软件进行。这种方式采用浮动的IP网络地址来向客户端屏蔽内部服务器的位置，当在线系统失败时，集群软件无须人工干预即可自动启动备份应用服务器并对外提供服务，整个过程对客户端透明。 动态域名解析。在线应用服务器与备份应用服务器各自保证应用的运行，客户端接入通过域名进行，在发生故障时，由域名解析服务器动态的将域名切换到备份应用服务器。这种方式的缺点是需要实现应用检测并动态调整域名解析表的功能。 应用实现名字解析功能。这种方式类似于J2EE中JNDI机制：客户端不直接通过固定的IP地址访问特定的应用服务器，而是首先通过名字服务器获得对应应用逻辑的位置后再通过该调用该位置的应用逻辑。这种方式的优点是可以灵活调整应用的分布而无需客户端