瓦片地图动态缓存中间件的优化设计及实现

孙 伟，李治庆，焦孟凯，李成名

(1.山东科技大学测绘科学与工程学院，山东青岛266510;2.中国测绘科学研究院，北京100830)

一、引 言

近几年来，随着Google Map等在线地图服务网站和系统的兴起，利用瓦片进行地图服务逐渐成为网络地理信息服务的主要形式，也使地理信息在线服务的能力和效率得到了有效提升［1-3］。与此同时，开放地理信息系统协会(Open GIS Consortium，OGC)也出台了一些网络地图服务标准，使瓦片地图服务的利用更加规范。

现有的瓦片地图服务一般有两种方式:一是预生成静态瓦片，通过缓存大量规则的地图瓦片来响应客户端的请求;二是采用动态瓦片，即按照用户请求序列实时生成并反馈地图瓦片［4］。这两种方法各有优缺点。采用静态缓存方法的优点是客户端的响应效率高，用户交互体验较好;缺点是由于瓦片需要预先生成，地图现势性差，用户可能无法得到真实的地理信息反馈。而采用动态缓存方法的优点是地理信息实时、现势性较好;缺点是即时反馈需要耗费大量的图片生成时间，客户端响应效率低、用户交互体验差，同时也会产生大量不必要的服务器处理开销［5］。

为了解决地图服务高效和现势性的双重需求，目前较常用的方法是采用具有动态切图策略的地图服务中间件，部署在客户端和服务器中间，根据客户端发送的地图服务请求，将相应的动态或静态缓存反馈到客户端。如GeoWebCache和TileCache等，就是目前国际上比较流行的开源瓦片缓存中间件，它们在保证地图现势性的同时，也提高了访问速度，具有较好的应用价值。本文就在参考GeoWebCache的架构基础上，从服务类型、信息交互、历史数据利用等方面，进行进一步的优化，从而提供更好的瓦片地图服务。

二、GeoWebCache原理、结构及不足

1.GeoWebCache原理及结构

GeoWebCache是OpenGEO的一个开源瓦片地图服务模块，采用Java实现基于WMS的动态缓存服务。在实际工作中，GeoWebCache部署于客户端和WMS兼容服务器之间，充当地图访问代理。其工作原理是:当客户端请求地图时，GeoWebCache服务器拦截该请求，判断本次请求的瓦片是否存在。如果存在，则将这些缓存图片直接渲染至客户端;如果不存在，则发送请求至WMS Server，由服务器处理请求数据，并返回给GeoWebCache服务器，Geo WebCache服务器经过渲染及缓存数据图片后绘制到客户端。

与单纯的静态缓存相比，利用GeoWebCache后的地图服务会有明显的能力提升。客户端所请求的图片事先或者在重复请求过程中就能够存储在GeoWebCache中。当其拦截到新的地图服务请求，分析后若发现与其存储的地图瓦片一致，则可直接将已存储的地图瓦片返回客户端，不需要在服务器端重复计算，这使得地图绘制的速度提升数倍，也得到了更好的用户体验效果，如图1所示。

图1 GeoWebCache结构及请求处理过程

从图1可以看出，GeoWebCache的主体由服务的管理部分和缓存存储两部分构成。服务管理部分能够支持 WMS、WMTS、TMS、KML、GMaps及VE等多种服务，客户端使用基于 HTTP的 Web Services与其进行服务请求，可满足多种客户端请求需求;缓存存储部分采用标准接口管理系统元数据及瓦片空间索引，并为地图瓦片提供高速缓存，支持的数据源主要为WMS兼容服务器，如GeoServer、ArcIMS、MapServer等。

2.GeoWebCache不足分析

作为一个开源的瓦片地图服务中间件，GeoWebCache能够较好地改善地图服务在动态更新和高效响应之间的问题。但作为一种需要兼顾各类瓦片服务请求和服务提供的中间件，其仍存在一些可改善之处:

(1)服务器端接口扩展

尽管GeoWebCache能够提供较为丰富的前端可支持服务，但是在后端的数据源，却仅提供了面向WMS兼容服务器的单向接口。而WMS是OGC标准化规范后的服务接口，这种方式限制了其他(如ArcGISServer、MapServer等地图服务器)的使用。

(2)历史版本数据的管理与应用

GeoWebCache的缓存存储器存储内容包括系统元数据、瓦片空间索引数据及瓦片缓存，但缺乏能够表现地理信息长时间序列变化的的版本信息，时序性无法很好地展现。

(3)服务协议的扩展

