您的当前位置:首页网站项目技术设计方案

网站项目技术设计方案

2020-08-18 来源:乌哈旅游
-----WORD格式--可编辑--专业资料-----

上海证券有限责任公司

网站项目

技术方案

(讨论稿)

作者 --完整版学习资料分享----

-----WORD格式--可编辑--专业资料----- 公布日期 批准人 文件名 版本 项目经理 所属团队 开发员 测试员

0.1 文档修改日志

序号 1

版本 0.1 创建

修改内容 修改日期 2009-05-27 修改人 1上海证券网站的总体建设目标

上海证券本次网站改版的总体目标为 (一)可扩展性

--完整版学习资料分享----

-----WORD格式--可编辑--专业资料-----

(二)可靠性 (三)易于维护管理 (四)易用性 (五)安全性 (六)高效性 (七)跨平台原则

--完整版学习资料分享----

-----WORD格式--可编辑--专业资料-----

2网站系统需求分析

2.1 系统建设需求

公司及公司产品宣传

面向互联网用户,向用户展现证券公司及其各种服务,特别是资料分析资讯等的基本信息。实现将普通社会公众培养为潜在投资者、将潜在投资者引导为证券公司股票投资者的宣传功能。

客户服务系统对来自互联网的客户提供服务功能

互联网客户服务系统必须整合证券公司主页和以上两项功能,在同一平台上对功能加以必要的完善,突出开放式投资和理财服务两项功能。

能够满足海量用户访问的系统负载要求

能够满足证券公司主动服务和客户自助服务的要求 增强的网站粘滞性

增强的网站SEO,通过搜索引擎主动为网站带来更多的流量。 能够满足现代网络安全性规范的要求

系统在运行后,网络日常维护重点便在于网站的安全性,我们通过我们的系统设计和日常维护规范等方面的工作,都可以保证网站安全性。

建立基于新型技术平台构建的网站门户系统(含后台分析管理系统),全面提升门户营运效能,变被动服务为主动服务。

基础构架要求支撑全站或指定页面的定制布局,可快速发布新页面。支持全站或指定页面的链接流量收集,全站或指定页面的客户行为收集。

后台系统配置灵活,具备一定的分析统计及客户行为的数据挖掘功能,为公司的客户分析系统做好数据收集准备。

建立以客户为中心的网站系统,和客服及相关系统整合,全面提升人机界面及客户体验。 对客户及相关系统作出更加有机的整合,进一步实现系统之间的联接和信息共享。包括:网站的交易、查询、论坛等全面实现单点登陆;网站和call-center邮件、短信、信息全面整合联动,杜绝信息孤岛(比如客户邮件投递失败,网站不知道,客户电话过客服中心而网站后台无体现)。

基于新的网站门户特定子系统的定制开发。

配合性的升级和建设一些适应新时期需求的子系统及特色功能,包括: a) 网上客户信息管理系统(含一定的挖掘功能)

--完整版学习资料分享----

-----WORD格式--可编辑--专业资料-----

b) 网站访问统计分析系统 c) 证券综合服务平台 d) 多媒体管理系统 e) 搜索引擎系统 f) 模拟炒股系统 g) 理财产品管理系统 h) 手机证劵 i) 客服支持系统 j) 经纪人互动系统 k) 积分商城系统 l) 企业资讯管理系统 m) 用户管理 n) 权限管埋 o) 系统监控 p) 日志统计 q) 统一内容发布管理 r) 问卷调查管理 s) 积分管理系统 t) 软件下载管理 u) 广告管理 v) WAP手机网站系统 w) 注册登录系统 x) 问卷调查系统 y) 全文检索系统 z) 内容管理系统 网页防篡改监控

根据证监会对网站安全性的要求,我们为系统提供了增强的网页防篡改监控功能,以便相应的证券公司内部管理人员能够在第一时间得到网页被篡改的通知,进而做出及时地处理。

--完整版学习资料分享----

-----WORD格式--可编辑--专业资料-----

3网站系统总体架构

本系统主要分成系统平台和应用软件两个部分,其中系统平台又由系统软硬件平台、网络通讯系统和开发平台三个部分组成。系统平台为应用软件提供系统运行环境、数据通讯环境及软件开发环境,应用软件提供业务的计算机实现,并提出对系统平台的要求。下面的章节将详细阐述网站软件系统结构设计和应用软件实现功能。

3.1 系统设计目标

