Docker本身不拆分单体应用，而是为拆分后的每个微服务提供标准化、可复用的运行载体；真正的转型关键在于“先拆再包”——先完成业务边界梳理与服务拆分，再用Docker为每个独立服务构建镜像。
直接切入核心：Docker本身不拆分单体应用，而是为拆分后的每个微服务提供标准化、可复用的运行载体。真正的转型关键在于“先拆再包”——先完成业务边界梳理与服务拆分，再用Docker为每个独立服务构建镜像。
一、拆分策略决定容器化成败
盲目打包单体应用进一个Docker镜像，只是“披着容器外衣的单体”，无法获得微服务优势。必须按业务能力（如用户管理、订单处理、支付网关）划分清晰的服务边界：
- 识别高内聚、低耦合模块：优先从日志独立、数据库可分离、接口契约明确的部分入手（例如把登录认证模块单独剥离）
- 避免共享数据库：每个服务应拥有专属数据库实例或schema，通过API交互，而非直接表连接
- 定义轻量通信协议：统一采用HTTP/REST或gRPC，禁用本地方法调用或共享内存方式
- 接受渐进式改造：初期可保留单体核心，将新功能以独立微服务形式上线，通过API网关聚合响应
二、为每个微服务定制Dockerfile
每个服务的Dockerfile不是模板复制，而要匹配其技术栈与运行特征：
- Java/Spring Boot服务：基础镜像选
eclipse-temurin:17-jre-jammy，关闭JVM调试端口，设置合理堆内存参数（如-Xmx512m） - Python服务：用
python:3.11-slim-bookworm，pip install --no-cache-dir -r requirements.txt避免残留缓存层 - Golang服务：坚持多阶段构建，构建阶段用
golang:1.22-alpine，运行阶段用alpine:latest，静态编译后仅复制二进制文件 - 所有服务：必须声明非root用户（
USER 1001），添加.dockerignore排除target/、node_modules/、.git等无关目录
三、用Docker Compose验证本地微服务协作
在K8s之前，Docker Compose是验证服务间调用、网络连通性和配置注入最高效的手段：
- 每个服务定义独立
service块，显式声明depends_on（仅控制启动顺序，不保证就绪） - 共用自定义网络（
networks: [app-net]），服务名即DNS名称（如orders可被users容器直接访问） - 敏感配置通过
env_file加载，数据库连接串等动态参数用${DB_HOST}占位符，运行时注入 - 挂载日志目录到宿主机（
volumes: - ./logs/orders:/app/logs），便于快速排查
四、容器化不是终点，而是可观测性起点
单体时代靠日志文件定位问题，微服务下必须默认集成基础可观测能力：
- 所有服务输出日志到标准输出（stdout/stderr），禁用文件写入；Docker自动采集并支持
docker logs查看 - 暴露健康检查端点（如
/actuator/health或/healthz），供Docker或后续K8s探针使用 - 在Dockerfile中设置
HEALTHCHECK指令，例如HEALTHCHECK --interval=30s --timeout=3s CMD curl -f http://localhost:8080/healthz || exit 1 - 预留Prometheus指标端点（如
/metrics），无需立即接入监控体系，但代码和镜像需支持
