招投标软件系统技术和服务解决方案

附件为全部文章,敬请下载。 ↑(完全免费,直接免费下载)

软件系统技术和服务解决方案

目录
第一部分 服务方案 6

第一节、 服务方案概述 6
第二节、 服务方式 6
第三节、 服务机构 7
第四节、 服务响应 8
第五节、 服务内容 9
第六节、 质保期内免费服务 9
第七节、 服务原则 10
第八节、 服务质量 11
第九节、 技术实现方案 12
第十节、 非功能性方案 19
第十一节、 系统部署方案 26
第十二节、 项目实施 37
第十三节、 项目评审 64
第十四节、 培训计划 90
第十五节、 项目过程及质量保障 91
第十六节、 项目验收 104
第十七节、 售后服务方案 109

第二部分 应用平台设计 119

(一) 技术目标 119
(二) 分层结构 119
(三) 服务层 121
(四) 持久层 122
(五) 工作流技术方案 123
(六) 企业微信端 130
(七) PC 端 133
(八) 安全架构 134
(九) 安全设计 148

第三部分 服务质量保证方案 155

(一) 项目审查会议制度 155
(二) 全过程检查管理 155
( 三) 全过程汇报制度 156
(四) 工作管理制度 156
(五) 风险管理制度 169
(六) 安全性设计原则 170
(七) 终端认证 171
(八) 终端授权 172
(九) 本地安全存储 172
(十) 数据传输安全 172
(十一) 数据库安全机制 173
(十二) 容错机制 174
(十三) 数据同步 174
(十四) 服务器集群和负载均衡 175
(十五) 队伍素质保障 177
(十六) 人员数量保障 177
(十七) 技术人员保障 177
(十八) 产品质量保障 178
(十九) 系统上线保障 180
(二十) 质量保障监督 181

第四部分 进度保证方案 184

(一) 进度控制的组织措施 184
(二) 进度控制的管理技术措施 184
(三) 进度控制的合同措施 185
(四) 进度控制的信息管理措施 186
(五) 项目组人员保证方案 186
(六) 开发质量保证方案 187
(七) 项目进度保证方案 195

第五部分 系统培训方案 197

(一) 培训承诺 197
(二) 培训目标 198
(三) 培训计划 200
(四) 培训形式 201
(五) 培训对象 203
(六) 培训内容及大纲 204
(七) 培训组织机构 210
(八) 培训课件设计 212

第六部分 售后服务方案 214

第一 售后服务承诺 214
第二 售后服务保障 215
第三 异常情况特别服务 218
第四 人员组织管理 220

第七部分 其他 226

第一 运维保障方案 226
第二 应急服务响应措施 229

第一部分 服务方案

第一节、 服务方案概述

作为的软件解决方案和服务提供商,充分融合国际一流的服务理念、方 法论和管理方法,结合多年来服务多行业经验和技术能力,已经建设有一 整套完善的技术服务体系,能够向我们的客户提供高效和高品质的技术支持和技术服务!

我公司一贯奉行技术先进、服务完善的原则,为此而赢得客户高度的肯 定和赞扬,在本项目中,我们将一如既往,本着一流服务、客户至上的服务原则,提供长期、优质、高效的技术支持和售后服务。

第二节、 服务方式

1.咨询服务

我公司具备多年的移动应用开发和系统整合实施经验, 累积了大量的技术、业务方面的知识和经验, 秉承一贯的开放性原则,我公司向客户提供了各类咨询服务, 共同分享这些成果。

2.应用系统的故障响应

当应用系统出现故障时,对故障进行综合诊断,提出解决办法。 如属于系统硬件平台以及系统故障,则为相关厂商排除故障提供应用级的配合和协助;如属应用故障则立即启动应用故障排除流程,使系统在最短的时间内恢复正常。

3.应用系统辅助操作

辅助客户的日常维护管理技术人员完成比较复杂的维护操作以及突发性事件处理等,如数据的备份、恢复,数据转载,重建索引、临时性统计、历史数据核查、年度参数设置、搬迁、服务器升级等。

4.应用系统的维护服务

主要指针对应用系统运行过程发现的潜在质量问题(如 Bug、程序缺陷)而进行的程序修改服务活动。

5.交流和培训

