网上客户管理方案计划系统投标书技术部分.doc

.\ XX集团 网上客户系统项目 招标编号： 投标书 正本 （技术部分） 2015年XX月 1 目录 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平台系统概述 1.1 平台建设背景 从增强老百姓便捷性，提高客户满意度，提升港华燃气自身信息化水平等多层面出发，需要建设一套网上营业厅系统，我们的目的是实现在网上完成线下实体客户中心可以完成的大部分主体业务，提升用户服务能力，提高客户满意度。 1.2 平台定位和战略目标 图1-1 网上营业厅价值链 针对客户不断增加的便民查询，业务受理等实际需求，我们将积极整合国内外人才、技术、产品资源，打造港华最便捷的网上处理平台。在平台建设和运营基础上，持续探索各种创新模式，发展多种有针对性的衍生技术服务，为企业持续创造节能服务价值。 港华网上营业厅平台的建设从起步、发展到系统成熟将经历不同的战略阶段，公司将本着务实审慎的原则，力求结合港华自身的特点以及市场的成熟，逐步扩展平台服务范围和服务空间，在平台建设和市场发展之间形成良性互动，最大限度地实现资源投入效应最大化 2 总体方案 2.1 技术架构 2.1.1 系统技术原则 系统实现过程中，应该遵循如下技术原则： 1、 先进性 系统的实现应参考国际标杆并结合现状，采用先进可靠的设备和技术，确保系统的先进性和成熟性，保证投资的有效性和延续性。 2、 安全可靠性 系统必须要达到较高的安全标准，提供良好的安全可靠性策略，支持多种安全可靠性技术手段，制定严格的安全可靠性管理措施。 3、 开放性 系统应基于国内外业界开放式标准，进行全国统一规划，为未来的业务发展奠定基础。 4、 可扩展性 系统应具备灵活的可扩展性，具备方便地适应业务需求的变化、迅速地支持新业务的能力。 5、 可伸缩性 系统应具备良好的可伸缩性，系统性能及并发处理能力对主机设备具备平滑的扩展能力，支持业务量快速发展的需要。 6、 易使用性 系统应易于使用与维护，具备良好的用户操作界面、人性化的管理工具和完备的帮助信息。 7、 IT与业务协同 在企业信息化能力建设的过程中，不仅要重视IT 技术体系建设，同时要高度重视对端到端业务管理流程、规则的理解和梳理，有效实现对流程和规则的固化，保证对企业业务运营和经营管理的有效支撑和高效原则。 2.1.2 系统架构技术原则 在技术原则的指导和约束下，系统设计实施必须遵循以下总体设计思路与原则，保证系统在性能、可靠性、易使用性等质量要素间的综合平衡，保证技术原则各项目标的顺利实现。 1) 面向服务的模块化系统架构 服务接口定义稳定：应充分考虑服务间接口稳定性，建议使用XML或者类似的结构，以保证接口传输参数与内容的可扩展性。 服务粒度合理确定：应综合考虑系统性能、扩展性等方面的因素，同时兼顾系统在部署、维护和管理等方面的要求，合理确定服务粒度。 多实例运行：应该尽量满足对每一个服务都可以同时运行多个服务实例的需求，以保证系统的高可靠性与可伸缩性。 2) 分布式、面向服务访问 每个服务均可以承担服务提供者和服务使用者两种角色，服务使用者通过访问服务提总线的接口获取相应的服务。 系统必须实现服务的分布透明机制。组成系统的服务实例可以部署在一台或多台主机上。服务总线提供的服务访问对分布地点、位置透明，服务使用者通过服务的逻辑名称即可获取服务而与服务所在主机的物理位置无关。 3) 松耦合、高内聚原则 系统设计须遵循松耦合、高内聚原则。服务之间保持松耦合状态，服务的具体实现方式对服务使用者透明。在服务内部所实现的功能与结构保持高度逻辑相关性的同时，保证服务间的相互独立性。 4) 业务流程与业务组件分离、应用与展现分离 应综合考虑业务流程与组件实现的分离的原则，建议利用流程管理、规则管理和门户技术，动态地定义系统的行为以实现系统功能。在应用此种技术获得灵活性与可扩展性的同时，也要充分考虑到其对系统性能带来的影响。 业务流程的实现往往会涉及多个系统的多个功能模块，为了降低系统间耦合程度，提高流程管理的灵活性，应该实现分层次的流程管理机制，各系统内部实现自己的工作流管理服务。 5) 数据与功能分离 系统必须提供独立于业务的信息存取层，信息存取层遵循企业的数据模型规范。外部系统通过对业务服务的访问来使用信息存取层的功能。 2.1.3 基本概念 在技术架构中，会涉及到以下一些概念，先分别做描述。 2.1.3.1 业务组件 组件是实现特定功能，遵循某一个组件模型的约定并可独立部署与运行的软件单元。 业务组件代表了一组业务逻辑相关的，高内聚的业务功能，如图2-1中层次一所述； 它实现了人机界面无关的业务逻辑相关的处理功能； 业务组件的功能可以被封装为业务服务，如图2-1中层次一可以直接封装为服务，也可以为层次二中封装为服务。 图2-1 组件层次示意图 2.1.3.2 业务服务 服务是组件实现并对外提供的功能与操作集合。 每个服务均可以承担服务提供者和服务使用者两种角色，服务使用者通过访问服务提供给总线的接口获取相应的服务； 组成系统的服务实例可以由一个或者多个业务组件的功能进行封装； 业务服务有标准的接口； 可以被注册到服务总线上被其它业务服务调用； 在服务内部所实现的功能与结构保持高度逻辑相关性的同时，保证服务间的相互独立性。 图2-2 服务组件关系图 2.1.3.3 面向服务的体系架构SOA SOA面向服务的体系结构，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口联系起来。接口是采用中立的方式进行定义的，它独立于实现服务的硬件平台、操作系统和编程语言，这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。 从业务人员角度来看，它使得我们能够更加容易地对客户和合作伙伴提供业务服务； 从架构师角度来看，它提出了更加松耦合、更强调重用性、可封装性的一种架构风格； 从开发人员角度来看，它提出了一些编程模型以及相应的一些规范，包括标准、工具、方法； 从运维人员角度来看，存在于服务请求方和服务提供方之间的一套协定和契约，它们规定了服务的质量。 图2-3 SOA架构图 2.1.3.4 业务对象 系统用业务对象来表示业务逻辑和业务流程中涉及的实体（例如订单、客户、用户）；业务对象以面向对象的方式进行设计，是一组属性和操作的集合；业务对象相关的数据可以以库表的方式存放在数据库中，系统通过数据存取的方式来完成业务对象和库表数据之间的双向转换。 2.1.3.5 业务流程 业务流程特指为了完成特定的业务功能，通过相应的规则与流程技术，将一个或多个服务进行编排而形成的业务流；例如订单调度流程、故障处理流程等。对于一些易变的应用逻辑，也可以流程化，例如客户认证与鉴权就是一个业务流程，它是通过业务流程组合了客户查询、客户认证、用户信息查询、客户信息过滤、燃气销售查询、推荐信息查询等多个业务服务。 2.1.3.6 界面集成 界面集成是对不同界面展现组件之间的集成。通过合理的规划和设计，界面集成可以重用已有的企业内外界面资源、提高开发部署效率、迅速满足客户和业务的需求，从而提高界面开发的灵活性和简易性。 2.1.4 分层技术架构 系统采用分层结构开发和设计，将界面、业务流程、服务、数据分离，实现系统内部松耦合，以灵活、快速地响应业务变化对系统的需求。系统层次结构划分为信息资源层、信息存取层、业务服务层、业务流程层、展现层，各层次间通过直接调用或者通过ESB进行调用，实现系统功能。 原则上信息资源层不允许信息存取层之外的层次对其进行调用，信息存取层不允许业务服务层之外的层次对其进行调用。 各层的应用组件利用系统支撑服务框架所提供的基础服务实现系统公共设计、运行与管理机制。 以下各小节将分别对这些系统内部层次进行说明。 图2-4 系统技术架构图 2.1.4.1 前台界面展示层 展现层是系统与用户进行信息交互的平台，通过界面集成将界面展现组件组合成用户界面。用户通过用户界面调用业务流程来实现业务功能。 即系统的服务对象层，包括各类通过该系统获取服务的人员，如港华燃气的客户，营销人员，系统管理人员，高层决策人员，合作伙伴，渠道服务人员等，各类服务对象可以通过多种接入方式获取服务，包括面对面的方式，呼叫中心方式，Internet登录方式，自助终端等方式。不同角色，不同岗位的服务对象在接入系统后将获得不同的服务功能视图。 n 界面展现组件 界面展现组件由一组基本并紧密相关的界面展现单元组成，并通过这些界面单元调用与之有较强内聚性的业务服务实现一个独立的、带人机交互界面的业务功能。 n 界面集成 界面集成是对不同界面展现组件之间的集成。通过合理的规划和设计，界面集成可以重用已有的企业内外界面资源、提高开发部署效率、迅速满足客户和业务的需求，从而提高界面开发的灵活性和简易性。 界面集成有静态和动态两种集成方式。 静态集成方式：开发人员以固化的方式集成各类界面展现组件，提供人机操作界面，实现系统的业务功能。 动态集成方式：采用界面集成工具，通过简单灵活的配置来定义各个界面组件之间的关系，组成用户界面，并定义界面的流程。在规则管理和流程管理的控制下，在系统运行过程中动态地决定界面的外观、行为和人机交互过程。 动态集成方式的实现有利于提升系统的配置能力、界面的个性化、可扩展性，保证系统迅速适应业务需求的变化和发展。系统建设时应尽可能实现动态集成方式。 2.1.4.2 业务流程层 业务逻辑层将主要本系统中的商业逻辑的实现和业务流程的控制集中，将表示层和数据层从业务逻辑中解耦出来，而专注于其所擅长的界面表示和数据存储访问。业务逻辑层采用基于组件模型的面向对象的设计思想，并基于成熟的应用服务器平台而实现和运行。 n 业务流程 业务流程特指为了完成特定的业务功能，通过相应的规则与流程技术，将一个或多个服务进行编排而形成的业务流；系统业务流程可以作为子流程被其它业务流程调用，也可以被展现层直接调用。 n 实施建议 将业务需求中易变的业务逻辑及相关的业务规则剥离出来，通过流程与规则技术进行编排整合，保证系统的灵活性、可配置性、可管控性． 对数据量大、实时性高的业务流程可通过业务服务层进行封装，可以不通过动态的业务流程实现。 2.1.4.1 业务服务层 业务服务以面向服务的方式对一个或者多个业务组件的功能进行封装，它具有明确的接口描述，可以被其它业务服务调用，也可以被业务流程或展现层调用。 业务服务是展现层、业务流程层和ESB调用的对象。 业务服务的功能由业务组件来实现，服务原子服务和复合服务，某个服务也可调用其它服务来完成更复杂的业务功能。 业务服务具有高内聚、可重用的特征，可通过标准的、明确的服务接口描述将具体的一个或多个组件中的功能按一定的规则和标准进行封装，可以被发现、绑定和调用。 2.1.4.2 后台处理层 涵盖了整个系统中的后台处理系统，其特征是不直接面向客户，客服人员和市场营销人员，其主要的使用和操作对象为系统管理员和业务管理员，后台系统的可靠运行是港华燃气业务能够正常运行，尤其是客户服务和各类营销活动能够正常展开的有效保障。 2.1.4.3 信息存取层 是系统的数据存储中心，按照业务和功能将系统的数据划分为如下几个数据库，在实际部署和运行中，考虑到实际容量和性能等原因可以进行适当的调整。 l 应用数据库 l 港华燃气数据库 l 日志数据库 n 数据存取 数据存储层专为业务逻辑层中业务组件提供数据资源操作和访问功能，包括对关系型数据库的CURD操作和文件系统的读写操作等。 完成业务对象(Business Object）的封装，以及业务对象到底层数据库结构之间的转换，实现对原始数据的存取访问，从而帮助业务组件层实现对业务对象的处理，使得业务组件层对数据的访问不受数据库物理设计、物理分布的影响。 能对数据库、操作系统文件或其他形式存储的数据进行操作，保证数据的完整性、一致性和准确性。 屏蔽信息资源层上数据模型和数据格式方面的差别，例如当数据定义的语义和语法不同时，可以在必要时进行语法转换和语义解析。 数据集成功能，屏蔽信息资源层上数据分布的差异性和分散性，例如实现跨表、跨库、跨地域的数据操作和访问。 2.1.4.1 信息资源层 信息资源层负责系统的数据存储及维护数据的完整性与一致性。数据可以根据需要存储在数据库管理系统、文件、外部存储设备中。信息资源层数据的组织按照企业业务概念模型在应用软件上优化实现的要求形成各个主题域，并支持《数据模型规范》中定义的概念模型和逻辑模型。 2.1.4.2 外部接口层（统一接口平台ESB） 系统的统一接口平台，面向不同外部系统的特征和要求提供不同的接口模式，包括实时接口模式，文件模式，基于消息的接口模式等。面向的外部系统主要包括财务系统，港华燃气TCIS系统，各支付接口，其他合作伙伴系统等。 服务总线的概念是从面向服务体系架构发展而来的，是所有基于面向服务的体系结构解决方案的核心组成部分，是SOA架构中应用整合的骨干。 服务总线功能如下： 服务总线是所有跨系统服务的注册中心，各系统的业务服务层甚至业务流程层提供的服务都可以在ESB上进行注册，从而对企业各系统的所有服务进行统一管理和查询；解耦域内各个子系统之间的调度。 实现对所有服务的管控，包括对服务调用权限的定义和控制以及对服务全生命周期的管理，即管理每个服务从需求提出-〉开发-〉发布-〉部署上线-〉维护更新-〉下线的全过程。 2.1.5 基于J2EE的软件层次结构 l 客户端 在基于J2EE平台的系统架构中，这里的客户端目前仅指Internet浏览器。 l Web层 运行于Web Server上，用于实现各类静态，动态页面展现，页面跳转控制等，在网站Web层主要采用MVC的设计模式。 View 视图。实现各类信息的展现，接受客户端的输入，并将输出信息通过页面反馈。在J2EE应用中，View层的表现形式一般为各类htm,jsp文件，以及各类资源和属性文件。 Controller 控制器。是MVC中的枢纽。用户各种类型的HTTP请求都将通过Controller进行处理，并将处理结果通过JSP（view）推向前端，因此控制器也可以说是控制了各类页面之间的流转。Controller以Servlet的方式来实现。 MVC Framework 这是实现了MVC模式的基础框架，可以采用目前较为成熟的struts,也可以自己开发。具体框架选用可后续根据实际情况与用户讨论确定。 l 业务层 在这一层实现了主要的业务逻辑和流程，其运行的主要上下文环境是EJB容器，并充分利用容器所提供的安全，事务，持久性，连接池等基础服务，按照功能的不同又可以分为如下几个层次： Model 是MVC中负责业务逻辑访问和实现的层次，也是对业务封装并向应用的上层开放的层次，其一般的表现形式是Java Bean，通过bean来调用相关的业务逻辑实现。 业务控制层 系统的业务流程的实现层，其实现方式可以是根据业务流程对底层业务组件并行组合和包装形成更上层的应用组件；也可以是通过工作流引擎来驱动流程的实现。 业务组件层 实现了从系统中抽象出来的各类系统和业务基础组件，其基本特点是可重用，可扩展，相互之间耦合度小，可以采用JAVA Class的方式来实现，并向上层提供Interface以供调用。 数据访问层 对数据层访问的接口层，在J2EE平台中对数据库的访问可以通过JDBC直接建立连接或者通过连接池共享连接的方式进行数据访问。对于一些简单的数据访问也可以在JDBC层次上通过实体Bean实现数据持久层，其好处是数据的持久性和事务的管理由容器来负责。 l 数据层 存放系统中的各类数据，通过JDBC进行本地数据库的访问，与核心TIS系统的数据交互通过webservice方式获取。 2.1.6 关键设计考虑 2.1.6.1 可靠性设计 港华燃气系统是一个基于在线生产系统派生系统，直接关系到客户服务的质量以及企业运营的效率与收入，因此要求系统能够达到7X24小时不间断稳定运行。由于港华燃气系统模块功能复杂，系统间结构与层次较多，在系统建设时需要对系统未来运行稳定型进行全面考虑与设计，并纳入系统设计的关键考量。我们将主要从主机与平台软件的可靠性、网络可靠性、应用软件可靠性三个方面来考虑并设计： n 平台可靠性 平台是指整个系统运行的基础硬件与软件环境，包括主机、网络、数据库、交易中间件、J2EE应用服务器、流程引擎等基础软件。平台是构造先进而实用的应用系统的物理基础。江苏移动将几个方面来保证平台的可靠性： A. 从系统的先进性、业务容量、成熟性、实用性、可靠性出发，综合以上考虑与未来的扩展因素，同时考虑本期工程的资金投资，选择具有成熟应用案例与经验的软硬件平台，构造应用系统稳定的基础； B. 充分考虑系统关键网络节点、网络链路、关键应用平台等的在线热备份，包括核心交换机与路由器、数据库服务器、关键应用服务器等，适当考虑平台的冗余性，避免单点故障的产生，保证关键平台故障发生时的透明快速接管。 n 应用软件可靠性 应用软件的可靠性是系统不间断运行的能力。应用软件可靠性需要从软件架构设计部署与在线系统应用备份设计两个方面来考虑以提高系统的稳定性与容错性。 一、 软件架构设计与部署 为了能够从软件体系架构上提高软件的可靠性，港华燃气系统采用了运行核心平台与上层业务系统分离的设计模式，所有的业务应用都基于稳定的基础业务运行平台而构建，基础业务运行平台独立于应用开发并统一演进，提供上层应用运行所必需的基础引擎与环境，以保证应用的稳定性与可靠性。 分布式应用软件的部署也是关系到系统稳定性的重要因素之一。我们在进行本系统应用部署设计时将充分考虑一下原则与方法： 1. 区分关键应用与非关键应用考虑部署，一方面减少应用间的相互影响，另一方面提高未来根据系统运行情况进行部署调整优化时的灵活性与伸缩性。 2. 区分快速联机交易与批量业务考虑部署，这也是提高系统性能并保证核心业务稳定运行的主要策略。 3. 考虑硬件平台的处理能力，并结合预计业务的发展情况，根据相关资源的消耗情况涉及足够的处理能力冗余，以降低由于出现性能瓶颈进而导致系统稳定性下降的可能性。 4. 在系统上线之前将进行充分的、具有足够业务冗余的业务量测试，并根据测试结果合理调整应用的部署。 二、 应用备份设计 为了能够降低系统故障导致应用处理中断给业务运营带来的影响，必须在系统规划与建设初期对应用软件的备份进行设计。应用的备份根据是否存在人工干预、备份切换时间等可以分为在线热备与冷备份两种，而从应用的分布与层次则主要考虑各类应用服务器的备份，而应用服务器则又可以分为交易应用服务器、WEB应用服务器、后端处理应用服务器等类型，设计时需要结合应用的特点与重要性考虑不同种类应用备份的实现方式。在本次系统建设中建议对关键应用包括计费应用、前台业务受理应用、服务开通进行在线热备份，保证系统故障时的自动切换；对其他应用采用独立服务器进行冷备份。各种类型应用服务器的在线热备方式考虑如下： l 后台处理服务器 后台处理服务器采用基于主机的HA cluster方式进行，在平台或者应用故障中断运行时由备机快速接管应用，保证不间断运行。考虑到业务量与投资规模，在本系统可以采用一台应用服务器备份多台机器的策略。 l 交易应用服务器 交易应用服务器需要接收客户端的请求并进行业务逻辑的处理，因此该应用服务器的备份需要同时考虑远程客户端的接入切换与后台服务器的应用接管。在港华燃气系统中，主要考虑以下可能的在线交易的应用备份策略： 1. IP映射技术。这种方式通过网络设备（如交换机或者路由器）对内部的在线应用服务器与备份应用服务器位置进行映射，对客户端提供统一的IP地址。并可以由网络设备自动检测应用的状态，在线应用发生故障时，可以自动把客户端请求转发至备份应用服务器，整个过程对客户端透明，同时这种方式在系统正常运行时也可由网络设备根据预定义的策略实现负载分担，且缺点是需要网络设备支持（需要四层交换功能）。 2. 通过主机cluster集群软件进行。这种方式采用浮动的IP网络地址来向客户端屏蔽内部服务器的位置，当在线系统失败时，集群软件无须人工干预即可自动启动备份应用服务器并对外提供服务，整个过程对客户端透明。 3. 动态域名解析。在线应用服务器与备份应用服务器各自保证应用的运行，客户端接入通过域名进行，在发生故障时，由域名解析服务器动态的将域名切换到备份应用服务器。这种方式的缺点是需要实现应用检测并动态调整域名解析表的功能。 4. 应用实现名字解析功能。这种方式类似于J2EE中JNDI机制：客户端不直接通过固定的IP地址访问特定的应用服务器，而是首先通过名字服务器获得对应应用逻辑的位置后再通过该调用该位置的应用逻辑。这种方式的优点是可以灵活调整应用的分布而无需客户端做出任何改变，可以实现应用的“部分备份”；其缺点是名字服务器本身需要确保足够稳定。 5. 利用应用服务器基础件本身的功能。部分交易中间件具有客户端自动监测并切换后端应用的功能，当系统正常运行时，客户端通过轮换机制实现后台在线与备份应用服务器的自动分担；当系统发生故障时，客户端则根据相关的配置切换对应的后台应用，以达到不间断运行的目的。 在本期港华燃气系统的建设中，主要推荐1、2、5三种应用服务器的热备份策略。 l WEB应用服务器 WEB应用服务器的备份实现与交易应用服务器的备份实现具有较多的类似可参考之处，同时针对web应用及相关J2EE平台的特点，还可以考虑充分利用绝大部分J2EE应用服务器具有的软集群功能，同时在WEB应用服务器前侧增加专用的HTTP接入proxy server来实现后端企业应用间的负载分担与灾难备份，在发生故障时，由HTTP proxy server负责将请求转发到备份web应用服务器。 2.1.6.2 灵活性与可扩展性设计 在建设港华燃气系统时不仅需要参考系统的设计容量，同时也需要充分考虑到未来随着业务的发展如何对现有的设备与软件进行扩展和平滑升级。一般来说，一个软件的系统扩展需要从硬件和软件两个方面进行，因此在考虑系统的扩展性时硬件平台需要考虑相关网络与主机方面的处理能力扩展与延伸；软件则需要从功能与处理性能两个方面来进行系统的可扩展性设计，同时也需要考虑到保护投资、充分利旧等因素。 n 网络与主机能力扩展 网络的升级扩展需要从多个方面综合考虑，并在系统建设初期根据相关原则，参考设计容量以及业务发展趋势对支撑网的影响，并结合以往系统的建设经验，合理规划具有良好扩展性与易于升级的网络建设方案。 A. 网络接入能力的扩展：接入能力是指交换机/路由器接入用户数的扩展能力，这种能力扩展一般出现在网络边缘，对于本次建设的港华燃气系统，则需要充分考虑未来港华燃气系统各种网络接入的终端数目的增加，因此在设计相关的网络方案时，充分考虑了接入部分的扩展能力，包括各类交换机端口数目的预留等。 B. 处理能力扩展：处理能力主要是指的核心网络设备的数据转发与处理能力。 这种要求主要出现在支撑网络的汇聚层与核心层。随着业务量的增多、业务数据流量的逐渐增大，或者当出现较多的网络质量与安全控制策略时，这些核心网络设备处理能力的不足就可能影响到正常业务的运行。在本项目方案中，江苏移动将根据设计容量并考虑未来必要的冗余，同时参考目前港华燃气TCIS系统中支撑网业务量的大小与网络设备的关系，并结合各主流网络设备的特点来综合设计各类核心网络设备的处理能力并选型，以保证未来业务需要时，能够尽快地通过模块增加、引擎升级、负载分担等手段快速的进行核心网络设备处理能力的扩展。 C. 通信带宽的扩展：随着数据量的增大以及各类应用功能的调整与增加，网络带宽将会有更高的要求，网络通信的带宽也是影响各类业务正常运行尤其是处理性能的重要因素之一。在本系统的建设中将充分考虑业务的特点及网络数据交换量的大小，预留足够的网络带宽以适应未来的带宽需求。 主机服务器的可扩展性是指服务器（包括存储）的硬件配置可以根据需要灵活配置，如内存、适配器、硬盘、处理器等，因为服务器的硬件配置可能是根据不同时期的网络配置与业务容量而改变。因此在设计本系统的主机相关配置时，将充分考虑本次设计容量、服务器所承载的数据或者应用特点考虑对应的硬件选型方案。 n 软件能力扩展 软件扩展能力是应用适应未来业务量与业务需求变化的能力。这些变化有的要求增加软件功能，有的要求应用处理能力能够实现良好的动态伸缩。港华燃气系统作为业务运营的支撑系统，本身具有较大的业务需求覆盖度与软件规模，同时作为飞速发展的燃气行业应用软件，将会面临着用户规模与业务量的不断增大以及各种新业务的推出，这些都要求支撑系统能够快速的适应需求的变化，包括性能需求与功能需求。因此针对港华燃气系统将主要从两个方面来考虑应用软件的扩展能力，包括软件功能的扩展与软件处理能力的扩展。 软件功能的扩展：软件功能的扩展性决定了支撑系统是否能够“随需应变”，以及在功能变化与扩展过程中是否能够保证软件基础结构与核心功能的不变与稳定性，而不是简单的采用代码修改的方式增加软件功能最终导致软件的臃肿与崩溃。 在本次系统建设中，将通过以下手段与设计策略来保证最终应用的高度扩展性，以帮助运营商快速的支撑新业务与业务的调整。 港华燃气网上营业厅系统采用基于组件的软件分析、设计与开发方法进行构建，通过对燃气行业业务的深入理解与抽象，将支撑系统软件在现有的分层化的基础上进一步模块化与组件化，同时抽离出独立的、公共的、具有扩展接口的业务引擎与组件作为上层应用运行与开发的基础，并在此独立的通用业务运行与开发平台上进一步对该平台中的业务组件进行扩展或者开发新的业务组件以满足客户化的需求与功能要求。这种方式给应用软件的扩展的带来的两大核心好处是： 1. 具有良好的、快速的、基于标准接口的应用扩展性。软件功能的扩展不再是简单的现有代码修改，而是在现有平台的基础上通过增加新的业务组件、更改相关的软件配置与流程定义、基于现有组件开放的二次开发接口进行新功能的实现。各种业务功能不再是固化的，而是可变可增加的。同时由于基础的业务平台屏蔽了较多的底层平台的差异与技术细节，并且实现了大量的公共业务功能与引擎，这使得二次开发与扩展工作可以更加快速的进行并满足需求。 2. 提高了系统扩展过程中应用软件的稳定性。在现有各业务支撑系统中，常常出现由于大量的新业务需求对应用功能带来的变化，大量的修改常常带来应用架构的脆弱，并最终体现到生产系统中，带来较多的系统隐患，有的甚至直接影响到客户服务的正常提供。在这种功能扩展方式中，强调了核心平台与业务功能的通用与重用，以及业务功能开发人员不再关注底层引擎与平台的变化，一方面，核心的业务功能在不断的重用过程中得到完善，另一方面，业务开发人员可以更加专注于业务功能的开发，提高软件的质量。 此外，从管理上设置了专门的业务分析与软件设计部门与岗位，充分保证在业务发展的过程中能够及时跟踪业务的发展与变化并分析，且对相关的软件架构进行必要的及时的调整，并进行针对性的设计，以保证软件功能的稳定快速的扩展。 软件处理能力的扩展：随着用户量与业务量的发展以及新业务功能的不断推出，应用软件需要在系统最初的设计容量范围内满足更高的处理性能要求，包括请求相应时间、并发数量、实时业务处理能力等。软件处理能力的扩展一方面要求软件设计与开发时能够提高单位处理的效率，另一方面要求软件能够在不修改的情况下提高处理吞吐量，港华燃气系统关键的处理能力扩展相关的设计考虑包括： 1. 采用可配置的多通道并行处理思想设计关键应用，通道扩展能够跨越服务器边界，如在业务系统中能够把处理部分用户标识号对应的服务使用记录的处理迁移到位于另外服务器中的独立通道进行处理；在联机充值系统中能够动态调整充值处理通道的数目等； 2. 各类交易与WEB应用服务器均可以通过相关参数配置的调整灵活改变系统处理能力，并能够针对各类业务进行独立的调整。如在业务高峰期间适当限制较大批量数据的联机请求处理，而增大联机事务处理的吞吐量；而在业务低峰期则又可以重新调整配置以降低相关处理通道的数目；此外在进行软硬件平台的选型时也充分考虑基础软件的处理能力扩展性，比如动态负载均衡能力、软件集群能力等，以满足在业务量增大时可以灵活的调整系统配置部署。 2.1.6.3 稳定性,高效性和易维护性 n 数据库 MySQL数据库服务器的master-slave模式，运用 数据库服务器在主从服务器间执行 同步，运用 只把数据写到主服务器，而读数据时则根据负载选择一台从服务器或者主服务器来读取，将数据按不同策略划分到不同的服务器（组）上，分散数据库压力。 n 缓存 运用缓存能有效应对大负载，减少数据库的压力，并显著提高多层运用 程序的性能 n 独立的图片服务器 　　对于Web服务器来说，不管是Apache、IIS还是其他容器，图片是最消耗资源的，于是我们有必要将图片与页面进行分离，这是基本上大型网站都会采用的策略，他们都有独立的图片服务器，甚至很多台图片服务器。这样的架构可以降低提供页面访问请求的服务器系统压力，并且可以保证系统不会因为图片问题而崩溃，在应用服务器和图片服务器上，可以进行不同的配置优化，比如apache在配置ContentType的时候可以尽量少支持，尽可能少的LoadModule，保证更高的系统消耗和执行效率 n 服务器集群与负载均衡 CDN ： 通过在现有的Internet中添加一层新的网络架构，将站点的内容揭晓到最接近用户的cache服务器内，通过DNS负载均衡的技能，判断用户来源就近访问cache服务器取得所需的内容，处理 Internet网络拥塞状况，提高用户访问站点的响应速度，如同提供了多个分布在各地的加快器，以达到高速、可冗余的为多个站点加快的目的。 2.1.6.4 性能设计