首页 > 代码库 > 简记某WebGIS项目的优化之路
简记某WebGIS项目的优化之路
文章版权由作者李晓晖和博客园共有，若转载请于明显处标明出处：http://www.cnblogs.com/naaoveGIS/
1. 背景
该项目为研究生时的老师牵头，个人已毕业数年，应老师要求协助其进行了该项目的管理。
项目组能获取到全球主要作物的生长指标，以及降水、温度等影响作物生长的指标数据。面对繁琐冗长的大量遥感数据，致力让广大没有遥感专业背景的用户了解到全球各农作物的生长情况，为用户提供一个可视化的全球农情遥感数据展示。
网站包括的功能有：
多种指标（NDVI、PAR、温度、降水等）的展示。
反演影像展示。
聚类产品展示。
产量及价格指数展示等。
2. 初始架构（1.0版本）——传统方案
2.1架构描述
由于对方已采购了SQLSERVER和ARCGIS SERVER，期望将这两款软件用上，所以初始版本的架构数据库采用了SQLSERVER，地理服务器采用了AGS，服务端基于JAVAEE，前端采用AGS JS。
在展示中，对于指标数据（全球地图）遍历，并且根据读出的指数值再逐个添加样式，最后用graphic逐个画出。 影像数据用MXD发布到ARCGISSERVER，包括边界（ 国家、MRU、MPZ等）数据。
2.2架构未解决的问题
此架构开发完DEMO后，便遇到了几个必须解决的问题。
问题1：进入系统后，全球化地图（基于graphiclayer）显示缓慢。
问题2：影像成果数据各指数产品，每周每旬每月均会增加。如果依靠人工发布至AGS，首先无法实现智能化；其次AGS上一年增加上千个影像的发布，很显然是不现实的。
3. 从数据处理进化架构（2.0版本）
3.1架构进化描述
a.开发自动切图程序，扫描指定文件夹，当影像下载至指定文件夹时则进行影像切图将其转移至目标文件夹。
b.对全球尺度SHP数据进行简化，使数据量大大减小。
c.将SHP数据处理为GeoJson文本后，再进行压缩为PBF格式，并且开启Tomcat中的GZIP压缩，进一步减少数据请求量大小。
d.对所有前段JS文件进行压缩打包，减少请求JS时的连接数。
总结：
舍弃AGS，将影像瓦片和SHP数据本地化，并且尽量减少JS请求个数。
3.2架构未解决的问题
随着需求进一步增加，要求增加国内县市级数据（2000+县），并且按作物产区显示反演影像。目前的数据库设计会导致每张指数表中数据量激增，随时过一千万。系统前端的展示十分卡顿。
4.从数据库层面开始进化之3.0版本
4.1架构进化描述
a.仔细分析业务后对数据库进行分表，即按照指数和地域来进行分表，使每张数据表的大小大大降低。
b.针对影像按产区展需求，增加地图的MASK功能。
4.2架构未解决的问题
由于之前均是基于个人服务器开发，用户后又提出希望将系统部署至阿里云上，于是对架构提出了新的规划。
5.从个人服务器转移至阿里云的进化（4.0版本）
5.1架构进化描述
a.云服务器采用Linux系统，数据库更换成Mysql。在服务器上搭建tomcat+javaee+mysql的架构。
b.由于切图程序为AE开发，所以这里将切图程序部署在windows服务器上，其切图成功后再将瓦片转移至指定目录。
5.2架构未解决的问题
在云服务搭建好后，系统开始投入使用，发现即使分表了，由于全球数据过多，依然导致每张指数表快接近一千万。系统又开始卡顿。
6.从索引、缓存、部署上进行进化（5.0版本）
6.1架构进化描述
a.增加合理的索引机制，如mysql的组合索引（mysql中的组合索引的各组合字段顺序比较有学问http://blog.sina.com.cn/s/blog_46d93f1901017biz.html）。
b.优化SQL语句，同样在mysql中between的使用也大有讲究，如果使用不当（查询内容占表的16%时会自动全表查询）会导致索引无效，而用IN则无此问题。还有针对Where字句顺序的调整等。
c.增加mysql的数据库级别缓存。
d.使用ehcache缓存。
e.采用CDN。
f.部署nginx,将瓦片文件夹等做静态资源代理，实现最大限度的静动态文件分离。
7.总结
1.需求总是不断变化的，我们即没有必要使用成本最高的实施方案，也不能总是选用没有扩展空间的方案，快一步就刚刚好。
2.一些必要的优化知识得铭记。
数据库层面：加索引（单列、组合），分表，SQL优化（逻辑和语法），分库。
服务器层面：GZI，反向代理，集群水平扩展。
前端：代码合并压缩，通过CSS sprites来整合图像，图像压缩，CDN（但内网无法使用），样式修改需要放一起。
最后上一张系统图：
-----欢迎转载，但保留版权，请于明显处标明出处：http://www.cnblogs.com/naaoveGIS/
简记某WebGIS项目的优化之路