综合信息平台整体方案.doc

《综合信息平台整体方案.doc》由会员分享，可在线阅读，更多相关《综合信息平台整体方案.doc（34页珍藏版）》请在麦多课文档分享上搜索。

1、第一章 系统背景、范围及目标 1.1. 系统背景 为全面掌握 信息服务工作情况，通过 从相关部门获取的调研数据发现 ， 我 市信息化建设虽然取得了很大成效，但信息化发展不平衡，面向城市居民、涉农部门和基层农民的信息服务体系不够完善，基础设施建设资金投入不足，涉及百姓生产生活的信息资源缺乏有效整合，各级管理与服务部门信息化意识不强的矛盾依然突 出；为了提高政府对公共信息服务质量的管理力度和水平，决定建立 公共信息综合服务平台，整合各类实用型服务信息资源，利用方便、快捷的信息化传送手段，向社会各行各业、大众群体提供信息服务，树立政府便民服务形 象，促进本地信息化的发展，达到方便城市居民衣食住行、农

2、民增产增收的目的。 1.2. 系统范围 系统信息展示平台提供涉农 信息 （种养殖、农产品加工、市场行情、农用物资供求、农村医疗、灾害预警等）展示功能； 系统信息展示平台提供新闻、惠农政策、新农村建设、涉农企业、专家咨询等信息展示 功能； 系统信息展示平台提供城市民生信息（衣食住行、水、电、煤等）查询、展示功能； 系统应用平台为农户、涉农企业、涉农专家等提供信息的发布功能； 系统应用平台提供农户、涉农企业、涉农专家、城市市民等之间的交流互动功能；交流的方式有手机、农村信 息机、网站门户论坛、网站视频下载等； 系统平台为同构或异构的数据采集、处理、转换提供统一的适配协议或接口； 系统平台为同构或异

3、构的数据提供多样化的采集、处理、转换方式；包括：手工录入、批量导入、数据接口访问、专用数据通道访问等； 系统平台为建立起涉农信息资源库、 农业信息专家知识库 、城市民生信息资源库提供支持； 系统平台提供 移动无线应用业务 （包括短信、彩信、远程广播等）支持。 1.3. 系统设计目标 系统功能完备，满足农户、涉农企业、涉农专家、政府、城市居民等用户的不同需求； 系统基础架构设计具有技术通用性、先进性；系 统运行安全、稳定、健壮；系统功能扩展方便； 系统使用简单、方便、快捷； 系统具有多样和便利的 数据 备份 、数据恢复功能； 系统具有多种数据 接口，支持不同 格式 的数据导入、 导出 、转换等操

4、作； 系统具有 /预设丰富的 应用 接口，易于和其他既存或新系统互连 互通。 1.4. 实施效果 通过本系统的实 施，能够建立起覆盖 各县乡村的统一服务体系，并建立起城市便民服务的系统框架，把主要 涉农 企业、乡镇、各村农户统一纳入本系统中。通过农户， 涉农 企业、 涉农 专家等相关人员的互动，利用行之有效的管理方案和手段，树立信息化服务新形象，推动农业、农村经济的 快速发展。 1对于农户： 农户可以通过网站，手机，电话等多种渠道，获取或接收 种植、养殖、农产品加工、市场行情、农用物资供求等信息内容，提高生产经营水平，拓宽市场渠道，实现增产增收。 2对于企业： 企业发布的采购信息和销售信息可以

5、快速准确地传递到农户手中，有利企业快速采购所需物品，而农户也可以及时无误地向企业销售农产品，增加经济效益。 3对于农业信息专家： 农业信息专家可以利用自己专长的优势，为本地农户提供技术服务和咨询指导，并获得适当的经济回报，利已利农。 4对于城市居民： 城市居民可以及时获取与自 己衣食住行相关、维持生产生活所必需的各类信息、提醒服务等，不用再为缴费等问题而烦恼，实用、方便、快捷。 5对于社会和政府： 提高社会公众的消费观念，提升农村经济水平；更新了农户对社会信息认识 不足 的传统观念； 既 增加了农户的收益， 又 使社会的消费整体水平得以提高； 从而 有利于政府在社会公众以及农户心中树立良好 服

6、务 形象。 第二章 业务流程 分析和网络拓扑 2.1. 系统整体分析 根据用户的业务需求，我们对系统需求作了整体的分析，具体的分析如下图： 图 2.1 系统整体分析图 本系统从整体来说，可以分为以下几个大的结构 层次，分别为用户层，展示层，应用层，数据服务层，消息中间件服务端程序接口，消息中间件客户端接口，信息服务单位共七个应用层，系统整合 PC，电话，手机多种用户终端，提供多种灵活的用户访问机制和互动手段，整合多部分相关信息，同时结合多种应用系统，打造全方面的综合信息服务平台，为用户提供全面的信息服务，打造一流信息服务平台。 2.2. 业务流程分析 2.2.1 系统信息展示平台 综合信息服务