对于客户端的请求，GeoWebCache需要使用基于HTTP的Web Services，从而保证服务的广泛支持和适用性。但在服务器端，由于使用了WMS兼容服务器，也将服务网络协议局限于HTTP。

三、瓦片地图动态缓存中间件的优化

为了使瓦片地图动态缓存效果在效率、服务扩展及历史回溯等方面更加完善，本文在参考GeoWebCache结构的基础上，针对其目前存在的几个不足之处，设计了一种动静结合的可回溯扩展性瓦片地图动态缓存中间件DCM(dynamic caching middleware)，并从底层编程实现。

1.架构设计

在主体架构方面，DCM分为服务解析模块、服务处理模块和服务适配模块3个部分(如图2所示)。其中，服务解析模块负责对客户端发送来的服务请求进行解析判断，然后把解析结果传递给服务处理模块进行处理。服务处理模块根据具体的解析结果进行处理操作，包括静态缓存获取、动态切图及动态缓存更新等。服务适配模块则主要是在需进行动态切图及更新时，将发送来的服务模式与后台服务器端的服务模式进行最优化匹配，并将处理后的结果按需反馈给服务处理模块进行操作。此外，DCM外部还搭配有一个缓存数据库，用于存放系统元数据、静态缓存数据及缓存版本信息。其中，静态缓存可根据版本信息进行分时间节点存放。服务器端则可以是Web Services服务器及其他可提供缓存服务的服务器。

在细节方面，针对GeoWebCache存在的几点不足，对DCM在服务扩展和响应效率上进行优化设计(图2中数字标注部分)。

1)利用插件式扩展结构，对服务解析配置模块进行服务动态扩展能力的提升，从而达到客户端多类型请求的自动扩展。

2)增加一个服务适配模块，根据客户端发送的服务请求和DCM实时链接的网络地图服务器或者空间数据库所支持的最高效地图服务接口之间进行转换，从而提供满足当前环境需求的最高效服务能力。

3)增加缓存存储模块中的版本信息索引，用户默认操作时，仍旧根据系统元数据信息来进行最新缓存的静态或动态地图服务，但同时提供用户可选的静态历史缓存数据获取服务。

4)根据服务器端的响应配置，扩充后台服务协议，增加FastCGI等可提高服务的响应效率与稳定性的协议，从而提高整个地图服务服务器端的能力。

整个服务流程中，所有地图服务客户端的请求都向DCM发送，DCM根据请求来确定是否需要向服务器端发出相应瓦片切片命令，而具体的瓦片存储及反馈则在DCM中实现。这种结构使得DCM两端都是低耦合的结构，在方便客户端用户使用的同时，也可提高动态缓存服务效率。

图2 DCM结构示意图

2.响应流程

加载了DCM后，在进行瓦片地图服务时，具体处理流程如图3所示。

图3 地图瓦片动态缓存服务流程

客户端发出请求被DCM接收(步骤①)，并由服务解析模块进行解析(步骤②)。解析的结果有两种:一种是该请求的地图服务所涉及的地图瓦片已存在(步骤③)，另一种是该请求的地图服务所涉及的地图瓦片不存在(步骤⑧)。

对于地图瓦片已经存在的情况，根据服务请求范围，通过服务处理模块查找缓存数据库中的元数据，根据查询结果判断相关地图数据是否已更新(步骤④)。若无最新的地图数据，即瓦片不需要更新，则直接从缓存数据库中按照服务请求获取已有的瓦片(步骤⑤)，并将瓦片通过服务处理模块反馈到客户端(步骤⑩);若已有最新的地图数据，即原有地图瓦片已非最新，则需要根据元数据信息将该更新结果发送到服务配置模块，服务配置模块进行服务最优匹配后向服务器端发送最新地图的实时动态瓦片生成请求(步骤⑥)，生成的瓦片及其元数据信息、版本信息将通过服务配置模块反馈给服务处理模块，并存储至缓存数据库(步骤⑦)，同时更新后瓦片则根据原地图服务请求返回客户端(步骤⑩)。

对于地图瓦片不存在的情况，根据服务请求的范围计算图片的位置，并将该处理结果发送到服务器端进行实时动态瓦片生成(步骤⑨)，生成的瓦片、元数据信息及版本信息存储至缓存数据库(步骤⑦)，并将最终的瓦片通过服务处理模块反馈到客户端(步骤⑩)。

四、优化测试

为了测试采用DCM瓦片动态缓存后的服务实际效果，本文搭建了测试环境，并对静态缓存WMTS与使用DCM的动态缓存服务进行性能测试。

1.测试方案

