《食品农产品认证信息系统V5升级改造项目.docx》由会员分享，可在线阅读，更多相关《食品农产品认证信息系统V5升级改造项目.docx（9页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、附件：食品农产品认证信息系统V2.5升级改造项目第6章资源配置评估工作分解里程碑开始时间结束时响有机码上传性能改造需求确认2016年12月1日2016 年 12 月 1a设计2016年12月2日开发测试+数据导入上线试运行2016年12月31日有机认证企业用户管理需求确认2017年1月4日2017年1月4日设计2017年1月5日开发测试+数据导入上线试运行2017年3月1日数据接口扩展需求确认2017年1月4日2017年1月4日设计2017年1月5日开发测试+数据导入上线试运行2017年3月1日认证活动风险预警需求确认2017年1月4日2017年1月4日设计2017年1月5日开发测试+数据导入
2、上线试运行2017年5月1日认证机构综合信息查询需求确认2017年1月4日2017年1月4日设计2017年2月1日开发测试+数据导入上线试运行2017年6月1日第七章其他要求系统的维护从合同系统终验合格之日起，乙方提供一年的免费维护支持服务。6.1 系统的培训乙方应就合同系统的正常使用、维护向甲方使用、维护人员提供必要的培训I。 乙方免费提供培训课程及授课讲师，并提供培训所需的场所、设施及其他物质条 件，甲方应积极配合乙方开展培训工作。培训实施时间由双方根据项目进度协商 确定。第1章建设目标L1背景1）政策背景认监委“十三五”规划提出全面服务经济社会发展，促进食品农产品认证。对通 过信息化手段
3、进一步助力业务部门提升食品农产品认证加速全面发展提出了更 高的要求。2）技术背景随着互联网技术发展日趋成熟、依托大数据技术、云计算技术、多屏技术进行全 新信息化系统改造与建设，对于进一步提升业务数据贯通融合、增加系统运行安 全性与稳定性、全面提升用户体验，提供稳定可靠的技术保证。1.2目标1）性能优化体验提升对软、硬件整体架构进行性能优化，结合互联网下的信息化特性，全面对系统性 能和用户体验改造升级。2）优化食品农产品认证信息化服务能力在认监委统一协调下，促进数据融会贯通、扩展数据接口，绘制相关机构画像提 供多维度认证机构查询服务，促进建立具有公信力的认证服务，进一步支撑规范 食品农产品相关认
4、证规范性建设。3）推进认证监管精准化能力依托大数据中心，对食品农产品认证活动进行综合预警模型建设，初步建立事中 事后的精准监管模型。1.2业务相关方系统业务相关方主要包括：质检总局、认监委、地方两局、认可中心、认证 认可协会、认证机构、持认证认可证书信息的企业、通过认证认可标准的产品、 销售认证认可范围内产品经销商及社会公众（消费者）。第2章业务需求概述2.1业务概述主要分为两个方面的升级改造：1）为了适应满足有机认证等自愿性农产品认证业务的发展需求，提出符合 现行系统业务改造需求；2）随着互联网技术趋于成熟，提出基于大数据技术解决包括性能改造、用 户体验提升等功能与非功能改造需求改造功能构架
5、图食品农产品认证信息系统2. 5第3章需求概要3.1 性能综合改造3.1.1 要问题分析1）现行系统存在有机码上传耗时长、正常数据上传不成功、系统无法及时 反应的现象。有机码上传存储数据量过大、单表数据量过大（单表最大超过10 亿条）是不可避免的客观因素，除此之外硬件升级数据存储分表原则、单线程运 行方式、上传校验运算规则等也是重要的性能改造点。2）现行系统有机码备案功能页面无法获取批次上传过程反馈信息，系统只 能提供有机码上传完成之后的结果信息（成功、失败、数据校验错误等标志信息）。 因此批量备案功能每次执行时间较长，用户无法及时获取上传进度或者排队情况 以及有机码上传预测等信息，用户体验有
6、很大的提升空间。3.1.2 改造原则本次性能改造升级，需要在不影响业务正常处理的基础上，进行上传方式、数据库架构设计、硬件部署等方面改造升级后，进行相同环境相同数据级别的性 能与功能测试并进行一次以上路演，在确保业务一致性并有效提高性能参数的基 础上发布修改内容。因此在测试以及上线预演等方面需要进行大量投入。3.1.3 改造方案1）硬件运行环境升级对系统运行硬件环境和网络环境进行运行效能、安全性升级改造，并且根据 目前固态硬盘在数据访问速度和数据安全保护等方面的优势，将数据存储更换为 固态硬盘方式。2）数据存储分表策略调整目前存储有机码的数据表采取单纯按年分表存储机制，同一年所有机构上传 有机
7、码都存储在同一数据表中，以2016年委里，存储有机码的表中目前数据量 已达到10亿级别，这也是造成目前性能问题的主要因素。有机码由17位数字组成，其中认证机构代码3位+认证标志发放年份代码2 位+认证标志发放随机码12位，不同机构对12位随机码的处理方法不同，但是 每家机构上传的同一批有机码的第6位采用相同方式。鉴于目前的情况采用新的存储分表机制（按年、按机构及有机码第六位分表。） 将很大程度上提高有机码上传效率。即每家机构的有机码存储在10张数据表中， 比如2016年机构码位123的机构的有机码存储在TORGANIC_NUMBER23160 至TORGANIC_NUMBER23169表中。上
8、传有机码时，系统根据有机码的前六 位判断写入到相应的数据表，查询时再根据有机码查询相应的数据表。3）上传执行计划调整目前有机码上传采用单机构单批次共用单一线程方式上传，单批次最大上传 数量为100万,上传时间为3到5个小时，结合100万程度的企业比较集中的业 务特点，本次多线程方式改造，将根据批次实际有机码数量制定线程使用机制， 解决大数量批独占资源的现状，最大程度活用系统资源。4）上传进度体验综合改善在目前只回馈上传结果信息的基础之上，增加上传过程信息（开始上传前的 等待时间预测、上传时长预测、完成进度百分比）的回馈，并且根据用户需求定 制刷新频率以及通知方式（页面显示+短信提示）。3.2
9、认证活动风险预警依托大数据中心建设基础，初步建设以实现精准监管为目的的机构风险预警模型 和认证活动风险预警模型；1）认证机构风险预警模型通过相关主流媒体舆情分析模型，实施监控有机获 证企业的经营与销售违法舆论，建立风险发生原因识别，通过发证机构及其下所 有发证企业的类似风险进行预警；2）认证活动风险预警模型通过对有机种植投入品名录建立实施监控，建立相关影响农产品识别模型，对可 能因投入品等因素引发的有机生产活动风险进行预警；3.3 认证机构大数据画像（移动端）基于认监委信息中心大数据中心数据基础，依托大数据画像技术，从基本信 息、市场监管、认证活动、人员信息、相关公司等维度，对认证机构进行综合
10、信 息展示，建立食品农产品认证体系认证机构大数据画像；1）认证机构综合信息画像；根据自愿性农业产品认证类别和范围进行逐级信息展开和查询公共，建立机 构模型（认证业务资质、发证数量及其市场占有率，市场监管信息），绘制 认证机构综合信息画像；2）企业认证综合信息图谱通过获证业企业查询为入口，关联此企业所有认证资质以及认证机构，以食品农 产品认证为轴心，建立企业认证综合信息图谱；34有机认证企业用户管理1）有机示范区服务开通功能建成有机示范区企业用户管理模块，实现对全体企业信息的注册、权限、登录、 基本信息录入的信息化模块；2）有机认证企业追溯服务开通功能建成有机认证企业的追溯开通功能以及相关用户管
11、理功能;3.5数据接口扩展1）食品农产品认证信息系统对外服务接口。进一步开放对外的服务接口，实现与进出口食品生产企业注册备案系统、统 一上报平台、统一查询和综合监管平台的互联互通与信息共享，通过传入证书编 号等参数返回相关信息，深入促进业务数据融合贯通。2）认证机构HACCP相关信息系统相关HACCP认证资质的认证机构系统进行对接，实现在系统中可以查询 HACCP码的相关信息、。3）对接有机示范区综合信息展示系统与有机示范区综合展示平台实现双向信息交互，将获证企业包括认证证书、 认证规模、特色产品、地理区域等信息，为有机示范区地理特性进行区域特色综 合展示提供数据接口服务。第4章非功能性需求概
12、述随着系统业务逻辑的扩展、数据信息的增加，系统的部分技术指标已经不能 满足目前用户的需要。本次系统重构，技术架构重点在于提高数据读写速度，在 系统本身数据量大的前提下，访问高负载情况下，能够保证系统的正常访问，有 效扩展服务器的吞吐量、加强数据处理能力、满足用户的体验程度。4.1 信息安全策略本次架构重整，我们希望依照国家信息安全等级第二级保护制度进行以下几 个方面安全策略：物理安全:保持将服务器放置于公司机房，开发办公地也限于公司内部开发, 对参与开发人员设备安装加密系统，防止文件外泄等；网络安全：合理预期网络峰值，设计网络带宽，建立安全的访问路径。通过 访问客户端IP地址范围控制和认证，保
13、证系统对接端口只向被授权对象使用， 单位时间访问次数控制及认证控制等手段防止网络爬虫并进行边界防护。主机安全：操作系统和数据库系统进行用户身份识别，权限分级管理，由授 权主体设置对客体访问和操作权限。数据完整：数据在传输、交换、存储和处理过程保持不可修改、不可破坏和 避免丢失的特性，即保持信息原样性，使信息能正确生成、存储、传输；数据可用性：系统信息可被授权实体正确访问，并按要求能正常使用或在非 正常情况下能恢复使用的特征。4.2 系统性能要求针对本次架构的关注点，要达到大数据基础上系统稳定的关注点，就必须首 先执行性能测试并明确需要收集、监控哪些关键指标并满足本说明书要求。资源使用率(Res
14、ource utilization)本架构重要解决在有限的硬件服务指标模式下，尽可能增加数据访问负载, 保证DB、AP服务器的资源使用率在正常(80%)范围内。响应时间(Response time)吞吐量(Throughput)并发用户数(Concurrent users)请参照4.7目标参数系统硬件架构方针为了保证系统运行时能正确存取所需信息，当系统遭受攻击或破坏时，能迅 速启用备份系统恢复并能投入使用，系统硬件架构采用如下设计思路：应用数据库采用内存数据库和磁盘数据库双重持久化方式。4.3 系统软件架构方针本次在不改变原系统软件架构基础上进行系统升级改造。4.4 系统网络设计要求提供网络拓
15、扑图，满足数据采集、存储、传输要求。4.5 目标参数查询响应时间：系统和其他系统对接业务，单个请求（包括打包请求），需 要保证最大处理时间不超过10秒（/200条）。统计页面响应时间：因为一般统计页面为业务管理员角色操作，实现单个分 析/预警页面最大处理时间不超过20秒。上传页面响应时间：考虑到有机码数据库规模的因素，实现单个上传请求最 大处理时间不超过1小时（20万条数据为单位），并随时报告上传状态，上传 后发送通知信息。稳定性指标：按照认监委正常工作时间运行，平均运行故障率低于0.05%。吞吐量I/O：达到10事务或请求秒级响应。并发：可以接受100用户同时并发万级数据库检索。第5章项目成果要求本项目成果需要满足以下要求：5.1 稳定性稳定性指标：按照认监委正常工作时间运行，平均运行故障率低于0.05% （因系统故障导致宕机死机小时/系统总运行小时）。5.2 灵活性在建设中要注意系统集成配置的灵活性，系统在设计中应充分考虑到业务调 整和扩展的需要。5.3 可扩展性系统设计要充分考虑系统集成和接口类型扩展的需要，为今后顺利扩展业务 功能打下良好基础、留下合理空间。5.4 规范性平台建设应遵守相关的标准化规范，包括需求规格说明书、平台设计规范、 代码开发规范、配置管理规范、运行维护规范等。