逐步建设一套完整的、能切实满足目前贵公司业务发展需要的网上业务系统,为上证提供信息发布、咨询、互联网交易服务等功能,提供快速、准确、方便的服务。

3.1.1 业务方面

遵循全盘考虑、分阶段实施的原则。即:一期目标和二期目标统一考虑,保证第一阶段目标的顺利实施和如期完成,保证系统在将来可以平滑地进行功能增加和规模扩充。对于网上交易系统和其他系统的关系,一方面保持网上交易系统在使用上的相对独立、完整,同时考虑好与其他系统的连接,包括数据的提取和引用,资源的共享与复用。

3.1.2 技术与工程方面

高度安全、可靠。可靠性方面,保证系统数据不丢失,不出现数据的不一致,不论是操作失误还是环境因素;安全性方面,在不影响性能的同时,确保系统的内部和外部安全。

利用成熟的网络技术平台和经验,保证系统稳定性,及良好运行,考虑到用户操作上的便捷。为了保证进度、保证质量、合理利用成熟的开发平台和交易传输工具。

尽量遵循软件工程的规则。在人员、计划与进程管理、质量控制、及文档管理,使用现成的管理工具和规范。

3.2 逻辑体系设计

基于以上考虑采用多层逻辑结构来构建系统的软硬件平台和开发平台。结构如下图:

--完整版学习资料分享----

-----WORD格式--可编辑--专业资料-----

在此结构中,系统平台层主要搭建网站系统的软硬件平台,同时借助应用服务器、WEB服务器等相关软件并根据项目的需求,开发业务处理功能。投资人可通过浏览器发出请求,查询交易信息。

3.3 技术架构

系统架构

平台:APACHE+WEBLOGIC+ORACLE (SQLERVER)

集群方案:采用F5作为负载均衡控制器,根据业务量的需要,可以对其进行线性扩充,包证业务系统稳定运行。

应用部署方案:(谨以单节点举例)采用APACHE作为前端静态资源服务器,核心业部署在WebLogic中,后端采用ORACLE数据库,考虑到与顶点系统的沟通,可能会使用到sqlserver数据库。具体情况根据综合服务平台系统数据库特点为准。

节点间关系:由F5作为用户的入口控制器,保证访问压力根据策略可以均衡的分摊到各个WEB节点上,个WEB节点是并列并且独立的关系。根据业务量多少来分配应用层服务器。连接ORACLE数据库服务器。

开发框架

--完整版学习资料分享----

-----WORD格式--可编辑--专业资料-----

框架:struts2+spring2+hibernate

设计原则:基于MVC思想,采用分层的架构设计,保持代码结构的清晰准确,并可以进行扩展,方便未来模块功扩展。前台引入WEB2.0概念,以用户为根本,方便用户的使用,提升用户体验。使用了ajax技术使用户交互更友好。

特点:基于成熟的设计思想,使得整体框架具有极强扩展性,方便未来业务量或功能模块的增加。

开发工具

代码编辑工具:Eclipse/MyEclipse 调试平台:Tomcat/Weblogic

单元测试:采用JUNIT作为单元测试工具,将测试引入开发步骤中,已保证代码质量。 数据库平台:ORACLE

测试工具及方法

开发中:每一模块都做到进行单元测试,从最根本上保证代码质量。 通过测试工具进行压力测试和内存溢出检测 代码规范性整体检查。

通过人工和自动方式进行功能测试。

问题跟踪与文档管理

采用JIRA作为统一的问题跟中与管理工具。 采用OA或VSS系统作为文档管理模式。

3.3.1 系统特点

3.3.1.1

安全性

 系统支持用户及用户组的设置

 系统在登录时需输入密码,密码的位数不小于6位,区分大小写  系统支持供授权,即不同用户使用不同的功能  系统支持不同工作组甚至不同用户之间数据查看的限制

--完整版学习资料分享----

-----WORD格式--可编辑--专业资料-----

 系统支持前台手工及定时数据备份功能,数据恢复的功能

3.3.2.1 系统响应速度要求

 单路500以上并发支持  200万容量客户访问支持  网站并发性能

并发首页:2000个,平均响应时间<2秒 并发查询:500  网站容量:

支持用户数量:200万级别

支持同时在线人数:30000人同时在线  数据查询

一般性数据保存、修改、删除等操作的响应反馈时间最大不应超过5秒,一般控制在2秒内。Web应用程序最大不应超过8秒,一般控制在2秒内。

