背景 一切都是业务的推动，继上次做的简陋的报表系统的雏形之后 zabbix二次开发之报表系统(一)， 业务同事越来越不满足于那个粗糙的玩意，于是在他们的胁迫下，抽空 完善了下。 新版效果 架构调整 之前的架构大致是这样的， bootstrap 前端 tornado 后端 mon
背景
一切都是业务的推动，继上次做的简陋的报表系统的雏形之后
zabbix二次开发之报表系统(一)，
业务同事越来越不满足于那个粗糙的玩意，于是在他们的胁迫下，抽空
完善了下。
新版效果
架构调整
之前的架构大致是这样的，
- bootstrap 前端
- tornado 后端
- monogodb 数据库
在一次的更新中几乎全换掉了。改用了如下的组件：
- bootstrap 前端
- django 后端
- mysql 数据库
调整的理由
django vs tornado
-
更熟悉django，且是all in one 的框架，可以省去很多的不必要的造轮子的过程。
-
tornado 的异步模式什么的对我吸引力不大
-
django完善的后台功能
-
django非常赞的ORM等功能
mysql vs monogodb
- 更熟悉mysql
调整的原则
-
开发方便、快捷
-
技术上更熟悉
目录树
[root@zabbix-3 report-system]# tree . ├── README ├── report_system │?? ├── data │?? │?? ├── KVM-2014-07-30-16-50.xls │?? │?? └── KVM-2014-08-03-06-01.xls │?? ├── kvm_report │?? │?? ├── admin.py │?? │?? ├── admin.pyc │?? │?? ├── __init__.py │?? │?? ├── __init__.pyc │?? │?? ├── kvm_report_generate.py │?? │?? ├── models.py │?? │?? ├── models.pyc │?? │?? ├── templates │?? │?? │?? ├── kvm_report_add.html │?? │?? │?? ├── kvm_report_base.html │?? │?? │?? ├── kvm_report_delete.html │?? │?? │?? ├── kvm_report_execute.html │?? │?? │?? └── kvm_report_search.html │?? │?? ├── tests.py │?? │?? ├── urls.py │?? │?? ├── urls.pyc │?? │?? ├── views.py │?? │?? └── views.pyc │?? ├── manage.py │?? ├── nohup.out │?? ├── report_system │?? │?? ├── __init__.py │?? │?? ├── __init__.pyc │?? │?? ├── mail.py │?? │?? ├── mail.pyc │?? │?? ├── settings.py │?? │?? ├── settings.pyc │?? │?? ├── urls.py │?? │?? ├── urls.pyc │?? │?? ├── views.py │?? │?? ├── views.pyc │?? │?? ├── wsgi.py │?? │?? ├── wsgi.pyc │?? │?? ├── zabbix_mysql_conf.py │?? │?? └── zabbix_mysql_conf.pyc │?? ├── static │?? │?? ├── css │?? │?? │?? ├── bootstrap.css │?? │?? │?? ├── bootswatch.min.css │?? │?? │?? └── font-awesome.min.css │?? │?? └── js │?? │?? ├── bootstrap.min.js │?? │?? ├── bootswatch.js │?? │?? └── jquery-1.10.2.min.js │?? └── templates │?? ├── base.html │?? ├── index.html │?? └── login.html └── requirement.txt
bootstrap模板的选择
第一次版的雏形也就算了，就是一个单页面，这次的可不是，好歹要有三个。。。
所以模板的事我还得头疼下，毕竟自己不大懂前端不是。
高大上的模板
挑了半天选中了一个效果，非常华丽的模板，但该起来的非常非常麻烦。
代价也非常大：
-
加载对象过多，仔细看了下里面的代码，引用了非常多的图片、css、js等
-
加载速度太慢，和加载对象有很大的关系，而且它居然还引用了谷歌的字体。。。
-
修改麻烦，需要修改的地方太多，例如静态文件，各种模板自定义的css效果
简洁才是王道
还是最简单的用起来方便，最后在同事的推荐下采用bootstrap的模块。
确实比较简洁，没太多的自定义效果，代码组织的也很清晰，就是它了。
后端的重构
由于之前采用的tornado写的，所以这次换django之后基本需要全部推倒重来了。
好在我之前基本没啥功能，加上也熟悉，很快就搞定了。
APP
目前只有一个kvm报表的功能，考虑到以后的其他业务的功能加进来，所以
对一个业务部门划分了一个app的方式去做，方便后期维护嘛；
models
还是跟app来的，每个app需要的话会写自己的models代码，即创建自己的表等。
目前就一个app,当然就一个models文件了。
模板
模板我这里采用了多个目录去存放的，熟悉django的应该清楚，每个app其实也
是有自己的模块文件的。所以我这里做的就是将公共的模块文件保存在根目录下
的templates文件夹中，app的则是存放在各自的templates目录下。
kvm_report 这个app下面的kvm_report_base.html会继承根目录下的base.html，
同时app下的其他html文件会继承kvm_report_base.html。
有兴趣的话看我的目录树吧。
这么做的好处自然不用说了，你懂的。
urls
urls这部分同样是根据app进行划分的，即所以以/kvm_report/开头的urls均会
由kvm_report这个app去处理，而具体怎么去处理的就可以在app中自由的组织了。
[root@zabbix-szq-13 report-system]# cat report_system/report_system/urls.py
from django.conf.urls import patterns, include, url
from django.contrib import admin
from report_system import views
admin.autodiscover()
urlpatterns = patterns('',
# Examples:
# url(r'^$', 'report_system.views.home', name='home'),
# url(r'^blog/', include('blog.urls')),
url(r'^$', views.index),
url(r'^login/$', 'django_cas.views.login'),
url(r'^logout/$', 'django_cas.views.logout'),
url(r'^accounts/login/$', 'django_cas.views.login'),
url(r'^kvm_report/', include('kvm_report.urls')),
url(r'^admin/', include(admin.site.urls)),
)
cas验证
这部分接入了公司的cas系统，实现起来非常简答，就是采用了django-cas实现的。
可以参考django接入cas验证系统。
手动执行的功能
报表这块最早提的是定时生成就可以的，但后来他们老是让我手动帮他们跑，
太烦了，于是做了这个功能让他们自己玩去。
由于这块最早的后台脚本都写完了，所以这次暂时就不改正了，直接使用
subprocess.call 调用系统命令去跑就ok了。
拿到执行结果，返回给用户成功或者失败。
主要更新
* 后台架构的更新自然不用说了 * 第一版本的很多的配置信息都是保存在文件中的，这一次全部放到了mysql中保存 * 加入公司的cas统一认证，增强了安全性 * 新增了查询、删除等功能 * 增加了每个操作之后的回执，即返回操作结果 * 增加了手动执行获取最新报表的功能
总结
当然目前还是有很多问题的。
-
精细的权限验证：
目前只是接入了cas的验证，还未做更具体的权限判断。
-
审计日志：
目前没有做审计日志的记录，
-
后台脚本重构：
后台脚本目前是采用subprocess 调用的，且直接是sql查询数据的，在面临版本升级，
例如zabbix1.8 升级至zabbix2.2的时候，这部分脚本都有可能要重写。
后期可以考虑采用zabbix api的方式去查询历史数据，方便维护。
原文地址：zabbix二次开发之报表系统(二), 感谢原作者分享。