依据客户要求,不定期举行交流和培训;根据需要和客户时间安排,不定期举行技术交流和专题培训。

6.应用系统业务调整

应用运行到一定时间, 由于业务的发展, 可能需要对应用系统已有的业务规范、流程作出相应的调整。

在应用中, 已采取了多种途径最大化地实现了业务参数化、模块化的可能性。 我公司将为用户的业务调整提供技术、业务上的有力支持。

7.应用系统升级

当业务的扩展到一定的程度, 原有的系统体系结构已经无法为进一步拓展提供空间时,需要为应用系统进行必要的升级。 我公司将为用户实现这方面的服务。

第三节、 服务机构

为保证响应时间及服务质量, 必须提供快速相应的机制,必须具备必要技术人员和技术服务能力,以响应招标人的技术服务要求。

在质保期(质量保证金扣留期限)内,投标人应提供至少 2 名本地售后服务人员(要求在本项目建设中常驻现场并参与数据建模和数据治理工作)。 在用户现场提供技术支持和故障清查、错误修改、业务改进及新增业务需求的修改、软件维护等服务。

我公司的技术支持和售后服务体系分为三级:

1、现场服务

我公司依托全国各地的分支机构,在当地设立本地化服务团队,为客户提供现场技术支持和售后服务。

2、公司运维中心

我公司在设立了客户服务中心,开通了 7*24 小时的热线服务。运维中 心由专业的客户专员、客户经理以及技术支持专家组成,他们受理所有的 服务求援电话、传真、邮件和服务投诉,建立客户服务记录,并根据服务 请求性质分配和调配人力资源,追踪服务请求的解决过程,重大服务完成后定期对客户进行回访。

3、公司维护服务专家组

对于重大故障或者需要较高技术的服务,我公司根据客户的具体情况, 紧急成立由各专家和资深技术人员组成的专家服务组,为客户提供诊断和技术咨询服务, 迅速排除故障。

第四节、 服务响应

明确承诺项目建设期间及质保期内的售后服务响应时间,并不得低于以下标准:

提供 7×24 小时电话或电子邮件服务,接到用户报修通知 1 小时内做出 明确响应和安排,2 小时内做出故障诊断报告。如需现场服务的, 具有解决 故障能力的工程师应在 4 小时内到达用户现场。接到用户报修通知之时起 6小时内解决软件故障。

1、重大故障

对于系统的重大故障,我公司在接到故障报修电话 30 分钟内做出实质响应,若未能解决故障,我公司启动更高级别的响应服务,并在 2 小时之内到达现场处理。

2、普通故障

对于不影响系统正常运行的软件和硬件故障,我公司实时响应,根据 客户具体情况以及备件情况,通过远程诊断、电话咨询、现场服务等手段排除故障

第五节、 服务内容

无论是否在质保期内,我公司都可提供如下技术服务项目

1、升级服务

提供在正常条件下保证系统正常稳定运行的系统扩充、版本更新升级及功能更新服务。

2、优化服务

提出在正常条件下改进系统性能的各项建议,包括系统资源分配与效 率改进建议、软件配置规划和性能优化建议、系统容量预测建议等,并进行实施。

3、咨询服务

包括系统软件应用和维护技术咨询服务。

4、电话或现场技术服务

提供电话远程服务以及必要的现场技术服务

第六节、 质保期内免费服务

质保期内中标方通过电话和现场技术服务方式进行的免费服务包括以下内容:

  • 系统故障解决;
  • 系统升级性服务:提供在正常条件下保证系统正常稳定运行的系统扩充、版本更新升级服务;
  • 系统运行的咨询服务:提供系统软件应用技术咨询服务。
  • 所有实施服务的质保期自本项目终验合格交付使用并签订终验证书之日起开始计算。投标人提供一年免费升级和人工保修维护, 7×24小时软件工程师现场维护。
  • 项目质保期服务时间不得少于 12 个月,自本项目终验合格交付使用 并签订终验证书之日起开始计算。
  • 项目建设期间及质保期内的所有售后服务均由售后服务人员到业主 产品使用现场提供服务,并对系统设备和软件提供一季度一次维护巡检。
  • 项目建设期间及质保期均属于免费服务期,该期限内的所有售后服 务,包括原厂商服务和非原厂商服务。