在测试环境方面，测试客户端选择WebLOAD V8.1来模拟访问时的Web操作;在测试服务器端，选用Intel双核2.0 GHz处理器、2 GB内存服务器;测试网络环境选择100 Mbit网络链接。

在测试数据方面，选择全国范围1∶400万地图数据并按照地理信息公共服务平台电子地图切片方式［6］中第8级进行切片，瓦片大小为256像素×256像素，格式为PNG，切图后瓦片共计2018张，占用磁盘空间9 MB。测试选择WMTS静态缓存和本文设计的DCM两种方式进行对比，针对WMTS使用已进行静态缓存后的瓦片地图数据，针对DCM则利用未进行切片的地图数据。

在测试方法方面，WMTS直接向测试服务器发送数据请求，而DCM需将已有缓存清空。在10个并发条件下，对同一区域范围地图的请求次数分别采用 50、100、300、500、1000、2000、3000、5000 八个组别，以多线程方式模拟客户端发出指令，同时向DCM发送2×2个地图瓦片数据请求，最终结果评定从服务响应时间方面进行比较。

2.结果及分析

图4显示了同样的请求环境下，分别对静态缓存策略下WMTS请求，与动态缓存策略下DCM请求平均响应时间的对比。从图4可以看出，对于静态缓存策略下WMTS请求，其响应时间较为平均，约为4.5 ms。而对于增加了DCM并进行瓦片动态缓存的WMTS请求，其响应时间变化较大。在测试初期阶段，由于已将DCM的缓存清空，因此在进行地图请求时，需要通过DCM向服务器发出地图获取指令并按照获取范围实时切图，然后将瓦片存储入DCM，最后返回客户端，因此时间较长，约为530 ms;而随着请求次数的不断增加，DCM缓存存储器中的地图瓦片不断增加，因此存储在DCM中的瓦片被检索到的概率越来越大，DCM向服务器发送指令并实时切图的次数也随之减少，平均响应时间急剧降低，当累积请求次数达到950次时，两种请求方法的响应时间已经接近相同。而随后，DCM的请求响应时间与普通WMTS请求大致相同。当DCM所缓存的地图瓦片趋于饱和后，DCM请求响应时间也逐渐稳定，约为5 ms。因此可见，使用了动态缓存策略后，随着对其访问量的逐渐增大，不仅能够有效保持与静态缓存服务相当的高效响应能力，而且还能够实现实时动态切图，对于提高地理信息更新服务能力具有重要意义。

五、结束语

瓦片地图动态缓存中间件能够有效地提升瓦片地图服务的地图现势性和服务响应效率，从而为用户提供最新的地理信息和更好的使用交互体验。本文在参考目前国际上较为流行的瓦片缓存中间件GeoWebCache结构的基础上，针对其在服务扩展性、历史版本数据使用及服务通信协议等方面存在的局限，从底层进行结构优化，设计并实现了动态缓存中间件DCM，可提高现有瓦片动态缓存服务的扩展能力和服务水平。通过对比测试，证明了该缓存中间件DCM不仅可以提供高效的服务响应能力，而且可根据地图数据的现势性提供最新的瓦片地图服务。与此同时，DCM也可根据客户端和服务器端服务请求和提供方式，选择最优的服务处理及传输，动态加载其他类型的瓦片服务，做到瓦片地图服务最大限度的高效提供。

图4 WMTS与DCM平均响应时间对比图

本文提出的动态缓存中间件DCM虽然能够提供较好的地图瓦片服务，但其试验效果仍旧是在特定试验环境下得出的，在规模化应用下的服务响应能力仍有待进一步的探索。此外，瓦片的空间索引、现势数据的快速切片等也是制约瓦片地图服务能力的重要因素，在今后的研究中，还需对这些因素进行更深入的研究。

［1］周沛.智能交通系统中的瓦片地图技术研究与应用［D］.上海:同济大学，2008.

［2］王晓东，刘慧平，乔瑜.利用Bing Maps地图切片实现网络地图服务［J］.国土资源遥感，2010(2):122-127.

［3］刘冰，谢轲，陈小乐，等.基于GIS的瓦片式地图切图算法的设计与实现［J］.科技信息，2011(7):60-61.

［4］许虎，聂云峰，舒坚.基于中间件的瓦片地图服务设计与实现［J］.地球信息科学学报，2010，12(4):562-567.

［5］聂云峰，刘海玲，许虎.GeoWebCache瓦片地图服务中间件研究［J］.测绘科学，2011，36(6):207-209.

［6］国家测绘地理信息局.CH/Z 9011-2011地理信息公共服务平台电子地图数据规范［S］.北京:测绘出版社，2011.