聊聊GeoServer的JMS集群部署。这个方案我在生产环境里前前后后折腾了小半年从最初两台机器照着网上的碎片教程硬凑到现在基本上小半天能搭出一套可用的多节点环境中间踩过的坑值得写下来。GeoServer是开源GIS服务器里用得最多的那一个但默认安装形态是标准的单机模式一个数据目录一个Tomcat实例配置以XML文件落在本地瓦片缓存也只在当前节点自己手里。流量上来之后单点问题很快就暴露出来这就需要做集群。而GeoServer的集群方案里JMS集群属于比较正统、也比较推荐的一种通过ActiveMQ事件总线把配置变更广播到所有节点再用数据库统一保存配置让每个节点对外提供一致的视图。这篇文章主要面向需要把GeoServer部署成高可用、多节点服务的运维和开发同学最好你已经能独立装好一个单机GeoServer再来看这套东西会顺畅很多。1. 部署链路拆解为什么JMS集群能解决同步问题1.1 单机数据目录的天然短板GeoServer默认把全局配置、工作区、样式、图层发布信息全部写到data_dir目录下的XML文件里。单机运行没问题但一旦复制出第二个实例麻烦就来了你在节点A上新建了一个样式节点B根本不知道除非你把整个数据目录手动拷一遍然后重启节点B。有人会说那把同一个数据目录放到NFS共享盘上让两个节点都指向它不就行了我最早也是这么干的结果遇到的问题比想象的更难受。GeoServer在运行时会对配置文件做本地缓存两个进程同时读同一份XML一个改了另一个不会立刻感知必须手动刷新。更关键的是GeoWebCache也就是瓦片缓存模块会用文件锁来管理磁盘缓存两个节点抢同一个锁文件轻则警告刷屏重则缓存直接写坏。所以共享数据目录这条路看起来很省事做下去全是坑。1.2 JMS集群的工作机制JMS集群的思路是把配置信息的“存储”和“通知”拆开处理。存储层面通过jdbcconfig插件把配置存进PostgreSQL这类关系型数据库。所有节点连同一个库读取到的Catalog就是一致的这一步解决了“配置文件各管各”的问题。但光有数据库还不够因为节点A改了配置之后节点B的内存里可能还是旧版本总不能每次都重启或手动Reload。于是就需要另一个机制来推送变更消息这就是JMS要做的事。JMS集群插件在每个GeoServer节点上挂了一个消息发布订阅客户端。当前节点做出版图、改样式、加存储等操作时插件会把变更事件序列化成消息发到ActiveMQ指定的Topic上其他节点订阅了同一个Topic收到消息后自动更新本地内存里的Catalog和缓存。整个过程对使用者是透明的管理员在节点A上发布一个图层过一两秒节点B不用做任何操作就能提供这个图层了。1.3 架构组成与关键角色一个标准的GeoServer JMS集群参与角色有这几类。角色技术选型作用配置存储PostgreSQL jdbcconfig插件统一保存GeoServer配置避免数据目录文件漂移消息总线ActiveMQ广播配置变更事件驱动各节点缓存刷新GeoServer节点多台Tomcat实例各自独立数据目录对外提供WMS/WMTS/WFS服务负载均衡Nginx / HAProxy流量分发摘除故障节点这里需要注意每个GeoServer节点的数据目录依然存在但它的职责从“保存配置”变成了“保存运行时所需的临时文件、日志、以及各节点自定义的环境差异”。配置主体放在数据库里本地XML不再是唯一事实来源。JMS负责的是把数据库中的变更“翻译”成各节点缓存刷新的动作。消息总线缺失的情况下集群只能靠数据库保证配置一致但运行时缓存没法实时同步算不上真正的集群。2. 环境准备与基础规划2.1 版本与依赖选型GeoServer的集群插件版本必须和你使用的GeoServer主版本严格对应这一点极其重要。我见过太多只是主版本差一个小版本结果消息反序列化直接报错节点之间静默不同步的情况。下面这套组合是我目前用得比较稳的搭配操作系统CentOS 7.9 或 Ubuntu 20.04 均可JavaOpenJDK 8 或 11中间件Tomcat 9GeoServer2.22.x用war包部署集群插件jms-cluster与GeoServer主版本匹配、jdbcconfig插件、PostgreSQL JDBC驱动消息中间件ActiveMQ 5.16.x数据库PostgreSQL 14 PostGIS 扩展负载均衡Nginx 1.18。版本匹配没法偷懒下载插件时一定要看清对应的GeoServer版本号。jms-cluster插件包解压后把里面的jar文件放进geoserver/WEB-INF/lib目录。jdbcconfig插件也一样。另外PostgreSQL JDBC驱动版本要和数据库大版本兼容选postgresql-42.x.x.jar这类新版本一般没问题。2.2 目录与实例规划我先按两台节点来规划后面要横向扩展再加节点也很容易。节点名IP地址GeoServer数据目录GWC磁盘缓存目录gis-node110.0.0.11/opt/geoserver/data_dir/opt/geoserver/gwc_cachegis-node210.0.0.12/opt/geoserver/data_dir/opt/geoserver/gwc_cache这里有一个关键点两台的目录路径可以设计成一样的但不要把GWC缓存目录指向同一个共享磁盘。每个节点保留自己的磁盘缓存缓存内容由JMS消息驱动去失效和重建这样避免并发写同一个缓存文件的锁冲突。数据目录初始内容需要保持完全相同建议你先在单机环境下把工作区、图层、样式、服务设置全部配好确认数据目录中没有残留测试垃圾再拷贝到两台机器上。2.3 数据库初始化在PostgreSQL里先建好库和账号SQL如下CREATE USER geoserver WITH PASSWORD geoserver_prod_pwd; CREATE DATABASE geoserver_cluster OWNER geoserver ENCODING UTF8;切换进新库启用PostGIS扩展\c geoserver_cluster CREATE EXTENSION IF NOT EXISTS postgis;强调一下jdbcconfig插件本身并不强制依赖PostGIS它需要的只是PostgreSQL的基础表结构。但既然GeoServer后面要发布空间数据PostGIS迟早要用不如建库时直接装上。字符集必须用UTF8否则配置里有中文注记或者图层名带中文时容易踩编码坑。3. 配置存储迁移与消息中枢搭建3.1 准备GeoServer应用目录用Tomcat部署war包的方式创建应用目录mkdir -p /data/tomcat9/webapps/geoserver unzip geoserver-${version}-war.zip -d /data/tomcat9/webapps/geoserver把jms-cluster、jdbcconfig两个插件里的jar和PostgreSQL JDBC驱动复制到cp /download/jms-cluster/lib/*.jar /data/tomcat9/webapps/geoserver/WEB-INF/lib/ cp /download/jdbcconfig/lib/*.jar /data/tomcat9/webapps/geoserver/WEB-INF/lib/ cp /download/postgresql-jdbc.jar /data/tomcat9/webapps/geoserver/WEB-INF/lib/如果解压出来的插件包里有目录结构比如ext目录或者lib目录看清楚再拷。我一开始图省事把整个解压目录直接扔进去结果多了一些版本不兼容的依赖jar启动直接报错。3.2 配置jdbcconfig连接串在数据目录下新建jdbcconfig.properties文件内容示例如下jdbcconfig.enabledtrue jdbcconfig.initdbtrue jdbcconfig.jdbc.driverorg.postgresql.Driver jdbcconfig.jdbc.urljdbc:postgresql://10.0.0.10:5432/geoserver_cluster jdbcconfig.jdbc.usernamegeoserver jdbcconfig.jdbc.passwordgeoserver_prod_pwd jdbcconfig.jdbc.maxActiveConnections20这个文件是配置存储是否切到数据库的总开关。jdbcconfig.initdbtrue表示启动过程中检测到数据库里没有GeoServer相关配置表时自动建表。如果你是在已有数据目录的情况下首次切换数据库插件会把当前目录下的XML配置内容导入到数据库后续的配置事实以数据库为准。有一点必须提醒启用jdbcconfig之后原本数据目录里的workspaces、styles这些XML文件不会再作为配置主源被实时读写。你不能再拿“目录下有没有这个文件”来判断配置是否存在。很多同学刚切完数据库发现目录里没生成预期文件就以为是同步失败实际上通过REST接口或者管理界面去查数据已经在了。3.3 启动ActiveMQ消息总线ActiveMQ可以先单独跑在一台机器上我用的是docker方式方便快速拉起docker run -d \ --name activemq \ -p 61616:61616 \ -p 8161:8161 \ -v /opt/activemq/data:/data \ webcenter/activemq:5.16.38161是ActiveMQ自带的Web管理控制台端口61616是OpenWire消息端口。生产环境不建议随随便便把8161暴露到公网一般内网访问或者直接不给外部开放。刚开始测试时有人为了省事会把embedded.brokerenabled打开让GeoServer内嵌一个ActiveMQ实例。我不建议你这么干尤其多节点环境。内嵌broker和GeoServer进程绑死节点一旦宕机消息通道直接断掉其他节点也就收不到事件了。单独跑ActiveMQ至少还能先把消息队列保住后续做ActiveMQ高可用时也更方便。3.4 配置GeoServer JMS连接参数在数据目录下创建cluster目录并新建geoserver-jms-cluster.propertiesbrokerURLtcp://10.0.0.10:61616?jms.useAsyncSendtrue embedded.brokerdisabled connection.retry.count5 connection.timeout30000 topicNameVirtualTopic.geoserver serializerstring GWC.enabledtrue GWC.clusterIdmy-gis-cluster instanceNamenode1两个关键参数我再解释一下brokerURL是GeoServer连接ActiveMQ的地址。我用的是单点ActiveMQ地址如果你后续要把ActiveMQ也做成高可用可以改成failover:tcp://10.0.0.10:61616,tcp://10.0.0.11:61616这种形式客户端会自动切换。instanceName是节点标识两个节点必须设置成不同值用于区分消息来源。我用的是node1和node2。GWC.enabledtrue是启动GeoWebCache集群同步的开关。没有这个样式和图层配置都同步了但瓦片缓存还是各自为政用户访问同一个图层可能一会儿命中A节点旧瓦片一会儿命中B节点新瓦片视觉上就会出现“缓存抖动”。3.5 首次启动验证先启动ActiveMQ再启动第一个GeoServer节点。启动脚本里Tomcat的JAVA_OPTS至少要设置数据目录export JAVA_OPTS-DGEOSERVER_DATA_DIR/opt/geoserver/data_dir启动后一定去看logs/geoserver.log重点确认两件事。第一jdbcconfig是否连上了数据库并完成建表/导入第二jms-cluster是否成功连接ActiveMQ并注册了消费者。正常日志里会看到类似“JMS Producer/Consumer started”的信息。如果日志里报ClassNotFoundException先检查插件jar是否完整、是否有重复依赖。这一步卡住的话后面所有同步都是空谈。4. 核心环节实操与多节点验证4.1 第二节点差异化配置第一节点跑通之后把整个数据目录拷贝到第二台机器上rsync -av /opt/geoserver/data_dir/ 10.0.0.12:/opt/geoserver/data_dir/然后到第二台机器上修改cluster/geoserver-jms-cluster.properties里的instanceNamenode2。这一条如果你的两台节点在同一套共享目录下部署差异会更多但我们现在是独立目录所以只需要改这个标识。第二个节点的Tomcat启动参数同样设置数据目录指向/opt/geoserver/data_dir。数据库连接串不用改因为jdbcconfig文件里已经写了同一个PostgreSQL地址两个节点自然共用同一个配置库。4.2 用REST接口验证配置同步在节点A上创建一个测试工作区curl -u admin:geoserver -XPOST \ -H Content-type: text/xml \ -d workspacenamecluster_demo/name/workspace \ http://10.0.0.11:8080/geoserver/rest/workspaces然后立刻到节点B上查询curl -u admin:geoserver http://10.0.0.12:8080/geoserver/rest/workspaces.xml正常情况下cluster_demo工作区会出现在列表里。这一步通过说明JMS事件已经成功从A广播到B并且B节点主动刷新了Catalog。如果在节点B上查不到不要急着怀疑消息总线。先检查ActiveMQ管理控制台里面是否有两个消费者订阅同一个Topic。如果只有一个消费者在线说明第二个节点没有成功订阅很大概率是geoserver-jms-cluster.properties里某个配置写错或者插件jar没有加载成功。再检查节点B的日志看有没有报连接ActiveMQ失败的信息。4.3 GeoWebCache缓存目录的独立与锁配置GeoWebCache默认磁盘缓存路径在数据目录下的gwc文件夹。两台节点如果各自独立目录默认路径就是独立的不会冲突。但有一种情况容易出现意外你把GWC磁盘缓存手动指定到了共享存储上想省磁盘空间。这时候就必须在GWC的配置里解决锁冲突问题。在每个节点的gwc/geowebcache.xml中看一下锁相关的配置建议使用内存锁lockProvider classNameorg.geowebcache.locks.ConcurrentLockProvider/这行配置的含义是节点内部用内存锁来控制并发不依赖外部文件锁。每个节点只锁自己的进程跨节点由JMS事件来协调缓存失效不会出现两个节点抢同一个锁文件的局面。如果你的缓存目录真的放在共享盘上这步不做的话第二天就会收到大量缓存写入失败报警。4.4 接入Nginx负载均衡前面这些做完GeoServer层已经具备集群条件了。对外统一入口再套一层NginxNginx配置可以这样写upstream geoserver_cluster { server 10.0.0.11:8080 max_fails3 fail_timeout30s; server 10.0.0.12:8080 max_fails3 fail_timeout30s; } server { listen 80; server_name gis.example.local; location /geoserver/ { proxy_pass http://geoserver_cluster/geoserver/; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_read_timeout 300s; proxy_send_timeout 300s; } }这里我没有开ip_hash因为GeoServer的WMS/WFS接口本身是无状态服务请求分给哪个节点都行。但如果你的业务用到了GeoServer的登录态管理或者后续接了OIDC单点登录就需要考虑会话保持最简单的方式是打开Nginx的ip_hash。管理界面建议只允许从一个固定入口访问不要把admin登录暴露在负载均衡后面两个管理员同时在A节点和B节点改配置很容易出现最后写入的一方覆盖前一方的情况。5. 常见问题与排查实例5.1 节点A改了样式节点B页面没有变化这是最常遇到的现象。第一步先等几秒因为JMS消息是异步的确实存在毫秒级到秒级的延迟。排除这个因素后就要看B节点日志。日志里如果没有任何消息消费记录去ActiveMQ管理台看消费者数量。还有个容易被忽略的坑浏览器或GeoWebCache把旧瓦片缓存住了。样式变更后GWC检测到配置变化理论上会触发对应瓦片失效重建但如果你之前的GWC集群同步开关没有打开旧瓦片会一直存在。遇到这种问题直接清掉该节点gwc目录下对应图层缓存再重试基本能定位是消息问题还是缓存问题。5.2 升级GeoServer后节点之间静默不同步升级的时候插件jar必须和GeoServer主版本一起匹配。比如从2.21升到2.22jms-cluster和jdbcconfig插件也要换到对应2.22版本。否则最容易看到的就是两个节点都能启动但发送的消息格式对不上反序列化报错被吞掉或者某个节点直接拒绝消费。我自己处理过一个真实案例升级后忘了换jdbcconfig插件节点B启动时去连数据库发现schema版本比插件期待的旧数据库迁移一直报错结果整个节点配置存储都挂了看起来好像还在服务但所有配置变更都写不进库。排查到最后才发现是插件版本不同步。5.3 数据库连接池耗尽导致节点假死当节点数量增加后每个节点都会向PostgreSQL发起连接池请求。jdbcconfig里如果maxActiveConnections设置得太小高并发访问时会出现数据库连接等待节点表现就是能响应但不干活。我建议至少设置20如果节点超过4台可以再进一步调大。同时给PostgreSQL的max_connections留好余量别让GeoServer把数据库连接池打满。5.4 常见问题速查表现象可能原因排查方法处理建议配置修改后其他节点不生效JMS消费失败、Topic订阅缺失查看ActiveMQ控制台消费者数、节点日志确认jms-cluster配置和插件jar完整节点反复断连ActiveMQ网络不稳定、broker负载过高查看ActiveMQ日志、节点心跳连接日志开启failover连接串、增加connection.retry.count数据库写入报错插件版本不匹配、schema版本落后查看启动日志中的jdbcconfig初始化记录同步升级插件、清理无效schema瓦片新旧交替GWC集群同步未开启检查geoserver-jms-cluster.properties中GWC.enabled开启GWC.enabled并配置GWC.clusterId管理界面登录后很快失效Nginx负载均衡未做会话保持检查cookie与后端节点访问情况打开ip_hash或启用会话粘滞ActiveMQ消息堆积消费者线程阻塞、某节点离线查看队列深度、消费者连接状态优先检查离线节点再调整消费并发参数5.5 避坑心得集群里的配置变更操作我强烈建议固定在一个管理节点上完成。比如约定好只有节点A能做样式修改、图层发布节点B只承担对外服务。JMS事件本身不能保证多写场景下的一致性两台机器同时改同一个样式最后到底是谁覆盖谁完全看消息到达顺序这并不受业务控制。约定单一管理入口能规避绝大多数配置覆盖问题。另外一个经验是上线前一定做一次断连演练。把某个节点从网络上断开观察负载均衡是否把它摘掉再重新接回来看看JMS客户端能否自动恢复连接并继续消费积压消息。ActiveMQ的自动重连机制在有网络抖动时大概率能自己恢复但如果你用的是嵌入式broker断连之后想恢复就只能重启节点差距非常明显。6. 影响范围与运维建议6.1 集群化带来的能力提升使用JMS集群后最直接的收益就是高可用。Nginx后面挂两个节点其中一个宕机另一个继续服务配置数据因为都落在同一个PostgreSQL里不会少一份配置。扩容也变得简单拷贝数据目录、改instanceName、启动Tomcat、挂到Nginx上游四个步骤就能加一台节点。我在一次压测里把节点从2台扩到4台WMS出图能力接近线性增长当然前提是CPU和数据库瓶颈没有被同时打满。滚动升级也顺手了很多。以前单机版升级GeoServer业务必须停。现在可以把节点先从Nginx上游摘掉升级完成后再加回来一台一台滚整个升级过程对调用方无损。6.2 引入的新运维成本但集群不是只有好处。配置存储从本地文件变成数据库意味着PostgreSQL本身成了强依赖。数据库挂了整个GIS集群就全部不可用这和以前单机只有一块磁盘故障是不同量级的事。所以数据库必须另外做高可用和备份推荐至少一主一从加定期全量备份。ActiveMQ也有运维成本。虽然消息体很小但Topic的消费者状态、队列深度、Broker内存都需要监控。消费者离线期间发布的消息默认根据Topic非持久化策略可能直接丢弃节点重启回来后并不会通过重放历史消息来补同步它只能依赖下一次配置变更事件来刷新。这就要求节点在线率必须高或者你去改Topic的持久化策略但这又牵扯到消息积压清理复杂度会上升。6.3 什么情况下不要硬上JMS集群如果业务系统只有一台GeoServer并且维护窗口可以接受不要为了集群而集群。JMS集群至少带来ActiveMQ和PostgreSQL两个额外依赖光维护成本就比单机高出一截。如果只有一个节点老老实实用单机加冷备就行别给自己找事。还有一种情况是系统对配置一致性的实时性要求特别高比如两个管理员需要在毫秒级看到彼此的修改而且修改频率非常高。JMS的异步特性决定了它只能做到最终一致节点间存在短暂的不一致窗口。这种情况下你需要考虑的不是JMS集群而是业务层设计上的配置审批和协调机制。7. 写在最后的一些实操体会最后分享一条我自己的经验这套集群的配置本身并不复杂复杂的是把它当作一个整体来运维。由于消息总线是异步的节点之间的状态不会在某一刻严格保持一致设计机制时不要追求每个节点的实时完全同步只要能满足业务上的最终一致服务不断流就已经达到生产环境的质量要求。还有升级顺序我踩过一次实实在在的亏。正确顺序应该是先升级ActiveMQ依赖和数据库驱动再升级jdbcconfig和jms-cluster插件最后升级GeoServer主程序。顺序一旦颠倒可能出现旧插件链接到新数据库schema的情况启动时不报错后面运行越跑越偏。如果这篇文章能帮你少踩几个坑那就很值了。如果你也准备动手搭GeoServer集群建议先在小规模环境里把消息同步跑通再逐步加节点别一上来就铺四台五台。集群这东西节点越多对网络和中间件的复杂度要求越高一步一个脚印最稳妥。