第七节、 服务原则

实用性原则

信息化系统的建设关注的是投资与回报。业务的可持续运行和数据的 安全是此次系统建设的根本, 只有在此基础上才能考虑信息系统的可靠性、可扩展性、 安全性以及可管理性。

信息化系统的性能是由应用系统的数据流量分布、服务器、存储备份 设备性能综合决定的。对应用系统的数据流量分布认真分析是信息化设备选型的基础。

方案必须采用成熟的、 经实践证明其实用性的技术。在选择服务器、 存储设备的过程中,我们应充分考虑保护和利用现有的资源,同时要根据实际情况,采用新技术和新设备。 另外要考虑平台的建设和平台的开发应用同步进行。总之力求使系统既能满足当前需要,又能适应未来发展,同时达到较好的性能和性价比。

可靠性原则

数据的可靠性是设备运行的一个重要指标。设计必须对可靠性重点考虑。 从结构设计、产品选择以及网络管理上要对整个系统的高可靠性和稳定性作出保证。系统传输信息的差错率要小,成功率要高,无故障运行时间要长。

由于运行核心业务系统,需要保证设备的正常运行,不因硬件的故障 或变化引起业务的瞬间质量恶化甚至业务的中断十分重要。硬件系统的可 靠性通过冗余技术实现,包括电源冗余、处理器冗余、模块冗余、设备冗余、链路冗余等技术。

扩展性原则

随着信息化的发展, 新的需求将随着应用业务系统的增加而逐步增加, 因此对系统设备的要求也越来越高,选用的技术和设备应能满足用户对系 统扩展的要求,选用的设备应具有兼容性,满足应用系统建设不断完善的需要。

标准性和开放性原则

系统的设计应符合国际标准和工业标准,采用开放式系统体系结构, 。

先进性原则

采用先进的技术,选用的技术和软硬件产品应具备持续发展的能力。

安全性原则

系统应具有良好的安全性,因此需进行有效的安全控制和管理。

第八节、 服务质量

我公司采用以下措施或手段,来提高技术服务的质量。

1、适应 IT 市场需要,改革服务组织体制
2、强化市场意识,推行诚信服务
3、提高员工素质,充分发挥每位员工的作用
4、完善激励机制,培养员工的责任与风险意识
5、实行集成与项目经理责任制

第九节、 技术实现方案

(一)架构

根据项目规划和系统架构的设计,系统平台架构是面向服务(SOA)的架 构,无论是 Web 应用、应用还是桌面应用, SOA 架构均可以充分满足当前的应用需求,也可很好的适应未来信息系统增长的需要。

合理的架构设计, 利于今后的扩展和升级, 考虑对于未来业务的发展,立足在产品的基础上通过升级改造来实现新需求的满足。

在本项目中,针对核心业务系统, 我们给出公司成熟的、技术先进的、 且经过多个实际项目实践成功过的架构作为本项目的架构, 其它的业务系统我们则采用主流的、 官方建议的架构, 从技术上保障项目的成功实施。

系统架构基于多层框架为核心构建,本架构成熟、稳定、简洁、易扩展,采用主流或开源的平台或组件,可以获得最佳的性价比。

系统架构是一个多层分布式的系统架构,系统分为表现层、业务层和数据层,可根据需要灵活地添加每层的服务器,进行分布式扩展。

表现层:针对 PC 端的表现层,以手机微信的形式与服务器交互;针 对终端的表现层已与服务器交互。通过以上表现层,可以获得更好的响应速度及用户体验。

前端框架层, 采用主流的 MVC+JQuery 框架,最大程度降低业务逻辑、 数据、界面 UI 的耦合程度,便于今后系统的扩展及维护; JQuery 使页面能 更方便地处理 HTMLDocuments,Events,实现动画效果,并且能方便地为Web应用提供 AJAX 交互,提高用户体验度。

服务接口层,采用 webservice 技术,面向 Web 及客户端提供统一的 接口服务,通过以 JSON 格式向客户端提供服务,从而避免重复的接口开发工作;

业务逻辑层,包含处理应用系统的各种业务逻辑组件,包括安全认 证、来电处理、统计分析等等业务组件,所有业务处理都是采用现在流行的面向服务的设计。