7、平台， 首先以应用为主，提供多种应用方案，同时，也提供了信息展示平台，做为对外展 示的窗口，系统提供了分类的信息展示，包括农业科技，农业政策，惠民信息，农业供求，农资产品价格，农产品销售，劳务信息，城市便民服务等，为用户提供公共信息服务，同时对外展示本地新形象。 综合信息服务信息展示平台 农业科技 农业政策 惠农信息 农业供求 农资价格 农产品销售 劳务信息 便民服务 2.2.2 系统信息应用平台 系统应用是综合信息服务平台的重点，本系统中，结合本地实际情况，量身定制了多种应用系统工程，全面服务于综合信息服务平台，包括网站门户，信息发布平台（ CMS），用户管理（ UMS），综合数据采集平台，

8、农业知识库平台，专家系统平台，系统综合互动平台， 远程智能广播平台，城市便民服务平台，无线应用平台等，为系统提供多方面的应用支持。 2.2.3 移动无线接口 本系统中，通过 Mas 连接到行业网关中心，获得基本的短信， Push， Wap，彩信无线通信能力，综合信息服务平台提供各种数据基本信息，如农业文字信息，农业科教图片等，综合信息服务平台通过专用 Mas 接口规范与 Mas 系统进行通信并传递数据，把相关数据发送到用户移动终端上。 Mas涉 农 Mas城市 综合信息服务平台 系统管理安全管理权限管理 移动终端用户 无线网络 行业网关 中心 网 站 门 户 信息发布平台 农业知识库平台 系统

9、 信息 应用 平台 专家系统平台 系统互动平台 远程智能广播 城市便民平台 无线应用平台 2.2.4 综合信息服务接口 2.3. 网络拓扑图 无线通信 服务接口 消息中间件接口 信息服务接口 A B MAS规范件接口 D 数据采集服务接口 C 第三章 系统总体设计 3.1. 功能性设计 3.1.1 系统功能点分析 本系统通过整合各种信息资源，建立起以门户网站为展示层，以 internet、手机、农村信息机为数据传输交互通道，以涉农信息资源库， 农业信息专家知识库 、城市民生信息资源库 等基础数据库为数据服务层，以农业，粮食，林业，社保，医疗卫生等涉农服务单位为数据接入层的跨部门、跨行业综合信息

10、服务系统。利用方便、快捷的有线、无线信息化传送手段，向农户、涉农企业、城市居民等提供多样化的信息服务，树立起政府便民服务形象，提高本地信息化的建设与发展水平，促进农民 增产增收，方便城市居民衣食住行等。 通过本系统，将分散在各个部门和企业的信息有效收集，整理起来，并以实用，灵活的方式予以展示，从而消除信息孤岛，推进社会的信息化，展示出政府对农户、涉农企业、城市居民的支持与帮助，从而做到信息化服务为民，获益为民，打造出“数字城市和便民政府”新形象。 通过 本系统 ， 能够 对不同的用户群体 提供不同的服务，满足各个用户群体信息化的需要 。对城市居民：系统平台 设计 了 众多便民服务的接口，方便相

11、应的便民信息服务功能的扩展，如提供城市水，电，气等民生信息查询和服务等 ；对社会和政府：系统平台的使 用 提高 了 社会公众的消费 及服务 观念，提升 了城市整体水平和农村经济实力；更新了 农户 、涉农企业、城市居民等 对社会信息认识 的传统观念；增加了涉农企业及 农户 等社会成员 的 整体 收益 ；对涉农企业： 在系统 平台中，企业可以自行发布供求信息，信息发布 后，系统自动的把企业供求内容 推送 给农户，以供农户进行筛选参考 ；对农户：系统平台为 农户提供 多样化的 信息服务， 可以满足不同生产领域的农业信息 需求； 系统平台还为本地农户提供适合本地特点的个性化服务，比如 建立起农户和本地

12、农业信息专家的沟通渠道 等 ，帮助农户解决在生产生活中遇到的疑难问题； 使农户 和涉农企业都能从农业信息化中受益。 3.1.2 系统功能点列表 3.1.2.1 网站门户 包括以下功能模块： 1）新闻栏目； 2） 农村信息化推进信息展示栏； 3）国家试点村建设进展信息展示栏； 4）政策信息展示栏； 5）专家咨询栏； 6）信息发布，支持信息的分类功能，信息包括： 最新的惠农信息 专家知识库信息 涉农供求信息 灾害预警信息 便民信息（如水电气等） 7）交流互动 平台的管理功能 收集和管理专家资源 建立企业，农户及农业专家三方交流平台 交流信息上传互动功能，上传方式有： SMS 短信 热线提问 网上提

