公司用着跑了五年的Java单体应用，Tomcat+MySQL搭在几台老服务器上，一到大促就报警，运维天天守着监控看CPU。去年终于下定决心做云原生迁移——不是为了赶时髦，是真扛不住了。
第一步：别急着删旧代码，先搞清‘它到底在干啥’
我们拉出三个月的Nginx日志和数据库慢查记录，用Excel画了个简易依赖图：用户登录→调用认证服务→查Redis缓存→查MySQL用户表→写操作日志。这一步花了一周，但省掉了后面两周返工。很多团队跳过这步，直接上容器化，结果上线后发现某个定时任务偷偷连了内网另一台Oracle，谁都不知道。
第二步：拆服务？先试试‘最小可容器化单元’
没强求立刻微服务。先把登录模块拎出来，Spring Boot打成jar包，写个Dockerfile：
FROM openjdk:17-jre-slim
COPY app.jar /app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "/app.jar"]用docker-compose本地跑通，再推到测试环境的K8s集群。注意：数据库连接字符串、Redis地址这些配置，先用ConfigMap挂载，别硬编码。
第三步：网络和存储，最容易翻车的地方
老系统里有个文件上传功能，直接存服务器硬盘。迁到K8s后，Pod重启文件就没了。我们没上复杂对象存储，先用MinIO自建轻量版S3，改两行代码：
// 原来：FileUtils.writeByteArrayToFile(new File("/data/uploads/xxx.jpg"), data);
// 现在：minioClient.putObject(PutObjectArgs.builder()
// .bucket("uploads").object("xxx.jpg").stream(...).build());网络方面，把原来写死的192.168.1.x改成Service名，比如auth-service.default.svc.cluster.local，K8s自动DNS解析。
第四步：灰度上线，拿5%流量试水
用Ingress加注解实现灰度：
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-weight: "5"观察半天，发现新版本登录耗时比老版多200ms——查出来是JWT验签用了默认RSA算法，换成ECDSA后秒降。这种细节，不跑真实流量根本发现不了。
第五步：监控不能只看CPU和内存
加了Prometheus+Grafana后，重点盯三个指标：HTTP 5xx错误率、服务间调用延迟P95、Pod重启次数。有次凌晨三点告警，发现是新Pod启动时并发拉配置，把配置中心压垮了——后来加了启动探针（startupProbe）和限流。
迁移不是终点，而是新问题的起点。现在我们每周开15分钟‘故障复盘会’，白板上只写三件事：这次哪条日志帮了大忙、哪个配置漏写了、下次迁移前必须补的自动化脚本是什么。