数据层,提供数据存储和数据访问服务。采用大型关系型数据库, 单独部署在独立的数据库服务器上, 只能通过应用服务器访问,以保证数 据的安全。数据层既可支持不同的关系型数据库,也支持目前流行的面向对象非关系数据库带来更好的性能。

本架构适用于业务系统、 协同转办系统、 门户网站及所有为不同终端提供服务的系统或服务。

(二)采用的技术

采用软件框架的开发思想,可以提高系统的性能和开发的速度,同时也有利于与其他软件产品进行整合。
在这里插入图片描述

1. 组件式开发

软件产品的所有功能全部采用组件式结构 组件式结构是提高开发效率、系统扩展性及稳定性的关键技术。按照组件规范开发的组件就可以实 现组件间的互操作,新的或升级后的功能部件“插入”系统后,便能“即插即用”,自动实现与系统的无缝连接和升级。
在这里插入图片描述

2. 积木式方案组合

系统所采用的所有产品可以独立分布和运行, 符合统一的安全、开发、部署规范,可以进行自由组合使用。
在这里插入图片描述

3. 采用统一的技术框架

在 J2EE 开发中广泛使用的 Eclipse 开发工具,采用 Struts 和 Hibernate,遵循 MVC 即 Model(模型)-视图(View)-控制器(Controller) 设计模式,并将 Model 进一步划分为“业务应用(Business Process)- 业务服务单元(Business Server Unit)-持久化(Hibernate+JDBC)” , 形成“View-Controller-Business Process-Business Server Unit-Hibernate+JDBC”的多层架构,其框图如下:

在这里插入图片描述

系统运行时,其 MVC 相关组件相互调用的基本模式如下图:
在这里插入图片描述

这套技术架构将和应用程序一起形成一个 WAR 包,独立的部署在应用 服务器上。即使应用服务器还运行有其他系统,打包的 Struts、Hibernate和应用程序将与其他系统物理隔离开,运行时相互不影响。

4. 基于组件架构

我们将依据总体规划和业务实际需要,系统采用 SOA 架构:

1.统一的数据模型:所有数据都以统一的方式展现

2.统一的调用方式:所有组件通过统一的方式表示,所有组件通过统
一的方式调用。

3.统一的服务方式: Web Service 改系统连接为系统对外开放服务

4.标准的服务编排:组件可以统一编排,与它们具体的实现方式无关

5.统一的调用方式:服务组件

6.业务逻辑不仅仅仅封装成一个组件,而且采用组件服务的方式,提供 WSDL 和 Java 接口的方式, 可以为广域网上远程相关系统提供应用集成、数据交互、服务使用提供统一的对外的调用。
在这里插入图片描述

系统的技术框架层是在系统框架层(操作系统、数据库及应用服务器) 和应用系统之间建立的一层技术封装层和系统资源监控和管理层。框架运 用了登录和安全框架(Security Framework)、持久化框架(Persistence Framework)、工作流引擎(Workflow Engine)、消息引擎(Message Engine)、 调度引擎(Scheduler)、缓存(Cache)服务、异常(Exception)处理、 运行日志(Log)管理等基础服务 ; JSP Tag、ajax 瘦客户端技术 ;同时框架中有运用了先进设计模式等。

该方案按照采用面向服务 SOA 的技术架构,该方案按照 SOA 的服务建模、组件开发、服务封装等思路进行设计开发。

基础架构层:它包括操作系统、中间件、应用服务器等支撑环境;

企业组件层: 用不同的组件把系统功能封装起来,以组件的形式出现;

服务提供层:用企业组件来构建所需要的不同功能的服务, SOA 中的服务可以被映射成具体系统中的任何功能模块。

业务流程管理层: 利用已经封装好的各种服务来构建商业系统中的商业流程。

业务展现层:利用业务展现层来向用户提供用户接口服务,可以用基于portal 的系统来构建。以上这 5 层都需要有一个集成的环境来支持它们的运行,企业服务总线(ESB)提供了这个功能。基础架构服务:主要为整个SOA 系统提供一些辅助的功能。

以上是一组最低功能,开发时可以确定利用何种现有技术来实现。通 过考虑特定情形下的需求如何确定对额外功能的需要,可以选择最适合这 种情形的实现技术。其中核心的 Web Services 服务方式,在内管系统中的具体实现内容包括:

