先把盘子铺开说一句：在Java后端这块摸爬滚打这么多年，服务器迁移最让人头疼的从来不是“搬代码”，而是“搬状态”。尤其是业务跑起来之后，你发现迁移就意味着要重启、要停服、要凌晨三点点着外卖干活。所以当我真正在Azure上把一套Java应用从旧环境热迁移到新环境、全程没有重启、用户毫无感知的时候，最大的感受就是——这事儿终于从“玄学”变成了“工程”。
今天这篇就来聊聊怎么给Java应用做热迁移，重点放在Azure体系下的可落地方案。我会把原理、步骤、坑、以及我实际踩过的雷全部交代清楚。适合正在做上云迁移、跨区域容灾、或者单纯想摆脱“重启恐惧症”的Java工程师和架构师参考。
1. 热迁移到底在“迁移”什么：别只盯着流量，状态才是命门
1.1 重启一次，代价远不止“几秒钟不可用”
很多同学对“重启”这件事比较麻木，觉得无非就是服务断几十秒，Liveness探针一拉，又能跑起来。但实际上，对Java应用来说，重启的杀伤力是滞后的、隐藏的。
先说JIT。Java应用跑久了，HotSpot会把热点代码编译成机器码，这部分编译优化是运行时逐步积累的。一重启，这些编译产物全部作废，应用进入冷启动状态，CPU飙高、RT变长，要花很长时间才能回到之前的性能水平。你以为重启只要1分钟，实际上业务要“软趴”十几分钟甚至更久。
再就是状态丢失。本地缓存、内存中的Session、Socket长连接、定时任务的状态、分布式锁的持有者……这些都会随进程消失而全部重置。尤其是那些用了本地缓存（比如Caffeine、Guava Cache）做热点数据挡板的服务，重启一次，相当于把缓存的“命中率”清零，数据库压力瞬间上来，运气不好直接拖垮下游。
所以热迁移的核心价值不只是“不中断”，而是“不降温”——让流量、状态、数据平滑地从一个节点挪到另一个节点，整个过程服务保持温热状态，用户无感、JIT不丢、缓存不冷。
1.2 把“状态”分类，才能知道要迁移什么
我在做热迁移方案时，习惯先把状态拆成三类：
- 流量状态：客户端连到哪个节点、负载均衡怎么分流的，这套由网关和注册中心管。
- 会话状态：用户的登录态、购物车、临时业务数据，这类必须外置，不能留在JVM内存里。
- 数据状态：数据库中的业务数据、文件、消息队列中的积压消息。这类是迁移的重头戏。
热迁移的本质就是：先把数据状态做同步，把会话状态外置，最后再切换流量状态。顺序错了，后面全是事故。
很多人在迁移时一上来就切流量，结果数据没跟上、Session没外置，流量切过去新节点跑了几分钟就开始报错，只能仓促回滚。这种问题我见得太多，根源就是没有分清楚”流量切换”和“状态迁移”的先后关系。
2. 方案选型：Azure体系下热迁移的几条路线和取舍
2.1 三条主流路径，按场景对号入座
做热迁移不是一个固定的动作，而是一套按场景组合的方案。我自己归纳为三条路线：
路线A：虚拟机/物理机级别的热迁移
如果你用的是Azure的IaaS虚拟机，或者从本地物理机迁到Azure，最直接的工具是Azure Migrate。它支持Agentless和Agent-based两种模式。Agentless意思是Azure通过Hyper-V或VMware的API做内存级复制，业务无感知；Agent-based则需要每台机器装个agent，把磁盘变化增量同步到Azure。
好处是粒度粗、覆盖面广，连操作系统一起搬，应用层完全不用改。代价是它对网络稳定性要求高，而且迁移完成后一般还是要做一次快速切换（相当于一次小暂停），做不到绝对的“不重启”。
路线B：容器化 + 滚动发布
如果应用已经容器化（Docker + AKS），那热迁移其实变成了“滚动更新”。把新节点加入后端池，确认健康之后，逐步摘除旧节点。这种方式非常丝滑，但前提是应用本身要无状态，或者状态全部外置。不然新Pod起来了，Session还在旧Pod的JVM里，切过去就是一大波报错。
路线C：应用级手工灰度
老系统没法容器化、又不想动底层的时候，走的就是纯应用层的灰度迁移。新环境并行部署一套，通过负载均衡/网关逐步切流量。这路线的优势是灵活、可控性强，回滚只要切流量就行，和底层基础设施解耦。缺点是比较考验手工操作和监控能力。
2.2 为什么我在Azure上偏向"应用级灰度 + 托管负载均衡"组合
很多人一听到热迁移就奔着Azure Migrate去，觉得“官方的肯定最省心”。实践下来，Azure Migrate对整机搬迁确实好用，但Java应用往往有自己复杂的拓扑：中间件多、依赖多、连接串多，整机搬过去容易产生“跑得起来但业务不对”的尴尬局面。
我更喜欢的方式是：新环境先按目标架构重新部署应用，数据层用Azure Database Migration Service或双写同步，流量层用Azure Load Balancer或Application Gateway做后端池切换。
选这个组合的理由很简单：
- 可控性强。每一批流量切换都是显式的，发现问题随时切回来。
- 和源代码、CI/CD天然打通。迁移的同时还能顺便规范部署流程。
- Azure的托管LB和App Gateway的健康探测很成熟，切换时可以用探测来控制“流量是否进入新节点”。
说白了，整机迁移适合基础设施层面的“搬家”，而应用级灰度迁移更适合“已经知道新环境长什么样、想按计划切流量”的场景。我做Java应用迁移时，90%的case都走后者。
3. 动手前的架构体检：不解决这四个问题，别谈热迁移
3.1 会话状态必须外置，这是铁律
热迁移的大前提是“新节点和旧节点要能无缝互换”。如果Session存在JVM里，那新旧节点天然无法互换——因为状态在各自的肚子里。
所以第一件事就是把Session搬到Redis这类外部存储里去。Spring Session + Redis Data的集成方式很成熟，改动成本很低。一般也就加个依赖、加几个配置项、把@EnableRedisHttpSession打开。
这里有个容易被忽视的细节：Redis的序列化方式要统一。默认的JDK序列化在跨版本升级时容易出幺蛾子，建议用JSON序列化（比如GenericJackson2JsonRedisSerializer），不然新老实例读取Session时可能字段对不上。
3.2 本地缓存要降级为“可重建的优化层”
本地缓存不是不能留，但你必须清楚：它只是性能优化手段，不是数据正确性的依赖。迁移时就算新节点缓存是空的，也不能影响业务正确性。
所以体检项目是：查一遍代码里有没有直接用本地缓存扛业务逻辑的。比如用Caffeine做幂等判断、用本地Map做分布式锁（这是重灾区）。一旦发现，必须改成Redis或数据库实现。
我自己项目里就踩过类似坑：有个服务用本地Cache记录“用户是否已领取优惠券”，平时没问题，迁移时新节点缓存是空的，用户又领了一次，线上事故直接变成资损。后来全面改成Redis + Lua脚本，才彻底解决。
3.3 数据层要有“同步中继”，而不是一次性拷贝
数据库迁移是热迁移里最需要提前量的一环。你不能在切换流量那分钟才开始导数据，必须提前让新库和旧库保持准实时同步。
Azure上做这件事，首选Azure Database Migration Service，支持从自建/其他云/本地数据库在线迁移到Azure SQL Database或Azure Database for MySQL/PostgreSQL。它会先做全量迁移，然后做持续的增量同步，直到你选择“Cutover”那一刻才把读写切换到新库。
如果是自建MySQL/PostgreSQL，也可以用原生的主从复制来搭同步链路，但会多一层运维工作。关键点是：数据同步必须提前跑起来，让“追赶延迟”趋近于零，再启动流量切换。
3.4 文件与对象存储要“迁完再切”
Java应用如果用了本地磁盘存文件，迁移时一定出问题。上传的图片、生成的报表、导出的Excel，这些一旦被请求访问，本地路径就失效了。
体检时凡是涉及文件读写的地方，统一改成对象存储（Azure Blob Storage或S3兼容存储）。迁移阶段用Blob的异步复制或双写策略，先把存量文件同步完，再在流量切换时点确认增量追赶完毕。
这一步很多人不重视，觉得“文件量不大拷一下就行”，实际上在线业务文件是持续增长的，你必须在切换前就建立好增量同步管道。我在一次迁移中就有过教训：存量文件拷完了，切换后用户上传的新文件写到了新存储，但旧存储里还有一批用户刚上传的文件没过来，最后只能写脚本补救，非常狼狈。
4. 一套可复现的Azure热迁移实操流程
4.1 前置准备：备份、配置核对、基线监控
先做备份。数据库做一次完整备份，配置中心导出全量配置，应用发布包和镜像打上本次迁移的标签。不要嫌麻烦，万一切换后要回滚，这些都是救命稻草。
然后是配置核对。重点查这几个地方：
- 数据库连接串：新环境必须指向新库（或同步中继库）。
- Redis地址：新旧环境是否共用一套Redis，如果不共用，Session迁移要提前做双读双写。
- 注册中心/配置中心：Nacos、Eureka、Apollo或Azure App Configuration的地址是否已更新。
- JVM参数：堆大小、GC策略、元空间大小，新旧环境要尽量保持一致，否则性能行为会漂移。
上线前最好把监控基线打出来：QPS、RT、GC频率、CPU、内存、数据库连接数。没有基线，切换后出了问题你都不知道“变化是不是迁移引起的”。
4.2 数据双写与缓存预热
在流量还没切之前，先把数据层和新环境的缓存准备好。
数据双写，我常用的方式是：业务代码里通过一个开关控制“双写”行为——主库照常写，同时异步写到新库。或者更轻量的做法是用DMS/Canal这类工具监听binlog做增量同步，业务零侵入。
缓存预热，这个特别重要，但很多人会忘。新应用节点刚起来，Redis缓存是空的（如果新环境用的是独立Redis），大量请求打过来就会穿透到数据库。我的做法是写一个预热脚本，从旧Redis把热点key批量读出来写入新Redis。热点key怎么定义？可以用旧Redis的INFO keyspace和SCAN统计结合业务特征来圈，也可以简单点：把过去24小时被访问过的key都拉一遍。
4.3 流量切换：借Azure负载均衡做“后端池换血”
这一步是整个热迁移的高潮。以Azure Application Gateway为例，流程是：
- 在Azure Application Gateway里新建一个后端池（Backend Pool），把新环境的应用节点加进去。
- 配置健康探测（Health Probe），路径指向你应用的
/actuator/health或自定义健康检查接口。 - 调整监听器规则，把部分流量切到新后端池，建议第一阶段切5%~10%。
- 观察监控指标，确认新节点无异常后，把比例逐步提升到50%、100%。
这里要特别注意健康探测的配置。Azure的探测器和我们常见的K8s探针逻辑不太一样，它的Interval、Timeout、Unhealthy Threshold要按应用实际启动时间调好。我曾经遇到一个情况：应用启动需要40秒，但探测器的超时时间只有10秒，结果新节点每次都被误判为不健康，永远进不了后端池。
常规参数参考如下：
| 参数 | 推荐值 | 说明 |
|---|---|---|
| Interval | 30s | 别太频繁，避免压垮应用 |
| Timeout | 5s | 超过5秒没响应视为失败 |
| Unhealthy Threshold | 3 | 连续3次失败才摘除节点 |
| Healthy Threshold | 2 | 连续2次成功才恢复在池 |
切流量时，我还会刻意打开CGI（Connection Draining）或类似机制的选项。它允许旧节点在断开前继续处理已建立的请求一段时间，避免“正在下单的用户突然连接被掐”。Azure Application Gateway里有Connection Draining设置，建议开启，超时时间设30~60秒。
4.4 流量切完之后，旧节点先别急着杀
100%流量已经切到新环境，不代表旧节点可以立刻销毁。IAAS迁移也罢、应用迁移也罢，都有一个“观察期”陷阱：你以为切完了，实际上还有很多存量连接、延迟请求、报表任务还在旧节点上跑。
我一般会给旧节点保留至少24~48小时的“只出不进”状态：负载均衡不再分配新流量，但节点别关机，让它自然把内存中的存量任务跑完。有些长任务跑几个小时很正常，你强行关机会导致任务中断、数据不完整。
这也是很多人“切完就释放旧资源”然后被业务方投诉的原因。热迁移讲究“软着陆”，旧节点慢一点退场，比什么都重要。
5. 热迁移中最容易翻车的五个场景
5.1 JIT冷启动导致的性能“假性劣化”
新节点刚上线时，因为缺少JIT编译预热，性能往往比旧节点差一截。如果你在低流量阶段没发现，等切到50%、100%流量时才发现RT飙升，那就很难受了。
解决办法：在服务真正接流量之前，主动发送预热请求。写一个预热脚本，把线上常见的请求路径循环打一遍，让JIT把热点方法编译成机器码。有些人会用-XX:CompileThreshold调低编译阈值来加速预热，但生产环境我不建议瞎调这个参数，容易引发额外的编译线程开销。最稳的方式还是“真实流量多打几分钟再说”。
5.2 WebSocket和长连接被负载均衡“掐断”
Java后端很多IM、消息推送场景离不开WebSocket。这类连接一旦建立，就绑定在某台机器上。流量切换时，新连接会走新节点，但旧连接还挂在旧节点上。如果你图的省事直接关旧节点，那所有WebSocket连接瞬间断开，客户端如果没有重连机制，就是大规模掉线事故。
我的经验是：网关层处理连接迁移，或至少确保客户端有指数退避重连机制。服务端也可以做“优雅下线”，先通知客户端重连，再关闭连接。Spring WebSocket里有SessionDisconnectEvent，可以用它来触发“服务端主动踢下线并告知原因”的逻辑，让客户端感知到之后秒级重连到新节点。
5.3 定时任务在新旧环境“双跑”
没做过分布式任务框架（如XXL-JOB、ElasticJob）统一管理的定时任务，迁移时特别容易踩坑：新老环境同时跑同一个定时任务，数据被重复处理，发券、推送、账单这些业务直接出事。
原则是：定时任务必须加分布式锁，或者通过任务调度平台统一控制“新旧环境只有一个能跑”。如果是自研任务，最简单的方式是借助Redis的分布式锁，锁的key包含任务名和环境标记。切流量前，把旧节点上的定时任务全部停掉，确认新节点接管后再逐步放开。
还可以用ShedLock这类轻量锁，配合数据库或Redis，只让一个实例执行任务。这个方案对Spring Boot项目侵入极小。
5.4 数据库连接池的“预热欠账”
数据库连接池（HikariCP、Druid）不会在应用启动瞬间把连接全部建好，而是按需创建。新节点刚切进去时，接到的请求多、连接池还没热起来，就会频繁创建新连接，加上MySQL/PostgreSQL服务端的资源开销，看起来就像“数据库被打挂了”。
经验做法：发布前先用脚本并发请求几次，把连接池“暖”起来；或者把HikariCP的minimumIdle和maximumPoolSize设成一致，让连接池启动时就建好足够连接。这样能显著减少切换瞬间的抖动。
5.5 日志和链路追踪不在一个“频道”
新环境如果没有和旧环境打通日志采集和链路追踪，出了问题你会发现：用户报障了，但你不知道请求最终落到哪台机器、哪个方法，两眼一抹黑。
迁移前必须把日志采集、TraceId透传、Metrics监控对新环境就绪。Azure侧可以接Application Insights，Java那边用OpenTelemetry SDK埋点，日志统一打到Azure Log Analytics或者自建的ELK。没有可观测性的热迁移，就像蒙着眼睛换轮胎。
6. 常见问题速查与实操心得
6.1 故障速查表
| 现象 | 可能原因 | 解决思路 |
|---|---|---|
| 切换后RT飙升 | JIT冷启动 / 连接池未预热 | 预热脚本、连接池预建 |
| 用户登录态丢失 | Session还在旧节点JVM | 外置到Redis、统一序列化 |
| 新节点一直被判定不健康 | 探针路径不对/超时太短 | 调整健康探测配置 |
| 数据出现重复 | 定时任务双跑 | 分布式锁/调度平台统一 |
| 文件404 | 文件还在旧存储 | 对象存储双写，迁移完再切流量 |
| WebSocket大面积掉线 | 网关关闭存量连接 | 客户端重连、服务端优雅下线 |
| 切回旧环境后数据不一致 | 双写补偿没做好 | 建立反向同步、回滚前数据校验 |
6.2 我总结的几条实操原则
第一，流量可以灰度，数据必须强一致。流量切错了能切回来，数据错了很难洗白。所以数据同步、校验、补偿这些环节一定要做到位。
第二，先慢后快，敢于停手观察。5%流量阶段多观察一段时间，不要急着往上加。我甚至建议切到20%的时候停一个小时，看看有没有慢SQL、连接池水位异常、缓存命中率下降等信号。
第三，每一次切换都要有回滚预案。如果新节点有问题，能不能一分钟内把所有流量切回旧节点？我见过很多团队说要回滚，结果发现旧节点已经被释放了、数据库已经被覆盖了，回滚变成了“重新部署”，那就不叫热迁移了。
第四，动用Azure的托管服务，别什么都自己扛。负载均衡、数据库迁移、对象存储复制、监控告警，这些Azure都提供了成熟的托管方案，能省多少事就省多少事。自己搭一套Erlang级别的脚本去复制数据，最后大概率被一两个边界case按在地上摩擦。
聊到这里，热迁移的整体思路和步骤应该比较完整了。我个人的体会是，做Java应用的Azure热迁移，最大的门槛不是技术方案选型，而是你有没有把“状态迁移”和“流量切换”这两件事彻底分开处理。只要状态外置了、数据同步准实时了、流量能按比例灰度，剩下的大多是执行层面的细心问题。最后再分享一个小技巧：迁移演练一定要做，挑业务低峰期，把整套流程完整走一遍，包括回滚动作都演练到位。真正做迁移那天，你会感谢自己提前“彩排”过几次。
