一句话结论
面对仍在承担核心业务的旧系统，更稳妥的路径不是一次性重写，而是先建立可部署、可观察、可回滚的技术底座，再按业务边界逐步迁移。本案例最终完成了分布式架构底座、配套文档和生产环境部署，并通过正式验收。
项目背景
客户是一家拥有多业务模块和线上交易场景的集团型企业。原有系统采用传统集中式架构，配置、发布、日志、权限和服务依赖集中在同一套应用中。随着业务增加，单体应用的版本发布风险、问题定位成本和横向扩展难度逐渐上升，同时内部团队需要能够独立接手后续开发与运维。
项目没有把“微服务化”理解成简单拆代码。前期首先梳理现有工程、公共组件、业务依赖、数据库关系和部署环境，判断哪些能力适合先抽离，哪些高关联数据仍应保留在同一业务边界内。
核心难点
- 旧应用仍在运行，架构升级不能影响现有业务连续性
- Spring MVC 项目需要逐步迁移到 Spring Boot，并保留原有配置与数据访问逻辑
- 服务拆分后，认证授权、配置、日志和调用链不能变成新的运维盲区
- 公共方法、数据库联合查询和服务版本依赖需要重新确定边界
- 客户内部团队需要获得可复用的工程规范，而不只是一次性交付代码
实施路径
第一步是建立迁移规范。项目整理了多环境配置、数据源、Web 配置、拦截器和日志配置的迁移方式，把传统 XML 配置逐步转换为 Spring Boot 的约定式配置，并保留测试环境验证路径。
第二步是搭建分布式技术底座。整体采用前后端分离和 API 网关统一入口，服务按业务高内聚、服务间低耦合的原则拆分。服务之间使用标准接口或消息机制协作，并加入认证授权、服务注册、集中配置、熔断降级和负载均衡能力。
第三步是补齐可观测与交付体系。项目统一了日志规范，建设调用链追踪、健康检查、指标采集和可视化监控；同时为不同微服务建立独立代码库、构建计划和版本规则，降低某个服务升级对其他服务的影响。
交付与验收
交付物包括架构技术规格、微服务组件清单、微服务创建指引、环境配置清单以及技术栈使用说明。生产部署完成后，客户通过现场会议对文档完整性、系统功能和交付清单进行验收，验收记录显示系统功能通过，未记录未通过项。
出于匿名化要求，本文不公开客户名称、合同编号、具体日期、服务器信息、项目人员和内部域名，也不把原始文档中的内部配置作为公开技术资料。
可复用经验
- 旧系统改造要先解决可部署、可监控和可回滚，再追求服务数量
- 数据库不必为了形式完全拆散，应按真实业务关系决定边界
- 服务拆分必须同时设计版本、配置、权限、日志和故障隔离
- 交付工程模板与运维文档，能降低客户后续接手成本
- 是否整体重写，应由业务连续性和迁移风险决定，而不是由技术栈新旧决定
适用边界
这一方式适合仍在运行、业务价值较高、无法长时间停机的 Java 旧系统。若原系统没有源码、数据库无法备份、核心流程无人确认，项目应先做资产盘点和可恢复性评估，不宜直接进入架构重构。