遗留系统的云原生改造，最危险的做法不是“不上云”，而是把原有系统整体搬进容器，再期待它自动获得弹性、敏捷和高可用。遗留系统通常承载核心交易，牵涉复杂依赖、批处理任务、数据一致性和长期积累的运维流程。改造目标不应是追逐技术名词，而应围绕发布慢、扩缩容困难、故障定位低效或资源成本不透明等业务问题，建立可验证的演进路径。
先划分边界，再选择改造对象
第一步不是拆分微服务，而是梳理系统边界：识别无状态模块、外部接口、定时任务、共享数据库和关键链路。优先选择业务影响可控、依赖较少、收益容易观察的模块进行容器化，先统一运行环境，再接入编排、持续交付和可观测能力。这样做的价值在于，团队可以先跑通“构建—部署—监控—回滚”的最小闭环，而不是在一次大迁移中同时承担架构、数据和组织风险。
对于强耦合的单体系统，不宜一开始就全面微服务化。更稳妥的方式是保留核心交易边界，通过接口逐步抽离外围能力，让新旧系统在一段时间内并行运行。每完成一个模块替换，就验证业务结果、性能表现和故障恢复流程，再决定下一步。数据库拆分尤其要谨慎：如果业务边界尚未厘清，过早拆库可能把单体内部耦合转化为跨服务调用和数据一致性问题。
把平台能力和治理机制同步建设
渐进式改造并不等于各团队各自试验。企业需要沉淀统一的容器镜像、编排规范、发布流程、日志、监控和链路追踪能力，避免每个项目重复搭建。Kubernetes 可以承担容器生命周期管理、资源调度和弹性伸缩，但它不是改造本身；真正决定成败的是服务边界、交付流程、权限控制和故障处置是否形成标准。
成本也应从第一阶段纳入治理。云原生资源更容易弹性扩张，但缺乏责任归属和使用分析时，成本可能随之失控。应让业务团队能够看见资源使用、环境归属和变更影响，并把成本、稳定性与交付效率放在同一套评估框架中。最终，成熟的路线通常不是“一次性重写”，而是以业务价值为牵引，分阶段替换、持续验证，在保留系统连续性的同时逐步获得云原生能力。