13、问 交流信息处理功能 信 息分类汇总，存入网站数据库中 通过 SMS/GPRS 把信息群发给相关专家及农户 交流信息反馈 专家可以根据不同分类的问题进行相对应的回答 通过 SMS/GPRS 第一时间把结果发给企业及农户 建立专家评价系统，用户对专家回答进行评价，评价结果定期反馈。 8）专家、涉农企业评价功能 专家评价规则策略设置 用户反馈信息主导 (满意率 ) 工作量规则 (点击率等 ) 专家级别和专家费用的关联设置 灵活的结算标准和激励功能 评价系统同样适用于涉农资源、城市公共信息资源提供 9）运营报表 实时 /定期管理报表 点击率 专家资 源一览表 用户情况表 运营状况表 10）用户管理功

14、能 管理功能 用户注册 用户维护 权限设置 资质审核 用户分类功能，用户类别有： 企业 农户 农业专家 城市居民 用户论坛功能，论坛内容包括： 农户与农户交流 农户与专家交流 农户与企业交流 企业与专家交流 行业之间交流 城市居民之间的交流 11）专家讲座频道播放功能 流媒体播放设置 频道设置 专家讲座 收看通知，设立专门的讲座播放频道，发送信息给相关的用户 收看讲座形式多样化 12）专家热线 专家分类 农业信息分类 服务管理 专家热线与农业信息机结合 13）语音交流频道 专家语音信息发布 远程语音教育在线 14）移动无线结合 短信通讯能力要求 系统 具有短信数据处理能力，实现标准的短信协议并

15、可以实现超长短信的处理能力，满足特殊情况下的超长短信应用。 手机 门户网站 在当前项目的基础上，系统 具有对应的 手机门户网站，方便用户通过手机查阅相关信息内容。 具有 主动推送 功能，可以通过 Push 短信把相关文件或网址 Push 到用户手机上。 多媒体信息 处理能力要求 系统 具有 多媒体信息 处理能力，并能够根据不同的用户终端类型，提供符合用户终端要求的多媒体 信息 数据。 15） 数据分析 能力 系统 具有强大的数据分析能力，能够根据网站运行参数，对网站的运行状况和用户使用情况进行各种分析、处理、统计，为网站管理者和政府决策部门提供表格或图形化统计数据。 3.1.2.2 信息发布

16、按接受群体分类，应包括以下方式： 门户网站发布，支持通过电脑终端以互联网方式访问信息； 支持基于手机的信息发布方式，提供包括手机短信、彩信、手机上网等多种接口，满足不同信息源对信息传递渠道的要求。 通过 手机、农村信息机等移动无线 技术手段建立无使用障碍信息传递渠道，解决 了 农村中老年等无法使用 internet 等 信息传递媒介获取信 息 （ 如 远程 疾病防治、 自然灾害 应急调度、 惠农 政策宣传等 信息）的 问题。 通过无线智能远程广播系统等方式对外发布信息。 按信息获取形式分类，应包括以下方式： 系统 平台主动向外推送； 信息需求者根据自身需要进行定向查询、个性化信息定制等； 3.

17、1.2.3 数据信息采集 与处理 3.1.2.3.1 数据信息 的 采集方式 系统 支持不同来源数据的采集，包括手工录入、批量导入、数据接口访问、专用数据通道访问等方式。 手工录入方式： 系统 提供手工录入数据的方式，这样在没有电子资料的情况下，数据可以直接通过系统手工录入； 批量导入方式： 系统 提供批量导入数 据的方式，通过设计固定格式的标准文档，可以把整理好的数据 /或已有的现成数据批量导入； 数据接口访问： 系统通过支持多样化的数据接口，支持多样的协议，来满足 在一些安全性要求比较高，数据不允许直接访问或不允许异地保存（如涉及到个人隐私数据）的情况下 统一读取和存储数据的需要； 便携式

18、终端的信息采集方式 结合便携式终端携带方便、用户普及程度高的特点，可以运用无线便携式终端实时把相关农业信息、城市便民信息等上传到数据采集服务器上，从而不受时间、地点等因素的影响。 专用数据通道访问方式： 系统支持通过专用的数据通道读取 特定数据（如： 涉及政府安全信息的数据等），这种数据一般在专用的内网内，不允许 外部 用户的直接访问，并且数据不允许异地保存或者异地保存无意义。这种情况下，就 需要采用专用数据接口加专用数据通道 技术 才能 采集到数据 。 3.1.2.3.2 数据 信息 的 收集、整理 充分考虑农户现有使用习惯和设备基础，系统运用无线技术手段，提供切实可行的农户需求调查、分析、

