WebGIS的去服务化,以GeoServer为例说明-轻识

一前言

GeoServer（以下简称GS）是一款非常流行的开源GIS组件，主要作用是把GIS相关的空间数据以OGC规范发布成Web可用的地理服务如WMS、WFS、WCS、WPS、WMTS，用户可以基于GS管理数据源、样式（SLD）、图层、切片等。

在Web2.0和WebGIS刚兴起的时代，其为开源WebGIS架构中不可或缺的组成，随着时代发展，尤其在进入互联网和矢量切片时代，数据的规模越来越大，用户对可视化和交互的要求越来越高，这一系列的变化导致GeoServer面临越来越多的挑战，甚至形成WebGIS的去服务化趋势。。。

二地位与功能

从事Web开发的都清楚所谓的BS三层结构，即：数据库、后台、前台， WebGIS=Web+GIS，本质也是要遵循BS三层结构的，即：空间数据库、地理信息服务、客户端空间可视化和交互，而GeoServer就是WebGIS中占据后台咖位的这么一个存在，经典框架如下图：

经典WebGIS架构

由上图可知，GS实际是一个后台应用服务，作为一个桥梁，让前台和数据库的通信能上传下达。在WebGIS刚兴起时，当时主要是强GIS领域使用，数据量通常不大，用户的交互和显示要求也不高，所以GS作为桥梁的功能更表现的还挺好，类似的ArcGIS Server也都是这类生态位。

所以，根据当时时代发展的要求，商业和开源引擎都在该时间段内诞生了专业的地理信息后台服务这么一个组件的要求，所以称之为“应运而生”是不过分的。

GS主页

GS的主要功能如下：

管理矢量和栅格数据源。
图层和图层组管理。
样式制作（WMS+SLD)。
集成的GeoWebCache的地图切片工具用于底图切图。

比较亮点的特色简单介绍下：

基于SQL视图发布图层，这个用的好挺有意思的，能灵活组织空间数据库中的数据（如postgis）和function。

丰富的数据源和功能扩展插件。
除了基于Web的GUI管理，还提供了一套Rest接口便于程序自动管理，例如自动发布批量发布数据源、图层、样式等。

该怎样评价GS咧？很强大，大概类似一个百货商店一样，有各种各样的商品，没事逛逛也挺有意思的。

三存在问题

虽然GS很强大，但是它的功能或多或少都有点不合时宜了，本章节简单介绍下。

3.1 样式体系的崩塌

从GS主要功能看，样式是它的主要组成部分，默认是早期ogc的SLD样式，就是用xml标签写样式（早期java服务几乎都是xml），sld的xml标签写起来非常费劲，于是又有人倒腾了一个CSS样式，这样写就简化了很多，之后还有其他的样式，例如mapbox styles等。

GS的样式主要是在后台对数据进行渲染，配合wms服务，将渲染后的地图图片传到客户端显示，这大概是10年前的技术了。随着矢量切片的兴起，当前主流渲染已经迁移到客户端渲染了。所以不管GS怎么折腾，样式功能是崩塌了，整体功能吸引力就少了一块。

3.2 WMS、WFS服务体系的崩塌

WMS服务（后端渲染）用的越来越少了，当前地图渲染主要由客户端基于的webgl技术实现，这个好理解。

WFS复杂点，具体看下图：

WFS请求数据链路

当用户发送wfs请求时，由于数据存在数据库，GS首先解析WFS参数，然后构造成查询数据库的sql去数据库查询数据，那么问题来了，数据库通常有IO瓶颈，GIS计算和分析通常又是重CPU操作，所以数据库端的IO和CPU瓶颈就会很严重；由于WFS的查询通常和普通表单的分页查询不一样，有时候查询的范围很大，查询到的数据数量很多，也会造成从数据库端到服务端的数据传输网络瓶颈。

应该怎么解决IO、CPU、网络开销问题咧？一方面是制定合理的业务规则，尽量不要暴力查询大量数据；另一方面是基于数据库去优化。以PostGIS为例子，通过优化内核参数、数据库配置参数、建立合适的时空索引、针对性的空间分析优化、在数据库端的gzip压缩等等，都能很好的解决这些问题。

面对类似这样的问题，GeoServer无权去优化数据库，他只是一个服务，只能暴力的去load数据到后台处理，性能当然很低，但GS却无能为力。

3.3 鸡肋的矢量切片

Mapbox搞出矢量切片规范以后，矢量切片在客户端渲染，显示和交互效果都更好，成为目前webgis中最常用的数据格式。GS也有一个矢量切片的插件，结合geowebcache生成矢量切片，但总体而言，GS中的矢量切片是非常鸡肋的：

性能低。上文说过，首先，要把数据库的大量数据load到后台，这也是最大的瓶颈，io、cpu、网络瓶颈一个不落；其次，在后台生成矢量切片，cpu密集型；最终将切片本地缓存并传输到客户端。

瓦片体积大。mapbox有个专门做静态底图的工具tippecanoe，该工具功能非常强大，生成的数据质量好，更灵活，缺点是只能处理json文件，不能连接企业级空间数据库，所以一般也就做做底图。而GS的矢量切片与该工具相比差别是非常大的，切片文件体积偏大，质量粗糙。

不支持动态矢量切片。动态矢量切片是指数据不切片，实时根据xyz请求动态查询数据并将数据编码成ptotobuf传输客户端，非常适合动态的业务场景。例如某些空间数据经常编辑维护，如果提前预切，数据变化就要重新生成，费时费力。动态矢量切片很好的解决了这个问题，数据只要入库，每次xyz请求的矢量切片都是最新时效的切片。但是很遗憾，GS目前的数据处理机制是如果切片缓存有请求的切片则返回（数据库和数据切片的数据一致性无法保证，数据库更新了，这个切片却未过期，用户看到的是过期数据），没有切片，则去数据库load到服务端处理，生成切片，返回客户端，并以文件形式持久化到切片缓存目录里。这个机制一方面数据很容易过期，另一方面性能很低（只要存在把数据从数据库load到后台性能都不可能好）。

四问题总结

类似GeoServer这种服务端GIS组件，最大最大的问题，就是将数据load到服务端内存处理，这是与当前技术潮流背道而驰的。将数据load到内存，在古典时期数据很小的时候没有问题，只要数据一大，就是灾难性设计。

因此，当前主流GIS的数据处理方案是将数据库作为服务化，例如基于PostGIS实现数据服务，基于xx时空数据引擎实现数据服务，以数据库为核心，提供存储、分析、数据切片、压缩甚至直接渲染成图片出图，一方面数据库的分布式方案很成熟，数据可以水平分布并行计算；另一方面，减少服务端和数据库端的通信，数据库自治完成一系列重CPU计算功能和数据压缩等；最主要的是，数据在数据库，瓶颈和问题就在数据库，解决问题的方法也在数据库端，类似GS这种服务端组件应该都是无可奈何的。

更好的GIS数据服务---空间数据库

总结：类似GS这种组件，在小数据时是没问题的，挺好用。在企业级应用尤其面向未来技术潮流的海量空间数据存储、分析、可视化等场景下，服务端的技术都会过时，即WebGIS的去服务化。