手里如果有 Apache Apollo 还在 Windows 上跑着的朋友应该能懂那种感觉系统不更新没事一更新就担心 broker 起不来内存占用像漏水一样天天得盯着。公司有个老项目就是用 Apollo 做消息总线Windows Server 上稳定跑了好几年直到一次补丁重启后服务卡在启动阶段消息积压了几十万条业务方半夜找过来才真正动了迁移的念头。这篇不是什么高深的理论文章就是我完整走了一遍从 Windows 迁移到 Linux 服务器的实际操作记录包括配置和数据怎么搬、踩了哪些坑、怎么验证迁移成功、失败了怎么回滚。适合那种手里有老 Apollo 项目、准备迁移到 Linux 又不知道从哪下手的运维或开发同学参考。如果你只是临时搭个环境测试这篇也能帮你省不少弯路。1. 为什么非迁不可Windows 上长期运行 Apollo 的真实处境1.1 Apollo 到底是做什么的Apache Apollo 是 ActiveMQ 的下一代消息代理市面上的定位是更快、更容易配置的替代品。它支持 STOMP、AMQP、MQTT 等多协议接入自带 Web 管理控制台消息持久化做得也不错。很多老项目当年选它就是因为配置比 ActiveMQ 简单功能又够用几个命令就能拉起一个 broker。但要注意一个背景Apollo 官方已经停止更新社区活跃度很低了。这意味着它不会像新中间件那样持续修 bug选择它本身就是一种稳定优先的取舍。1.2 在 Windows 上跑 Apollo麻烦是慢慢攒出来的Apollo 在 Windows 上可以跑而且跑得也不算差但长期运维会碰到几个绕不开的问题内存占用越来越不透明。JVM 进程长时间运行堆外内存和 GC 状态不直观Windows 任务管理器只能看到整体占用很难定位是堆的问题还是线程的问题。服务自动重启不可靠。用 Windows 服务方式注册后如果 broker 异常退出默认并不会自愈需要手工登录远程桌面重启非常被动。远程维护体验差。RDP 慢、安全补丁重启频繁、安全策略收紧后端口管控麻烦。对运维来说一台 Windows 服务器往往比 Linux 服务器更让人头疼。许可与合规压力。Windows Server 需要正版授权如果只是为跑一个轻量级消息中间件这个成本并不划算。1.3 迁到 Linux 之后运维体验是质变Linux 上同样跑 Apollo至少这几件事会舒服很多可以用 systemd 托管服务崩溃自动拉起、开机自启、日志统一交给 journald。SSH 远程维护比 RDP 轻量太多随时随地能查端口和进程状态。内存占用可以精确到进程内 JVM 层面去排查配合jstat、jmap这些工具问题定位效率完全不一样。不依赖 GUI占用的系统资源更少旧服务器也能继续发光发热。当然也得说明白并非所有场景都必须迁。如果你那套 Apollo 只是内网测试环境数据丢了也无所谓那折腾迁移确实性价比不高。但如果是生产环境、半年一年都不用动的那种趁早迁比出事故后再迁要稳妥得多。2. 动工之前先把这几样东西摸透迁移最忌讳的不是学不会操作而是对现状一知半解就动手。我先花了一天时间把旧的 Windows broker 从头到尾盘了一遍下面这几项是必须提前确认的。2.1 版本核对跨版本迁移要谨慎登录旧服务器在 Apollo 安装目录下找到版本信息比如lib/apollo-1.7.1.jar或者运行命令查看。版本确认的意义在于老版本 Apollo 的持久化文件格式与新版不一定完全兼容跨大版本直接复制数据目录容易踩坑。如果目标 Linux 端用的是同一个大版本数据迁移才能做到无痛。补丁版本不一致也有风险比如 1.7.0 到 1.7.1虽然大概率没问题但稳妥起见最好保持新旧两侧版本完全一致。我的做法是新服务器下载同一个版本的 tar.gz不做任何升级先保证迁移成功后续要升级再说。2.2 数据目录与配置目录盘点Apollo 的实例目录结构很清晰迁移前要搞清楚每一部分的作用。我列一下常见的结构etc/配置目录。apollo.xml是核心配置包括连接器端口、虚拟主机、存储策略users.properties存用户认证信息groups.properties存用户组权限。data/运行时数据目录。store/保存持久化消息数据tmp/是运行时临时文件。log/日志目录排错时最常用。bin/启动脚本与命令行工具。这次迁移里配置和消息数据都要完整搬走日志和历史不需要。2.3 连接方与端口清单在真正停机前我盘了一遍所有客户端有多少个业务系统在连这个 broker用的协议是 STOMP、MQTT 还是 OpenWire端口是默认值还是改过客户端配置里写的是 IP 还是主机名这一步非常关键。因为迁移后 Linux 服务器的 IP 几乎肯定会变所有客户端都要改连接地址。如果客户端是写死的 IP就需要提前出方案改配置、改 DNS 或做端口映射总得选一个。2.4 迁移窗口不是想做就做Apollo 迁移需要停机窗口因为要把旧 broker 停下来复制数据目录避免数据还在写入时复制导致文件不一致。我选的是业务低峰期的凌晨在窗口内完成了备份、停服、复制、启动和验证全套流程。窗口时长建议至少预留两小时别压缩到半小时因为你不知道复制数据和验证过程中会碰到什么问题。3. 核心迁移流程从 Windows 到 Linux 的完整操作确认完现状后就可以开始实操了。这里我按顺序拆开讲每一步都能落地的命令和说明。3.1 在 Linux 端准备 JDK 环境Apollo 是 Java 应用环境先搞定。我用的发行版是 CentOS装的是 OpenJDK 8。Apollo 1.7.x 对 JDK 8 支持最稳不建议上来就装 JDK 17 或更高版本新 JDK 的模块化限制有可能会出兼容性问题。安装步骤如下# 查找 JDK 8 包 yum search openjdk | grep 1.8 # 安装 yum install -y java-1.8.0-openjdk-devel # 验证 java -version输出类似这样就算成功openjdk version 1.8.0_xxx OpenJDK Runtime Environment (...) OpenJDK 64-Bit Server VM (...)安装完后确认JAVA_HOME因为后面启动脚本要用到echo $JAVA_HOME如果为空就把以下内容写到/etc/profile.d/java.shexport JAVA_HOME/usr/lib/jvm/java-1.8.0-openjdk export PATH$PATH:$JAVA_HOME/bin然后source /etc/profile.d/java.sh使其生效。3.2 下载并部署 Apollo 本体从 Apache 归档仓库下载与 Windows 端一致版本的 Apollo 发行包放到/opt下解压cd /opt wget https://archive.apache.org/dist/activemq/activemq-apollo/1.7.1/apache-apollo-1.7.1-unix.tar.gz tar -zxvf apache-apollo-1.7.1-unix.tar.gz解压后会生成apache-apollo-1.7.1目录。这其实是 Apollo 的安装主目录接下来要用它创建 broker 实例。3.3 创建 broker 实例Apollo 的运行单元是实例不是简单的解压目录。创建实例用apollo create/opt/apache-apollo-1.7.1/bin/apollo create /opt/mybroker执行完成后/opt/mybroker目录会自动生成bin、etc、data、log、tmp这些子目录说明实例创建成功。很多新手会困惑为什么不用apache-apollo-1.7.1目录直接启动非要再 create 一份。原因是 Apollo 把程序文件和实例数据分开了升级程序不影响业务数据管理上更干净。3.4 迁移配置复制并修改关键配置文件创建完新实例后把 Windows 端etc/下的几个文件复制到 Linux 实例目录覆盖。复制前一定要先看一遍内容重点检查有没有 Windows 路径。# Windows 端执行假设 C 盘是安装路径 copy C:\apollo-instance\etc\apollo.xml \\linux-ip\upload\apollo.xml copy C:\apollo-instance\etc\users.properties \\linux-ip\upload\users.properties copy C:\apollo-instance\etc\groups.properties \\linux-ip\upload\groups.properties然后在 Linux 端执行覆盖cp /upload/apollo.xml /opt/mybroker/etc/ cp /upload/users.properties /opt/mybroker/etc/ cp /upload/groups.properties /opt/mybroker/etc/打开apollo.xml重点检查以下几点连接器端口新旧配置的端口是否一致如果目标 Linux 上端口被占用需要改掉。虚拟主机配置virtual-host里的 store 类型、路径配置是否都是相对路径。如果是绝对路径且指向 Windows 盘符如C:\data\store要改成 Linux 路径。认证配置确认用户级别和权限设置与旧环境保持一致。覆盖完成后统一处理一下换行符问题防止从 Windows 复制过来的文件带了\r\n。用dos2unix处理最省事yum install -y dos2unix dos2unix /opt/mybroker/etc/*这一步不做后续启动时日志输出可能会出现奇怪的字符某些解析逻辑会直接报错。3.5 迁移消息数据先停旧服务再复制这是整个迁移最核心、也最需要耐心的一步。消息数据在data/目录下里面是 LevelDB 或其他存储引擎格式的文件不是文本绝不能手工改。先停止 Windows 端 broker 服务确保不再有消息写入net stop Apollo确认进程退出后再复制data目录。我建议先把整个data目录打成压缩包再传输到 Linux这样比直接复制成千上万个零散小文件快得多# Windows 端cmd cd C:\apollo-instance tar -czf data_backup.tar.gz data然后上传到 Linux 端解压cd /opt/mybroker tar -xzf /upload/data_backup.tar.gz解压完成后检查目录归属和权限chown -R root:root /opt/mybroker/data这里我用的是 root 用户操作后面章节会专门说为什么生产环境不建议这样做以及如何用独立用户运行。3.6 启动 broker 并登录管理台先以前台方式启动方便直接看日志/opt/mybroker/bin/apollo-broker run日志正常输出、且看到类似Apollo Broker ... is now active的信息后按CtrlC停掉再改成后台方式确认/opt/mybroker/bin/apollo-broker start启动完检查端口是否在监听ss -lntp | grep 61613再用管理台验证一下默认地址是http://linux-ip:61680用users.properties里的账号密码登录若能看到虚拟主机和队列状态都正常基础迁移就完成了。如果你在apollo.xml里改过配置端口访问时换成自己的配置端口即可。4. 避坑手册之一路径、权限、端口与防火墙4.1 Windows 路径残留最容易忽略的隐形炸弹复制配置文件时最容易漏掉的就是藏在注释或者深层标签里的 Windows 绝对路径。比如apollo.xml里如果显式配置了 store 目录写成C:\apollo-instance\data\store到了 Linux 上这个路径既不存在也不合法broker 启动时要么报错要么创建出一堆以C:开头的诡异目录。另外还要提一下换行符的坑。Windows 文件是 CRLF 结尾Linux 是 LF。直接把 Windows 配置文件复制到 Linux很多程序能容忍但 Apollo 在解析 XML 时如果遇到异常字符可能报ParseError。我的习惯是复制完后对etc/下所有文件统一跑一遍dos2unix。4.2 权限配置大量生产事故的元凶很多人刚上手时为了方便直接用 root 启动 broker。这样短期没什么感觉但 JVM 进程挂掉后如果数据文件被 root 写了一遍后续切换普通用户启动可能因为权限不足直接启动失败。更麻烦的是一旦 broker 被攻破root 权限会让风险成倍放大。正确的姿势是创建一个专用系统用户useradd -r -s /sbin/nologin apollo chown -R apollo:apollo /opt/mybroker然后切换到该用户启动服务或者通过 systemd 指定Userapollo。这样既安全又不会污染系统其他目录。4.3 端口与防火墙起服务不等于能连上很多人在服务器本地明明看到端口监听了客户端却连不上十有八九是防火墙没放行。CentOS 7 以上默认用的是 firewalld操作如下# 放行 STOMP 默认端口 firewall-cmd --permanent --add-port61613/tcp # 放行管理台端口 firewall-cmd --permanent --add-port61680/tcp # 重载防火墙规则 firewall-cmd --reload如果你用的是云服务器还要检查安全组规则在控制台里放行相应端口。这一步最容易被忽略。我在迁移时就是先站在原地netstat看半天然后在另一台机器上telnet不通查了十分钟才发现是云安全组没加白名单。4.4 新环境端口冲突Linux 服务器通常不止跑一个服务Apollo 默认端口可能被其他程序占用。启动前先检查ss -lntp | grep 61613如果被占用有两个选择杀掉占用进程前提是确认可以停或者改 Apollo 的监听端口。改端口并不难在apollo.xml里找到对应 connector 的port属性改掉就行但别忘了客户端那边也要同步改连接地址。5. 避坑手册之二内存、自启动、跨版本与时间同步5.1 JVM 内存配置别让 broker 死在 OOM 上迁移完成后 broker 起来了接着要处理的是稳定性问题。在高负载场景下Apollo 的 JVM 如果内存参数设置不合理很容易触发 OOM。Apollo 实例的启动参数在实例目录的bin/apollo-env.sh中。默认参数比较保守如果你的生产环境消息量很大建议提前手动设置。我的参考配置是JAVA_MEM-Xms512m -Xmx1024m MAX_MEM-XX:MaxMetaspaceSize256m怎么理解这个配置-Xms是 JVM 启动时分配的初始堆内存-Xmx是最大堆内存。两者设成一样的值可以避免运行期间频繁扩容和收缩带来的性能抖动。如果机器内存够也可以直接给个 2GB 上限但关键是不要让-Xmx超过物理内存否则系统会疯狂 swap表现比 OOM 还难受。改完后重启 broker再观察jstat -gc pid输出的 GC 情况确认没有频繁 Full GC 和内存泄漏迹象。5.2 systemd 自启动没有它迁移等于白做Windows 下的服务可以用服务管理器 自动恢复来兜底Linux 上你自然也会想配开机自启。很多教程会推荐用apollo-broker-service install来注册成服务原理是基于 Java Service Wrapper这东西本身也能用。但我个人更倾向于 systemd原因是它和操作系统集成度更高崩溃重启、日志收集都可以统一配置。在/etc/systemd/system/apollo-broker.service里这样写[Unit] DescriptionApache Apollo Broker Afternetwork.target [Service] Typesimple Userapollo Groupapollo WorkingDirectory/opt/mybroker ExecStart/opt/mybroker/bin/apollo-broker run Restarton-failure RestartSec5 LimitNOFILE65536 [Install] WantedBymulti-user.target启用并启动systemctl daemon-reload systemctl enable apollo-broker systemctl start apollo-broker systemctl status apollo-broker这里要注意ExecStart用的是run参数让 broker 在前台运行systemd 才能接管它的生命周期。如果你写成startsystemd 无法跟踪守护进程服务状态会不准重启管理也会失灵。另外LimitNOFILE建议显式调大。Apollo 作为消息中间件高并发下会打开大量 socket 连接默认 1024 的文件描述符上限很快就会被耗尽到时候连接失败都不太容易往这上面想。5.3 跨版本数据兼容好险差点翻车Apollo 虽然停止更新了但它内部使用的存储格式在不同版本间还是会有差异。如果你 Windows 端是 1.7.0Linux 端却装成了 1.7.1极少数情况下会出现旧数据能读但文件格式自动升级后无法回退的情况。我当时的做法是先在实验室用完全相同版本的 Apollo 在 Linux 上跑了一晚上反复往队列里生产消费测试消息确认数据目录复制过去后能正常读写才定的正式迁移窗口。这一条也许有人觉得多余但对于消息中间件来说数据文件一旦坏了业务方丢消息的后果不是一句抱歉能解决的。所以强烈建议大家无论如何都要在预发环境先演练一遍再把生产环境的数据目录复制过去。5.4 时间同步看似无关实则影响排错迁移后如果发现消息时间戳和业务系统对不上或者管理台显示的时间与北京时间差了好几个小时先别急着怀疑代码。Apollo 的消息体里会带上 broker 的时间戳如果 Linux 服务器时区或时间不对所有新消息的时间都会乱。检查并校正timedatectl set-timezone Asia/Shanghai timedatectl set-ntp true chronyc sources -vWindows 那台机器通常保持的是本地时间Linux 默认可能用 UTC。迁移后建议强制统一时区避免后续日志和消息排查时错乱。6. 怎么判断迁移成功三个维度的验证方法服务进程跑起来、管理台能登录这只能算看起来活了真正要确认迁移成功至少要从服务、消息、客户端三个维度去验证。6.1 服务级验证看端口与系统资源先看基础指标# 检查端口监听 ss -lntp | grep -E 61613|61680 # 检查进程状态 ps aux | grep apollo # 检查内存与CPU占用确认没有异常抖动 top -p pid服务级验证的目的是确认 broker 进程没有异常退出、端口监听正常、内存使用在预期范围内。这一步通常迁移完成后十分钟内就能确认。6.2 消息级验证用测试数据实际生产消费broker 活着只是前提消息能不能正常生产、持久化、消费才是核心。如果你有现成的客户端就用现成的没有的话可以用 Python 的 stomp.py 快速验证import stomp import time # 建立连接 conn stomp.Connection([(localhost, 61613)]) conn.connect(admin, password, waitTrue) # 发送一条消息 conn.send(/queue/migration-test, hello from new broker, persistentTrue) # 监听队列 messages [] class Listener(stomp.ConnectionListener): def on_message(self, frame): messages.append(frame.body) print(received:, frame.body) conn.set_listener(test, Listener()) conn.subscribe(/queue/migration-test, idtest) time.sleep(3) # 验证消息是否收到 assert len(messages) 1 and messages[0] hello from new broker print(message verified!)注意这里使用的是persistentTrue这样消息才会走持久化通道能测出 store 迁移是否正常。如果这条消息能发出且能消费回来说明存储链路没问题。如果旧环境里还有积压的历史消息那还得在前端队列中看消费位点是否延续。管理台的队列浏览功能可以直接看到当前队列里的消息数量和内容可以和 Windows 端迁移前的截图做对比。6.3 客户端级验证让真实业务跑一遍测试消息跑通了最后一步是让真实应用连新的 broker 跑一遍。这一步需要业务方配合建议按以下顺序来先让一个非核心业务系统切换连接地址观察半小时。确认日志无异常、消息上下游都正常后再切换其他系统。全部切换完成后在管理台观察各队列的生产消费速率确认没有积压。如果客户端用的是长连接配置改了之后要记得重启应用进程光改配置文件不重启是不会重新连接的。6.4 回滚预案万一失败怎么恢复到 Windows迁移这件事不能只讲怎么往前走还得留好退路。迁移前我把 Windows 端的数据目录完整备份了一份并且明确在迁移窗口内不删除旧环境任何东西。回滚的触发条件是新 broker 启动后业务系统切换到新环境 1 小时内出现消息丢失、队列错乱、消费重复等严重问题且短时间无法修复。回滚步骤很简单把客户端连接地址全部切回 Windows 端 IP。在 Windows 端启动 broker 服务。确认消息恢复收发正常。保留 Linux 环境不动等业务稳定后再排查问题原因。需要注意的是如果迁移后 Linux 端已经开始接收新消息回滚时这些新消息不会自动同步回 Windows 端需要在客户端层面做好补偿或者接受小范围丢失。这也是为什么迁移窗口要选在业务低峰期尽量把数据损失降到最低。最后再分享一个实操中的小经验给 Apollo 做迁移最容易被低估的是复制数据目录的时间。消息量大时data目录可能是几十 GB 甚至更大从 Windows 机器传到 Linux 服务器走内网可能很快但如果跨机房还得考虑带宽损耗。我在迁移前一天做了一次全量数据 copy 测试确认了传输耗时才把正式窗口的时间定下来。另外一个小技巧复制数据之前先在 Windows 端执行一次apollo-broker stop然后等 30 秒确认没有子进程残留再打包数据目录。别直接在线打包虽然多数情况下没问题但万一赶上某个消息正在写半截后果就是新环境上出现脏数据。迁移这事做完之后我现在最直观的感受是以后维护这台 broker 不用再开远程桌面了systemctl status apollo-broker一条命令就能看到健康状况日志也能用journalctl -u apollo-broker -f实时跟踪运维负担小了一大截。如果你的老 Apollo 还在 Windows 上裸奔建议找个低峰期照着这篇流程完整演练一遍你会发现真正操作起来并没有想象中那么复杂。
