企业官网建设流程全解析

GeoServer 图层能显示，只是第一步。真正上线后，更容易出问题的是性能和权限。

常见问题：

地图一缩放就很慢。 WFS 一次返回太多数据导致浏览器卡死。 不同租户图层边界不清晰。 用户绕过前端直接访问 GeoServer URL。 数据更新后前端仍然显示旧瓦片。 GeoServer 管理接口暴露风险过高。

这篇文章整理 GeoServer 在生产业务系统中需要重点考虑的性能与权限设计。

一、性能问题先从链路看

一次普通 WMS 请求链路：

前端地图请求 GetMap -> GeoServer 解析图层、bbox、srs、style -> GeoServer 查询 PostGIS -> PostGIS 执行空间过滤 -> GeoServer 渲染 PNG -> 返回前端

慢可能慢在：

PostGIS 查询慢。 空间索引没走。 返回要素太多。 GeoServer 样式太复杂。 图片尺寸太大。 并发太高。 没有缓存。

所以不要只盯着 GeoServer，也要看数据库和前端请求方式。

二、PostGIS 索引是基础

空间表必须有 GiST 索引。

CREATEINDEXidx_biz_point_geomONbiz_schema.biz_pointUSINGGIST(geom);CREATEINDEXidx_biz_line_geomONbiz_schema.biz_lineUSINGGIST(geom);

常用过滤字段也要建普通索引：

CREATEINDEXidx_biz_point_codeONbiz_schema.biz_point(code);CREATEINDEXidx_biz_line_codeONbiz_schema.biz_line(code);CREATEINDEXidx_biz_point_classONbiz_schema.biz_point(classification_code);CREATEINDEXidx_biz_line_classONbiz_schema.biz_line(classification_code);CREATEINDEXidx_biz_point_statusONbiz_schema.biz_point(status);CREATEINDEXidx_biz_line_statusONbiz_schema.biz_line(status);

如果经常按区域、状态、类型组合过滤，可以结合实际 SQL 做组合索引。

检查 SQL 是否走索引：

EXPLAINANALYZESELECTidFROMbiz_schema.biz_lineWHEREST_Intersects(geom,ST_MakeEnvelope(500000,3300000,530000,3360000,4549));

三、控制 WFS 返回量

WFS 返回的是矢量要素数据，一次返回太多会拖垮前端。

建议前端请求 WFS 时带：

maxFeatures / count bbox CQL_FILTER propertyName srsName

例如：

service=WFS request=GetFeature typeName=example_ws:biz_points outputFormat=application/json srsName=EPSG:4326 maxFeatures=100 CQL_FILTER=status='normal'

不要这样做：

页面初始化直接加载全量几万条点线。 WFS 不加 bbox。 WFS 不限制字段。 把 WFS 当成列表分页接口。

业务查询和分页应优先走后端 API。

四、WMS 和 WMTS 的性能取舍

WMS：

实时渲染。 灵活。 适合调试和动态过滤。 数据更新后更容易看到最新结果。 高并发时压力较大。

WMTS：

瓦片化。 缓存友好。 适合稳定图层和高并发访问。 数据更新后要清缓存。 不适合大量动态过滤。

生产建议：

后台管理、编辑、调试： WMS。 稳定基础图层、大屏、常用底图： WMTS。 点选、高亮、编辑态： WFS 或后端 API + 前端矢量。

五、GeoWebCache 使用建议

GeoServer 通常集成 GeoWebCache，用于瓦片缓存。

适合缓存：

底图。 行政区划。 基础管网。 低频变化专题图。

谨慎缓存：

频繁编辑图层。 实时轨迹。 按用户权限变化的图层。 按 CQL_FILTER 高频变化的图层。

配置时关注：

Gridset： 是否和前端底图一致，例如 EPSG:3857。 Format： 透明业务图层优先 image/png。 Zoom levels： 只缓存业务实际会用的缩放级别。 Bounds： 只缓存业务区域，不要无意义缓存全球范围。

六、缓存失效策略

如果数据更新后不清缓存，前端可能继续看到旧瓦片。

建议：

数据导入成功后，清理相关图层缓存。 点线编辑成功后，清理受影响 bbox。 如果访问量大，再异步 seed 常用范围。

局部清缓存比全图清缓存更稳。

局部 bbox 可以来自：

更新前 geometry envelope。 更新后 geometry envelope。 两者合并后的 envelope。 额外扩一点 buffer，避免线宽和符号边缘漏清。

七、样式也会影响性能

GeoServer 样式越复杂，渲染压力越大。

可能影响性能的样式：

复杂规则过多。 按多个属性动态分类。 大量 label 标注。 线符号叠加多层 stroke。 高 zoom 下显示过多文字。

