Grails开发总结报告
一.概述
1.编写说明
Oneteam后台采用grails进行开发,在此对grails的开发和运行情况进行总结。
2.系统简介
Oneteam项目集成管理系统是一个基于项目过程的协同工作和管理平台,以CMMI理论为基础,结合PSP/TSP、PMB、Scrum等理论,以满足用户需求为目的,进行有机地整合。
功能包括:
个人工作管理:时间管理、工作日历、工作报告、工作排期、工作负荷分析、博客、便签等
团队协作:通讯录、资料共享、信息共享和交流(门户、评论、关注、消息)、信息发布(通知、新闻、博客)、问题管理、干系人管理、公文流转
项目管理:项目计划、项目范围、风险管理、工作量估算、工作报告、项目监控、项目分级管理(计划、范围)、项目评审
敏捷开发:冲刺、障碍、需求排期、燃尽图、看板、工作认领、每日站立会议
工程:需求开发和管理、测试管理
知识管理:提问、建议、资料共享(支持多用户编辑)、知识库搜索、过程资产库、知识能力、知识达人
过程管理:项目生命周期、文档模板、支持项目QA
组织:组织视图、部门管理、组织级项目管理、支持组织级对人员、项目的可视化分析和监管
系统管理:系统设置、组织结构管理、参数维护、安全管理、系统监控、批处理、二次开发、软件注册升级等
3.系统规模
序号 | 要素 | 数量 | 备注 |
1 | 表单 | 229 | Swf文件 |
2 | 工作流 | 9 |
|
3 | 查询 | 199 |
|
4 | 构件 | 27 |
|
5 | 数据库表 | 106 |
|
6 | 后台代码行数 | 19951 | 其中自动生成的为8209 |
二.开发总结
1.系统架构
|
前台采用flex,通过http访问后台。
序号 | 技术 | 版本 | 备注 |
1 | flex | 3.6A |
|
2 | tomcat | 6.0.20 |
|
3 | grails | 1.3.7 |
|
4 | mysql | 5.1.54 |
|
5 | jdk | 1.6.0_21 |
|
6 | vdk | 0.9 | Voneteam的开发库 |
2.后台开发架构
分构件组织开发,每个构件具有相同的后台开发架构:
序号 | 层 | 说明 |
1 | Control(控制器) | 1. 作为交易总控,前台发来交易请求,在此进行解析,实例化服务,进行业务处理,并将处理结果返回前台。 2. 整个系统只有一个Control 3. 开发人员基本无需开发。 |
2 | Service(服务) | 1. 实例化业务类,调用业务类的交易方法 2. 开发人员无需开发,已放入vdk |
3 | BO(业务类) | 1.开发人员在此编写业务逻辑代码 |
4 | vdk(voneteam开发库) | 封装相关基类和公用方法 |
采用这种开发架构,给我们带来以下好处:
1) 大量通用交易被封装在vdk中,在groovy高效开发地基础上,进一步降低了后台开发量。
226个表单,106个表,后台只需手动编写11700行代码,确实超出了我们预想的结果。
2) 后台开发人员只需要关注交易接口和业务逻辑,进行BO的开发,不需考虑架构,无需关注前台。
3) 构件之间通过构件接口进行调用,平衡低耦合和高复用之间的关系。
3.后台开发环境
序号 | 工具 | 说明 |
1 | Idea10.0.2 | Grails开发工具 |
1 | Navicat for Mysql 9.0.10 | Mysql管理工具 |
4.开发总结
这是我们使用grails开发的第一产品,在开发架构稳定后,一个具有java开发经验的人员,只需一周左右即可独立工作,迁移成本非常低。
Groovy的动态特性,使我们在开发vdk的基类时获得很大帮助。
根据我们估算,后台采用groovy+vdk,比用java开发,后台代码量至少降低了80%。
5.开发中面临的问题
使用idea开发grails应用,目前面临最大的问题是idea重启应用服务需要一定时间,开发人员只能干等,降低了开发效率。
在调试过程中,有时会出现OutOfMemoryError: PermGen space的问题,需要重启应用服务。
6.技术升级的考虑
目前grails已经到2.3.0,我们考虑在以下方面进行改进。
1) 基于OSGi的热插拔
使生产系统的升级更加轻量。
2) 内置Jetty服务器,不用重新启动服务器就可以进行重新加载
减少开发过程中的等待
三.运行总结
1.运行环境
生产系统中服务器环境:
普通PC,win7 32位旗舰版,cpu:2.3G,内存:4G
用户数:10人
日均交易量:4870(平均每日前台向后台发起4870次交易请求)
以下基于我们生产系统的交易数据进行性能分析和稳定性分析。
2.性能分析
平均交易时间:0.73秒
短交易平均交易时间:0.23秒(排除交易时间>5秒的统计、出错等较长时间的交易)
3.稳定性分析
出现系统异常的交易比例为4.8‰。