一般10万条数据的简单查询及统计不应超过10秒,百万条数据的查询及统计不应超过20秒。复杂综合性跨模块查询及统计不应超过1分钟

3.3.3.1 可用性

系统应具备高可用性,满足以下指标

 应用系统无故障运行时间>99.9%(以7×24小时计算)  因应用系统原因导致非正常当机次数<4次/年  因应用系统原因导致处理错误次数 < 1次/月

3.3.4.1 系统处理能力

 在我们推荐的硬件和软件配置达到的情况下的系统处理能力达到:2000用户并发访问  保证在网站登录高峰时系统能够正常运行(极端响应达到:4000用户并发访问 )  系统最大单表记录数至少支持500万条

 系统数据库应支持至少高达1T的数据容量

--完整版学习资料分享----

-----WORD格式--可编辑--专业资料-----

3.3.5.1 系统可扩展能力

 系统应适应组织的变更及扩展而不需要对程序做相应的修改

 系统应能适应应用不断的添加而不至于导致程序大量的修改或推翻重来

 随着用户数的增长及功能应用的增长系统能够保持足够的稳定性,维持正常的运行

3.4 网站软硬件部署 3.4.1 网站软硬件建议配置

网站WEB SERVER:8台 网站Application Server:4台

网站数据库服务器:1台(建议采用集群方式部署) 备份服务器:

前端采用F5作为负载均衡服务器

操作系统可采用Windows 2003 或 Redhat Linux AS4

以上的操作系统均为当前主流的操作系统,而且能够得到相对比较多的支持,且成本可控。 以上配置已经基本满足了当前上海证券网站访问量和功能的需求,但考虑到网络的应用越来越多,在网络负载提高,当前设备无法满足时可以适当增加web server及APP server。

对于数据库服务器,也应当考虑到系统备份安全。

性能指标

类别 指标 指标值 7*24小时无间断服务 8分钟 可支持在线用户数(N) 每秒事务数 最大响应时间 平均响应时间 >3000户 >2000 <=3s <2s 备注 连续系统服务时间 服务性能故障恢复时间 指标 网站整体 性能指标 静态页面响应时间 --完整版学习资料分享----

-----WORD格式--可编辑--专业资料----- 每秒事务数 动态页面响应时间 最大响应时间 平均响应时间 WEB页面行情请求响应时间 每秒事务数 刷新响应时间 行情延时时间 每秒事务数 交易响应时间 最大响应时间 平均响应时间 >500 <5s <3s >500 <3s <5s >80 <5s <3s 应用服务器前端有复杂计算除外 3.5 与其他系统的集成

作为一个开放的、标准的、适应性强的网站技术平台,具有很强的扩展能力,对现有的数据接口系统、综合服务平台接口、基金TA系统接口、第三方资讯平台接口和网上营业厅接口系统实现完美对接,并且为后续系统,预留接口进行连接, 以满足今后业务发展的扩展要求。

各系统间可通过多种方式与各系统之间进行通信,如:数据库、webservice、等。

3.6 网站备份设施以及措施

证券公司网站应有必要的备份设备和相应的措施,在一些极端情况下系统能够迅速切换至备份系统,为上证提供基本服务,减少事故的发生。

--完整版学习资料分享----

-----WORD格式--可编辑--专业资料-----

4应用系统测试

4.1 测试计划

详细设计文档被认证后,制定《测试计划》,测试计划需由质量保证组制定,项目经理、测试负责人共同签字认可。

测试计划将作为测试工作的依据。

测试计划的撰写工作应在系统提交测试前完成。

测试计划包括代码审查、规范审查、单元测试、组装测试、系统测试、回归测试。

4.2 测试设计与测试案例

测试计划通过认可后,测试人员开始编写测试设计及测试案例文档。

根据产品测试计划制定具体测试设计及测试案例,测试设计及测试案例文档需经设计负责人及测试负责人共同签字认可。

测试设计及测试案例文档的撰写应在系统提交测试前完成。

测试的设计方法包括边界值测试法、等价类划分、功能覆盖、分支覆盖。

4.3 系统测试实施

按照《测试计划》、《测试设计及案例》的要求对系统进行测试。

测试人员应该记录测试事件,记录测试日志,并通过测试日志及时与开发人员进行交流,测试日志可作为测试工作进行或停止的依据。

测试过程中如需进行程序修改,则必须暂停或停止测试工作。

4.4 测试工作暂停、停止、启动的条件