19、整理功能的整体 解决方案。通过该方案，可以 实现对农户信息需求的准确分析、归类，这是整套系统运作的基础， 该功能模块具备以下特征： 低成本，摆脱传统人力调查模式，具备良好的经济性； 高效率，支持短 时间内对大规模群体的需求调查； 符合农户使用特点，具备良好的可操作性； 支持定时、不定时，特定人群、普遍人群，一次调查和分阶段调查等灵活形式的需求调查； 3.1.2.4 后台管理 系统具有功能完备、界面简洁友好、 操作方便的后台管理系统 （即系统维护接口） ， 后台 统一实现对 用户权限管理、基础 数据 处理 、 系统 功能模块、门户网站等各类子系统和模块的变更、扩展、管理、 维护，提高系统的工作

20、效率和易用性。 3.1.2.5 城市便民服务 系统为多种类的城市便民信息服务提供支持，并预留多个数据获取、转换接口，建立起统一的便民服务体系。同时提供便民信息的可定制 提醒功能。 例如，在系统初期，系统设计好提供居民用水信息服务（如水、电、燃气等）的接口，通过与供水公司合作，可以为用户提供用水查询；通过与电业部门合作，可以为居民提供电费信息查询，通过与燃气公司合作，可以为居民提供燃气信息查询； 另一方面，系统应用中也可以与一些大型的服务型商业部门合作，如大型商场，公交公司，房产公司等，这样，可以构造起满足各行各业，服务于居民衣食住行的综合信息服务平台，极大的方便城市居民生活。 3.1.2.6

21、远程智能广播系统 本系统中提供了对远程无线智能广播应用系统的支持，通过农村信息机与本系统的结合 ，实现远程无线智能广播，这样，把现代无线通信技术与传统广播系统相结合，发挥各自特点，实现信息的多渠道、实时、便捷传播。 远程无线语音信息广播功能； 远程无线录音信息广播功能； 远程无线科普信息广播功能； 远程无线通知信息广播功能； 远程无线教育信息广播功能； 3.1.2.7 无线通讯功能 本系统根据综合信息服务平台的特点，结合本地特色，充分应用移动通信技术，通过短信， Push， WAP，彩信等多种信息交互方式，将系统平台直接延伸到用户终端，实现有效信息可以随时随地、按需直接传递到用户手机上，进一步

22、增加系统功能，提高系统服务的 能力。 具体来说，可以分为以下几个方面： 围绕农业知识库方面： 1. 通过现有的知识库系统主动、及时把农业科技、病虫害防治、农业生产指导信息等下发到农户手机上； 2. 农户可以选择性的订阅相关类别的农业信息。 农业信息专家方面： 1. 农户可以通过手机短信方式把农业生产中遇到的问题和情况反馈给相关专家； 2. 农户可以通过手机彩信方式把相关病虫害信息发给农业信息专家并请求予以指导； 3. 农户可以通过专家热线与农业专家进行直接互动沟通。 农业供求方面： 1. 本地特产，种植，季节性产品等最新销售价格信息直接发送到农户手机上； 2. 农业生产相关产 品价格直接发送到

23、用户手机上； 3. 企业对农业生产资料的收购信息和收购价格直接发送到用户手机上； 4. 农闲时务工信息及时、直接发送到用户手机上。 城市便民服务 1. 日常生活消费用品，如水，电相关信息查询； 2. 车辆违章信息查询，驾照年审相关信息查询； WAP 网站 1. 用户可以通过 GPRS 登陆 WAP 网站浏览相关信息； 2. 各种农业信息可以通过 WAP 网站浏览，查询； 3. 各种便民服务信息可以通过 WAP 网站浏览，查询； 远程无线智能广播方面 1. 通过远程无线智能广播系统对农户进行信息传播、技术指导等； 3.2 非功能性设计 3.2.1 安全性 设计 系统安全的重要 性 是不言而喻的。

24、对于这样使用者众多、覆盖面广泛的 综合信息服务平台 系统来说，必将面临各种各样、错综复杂的 破坏和入侵。其中有的是无意的，有的是故意的。不管哪一种， 系统的设计，必须在安全性方面确保有足够的强度来防范和抵御。 对应用程序及其数据提供安全的能力称为安全性。应用程序的安全性受很多设计选择影响，如通信协议和用户身份验证方法的选择。大多数安全漏洞都不在与安全性有关的代码中。而是在与安全性无关的代码中，在编写这些代码时未注意到安全性。 3.2.1.1 安全性的概念 安全性是有关控制对各种资源（如应用程序组件、数据和硬件）的访 问的问题。以下是大多数安全措施所基于的四个概念： 身份验证 授权 数据保护 审