规定了服务规约的基本原则和方法,采用服务标识、服务提供者、服 务使用者、服务描述、方法名称、方法功能、输入参数、输出参数等一组属性对交换服务进行规范性描述。

(三) 技术规范

  • 模块化

本系统是一种低耦合、 高内聚的组件化应用系统, 即在模块内部是 个具备关联性的整体, 同时在模块之间是一种有机的组合。系统将在为复 杂企业应用软件系统的开发提供一个基本框架(技术框架层和应用框架层)的同时,提供与之相应的、方便易用的开发、实施、维护和管理工具集。这个工具集预置了大量的基本功能件、核心功能件和应用组件,支持企业模型的仿真、分析、诊断、优化和调整。通过技术框架和应用框架提供的 开发与管理工具,能很方便地满足个性化的需求及在发展过程中各种各样 变化的需求;降低开发难度,提高开发效率;支持基于企业参考模型的快速实施; 提供全新的应用软件开发模式。

  • 权限管理

系统提供完善严密的权限控制机制,来保证对不同操作员的业务处理范围的授权。系统提供两个层面的权限管理:功能权限和数据权限。功能权 限细化到功能模块、功能节点、功能菜单/功能按钮等三个层次的的权限级别。该权限机制机能保证应用模块功能安全按不同的级别分级控制与管理,同时保证功能权限的更丰富划分。

数据权限即对人员对数据的业务操作范围的权限控制,例如部门负责人仅仅对本部门人员所做的数据操作的权限。

  • 标准化、规范化

系统通过设置规范的业务流程,实现对业务管理的规范化,同时,通过下文所描述的编码系统设计,实现医院规范体系建设;

  • 流程化

系统通过流程的动态配置实现对业务的流程化应用。工作流的主要特点是(包含了各种基于人和机器的活动的)流程的自动化,特别是那些包含了应用程序之间的交互的流程的自动化。在一个工作流中,文档、信息 或任务等根据一组设定的规则在参与者之间自动传递,以实现整体的业务 目标。由于企业的工作流贯穿企业生产经营的各个阶段,所以企业通过引 入工作流能够加快流程处理速度,提高企业工作效率和企业市场竞争力;增加对工作流程的控制; 便于流程的整合,提升决策质量与正确度。

  • 简单化

系统是面向全员参与的应用系统, 因此在系统设计上必须考虑到不同 层次应用人员的操作习惯和操作的易用性,通过与内部系统整合应用实现不同应用人员的不同界面展示和灵活调整,实现系统的简单化简便化操作;

第十节、 非功能性方案

(一)性能设计

根据我公司大数据平台分析及计算,结合我单位的实际情况,年数据 量约在 100 万条,不含管理文件的数据容量大概在 20G 左右,管理文件容 量约 1T 左右,从容量和可扩展性和灾备等多方面综合考虑,建议每年的数据库服务器分配在 25G 左右,文件服务器容量分配 2T 左右。

各单位系统整合后,随着数据量、并发访问量呈几何级数增大,系统 平台的性能将是决定平台是否高效、实用的关键,性能高的响应能给用户 带来效率上的提升,加快工作效率,减少等待时间,同时加快了系统的处理效率,我们将通过以下几方面设计来保证用户得到高质量的响应:

  • 利用集群功能,合理分配负载,充分利用各主机的 CPU,内存等硬件 资源;利用集群管理, 当主服务器故障时,备份服务器能够自动接管主服务器的工作,并及时转换过去,以实现对用户的不间断服务;充分利用集群中的每一台计算机的资源,实现复杂运算的并行处理。
  • 负载均衡设计, 利用负载均衡根据某种算法合理分配到集群中的每 一台计算机上,以减轻主服务器的压力,降低对主服务器的硬件和需求。
  • 有效利用数据库的缓存功能, 对于经常访问的数据,可将数据缓存于数据库中,减少 IO 读写。
  • 配置分布式的缓存服务器, 对常用数据进行缓存,减少对数据源的实时访问。
  • 硬件部署上, 将数据库服务器、Web 服务器、Web 服务、缓存服务器、 文件服务器分开单独部署,减轻服务器压力的同时,提升性能的同时,便
    于今后分布式部署。
  • 对每年的历史数据作备份,备份的历史数据仅供查询用,使用中的 业务数据仅保留 6 – 12 个月的数据,减少历年累积的数据对处理性能的影响。