暂停条件:测试工作是否暂停可由测试员与开发人员协商决定,暂停时间原则上不能超过两个工作日。

停止条件:测试工作如无法按照测试计划正常进行下去,则必须停止,要停止的测试工作必须由测试员出具《阶段测试总结报告》并由开发经理认可,在阶段测试报告中必须注明再启动时间,如无法估计时间则必须注明再启动条件。

--完整版学习资料分享----

-----WORD格式--可编辑--专业资料-----

4.5 系统测试报告

测试报告分为《阶段测试总结报告》和《测试总结报告》两种。其中《阶段测试总结报告》主要作为程序修改的依据;《测试总结报告》主要作为系统验收的依据。

测试工作停止时测试人员必须撰写《阶段测试总结报告》,提交开发人员进行程序修改,如修改后无设计变动或变动不大(测试案例仍然可用),可以在产品测试环节内部循环,但必须保留每一次的《阶段测试总结报告》。

如《阶段测试总结报告》提交后设计变动较大,则应视具体情况决定下一步的测试工作。对于测试案例不可用的情况需要重新制定测试设计和测试案例;对于设计变动影响了测试计划的可用性的需重新根据详细设计文档制定测试计划。

4.6 应用系统初始化

系统配置计划

根据需求分析,对照原形系统制定系统客户化的配置计划。 初始化数据的准备和确认

实施工程师根据配置计划进行初始化数据的准备,填写系统初始化数据清单和初始化实施工作表,会同双方技术负责人进行确认。

系统配置

实施工程师根据系统初始化数据清单和初始化实施工作表进行系统初始化设置。向实施经理及客户提交系统初始化工作报告。

4.7 试运行

试运行是项目各部分组装,项目最后接受真正测试阶段。试运行阶段工作参照上海XXXX公司《项目/产品试运行规范》进行。产生的试运行工作日志是项目最后开始验收的前提之一。

试运行计划

在系统试运行之前,由双方共同制定《系统试运行计划》。计划中应明确试运行的范围、时间、双方技术负责人等内容。

试运行

在系统试运行期间,双方共同维护试运行日志,记录在此期间发生的问题及解决情况。 系统试运行过程中,上海XXXX公司提供系统性能调整的服务,提高系统的运行效率。 试运行结束

试运行结束后应提交试运行总结报告,汇总试运行日志中的问题。

--完整版学习资料分享----

-----WORD格式--可编辑--专业资料-----

试运行成功标志

系统试运行三个月内,系统运行正常。

--完整版学习资料分享----

-----WORD格式--可编辑--专业资料-----

5 验收标准

应用系统的验收遵循上海XXXX公司的《应用系统验收规范》进行。

5.1验收组织

系统的验收人员由双方共同派出,另外聘请本行业的应用专家,组成验收小组,执行验收的各项任务。

5.2验收方式

系统的验收执行方为上海证券公司相关机构,验收工作的组织由甲方负责,乙方应积极配合和支持,验收报告由甲方起草并签署。

5.3验收步骤

项目的验收工作步骤将通过双方协商确定,基本依据以下顺序进行。 确定验收计划

验收小组确定本系统验收的验收工作进度计划,以及必要的准备工作。 审查和确定系统验收标志

验收小组审查系统验收标准,确定最终的系统验收标准。 确定验收环境

根据系统验收要求,建立验收环境。 系统验收环境为系统的最终运行环境。 项目审查

验收小组根据本系统的系统验收标准,参考系统需求、工作说明书和合同,对项目最终提交的各项产品和文档进行审查。

系统演示

验收小组通过系统演示方式,对本系统所提交的运行系统进行验证,以确保交付系统符合系统需求。

验收测试

对于交付的应用系统,验收小组抽取系统测试案例或另外编制系统测试案例,对系统的功能和性能进行测试,确认本系统的功能和性能符合系统需求。

项目验收会

--完整版学习资料分享----

-----WORD格式--可编辑--专业资料-----

验收小组召开项目验收会,对本系统的验收结果进行评议。 验收报告

验收小组提交验收测试报告。

如系统通过验收,则标志本系统实施工作全部完成,系统进入维护阶段。

如系统未通过验收,则验收小组必须书面说明原因,上海XXXX公司与上证一起对其进行分析,如是我方责任,我方将对本系统进行修改,如是上证原因,将视其为项目变化,按项目变化管理说明执行。

--完整版学习资料分享----

因篇幅问题不能全部显示,请点此查看更多更全内容