25、核 3.2.1.1.1 身份验证 身份验证是确认身份的过程，它是安全控制的一层。在应用程序授予对某资源的访问权限以前，它必须确认请求者的身份。请求者通过提供某些形式的凭据来确立一个身份，该身份只有请求者和身份验证主机知道。在某些情况下，请求者可能希望验证身份验证主机的身份，这称作互相进行身份验证。 3.2.1.1.2 授权 授权是验证经过身份验证的一方是否具有访问特定资源权限的过程，它是身份验证之后的安全控制层。并不是只因为身份验证主机已确认请求者的身份，就一 定表示经过身份验证的请求者具有访问特定资源的正确权限。 3.2.1.1.3 数据保护 数据保护是提供数据保密性、完整性和非拒绝性的过程

26、。数据不仅在传输时需要保护，在存储时也需要保护。不管数据形式如何，一旦数据进入不安全的通信信道便容易受到攻击。 对数据加密可提供数据保密性。数据加密同时使用加密算法和加密密钥来呈现数据，这些数据对于既没有解密数据的正确算法又没有密钥的人无意义。加密密钥是算法中使用的附加变量。加密密钥包含受密钥包含的位数限制的数值。尽管 40 位的密钥包含 240 或 1,099,511,627,776 个可能的 密钥值，但通常情况下 PC 可以在大约一周内彻底搜索完毕所有可能的密钥值。但是，如果加密密钥包含 128 位，强力攻击将需要尝试高达 2128 或 3.4 x 1038 个值。每增加一位都会增加一倍的

27、可能值的个数。加密密钥允许多方使用一个公共算法而不会危及用该算法加密的数据。 由于加密密钥决定了加密的强度，所以所有加密算法都易受到强力攻击。强力攻击是有计划地尝试使用每个可能的密钥解密数据。例如，如果用于加密数据的加密密钥只有四位，那么强力攻击将只需要最多尝试 16 个加密密钥值便能够危及您的数据。 数据完整 性通过使用哈希算法、数字签名和消息身份验证代码来实现。 为确保数据的完整性，可以伴随数据发送数据的哈希值。然后，接收方可以将根据收到的数据所计算的哈希值与随数据所收到的哈希值进行比较。如果二者吻合，那么收到的数据一定与创建收到的哈希值所基于的数据相同。哈希值是长度固定的数字和字符的字符

28、串。它使用哈希算法计算得到，哈希算法有消息摘要 5 (MD5) 或安全哈希算法 (SHA-1) 等。哈希计算是单向操作，不能反转以重新创建原始数据。 数字签名通过使用私钥对计算得到的哈希值加密将哈希再发展了一步。该额外步骤可以防止攻击者截获数据及其伴随的哈希值，修改数据，然后只需重新计算已修改数据的新哈希值。由于数字签名是加密的哈希值，所以攻击者需要访问用于创建原始数字签名的原始私钥。在接收端，可以使用关联的公钥验证数字签名。数字签名可用于强制认可，可在以后用于证明数据的起源、内容和时间戳。 消息身份验证代码 (MAC) 由 SSL/TLS 等技术使用，以验证传输中数据未被更改。但是，由于 M

29、AC 使用公钥进行加密和验证，所以它们不能用于强制认可。 3.2.1.1.4 审核 审核是记录和监视系统中发生并与安全性有关的事件的过程。审核为安全辩证提供主 要来源。 3.2.1.2 当前系统设计 当前系统采用如下方式来保证系统应用的安全性、数据的安全性： 3.2.1.2.1 系统应用安全性保证措施 1） 身份认证 系统根据业务的需要，将使用系统的不同人员对应设计成为系统不同的用户，对应的用户具有不同的用户标识和密码分配；从而保证非法的用户对本系统的访问被有效隔离起来； 2） 功能授权 在本系统的设计中，建立系统角色的定义，将不同的系统功能授予不同的角色之中，业务要求不同的用户授予不同的用户

30、角色，从而既能保证系统功能对用户开放，又能把不同业务需求的用户对系统的访问区别开来。 3.2.1.2.2 数据安全性保证措施 1） 防止 未被授权的数据被读取 防止未被授权的数据读取，即没有权限知道的信息，是不可以被获取的。这里就需要使用信息加密技术。为了在加密速度和加密强度中寻找平衡， 在目标系统设计中，我们通常将系统中的信息划分成 3 个密级： 秘密 机密 绝密 不用的密级适用不用的加密方案，这样对于数量比较多的“秘密级”信息，我们可以采用非常快速的，强大相对较弱的加密方案；而对于安全性要求最高的“绝密级”信息，我们采用强度大，但相对速度稍慢的加密方案。 区别对待而不是一视同仁的做法，也优

31、化了系统资源的利用，提高了处理器的工作效率。 为了防止未被授权的数据访问，系统将提供庞大复杂的权限管理子系统来管理所有用户的权限。同时，权限管理子系统提供的良好界面，却让使用者丝毫感觉不到底层的复杂处理逻辑，更多感觉到的是简洁易用的操作界面。 为了防止未被授权的数据访问，系统还将采用一整套安全强度高、实践效果好的安全方案，以防止系统外的入侵和攻击行为。因为基于互联网应用的系统，必然无法和公众网络 (Internet)物理隔离，这样，系统必然面临大量来自系统外的嗅探和攻击。作为应对技术，比如 IP 地址过滤、入侵侦测、帐户锁定、图形校验码登录等安全技术，将确 保系统免收外来的入侵，让用户安然使用

