简介本资源是面向中高级Java开发工程师、云原生架构师及DevOps实践者的《Docker微服务架构实战》技术专著PDF电子版聚焦中小型企业微服务落地过程中的柔性演进路径。全书系统讲解微服务拆分原则、传统单体向微服务迁移方法论、Docker底层原理与跨主机通信方案、Docker与DevOps整合实践并提供基于Rancher快速构建容器云平台的完整案例兼顾理论深度与工程可操作性。资源为单文件PDF格式大小151.92MB内容完整覆盖作者蒋彪资深高级架构师曾主导银行级系统与高并发互联网平台架构多年一线经验总结含详细目录、章节导图、实操配置示例及版权说明页。目前已有1313人学习下载适合希望构建微服务容器化全局知识体系、规避常见落地陷阱的技术人员系统研读与反复查阅。1. 为什么用 Docker 搭微服务不是“装完就跑”而是要卡在服务发现、网络互通、配置漂移这三道坎上你手上有 Spring Boot 写的订单服务、用户服务、支付服务本地跑得飞起一扔进 Docker 就连不上数据库、调不通其他服务、配置改了十次还是读不到——这不是 Docker 不行是微服务在容器里突然暴露了它最真实的底色服务不是孤立进程而是一组动态协作的网络实体。这份《Docker微服务架构实战.pdf》不是教你怎么docker run -d启一个镜像而是直面真实产线中那几个高频翻车点服务启动后注册到 Consul/Eureka 却被其他容器 ping 不通Nginx 网关转发时提示upstream connect error.env文件在 compose 启动后压根没加载进 Java 进程甚至docker-compose up成功了但curl http://localhost:8080/actuator/health返回 503。本文只讲一线工程师每天真正在 debug 的事怎么让每个服务在容器里活下来、连得上、配得对、扩得稳。适合已经写过至少两个 Spring Boot 接口、能手敲Dockerfile、但一上docker-compose.yml就卡在network_mode: host和extra_hosts之间反复横跳的开发者。不讲 Docker 原理只讲你明天上班就要改的三行配置、两个命令、一个必须加的健康检查探针。2. 从单体打包到服务拆分Dockerfile 不是复制粘贴而是按服务生命周期定制构建策略微服务不是把单体代码切开扔进不同 Dockerfile 就完事。每个服务的构建逻辑必须匹配它的运行角色API 网关要轻量、状态服务要带 Redis 客户端、批处理服务要挂载宿主机定时任务目录。硬套统一模板只会导致镜像臃肿、启动超时、JVM 参数失效。2.1 基础镜像选型OpenJDK 还是 JREARM 还是 AMD64别让java.lang.UnsatisfiedLinkError在生产环境凌晨三点报错Java 微服务最常踩的坑是基础镜像和宿主机架构不匹配。比如你在 M1 Mac 上用openjdk:17-jre-slim构建推到 x86_64 的 CentOS 服务器上运行JVM 可能因 glibc 版本差异直接崩溃更隐蔽的是slim镜像缺失libz.so.1导致 Spring Boot 读取 ZIP 资源失败。# ✅ 推荐写法显式声明架构 最小化 JRE 补全必要系统库 FROM --platformlinux/amd64 openjdk:17-jre-slim # 补齐常见缺失库尤其用于文件解压、SSL 通信 RUN apt-get update apt-get install -y \ libz-dev \ libssl-dev \ rm -rf /var/lib/apt/lists/* WORKDIR /app COPY target/order-service.jar app.jar # 显式指定 JVM 参数避免容器内存限制下 OOM ENTRYPOINT [java, -Xms256m, -Xmx512m, -XX:UseG1GC, -jar, app.jar]注意--platformlinux/amd64是强制构建目标平台的关键开关。M1/M2 用户务必加上否则默认构建 ARM 镜像部署到云服务器99% x86必然失败。-jre-slim比-jdk-slim小 120MB且微服务无需编译器JRE 足够。2.2 分层构建优化把依赖层和代码层彻底分离CI/CD 中节省 70% 构建时间Spring Boot 的 fat jar 包含所有依赖每次代码变更都重做整个镜像浪费 CI 时间和镜像仓库空间。正确做法是利用 Docker 多阶段构建 Maven 分层# 第一阶段构建依赖层仅当 pom.xml 变更时才重建 FROM maven:3.8.6-openjdk-17 AS builder WORKDIR /app COPY pom.xml . RUN mvn dependency:go-offline -B # 预下载所有依赖生成 target/dependency # 第二阶段构建代码层仅当 src/ 变更时才重建 FROM openjdk:17-jre-slim WORKDIR /app # 复用第一阶段下载的依赖缓存友好 COPY --frombuilder /root/.m2 /root/.m2 COPY --frombuilder /app/target/dependency /app/libs COPY target/*.jar app.jar # 使用 Spring Boot 的分层启动机制需 spring-boot-maven-plugin 2.4 ENTRYPOINT [java, -cp, app.jar:libs/*, org.springframework.boot.loader.JarLauncher]关键参数说明mvn dependency:go-offline提前拉取全部依赖到本地 Maven 仓库后续mvn package不再联网构建稳定COPY --frombuilder实现跨阶段依赖复用只要pom.xml不变/root/.m2层永远命中缓存JarLauncher启动方式比java -jar更快因为跳过 fat jar 解压过程直接加载 classpath。2.3 构建上下文瘦身.dockerignore不是可选项是防止COPY . .把.git和node_modules打进镜像的后悔药一个没配.dockerignore的Dockerfile可能把 2GB 的node_modules前端项目、.git含历史记录、target/旧 jar、logs/日志文件全塞进镜像。结果镜像体积暴涨 3 倍推送耗时翻 5 倍安全扫描报出上百个高危漏洞来自node_modules。标准.dockerignore必须包含.git .gitignore README.md target/ *.jar *.war node_modules/ npm-debug.log .DS_Store *.log .env血泪经验某次上线前发现镜像大小 1.2GBdocker history查看各层体积发现COPY . .占了 980MB。删掉.dockerignore后重新构建镜像降至 280MB —— 直接省下 70% 传输带宽和仓库存储。3. docker-compose.yml 不是配置清单而是服务协作的契约协议网络、依赖、健康检查缺一不可docker-compose.yml是微服务架构的“宪法”。它定义服务间如何通信、谁先启动、失败后怎么重启、健康状态如何判定。写错一行depends_on或漏掉healthcheck就会导致网关启动时后端服务还没 ready流量打过去全 503。3.1 网络模式选择default网络 vshostvsbridge—— 90% 的“连不上”问题源于网络隔离误判Docker 默认为docker-compose创建一个自定义 bridge 网络如myapp_default服务间可通过服务名直接通信curl http://user-service:8080。但新手常犯两个致命错误错误 1在docker-compose.yml中给所有服务加network_mode: host以为这样就能“通”。结果服务失去 Docker 网络隔离端口冲突频发且无法用服务名互相访问host模式下 DNS 不生效错误 2MySQL 服务用了network_mode: host但 Java 服务没配导致 Java 服务连localhost:3306连的是自己容器的 3306空而不是宿主机的 MySQL。✅ 正确做法全部使用默认 bridge 网络用服务名通信version: 3.8 services: api-gateway: image: registry.example.com/gateway:1.2.0 ports: - 8080:8080 environment: - SPRING_PROFILES_ACTIVEdocker # 依赖 user-service 启动完成但不保证其 ready depends_on: - user-service - order-service user-service: image: registry.example.com/user:1.1.0 # 关键不暴露端口给宿主机只允许内部服务调用 # ports: # ← 删除这一行外部通过网关访问 environment: - SPRING_DATASOURCE_URLjdbc:mysql://mysql:3306/userdb?useSSLfalse # 健康检查确保服务真正可用而非仅进程存活 healthcheck: test: [CMD, curl, -f, http://localhost:8080/actuator/health] interval: 30s timeout: 10s retries: 3 start_period: 40s mysql: image: mysql:8.0.33 environment: MYSQL_ROOT_PASSWORD: root123 MYSQL_DATABASE: userdb volumes: - mysql-data:/var/lib/mysql # MySQL 也走默认网络Java 服务用 mysql:3306 访问 # 不需要 ports: [3306:3306]除非本地调试需直连 volumes: mysql-data:参数详解depends_on只控制启动顺序不等待服务 ready。所以必须配合healthcheckhealthcheck.start_period: 40s给 Spring Boot 应用预留足够启动时间JVM Spring Context 初始化SPRING_DATASOURCE_URL中的mysql是服务名Docker DNS 自动解析为对应容器 IP。3.2 环境变量注入.env文件 environmentenv_file三层覆盖规则搞不清顺序就配错Docker Compose 环境变量有明确优先级environment字段 env_file.env文件。新手常把数据库密码写在.env又在environment里写死SPRING_PROFILES_ACTIVEdev结果生产环境启动时 profile 还是dev。✅ 推荐分层策略.env存放跨环境不变量如COMPOSE_PROJECT_NAMEmyapp,IMAGE_TAG1.2.0env_file存放环境专属敏感配置如prod.env存DB_PASSWORDprod123dev.env存DB_PASSWORDdev123environment存放服务级固定配置如JAVA_HOME/opt/java,TZAsia/Shanghai。# docker-compose.prod.yml services: user-service: image: user:${IMAGE_TAG} env_file: - ./config/prod.env # ← 优先级高于 .env environment: - JAVA_HOME/opt/java - TZAsia/Shanghai # 注意这里不能覆盖 prod.env 里的 DB_PASSWORD./config/prod.env内容SPRING_DATASOURCE_PASSWORDprod123 SPRING_PROFILES_ACTIVEprod玄学提醒env_file中的变量名不能有空格、不能用引号包裹否则 Docker 会静默忽略。SPRING_DATASOURCE_PASSWORD prod123❌SPRING_DATASOURCE_PASSWORDprod123✅。3.3 服务依赖与启动等待wait-for-it.sh不是银弹healthcheckrestart: on-failure才是正解很多教程教用wait-for-it.sh脚本等 MySQL 启动但这是反模式它只检测端口是否开放不验证 MySQL 是否真正可执行 SQL。曾有案例MySQL 容器端口开了但mysqld进程卡在初始化wait-for-it.sh认为已就绪Java 服务连接后抛CommunicationsException。✅ 正确方案用 Docker 原生healthcheckrestart策略组合services: mysql: image: mysql:8.0.33 healthcheck: test: [CMD, mysqladmin, ping, -h, localhost, -u, root, -proot123] interval: 20s timeout: 10s retries: 5 start_period: 60s # 给 MySQL 充足初始化时间 user-service: image: user:1.1.0 depends_on: mysql: condition: service_healthy # ← 关键等待 mysql 健康检查通过 restart: on-failure # MySQL 崩溃时自动重启 user-servicecondition: service_healthy是depends_on的增强版它等待被依赖服务的healthcheck返回healthy状态而非仅进程启动。4. 避坑微服务 Docker 化的 5 个高频翻车现场与根因修复4.1 现象服务启动后curl http://user-service:8080/actuator/health返回Connection refused但docker exec -it user-service sh进容器netstat -tuln | grep 8080显示端口未监听原因Spring Boot 默认绑定localhost127.0.0.1Docker 容器内localhost指向自身外部服务无法访问。解决在application-docker.yml中强制绑定0.0.0.0server: address: 0.0.0.0 port: 8080并在启动时激活该 profileSPRING_PROFILES_ACTIVEdocker。4.2 现象docker-compose logs -f api-gateway显示Failed to resolve user-serviceDNS 解析失败原因服务名拼写错误如user_servicevsuser-service或服务未在同一docker-compose.yml中定义跨文件需extends或networks共享。解决检查docker-compose.yml中服务名是否完全一致连-都不能错进入网关容器执行nslookup user-service确认 DNS 是否返回 IP若跨文件部署必须在networks下声明共享网络networks: default: external: name: myapp_default # ← 与主文件 network 名一致4.3 现象MySQL 容器启动成功但 Java 服务报Access denied for user root172.20.0.5原因MySQL 8.0 默认认证插件改为caching_sha2_password老版本 JDBC 驱动不兼容。解决在docker-compose.yml中为 MySQL 指定传统插件mysql: image: mysql:8.0.33 command: --default-authentication-pluginmysql_native_password environment: MYSQL_ROOT_PASSWORD: root123并确保pom.xml中 JDBC 驱动版本 ≥ 8.0.28。4.4 现象docker-compose up后docker ps显示服务状态为Restarting (1)循环重启原因健康检查失败如actuator/health返回DOWN触发restart: on-failure策略。排查步骤docker logs user-service查看启动日志定位 Spring Boot 启动失败原因常见数据库连接超时、Redis 密码错误临时注释healthcheck确认服务能否正常启动恢复healthcheck调整start_period如从 40s 改为 90s检查actuator/health是否被 Spring Security 拦截需配置management.endpoints.web.exposure.includehealth。4.5 现象Windows 上docker-compose up报错virtualization support not detected原因WSL2 未启用或 BIOS 中 VirtualizationVT-x/AMD-V未开启。解决Windows 10/11启用 WSL2PowerShell 管理员运行wsl --installBIOS 设置开机按 F2/Del 进 BIOS找到Intel Virtualization Technology或SVM Mode设为EnabledDocker Desktop 设置Settings → General → Use the WSL2 based engine勾选不要用--platformlinux/amd64强制构建WSL2 已原生支持 x86_64。5. 生产就绪用docker stack deploy替代docker-compose up实现真正的服务编排与滚动更新docker-compose up是开发测试神器但生产环境必须用 Docker Swarm 或 Kubernetes。Swarm 学习成本低docker stack deploy命令几乎兼容docker-compose.yml是平滑过渡首选。5.1 从docker-compose.yml到docker-stack.yml只需三处改造原docker-compose.yml字段docker-stack.yml改造点说明version: 3.8改为version: 3.8Swarm 支持 3.8无需降级ports: [8080:8080]改为publish: [8080:8080]Swarm 使用publish语法deploy:块缺失新增deploy配置控制副本数、更新策略、资源限制改造后docker-stack.yml示例version: 3.8 services: api-gateway: image: registry.example.com/gateway:1.2.0 deploy: replicas: 3 update_config: parallelism: 1 delay: 10s failure_action: rollback resources: limits: memory: 512M cpus: 0.5 ports: - published: 8080 target: 8080 mode: host # ← 关键host 模式让 Swarm 路由到任意节点 user-service: image: registry.example.com/user:1.2.0 deploy: replicas: 2 restart_policy: condition: on-failure networks: - myapp-network networks: myapp-network: driver: overlay # ← Swarm 必须用 overlay 网络5.2 滚动更新实操一条命令完成零停机发布假设你要将user-service从1.1.0升级到1.2.0# 1. 构建新镜像并推送到私有 Registry docker build -t registry.example.com/user:1.2.0 ./user-service docker push registry.example.com/user:1.2.0 # 2. 更新 stack自动触发滚动更新 docker stack deploy -c docker-stack.yml myapp # 3. 实时观察更新进度看到 old → new 逐个替换 docker service logs --follow myapp_user-serviceSwarm 会按parallelism: 1逐个停止旧容器、启动新容器期间replicas: 2始终保持至少 1 个实例在线用户无感知。关键技巧failure_action: rollback是后悔药。若新版本启动失败健康检查连续失败Swarm 自动回滚到上一版镜像无需人工干预。我线上集群已用此策略保障 3 年零发布事故。5.3 日志与监控用docker service logs Prometheus Grafana 搭建轻量可观测体系docker-compose logs只能看当前日志Swarm 需集中采集。推荐方案日志用docker service logs myapp_api-gateway --since 1h查最近 1 小时日志指标在 Spring Boot 服务中引入micrometer-registry-prometheus暴露/actuator/prometheus采集部署 Prometheus配置docker_swarm_sd_configs自动发现服务可视化Grafana 导入 Spring Boot Actuator DashboardID: 12856。Prometheus 配置片段scrape_configs: - job_name: swarm-services docker_sd_configs: - host: unix:///var/run/docker.sock role: tasks relabel_configs: - source_labels: [__meta_docker_task_label_com_docker_stack_namespace] regex: myapp action: keep - source_labels: [__meta_docker_task_container_port_number] regex: 8080 action: keep我的习惯上线新服务前必加spring-boot-starter-actuatormicrometer-registry-prometheus并用curl http://service-ip:8080/actuator/metrics验证指标端点可访问。没有指标等于在黑匣子里开车——你永远不知道服务是慢了、卡了还是假死了。希望帮到你。本文还有配套的精品资源点击获取 Docker微服务实战：解决服务发现、网络互通与配置漂移
简介本资源是面向中高级Java开发工程师、云原生架构师及DevOps实践者的《Docker微服务架构实战》技术专著PDF电子版聚焦中小型企业微服务落地过程中的柔性演进路径。全书系统讲解微服务拆分原则、传统单体向微服务迁移方法论、Docker底层原理与跨主机通信方案、Docker与DevOps整合实践并提供基于Rancher快速构建容器云平台的完整案例兼顾理论深度与工程可操作性。资源为单文件PDF格式大小151.92MB内容完整覆盖作者蒋彪资深高级架构师曾主导银行级系统与高并发互联网平台架构多年一线经验总结含详细目录、章节导图、实操配置示例及版权说明页。目前已有1313人学习下载适合希望构建微服务容器化全局知识体系、规避常见落地陷阱的技术人员系统研读与反复查阅。1. 为什么用 Docker 搭微服务不是“装完就跑”而是要卡在服务发现、网络互通、配置漂移这三道坎上你手上有 Spring Boot 写的订单服务、用户服务、支付服务本地跑得飞起一扔进 Docker 就连不上数据库、调不通其他服务、配置改了十次还是读不到——这不是 Docker 不行是微服务在容器里突然暴露了它最真实的底色服务不是孤立进程而是一组动态协作的网络实体。这份《Docker微服务架构实战.pdf》不是教你怎么docker run -d启一个镜像而是直面真实产线中那几个高频翻车点服务启动后注册到 Consul/Eureka 却被其他容器 ping 不通Nginx 网关转发时提示upstream connect error.env文件在 compose 启动后压根没加载进 Java 进程甚至docker-compose up成功了但curl http://localhost:8080/actuator/health返回 503。本文只讲一线工程师每天真正在 debug 的事怎么让每个服务在容器里活下来、连得上、配得对、扩得稳。适合已经写过至少两个 Spring Boot 接口、能手敲Dockerfile、但一上docker-compose.yml就卡在network_mode: host和extra_hosts之间反复横跳的开发者。不讲 Docker 原理只讲你明天上班就要改的三行配置、两个命令、一个必须加的健康检查探针。2. 从单体打包到服务拆分Dockerfile 不是复制粘贴而是按服务生命周期定制构建策略微服务不是把单体代码切开扔进不同 Dockerfile 就完事。每个服务的构建逻辑必须匹配它的运行角色API 网关要轻量、状态服务要带 Redis 客户端、批处理服务要挂载宿主机定时任务目录。硬套统一模板只会导致镜像臃肿、启动超时、JVM 参数失效。2.1 基础镜像选型OpenJDK 还是 JREARM 还是 AMD64别让java.lang.UnsatisfiedLinkError在生产环境凌晨三点报错Java 微服务最常踩的坑是基础镜像和宿主机架构不匹配。比如你在 M1 Mac 上用openjdk:17-jre-slim构建推到 x86_64 的 CentOS 服务器上运行JVM 可能因 glibc 版本差异直接崩溃更隐蔽的是slim镜像缺失libz.so.1导致 Spring Boot 读取 ZIP 资源失败。# ✅ 推荐写法显式声明架构 最小化 JRE 补全必要系统库 FROM --platformlinux/amd64 openjdk:17-jre-slim # 补齐常见缺失库尤其用于文件解压、SSL 通信 RUN apt-get update apt-get install -y \ libz-dev \ libssl-dev \ rm -rf /var/lib/apt/lists/* WORKDIR /app COPY target/order-service.jar app.jar # 显式指定 JVM 参数避免容器内存限制下 OOM ENTRYPOINT [java, -Xms256m, -Xmx512m, -XX:UseG1GC, -jar, app.jar]注意--platformlinux/amd64是强制构建目标平台的关键开关。M1/M2 用户务必加上否则默认构建 ARM 镜像部署到云服务器99% x86必然失败。-jre-slim比-jdk-slim小 120MB且微服务无需编译器JRE 足够。2.2 分层构建优化把依赖层和代码层彻底分离CI/CD 中节省 70% 构建时间Spring Boot 的 fat jar 包含所有依赖每次代码变更都重做整个镜像浪费 CI 时间和镜像仓库空间。正确做法是利用 Docker 多阶段构建 Maven 分层# 第一阶段构建依赖层仅当 pom.xml 变更时才重建 FROM maven:3.8.6-openjdk-17 AS builder WORKDIR /app COPY pom.xml . RUN mvn dependency:go-offline -B # 预下载所有依赖生成 target/dependency # 第二阶段构建代码层仅当 src/ 变更时才重建 FROM openjdk:17-jre-slim WORKDIR /app # 复用第一阶段下载的依赖缓存友好 COPY --frombuilder /root/.m2 /root/.m2 COPY --frombuilder /app/target/dependency /app/libs COPY target/*.jar app.jar # 使用 Spring Boot 的分层启动机制需 spring-boot-maven-plugin 2.4 ENTRYPOINT [java, -cp, app.jar:libs/*, org.springframework.boot.loader.JarLauncher]关键参数说明mvn dependency:go-offline提前拉取全部依赖到本地 Maven 仓库后续mvn package不再联网构建稳定COPY --frombuilder实现跨阶段依赖复用只要pom.xml不变/root/.m2层永远命中缓存JarLauncher启动方式比java -jar更快因为跳过 fat jar 解压过程直接加载 classpath。2.3 构建上下文瘦身.dockerignore不是可选项是防止COPY . .把.git和node_modules打进镜像的后悔药一个没配.dockerignore的Dockerfile可能把 2GB 的node_modules前端项目、.git含历史记录、target/旧 jar、logs/日志文件全塞进镜像。结果镜像体积暴涨 3 倍推送耗时翻 5 倍安全扫描报出上百个高危漏洞来自node_modules。标准.dockerignore必须包含.git .gitignore README.md target/ *.jar *.war node_modules/ npm-debug.log .DS_Store *.log .env血泪经验某次上线前发现镜像大小 1.2GBdocker history查看各层体积发现COPY . .占了 980MB。删掉.dockerignore后重新构建镜像降至 280MB —— 直接省下 70% 传输带宽和仓库存储。3. docker-compose.yml 不是配置清单而是服务协作的契约协议网络、依赖、健康检查缺一不可docker-compose.yml是微服务架构的“宪法”。它定义服务间如何通信、谁先启动、失败后怎么重启、健康状态如何判定。写错一行depends_on或漏掉healthcheck就会导致网关启动时后端服务还没 ready流量打过去全 503。3.1 网络模式选择default网络 vshostvsbridge—— 90% 的“连不上”问题源于网络隔离误判Docker 默认为docker-compose创建一个自定义 bridge 网络如myapp_default服务间可通过服务名直接通信curl http://user-service:8080。但新手常犯两个致命错误错误 1在docker-compose.yml中给所有服务加network_mode: host以为这样就能“通”。结果服务失去 Docker 网络隔离端口冲突频发且无法用服务名互相访问host模式下 DNS 不生效错误 2MySQL 服务用了network_mode: host但 Java 服务没配导致 Java 服务连localhost:3306连的是自己容器的 3306空而不是宿主机的 MySQL。✅ 正确做法全部使用默认 bridge 网络用服务名通信version: 3.8 services: api-gateway: image: registry.example.com/gateway:1.2.0 ports: - 8080:8080 environment: - SPRING_PROFILES_ACTIVEdocker # 依赖 user-service 启动完成但不保证其 ready depends_on: - user-service - order-service user-service: image: registry.example.com/user:1.1.0 # 关键不暴露端口给宿主机只允许内部服务调用 # ports: # ← 删除这一行外部通过网关访问 environment: - SPRING_DATASOURCE_URLjdbc:mysql://mysql:3306/userdb?useSSLfalse # 健康检查确保服务真正可用而非仅进程存活 healthcheck: test: [CMD, curl, -f, http://localhost:8080/actuator/health] interval: 30s timeout: 10s retries: 3 start_period: 40s mysql: image: mysql:8.0.33 environment: MYSQL_ROOT_PASSWORD: root123 MYSQL_DATABASE: userdb volumes: - mysql-data:/var/lib/mysql # MySQL 也走默认网络Java 服务用 mysql:3306 访问 # 不需要 ports: [3306:3306]除非本地调试需直连 volumes: mysql-data:参数详解depends_on只控制启动顺序不等待服务 ready。所以必须配合healthcheckhealthcheck.start_period: 40s给 Spring Boot 应用预留足够启动时间JVM Spring Context 初始化SPRING_DATASOURCE_URL中的mysql是服务名Docker DNS 自动解析为对应容器 IP。3.2 环境变量注入.env文件 environmentenv_file三层覆盖规则搞不清顺序就配错Docker Compose 环境变量有明确优先级environment字段 env_file.env文件。新手常把数据库密码写在.env又在environment里写死SPRING_PROFILES_ACTIVEdev结果生产环境启动时 profile 还是dev。✅ 推荐分层策略.env存放跨环境不变量如COMPOSE_PROJECT_NAMEmyapp,IMAGE_TAG1.2.0env_file存放环境专属敏感配置如prod.env存DB_PASSWORDprod123dev.env存DB_PASSWORDdev123environment存放服务级固定配置如JAVA_HOME/opt/java,TZAsia/Shanghai。# docker-compose.prod.yml services: user-service: image: user:${IMAGE_TAG} env_file: - ./config/prod.env # ← 优先级高于 .env environment: - JAVA_HOME/opt/java - TZAsia/Shanghai # 注意这里不能覆盖 prod.env 里的 DB_PASSWORD./config/prod.env内容SPRING_DATASOURCE_PASSWORDprod123 SPRING_PROFILES_ACTIVEprod玄学提醒env_file中的变量名不能有空格、不能用引号包裹否则 Docker 会静默忽略。SPRING_DATASOURCE_PASSWORD prod123❌SPRING_DATASOURCE_PASSWORDprod123✅。3.3 服务依赖与启动等待wait-for-it.sh不是银弹healthcheckrestart: on-failure才是正解很多教程教用wait-for-it.sh脚本等 MySQL 启动但这是反模式它只检测端口是否开放不验证 MySQL 是否真正可执行 SQL。曾有案例MySQL 容器端口开了但mysqld进程卡在初始化wait-for-it.sh认为已就绪Java 服务连接后抛CommunicationsException。✅ 正确方案用 Docker 原生healthcheckrestart策略组合services: mysql: image: mysql:8.0.33 healthcheck: test: [CMD, mysqladmin, ping, -h, localhost, -u, root, -proot123] interval: 20s timeout: 10s retries: 5 start_period: 60s # 给 MySQL 充足初始化时间 user-service: image: user:1.1.0 depends_on: mysql: condition: service_healthy # ← 关键等待 mysql 健康检查通过 restart: on-failure # MySQL 崩溃时自动重启 user-servicecondition: service_healthy是depends_on的增强版它等待被依赖服务的healthcheck返回healthy状态而非仅进程启动。4. 避坑微服务 Docker 化的 5 个高频翻车现场与根因修复4.1 现象服务启动后curl http://user-service:8080/actuator/health返回Connection refused但docker exec -it user-service sh进容器netstat -tuln | grep 8080显示端口未监听原因Spring Boot 默认绑定localhost127.0.0.1Docker 容器内localhost指向自身外部服务无法访问。解决在application-docker.yml中强制绑定0.0.0.0server: address: 0.0.0.0 port: 8080并在启动时激活该 profileSPRING_PROFILES_ACTIVEdocker。4.2 现象docker-compose logs -f api-gateway显示Failed to resolve user-serviceDNS 解析失败原因服务名拼写错误如user_servicevsuser-service或服务未在同一docker-compose.yml中定义跨文件需extends或networks共享。解决检查docker-compose.yml中服务名是否完全一致连-都不能错进入网关容器执行nslookup user-service确认 DNS 是否返回 IP若跨文件部署必须在networks下声明共享网络networks: default: external: name: myapp_default # ← 与主文件 network 名一致4.3 现象MySQL 容器启动成功但 Java 服务报Access denied for user root172.20.0.5原因MySQL 8.0 默认认证插件改为caching_sha2_password老版本 JDBC 驱动不兼容。解决在docker-compose.yml中为 MySQL 指定传统插件mysql: image: mysql:8.0.33 command: --default-authentication-pluginmysql_native_password environment: MYSQL_ROOT_PASSWORD: root123并确保pom.xml中 JDBC 驱动版本 ≥ 8.0.28。4.4 现象docker-compose up后docker ps显示服务状态为Restarting (1)循环重启原因健康检查失败如actuator/health返回DOWN触发restart: on-failure策略。排查步骤docker logs user-service查看启动日志定位 Spring Boot 启动失败原因常见数据库连接超时、Redis 密码错误临时注释healthcheck确认服务能否正常启动恢复healthcheck调整start_period如从 40s 改为 90s检查actuator/health是否被 Spring Security 拦截需配置management.endpoints.web.exposure.includehealth。4.5 现象Windows 上docker-compose up报错virtualization support not detected原因WSL2 未启用或 BIOS 中 VirtualizationVT-x/AMD-V未开启。解决Windows 10/11启用 WSL2PowerShell 管理员运行wsl --installBIOS 设置开机按 F2/Del 进 BIOS找到Intel Virtualization Technology或SVM Mode设为EnabledDocker Desktop 设置Settings → General → Use the WSL2 based engine勾选不要用--platformlinux/amd64强制构建WSL2 已原生支持 x86_64。5. 生产就绪用docker stack deploy替代docker-compose up实现真正的服务编排与滚动更新docker-compose up是开发测试神器但生产环境必须用 Docker Swarm 或 Kubernetes。Swarm 学习成本低docker stack deploy命令几乎兼容docker-compose.yml是平滑过渡首选。5.1 从docker-compose.yml到docker-stack.yml只需三处改造原docker-compose.yml字段docker-stack.yml改造点说明version: 3.8改为version: 3.8Swarm 支持 3.8无需降级ports: [8080:8080]改为publish: [8080:8080]Swarm 使用publish语法deploy:块缺失新增deploy配置控制副本数、更新策略、资源限制改造后docker-stack.yml示例version: 3.8 services: api-gateway: image: registry.example.com/gateway:1.2.0 deploy: replicas: 3 update_config: parallelism: 1 delay: 10s failure_action: rollback resources: limits: memory: 512M cpus: 0.5 ports: - published: 8080 target: 8080 mode: host # ← 关键host 模式让 Swarm 路由到任意节点 user-service: image: registry.example.com/user:1.2.0 deploy: replicas: 2 restart_policy: condition: on-failure networks: - myapp-network networks: myapp-network: driver: overlay # ← Swarm 必须用 overlay 网络5.2 滚动更新实操一条命令完成零停机发布假设你要将user-service从1.1.0升级到1.2.0# 1. 构建新镜像并推送到私有 Registry docker build -t registry.example.com/user:1.2.0 ./user-service docker push registry.example.com/user:1.2.0 # 2. 更新 stack自动触发滚动更新 docker stack deploy -c docker-stack.yml myapp # 3. 实时观察更新进度看到 old → new 逐个替换 docker service logs --follow myapp_user-serviceSwarm 会按parallelism: 1逐个停止旧容器、启动新容器期间replicas: 2始终保持至少 1 个实例在线用户无感知。关键技巧failure_action: rollback是后悔药。若新版本启动失败健康检查连续失败Swarm 自动回滚到上一版镜像无需人工干预。我线上集群已用此策略保障 3 年零发布事故。5.3 日志与监控用docker service logs Prometheus Grafana 搭建轻量可观测体系docker-compose logs只能看当前日志Swarm 需集中采集。推荐方案日志用docker service logs myapp_api-gateway --since 1h查最近 1 小时日志指标在 Spring Boot 服务中引入micrometer-registry-prometheus暴露/actuator/prometheus采集部署 Prometheus配置docker_swarm_sd_configs自动发现服务可视化Grafana 导入 Spring Boot Actuator DashboardID: 12856。Prometheus 配置片段scrape_configs: - job_name: swarm-services docker_sd_configs: - host: unix:///var/run/docker.sock role: tasks relabel_configs: - source_labels: [__meta_docker_task_label_com_docker_stack_namespace] regex: myapp action: keep - source_labels: [__meta_docker_task_container_port_number] regex: 8080 action: keep我的习惯上线新服务前必加spring-boot-starter-actuatormicrometer-registry-prometheus并用curl http://service-ip:8080/actuator/metrics验证指标端点可访问。没有指标等于在黑匣子里开车——你永远不知道服务是慢了、卡了还是假死了。希望帮到你。本文还有配套的精品资源点击获取