优化建议：

按缩放级别控制显示内容。 低 zoom 只显示主干或简化样式。 高 zoom 再显示细节和标注。 避免所有要素都显示文字。 复杂专题图考虑预计算字段。

八、多租户隔离怎么设计

常见多租户方案：

方案一：每个租户一个 schema。 方案二：所有租户共表，用 tenant_id 区分。 方案三：每个租户一个数据库。

如果使用 schema 隔离，GeoServer 可以这样设计：

一个租户一个 workspace。 一个租户一个 store。 每个租户发布同名图层。

例如：

tenant_a_ws:biz_points tenant_a_ws:biz_lines tenant_b_ws:biz_points tenant_b_ws:biz_lines

优点：

边界清楚。 权限容易配置。 排查时容易定位。 迁移时可以按租户处理。

缺点：

租户多时 GeoServer 配置数量增加。 需要自动化发布脚本。

如果所有租户共表，需要 GeoServer 层或数据库视图层做过滤，否则容易越权。

九、前端直连 GeoServer 的风险

前端直连 GeoServer 很方便，但要注意：

用户可以在浏览器开发者工具里看到 GeoServer URL。 用户可能直接改 CQL_FILTER。 WFS 可能暴露原始属性字段。 GeoServer 不一定识别业务系统 token。 不同租户图层可能被枚举。

所以正式系统要明确：

哪些 WMS/WMTS 可以公开。 哪些 WFS 禁止公开。 哪些字段不能暴露。 GeoServer 是否必须经过网关。 GeoServer 管理后台是否只允许内网访问。

十、权限控制策略

可选策略：

1. GeoServer 自身安全配置。 2. Nginx / 网关代理。 3. 后端 API 代理。 4. 数据库视图隔离。 5. 不开放 WFS，只开放后端查询接口。

一般建议：

WMS/WMTS： 可以通过网关代理，结合登录态控制访问。 WFS： 谨慎开放，敏感系统尽量走后端 API。 GeoServer REST 管理接口： 只允许内网或 CI/CD 访问。 GeoServer 管理后台： 禁止公网暴露。

如果需要字段级控制，可以考虑：

发布数据库视图，而不是直接发布原表。 视图中去掉敏感字段。 不同角色发布不同图层。 复杂权限走后端接口。

十一、数据库视图发布图层

有些场景不建议直接发布原表。

例如：

原表字段太多。 有敏感字段。 需要字段改名。 需要过滤无效数据。 需要统一坐标输出字段。

可以创建视图：

CREATEVIEWbiz_schema.v_public_linesASSELECTid,code,type,status,geomFROMbiz_schema.biz_lineWHEREstatus<>'deleted';

然后 GeoServer 发布：

v_public_lines

好处：

减少字段暴露。 统一图层口径。 降低前端理解成本。

注意：

视图性能也要检查。 复杂视图可能影响 WMS 渲染。 必要时使用物化视图。

十二、生产环境排查 checklist

地图慢时，按顺序查：

1. 前端请求的是 WMS、WMTS 还是 WFS。 2. WFS 是否一次返回太多数据。 3. WMS bbox 是否过大。 4. 图片 width/height 是否过大。 5. PostGIS geom 是否有空间索引。 6. SQL 是否走索引。 7. GeoServer 样式是否过重。 8. 是否开启 GeoWebCache。 9. 缓存 gridset 是否和前端一致。 10. 是否有大量动态 CQL_FILTER 导致缓存失效。

权限异常时，按顺序查：

1. GeoServer 是否被公网直接访问。 2. WFS 是否开放。 3. 图层是否跨租户可访问。 4. 字段是否暴露过多。 5. 网关是否校验登录态。 6. GeoServer REST API 是否暴露。 7. 管理账号是否弱口令或共享过多。

十三、推荐生产架构

比较稳的架构：

前端地图 -> 业务网关 / Nginx -> GeoServer WMS/WMTS -> PostGIS 前端业务操作 -> 后端 API -> PostGIS / 业务库 CI/CD 或管理服务 -> GeoServer REST API

并且：

GeoServer 管理后台不公网开放。 GeoServer REST API 不给普通前端调用。 WFS 谨慎暴露。 业务详情和统计走后端。 缓存刷新由后端或运维脚本触发。

十四、总结

GeoServer 生产化要重点关注两条线：

性能线： PostGIS 索引、WMS/WMTS 选择、GeoWebCache、样式优化、WFS 限流。 权限线： 租户隔离、字段暴露、WFS 控制、网关代理、管理接口保护。

地图能显示只是开始。只有性能和权限设计到位，GeoServer 才能稳定支撑业务系统长期运行。