32、，让领导高枕无忧。 另外，我们还将在系统的日常维护等实施环节和运行环节上，提供强有力的技术支持和咨询，帮助客户解决突发事件。 2） 防止数据的篡改和伪造 任何一个客户都不希望自己的机密数据（如工资信息）被恶意修改，或者发生伪造这样的事件。就像目前充斥市面上的大量廉价 OA 系统一样，为了成本的需要，根本不考虑这些安全性问题。一旦遇到对计算机技术掌握比较好的使用者，就会被发现许许多多的系统安全漏洞。甚至被利用这些漏洞，从而造成不必要的损失。 漏洞其中之一，就是数据篡改或 者伪造的问题。 作为应对，我们的系统设计，将采用数字签名技术，确保系统中的信息是作成者真实的意思表达。 但区别于目前通常的数字

33、签名技术，我们不采用非对称加密，而是采用对称加密技术。一方面提高了加密、解密的速度，另一方面安全强度毫无损失。 3） 防止灾害事故导致数据的丢失 我们的方案将采用集群技术，以实现数据的热备份。如果某台服务器发生故障，集群技术可以让该服务器上的全部工作，转移到其他服务器上。一方面，系统不会中顿，用户的使用没有丝毫影响；另一方面，数据不会遭受损失。 同时，我们将根据用户的实际情 况，建议最佳的系统备份策略，或者和客户一起设计最佳备份策略。 4） 重要数据的加密 由于用户重要数据在网络中传输或存储时存在数据丢失、篡改、非法访问等一系列的安全风险，本系统对用户的重要数据在网络传输或存储时，首先对数据进

34、行安全的加密，当用户需要数据提取时再进行对应的解密，从而保证数据的安全性。加密采用国际通用的对称加密技术。 3.2.1.2.3 系统操作审核措施 1) 日志记录 为了保证系统能够稳定、健壮运行，在系统出现非正常情况时能够及时分析原因，做出正确性判断并加以处理、响应； 系统 设计中加入系统日志的记录功能；系统日志主要是记录下系 统正常、非正常情况时的各种正常、非正常参数，异常表现时的解决措施等信息；以便系统出现同样问题时，系统管理员能够分析原因并及时对应解决。 当用户对系统中重要的功能进行 操作或重要的数据进行 操作时，为了保证应用操作错误或数据操作 错误后能及时 对应 和确认，系统将用户的 应

35、用操作和数据的操作 用 操作 日志的形式记录下来，以备 相关 人员发现问题后及时对应 处理 。 2) 日志审核 系统设计中加入日志审核功能，以被相关人员对系统日志的信息进行分析、统计处理。 3.2.2 界面和性能设计 界面和性能的设计是系统非功能性要求的重要内容，为了方便用户的使用，充分考虑到用户的习惯，界面和性能设计坚持“界面简洁、易操作；性能满足反应及时、无明显延迟”的原则。 3.2.2.1 界面设计 系统界面采用 GUI 设计，完全支持用户使用鼠标、键盘对系统进行各种操作；同时，考虑到不同用户的便捷性要求，系统支持主要操作的快捷键功能；对系统的信息输入、展示提供相对应的 Tooltip

36、提示，并支持用户的在线帮助功能； 系统界面设计运用成熟的人机交互理论和技术，设计的界面简单、大方，适合不同用户的操作习惯；界面元素布局合理，功能组织层次清晰。 3.2.2.2 性能设计 系统的性能设计按照“反应及时、无明显延迟”的原则， 采用 SQL Server 2005 数据库管理系统，能够满足海量农业信息的存储、海量专家信息的存储需要；并能够满足大量信息查询的性能要求；满足数据信息快速增长的需要； 系统采用软硬件相结合的设计方案，保证支持 1000 以上用户的并发访问要求；保证页面的响应显示时间不超过 2s。系统软件采用各种性能优化技术（比如数据库性能优化技术等）；硬件支持平台可以采用双

37、机热备份， RAID、负载均衡技术等来保证系统在大量用户并发访问情况下，系统能够平稳、健壮运行；用户的请求不出现无法响应、访问被拒绝或响应速度过慢的现象。 3.2.3 可扩展 性 设计 系统的可扩展设计使 系统模块可进行灵活定制，很容易与其他系统进行衔接 ， 进行系统升级或与其他系统连接变得简单方便，系统规模也可根据不同情况变化。 3.2.3.1 可扩展性的概念 可扩展性程序设计，最主要一点是代码复用，这在设计中考虑公用部分，以及各任务划分 时 ，任务的创建、执行和销毁 操作可以 这样来设计： (1) 任务在其需要的时候才创建。任务的创建通过 new 操作，动态创建具体的任务对象，然后传入线程