(二)安全性设计

考虑到企业信息化系统对安全的高标准,系统平台对安全性方面采用以下技术手段来保证系统的安全:

  • HTTPS 协议:因协同系统供多个单位使用,必须部署在公网,另外 APP调用的Web服务也需要部署在公网,
    为了保证数据传输过程中的安全性,部署在公网的应用及服务采用单项 HTTPS 协议;因中心目前已经有统一认 证平台及人员信息库,
    组织机构库, 内网用户使用统一认证平台验证用户登录合法性。

  • 身份认证:平台对所有的业务系统提供身份认证功能,使用系统的 用户必须先要经过申请审批管理流程, 通过管理人员的合法性审批;在系统登录界面中, 只有输入正确的用户名和密码,才能进入系统, 进入系统后用户可随时修改自己的密码。对用户密码可提供更严格的控制功能,如首次登录系统必须修改密码、经过多长时间必须修改密码、多次登录失败锁定用户等,进一步提供系统的身份认证安全性。

  • 数据加密:为了保证重要资料数据在数据库层不能被查看,系统对 重要数据加密后存入数据库;对于用户注册密码,我们采用将用户密码进行MD5加密后以密文的方式保存到数据库中,用户登录时,将用户输入的密码以同样的加密算法进行加密后,与当前用户注册密码的加密密文进行比对。

  • 权限控制: 系统提供权限管理功能模块, 系统管理员可增加、删除、修改用户、用户组,设置用户的操作权限、数据权限;通过用户、用户组及权限管理功能对登录的用户操作的页面、功能进行权限控制,实现系统应用的数据安全。

  • 操作日志:系统对用户登录情况,如登录用户、进入时间、退出时 间、操作功能项等进行自动记录;对于数据录入、数据同步、数据抽取和数据分析等应用处理的时间、数据范围、执行情况等也自动记录日志,以便出问题时跟踪追查审计。

(三) 可靠性设计

系统平台提供 24 小时面向客户的服务平台,因此必须确保 7×24 小时 稳定可靠运行; 平台需提供系统崩溃时的快速恢复机制, 确保系统出现故障时能快速恢复系统正常运行。

  • 对于核心的业务系统, Web 服务器、 IVR 服务器、数据库服务器采用 集群部署的方式分别部署在两台不同的服务器上,这样即使一台服务器停机,业务人员还可以正常使操作平台处理业务,不影响系统的正常使用。

  • 系统对用户数据输入的合法性进行严格校验,并对非法数据(如数据 类型及范围不匹配等)产生含义明确的提示。系统不会因用户非法输入而造成程序中止(产生源代码错误信息、死机等)。

  • 系统采用分布式架构,在资源占用、数据存储等方面设计合理,不 会对服务器造成过高压力而导致死机或服务器操作系统崩溃等情况;确保系统运行较长时间(如两年以上)后不会因信息过多、数据库容量不足而导 致整个系统的崩溃。

(四) 可扩展性设计

系统平台采用成熟、先进的主流技术,确保系统技术的持续领先性,保证项目投资的有效性、保值性和延续性。

  • 平台采用 SOA(基于服务的架构)架构, 所有的核心业务逻辑以服务 的形式发布,并且采用 ESB(企业服务总线)技术进行调度、调用;未来随着业务的扩展,只需要在原来的架构基础上开发扩展服务并部署即可,不 需要修改架构。

  • 所有的服务采用标准的基于 HTTP 的协议,服务端和客户端的数据交 互以基于 HTTP 的 JSON格式来进行数据定义,确保数据传输交换和效率,对 于大数据的传输使用 GZIP 进行数据压缩。

  • 采用分布式的架构,便于以后业务量及数据量加大后,方便扩展硬件,不需要调整架构及修改代码。

  • 服务端采用 MVC 框架开发,保证项目运行稳定性和保证后续开发的便利性。

  • 系统采用通用的标准、协议定义框架、接口,设计精当,方便向外 部系统提供标准的接口,接入外部系统或为外部系统提供服务,标准的设计可以充分满足项目需求,具有很强的适应性及可扩展性。

