平滑迁移微服务的关键是“先理清边界、再逐个封装”：第一步识别高内聚低耦合模块（如登录认证）；第二步为各技术栈编写专用dockerfile并声明非root用户；第三步用docker compose验证服务协作；第四步通过api网关灰度共存，确保数据一致与监控基线。
Dockerfile本身不驱动拆分，只承载已拆分的服务。平滑迁移的关键是“先理清边界、再逐个封装”，而不是把整个单体塞进一个镜像里。
第一步：识别可独立封装的业务模块
从单体中找出高内聚、低耦合的部分作为首个微服务候选，例如登录认证、短信发送、文件上传等。判断标准包括：
- 有明确输入输出接口（如REST端点或消息契约）
- 数据库表可物理分离，不与其他模块共用核心业务表
- 日志能独立采集，错误不影响主流程其他环节
- 代码目录结构相对清晰，依赖外部模块较少
第二步：为每个模块编写专用Dockerfile
不同技术栈的服务需差异化构建策略，避免“一套模板打天下”：
- Java服务：基于openjdk:17-jre-slim，COPY target/*.jar，禁用JVM调试端口，设置-Xmx512m防止内存溢出
- Python服务：用python:3.11-slim-bookworm，pip install --no-cache-dir -r requirements.txt，删掉.pyc和__pycache__
- Go服务：采用多阶段构建，build阶段用golang:1.22-alpine编译，runtime阶段仅COPY静态二进制文件到alpine:latest
- 所有Dockerfile必须声明非root用户（USER 1001），并配置.dockerignore排除.git、node_modules、target等无关路径
第三步：用Docker Compose验证服务协作
在本地模拟微服务网络环境，验证拆分后的实际运行效果：
- 每个服务定义独立service块，使用自定义网络（如app-net），服务名自动成为DNS名称（orders可直连users）
- 通过env_file注入配置，敏感字段如DB_HOST、REDIS_URL用${}占位，运行时由环境变量填充
- 挂载日志目录到宿主机（如./logs/users:/app/logs），方便快速比对单体日志与新服务日志行为差异
- 用depends_on控制启动顺序，但需配合健康检查脚本（如curl -f http://users:8080/actuator/health）确认就绪再启动下游
第四步：保留单体灰度共存能力
初期不追求全量替换，而是让新服务与原单体并行运行：
- API网关按路径分流，/api/v1/auth → user-service，其余仍走单体
- 数据库层面启用双写或CDC同步，确保用户数据在单体库和user-service专属库中一致
- 所有新服务日志统一输出到stdout/stderr，由Docker采集，便于后续接入ELK或Loki做集中分析
- 监控指标（如HTTP 5xx率、P95延迟）在迁移前后保持基线对比，确认无性能退化