38、池，由线程池自动分配线程来执行此任务。 (2) 任务是否执行完毕由其自身来决定。一个未知任务什么时候执行完毕是不可能预测的， 必须任务本身来决定。这个策略通过， Task:run()的返回值来实现。当工作线程执行一次任务时，如果返回值为 true，表示任务执行完毕，就用 delete 操作销毁此任务；如果返回值为 false，表示任务需要执行的工作并未完成，继续执行此任务。 这样的策略，使得在设计新的任务处理流程的时候，不需要过多的关心任务的接口规范，只需要在新任务类的构造函数中初始化各种资源，在新任务类的析构函数中回收资源，在 run()方法中实现主要的处理逻辑，那么新的任务类即可在线程池中

39、执行。这样的话，代码的复用就会大大的提高了。 3.2.3.2 当 前系统设计 系统采用面向对象的设计方法，辅助以功能模块化划分、代码及接口的复用技术来保证系统具有良好的扩展性； 面向对象的方法是一套成熟的软件分析、设计、开发技术，它把系统中的不同用户、业务流程、业务实体等转化成系统特有的类和对象，并将各自不同的操作和数据以类的形式定义并封装起来，类和类之间的通讯采用接口进行，这样就保证了系统具有“高内聚、低耦合”的特性； 模块化的方法是一种传统的软件设计开发技术，它的特点是把 复杂系统 功能采用自顶向下的设计方法 化大为小，化繁为简 ；软件结构 层次清晰，可扩展性强；本系统应用模块 化的方法，

40、将系统功能划分成不同的模块，模块再划分成不同的功能点，不同的功能点对应 1 个或多个的操作画面；这样，在系统增删改功能的时候，不会造成系统大规模的改动，系统的可伸缩性也很强。 代码及接口的复用技术是指在快速化开发过程中，运用公司强大的资源积累优势，把共通的代码或接口直接或修正后用于当前系统中，使系统的建设从非零起点进行，节约了系统建设的成本。 3.2.4 可维护性设计 系统的可维护性是指系统的架构、设计、实现等能够满足或适应在系统未来业务需求变化时，导致的系统业务流程变更，业务功能的增加与修改等的需要。 本系统提 供系统可维护性功能界面，能够对系统的各种运行参数进行设置，维护简单、方便；为保证

41、门户网站的易于维护性，系统 通过在门户网站内部部署移动 终端网关 代理服务器方式为广大农户和城镇居民提供基于移动终端（包括短信、彩信、 WAP、手机客户端等）的信息化应用服务 。 本系统通过与无线运营商展开积极的合作，可以提供农业需求的调查信息，并提供调查的资料和统计结果数据，做到有的放矢。 3.2.5 可靠性 设计 软件可靠性是指应用程序能在多大程度上，在不发生失败的情况下，准确地提供在原始规范中定义的服务。除了应用程序在失败前运行多长时间外，可靠性 工程处理是指提供正确的结果和为了避免失败而处理错误检测和恢复。 3.2.5.1 可靠性的概念 可靠性定义为平均故障间隔时间 (MTBF)，即应

42、用程序在发生故障前运行的平均时间长度。 MTBF 的公式为： MTBF = 小时数 /失败次数 软件可靠性的一个重要概念是软件发生失败而软件仍可用并继续执行。 企业应用程序是硬件、操作系统服务、软件组件以及人员参与过程（通常有此一项）的集合，这些内容用于相互配合以提供预期的业务服务。整个应用程序的可靠性在很大程度上依赖于单个组件的可靠性。因为系统中的所有组件是相关的，一个组件中的失败会影 响其他组件的可靠性。 3.2.5.2 具体技术措施 我们通过以下技术措施来尽可能的提高系统的可靠性指标。 1) 遵守可靠性设计原则 系统设计和开发过程中，将遵守以下可靠性原则： 遵守操作系统应用程序设计指南。

43、 将可靠性要求写进规范中。 使用结构良好的基础结构。 将管理信息置入应用程序中。 使用冗余获得可靠性。 使用优质开发工具。 使用内置应用程序运行性能状况检查。 使用一致的错误处理。 2) 进行可靠性测试 在开发完成后，除了功能测试外，我们还将专门进行可靠性测试，包括： 使用组件压力测试 使用集中压力测试 使用随机破坏测 试 3.2.5.3 当前系统设计 系统采用软硬件相结合的设计方案，软件上才能“高内聚、低耦合”的设计方式减少系统与系统之间，模块与模块之间的关联性，使得系统的单点故障不至于对整个系统产生整体的影响，从而保证系统的可靠性；硬件上采用 RAID、双机热备、负载均衡技术，施行冗余、高