(五)易用性设计

在的易用性方面,我们将充分考虑用户群体的使用习惯,提供用户体 验好、简单易用、操作明了的用户界面, 高效地为客户定制一套更适合客户需要的的系统:

  • 使用大众化、标准的 Web 浏览器如 IE、Firefox 作为客户端的浏览 工具, 界面设计兼容主流的操作平台及浏览器。

  • 采用通用、标准的 UI 设计元素,减少歧义。

  • 用户界面友好、 同时易操作, 符合用户操作习惯, 界面操作符合浏览习惯、 界面风格术语统一;合理的组织操作菜单。

  • 提供友好的联机帮助界面及友好的错误提示界面。

(六)灾备设计

备份策略

为了保障核心数据和重要数据的完整性和一致性,我们将提供对应的磁盘备份、联机备份功能:

  • 磁盘备份:通过镜像(mirrored)磁盘矩阵,对每一个写到磁盘的字节, 作实时的镜像备份, 减少磁盘机出错的几率。磁盘备份一旦设定,由实现,无需人工干预。

  • 联机备份:提供 24*365 天的备份机制,用户可以基于调度来运行备 份,可以基于系统运行的热备份。

以上的备份策略,保证在不影响系统服务的条件下,在本地保留一份前一天的备份数据,包括数据仓库和报表服务器的数据。当地备份建议保留 30天。备份可以保存在磁带库、或光盘库。本地备份耗时目标是 2 小时。

恢复策略

常规的数据恢复流程设计如下:

  • 重启系统的所有服务器和存储

  • 如必要, 恢复系统

  • 从本地备份选取前一天的备份,或最近的备份

  • 恢复数据库

  • 恢复系统服务

(七)外部接口设计

从整个平台的业务需求来看,对于外部接口主要包括两个, 一个短信平台接口,另一个支持邮件系统接口。

  • 短信平台接口-根据运营商提供 WebService 接口,系统完成 3 大运营商短信接口的封装,并以统一的报文格式提交到运营商,由运用商最终 完成短信相关操作;并且以服务的形式供各业务子系统调用。

  • 邮件系统接口-根据提供的标准服务接口,以服务的形式封装,在系统内进行调用,完成收发邮件的相关功能。

第十一节、 系统部署方案

系统由于采用 J2EE 技术,具备了跨平台运行能力和极强的扩展能力。系统在不进行任何编码的情况下,可以在线进行容量扩展,利用更多的设备,为移动业务发展提供更高的保证。

硬件设备扩容上,服务器可以通过在线/离线增加设备的方式迚行扩容和优化。集群扩展时,仅需要根据处理能力添加新的主机迚集群即可。

系统采用分层架构开发和设计, 将界面、控制逻辑、业务逻辑和模型分离,实现系统内部松耦合,以灵活、快速地响应业务变化对系统的需求
系统拓扑结构

系统拓扑结构

整个系统包括以下三个部分,描述如下:

用户部分:工作人员通过手机客户端软件使用系统,登录的网络方式 可采用 VPN/APN 专网接入。内部人员通过局域网接入,使用 Web 浏览器访问后台管理系统。

应用部分:主要包括系统的软硬件设备,提供系统整体功能。

数据部分:主要包括数据存储的软硬件设备,提供数据存储及安全保障。

具体系统部署

系统基于 Nginx 的 Tomcat 负载均衡以及集群。

在这里插入图片描述

项目在体系结构、软件产品、数据共享交换等方面,贯彻标准和开放的原则,保证系统具备良好的互连性、扩充性,使得最广泛的软件可以被 采用;系统采用通用的平台产品技术和开放的体系结构,使具有较好的互 操作性、可移植性、档次皆宜性和易获得性,使得最广泛的社会人才可以 加入新系统的开发、管理、培训、使用和维护,最广泛的 Internet 新技术可以最先采用,同时拥有最短的开发周期;系统要能够支持多种服务器平台、多种网络传输协议,同时又能适应新技术的发展。

附件为全部文章,敬请下载。 ↑

猜你喜欢

转载自blog.csdn.net/Roinli/article/details/132826987