44、可用的配置，保证系统无单点故障，从而可以使网络主机和业务系统能够保证 7*24 小时连续运行，经机构测试，平均无故障时间（ MTBF）可达到 80000 小时以上。 3.2.6 可用性 设计 所有的应用程序都至少在某些时间是可用的，但是基于 Web 的应用程序和执行关键任务的 企业应用程序通常必须提供全天候服务。 “综合信息服务平台系统” 需要每周 7 天、每天 24 小时 地工作，具有较高的可用性。硬件和软件方面的进步已经大幅度提高了高可用性应用程序的质量。但是，可用性的实现 仍旧 不是 件 容易的事情， 我们在方案中将介绍我们解决此棘手问题的相关技术措施。 3.2.6.1 可用性的概念 现

45、在基于 Web 的应用程序通常都依赖于多个服务器、或许成百上千台客户端工作站、内部和外部网络通信、数据库服务、操作进程以及大量其他基础结构服务，所有这些都必须协调一致地工作。商业理想追求的是连续的信息流，中断将会导致公司在金钱 上的损失，在这种情况下，创建高可用性应用程序便成为重要的商业策略。 对于那些日益依赖于基于 Web 的分布式应用程序进行重要业务活动的公司而言，需要一系列可用性工程处理选项，从而以一种低耗高效的方式满足服务级别要求。实际上，并非所有应用程序都需要每周 7 天、每天 24 小时正常运行，而且具有即时响应能力。一些应用程序可以不用达到这个标准，而且不会有任何影响。其他应用程

46、序能够容忍意外停机，但可能要求改变恢复策略，而还有一些应用程序则必须使用待机复制策略来提供非常高的可用性，以保证在实际上感觉不到停机的情况下 进行即时、透明的恢复。 自分布式应用程序首次安装后，随着分布式应用程序的复杂性和访问量的增加，在原始设计、支持服务或维护和增强功能方面也越来越有可能暴露出一些缺陷。不幸的是，停机导致的问题和远期损失所播及的范围会大大超出本地计算环境。 约有 40% 的应用程序停机时间是由于测试不充分、更改管理以及缺少进行中的失败监视而发生的。另外 40% 的应用程序停机时间是由因缺乏严格的操作规程而导致的操作错误和备份 /还原错误造成的。近几年来硬件的可靠性有了很大的提

47、高，因此由于硬件问题导致的停机时间通常不到总停机时间的 10%。剩余的 10% 的停机时间是由于环境和其他各种问题造成的。 一般来讲，可用性是衡量应用程序多长时间可使用一次的方法。更具体地说，即可用性是一个百分比值，它是基于与计划的总可用运行时间相比时，应用程序实际可以多长时间处理一次服务请求而计算的。可用性的正规计算包括修复时间，因为正在修复中的应用程序无法使用。 可用性的计算使用下列几项度量值： 名称 缩写 计算 定义 失败之间的平均时间 MTBF 小时数 /失败次数 应用程序在失败前运行的平均时间长度。 平均恢复时间 MTTR 修复小时数 /失败次数 失败 后修复和还原服务所需的平均时间

48、长度 可用性公式如下所示： 可用性 = (MTBF / (MTBF + MTTR) * 100 描述可用性的一种常用的方法是使用“ 9”，如三个 9 表示 99.9% 可用性。但是，有时会误解用 9 度量的含义。需要进行算术运算才能知道三个 9（ 99.9% 可用性）表示一年大约有 8.5 小时的服务中断期。四个 9 (99.99%) 是更高一级的可用性，表示一年大约有 1 小时的服务中断期。五个 9 (99.999%) 表示每年仅有大约 5 分钟的中断期。 本方案所描述的目标 系统，将以 99.9% 的可用性 作为设计目标 。 3.2.6.2 具体技术措施 减少失败（从而增加 MTBF）而不

49、同时减少修复时间不会将可用性最大化。仅仅减少失败只是答案的一部分。假设应用程序只有几次失败但没有停机时间，这样的应用程序与无失败的应用程序具有相同的可用性百分比。最小化停机时间比最小化失败次数便宜得多。 因此，设计可用性必须在硬件或软件故障导致服务错误、事件错误或数据损坏之前，预测、检测和自动排除这些故障，从而使停机时间缩短到最小。解决方案的技术部分要求多个到应用程序服务和数据的通路。解决方案的操作部分在应用程序 的整个生命周期中，只使用经测试而且证实过的过程（不论自动的还是基于人员的过程）支持该应用程序。 虽然可用性工程处理主要是指减少非计划停机时间，但减少计划停机时间也很重要。这样的计划停机时间可包括维护更改、操作系统升级、备份或任何其他暂时将应用程序从服务中移除的活动。 3.2.6.2.1 避免使用较旧