简介：内容为《Docker容器技术与微服务解决方案》Word文档，面向云计算开发者、架构师及技术管理者，用于快速建立对容器技术与微服务落地路径的整体认知。文档从Unix chroot谈起，梳理容器技术演化脉络，并围绕Docker的组成、实现机制与生态圈展开，重点说明Docker Hub、Docker Engine与Dockerfile在镜像分发和开发运维协同中的作用，分析容器技术如何助推DevOps与微服务架构的实践。文中还通过集装箱与码头工人的比喻，直观解释容器隔离、应用打包与虚拟机方案的差异，便于初学者理解抽象概念。资源共1个docx文件，约323KB，内容结构紧凑，适合直接阅读与检索。目前已有223人学习，适合作为入门阶段的体系化参考资料，帮助读者在较短时间内把握容器技术背景、Docker核心概念及其与微服务方案的关系，为后续深入实践提供清晰的路线铺垫。
1. 容器化改造做到一半就卡住的人，缺的往往不是 Docker 而是微服务的拆法
你大概率见过这类场景：团队把 Spring Cloud 项目塞进镜像，docker run 一条命令跑起来，觉得容器化已经完成了。可真到拆分的时候，服务拆了十几个，发现启动顺序没人管、配置改一处全链路要动、MySQL 和 Redis 换个环境就失联。最后得出一个结论——Docker 不难，难的是容器时代怎么重新组织你的服务。这个标题对应的正是这件事：把容器技术当作微服务落地的底层载体，而不是单纯把应用打成镜像。
这套方案的直接价值有三点：让每个微服务拥有独立的环境依赖，让部署从"手工登录服务器敲命令"变成"一条命令拉起整条链路"，再让存储这类有状态组件在容器里获得相对可靠的持久化方案。适合正在做微服务改造、被环境不一致和部署效率折磨的后端团队，也适合准备从单体过渡到微服务、想先搞清楚容器在其中到底扮演什么角色的人。下文按一条实际可走的路线展开：先补上 Docker 的三个底层认知，再把微服务拆成镜像规划，最后用 Docker Compose 跑通一个包含注册中心、网关、业务服务和 MySQL 的完整环境。
2. Docker 三件套的底层逻辑：镜像层、容器写时复制、数据卷的边界
2.1 镜像分层为什么能同时解决"构建慢"和"传输慢"
很多初学者把 Docker 镜像当成一台完整的虚拟机，这是第一个认知偏差。镜像的本质是一个只读的分层文件系统，每一层由 Dockerfile 中的一条指令生成。真正让镜像高效的是层与层之间的复用：基础镜像层（比如openjdk:11-jre）一旦存在于宿主机，后续构建只要在它之上追加变化的部分，不需要重新拉取整份基础层。
这里有个实际收益：团队十个微服务都用同一个 JDK 基础镜像，本地磁盘上只存一份基础层，启动时以只读方式共享挂载，每个容器只写入自己的可写层。从构建角度，改动业务代码后重新打包镜像，只有最上面的业务层需要重建，几十秒到几分钟不等，而不是每次从零开始。
Dockerfile 的指令顺序直接决定缓存命中率。按变更频率从低到高排列指令，是必须养成的习惯。常见的反面教材是这么做：
FROM openjdk:11-jre COPY target/app.jar /app.jar RUN apt-get update && apt-get install -y curl CMD ["java", "-jar", "/app.jar"]这种写法把RUN apt-get install放在COPY之后，只要 Jar 包内容变化，后面所有层的缓存全部失效，每次都要重新执行 apt 下载。更合理的顺序应该是先做依赖安装，再拷贝业务产物：
FROM openjdk:11-jre RUN apt-get update && apt-get install -y curl && rm -rf /var/lib/apt/lists/* COPY target/app.jar /app.jar EXPOSE 8080 CMD ["java", "-jar", "/app.jar"]关键点在于：RUN层只有指令字符串变化才会失效，COPY层只要文件内容有变化就失效。依赖安装指令的变更频率远低于业务代码，把它放在前面就能最大化利用缓存。另外&& rm -rf清理 apt 缓存列表，是为了单独这一层塞进镜像的东西不包含不需要的索引，瘦身效果在交付时更明显。
2.2 容器不是轻量虚拟机：进程、PID 1 与写时复制
容器和虚拟机的本质差异在隔离粒度。虚拟机虚拟的是硬件，跑完整内核；容器共享宿主机内核，隔离的是进程视角——文件系统、网络栈、进程号、用户权限各自独立，但 CPU 和内存调度仍由宿主机统一管理。这也是容器启动秒级而虚拟机需要几十秒的根本原因。
这个差异带来两个必须注意的行为：容器中的 PID 1 进程就是你在 CMD 或 ENTRYPOINT 里启动的进程。如果这个进程不是处理信号的核心进程，比如你写了一条CMD java -jar app.jar &，让 java 变成了后台子进程，那么 docker stop 发出去的 SIGTERM 信号会被 PID 1（此时是 shell）接住，但不一定会转发给 java，结果就是应用没有优雅退出而是被强制 SIGKILL。处理办法是：启动命令里务必让主进程以前台方式运行。Java 直接CMD ["java", "-jar", "/app.jar"]就行，Java 会成为 PID 1。
写时复制概念则关系到运行时的文件改动。容器可写层从镜像层复制出来的内存页，在进程首次写入时才会真正分配新空间。这意味着：容器内写文件不会改变镜像本身，容器删掉以后写入的内容全部丢失。镜像还是那份镜像，容器是可写层的临时态。搞清楚这个过程，你才能理解为什么数据卷是唯一可靠的持久化方案，后面第 4 章还要细说。
2.3 三个核心对象的边界：镜像、容器、仓库
这三个词是 Docker 体系里最容易被混在一起的。镜像（Image）是模板，不可变，描述"这个应用在什么环境里依赖什么运行"；容器（Container）是镜像的运行实例，有生命周期，能被启动、停止、删除；仓库（Registry）是镜像的存放与分发中心，内部部署用自建的 Registry，公有云上用云厂商镜像服务，本地开发时镜像只存在于 Docker 守护进程的存储里。
三者的关系想成类和对象的关系也不够准确，因为镜像的分层复用决定了它不是类那样完整的拷贝。更贴切的参照是：镜像是一份 git 提交记录里某个 commit 的完整文件快照，容器是把这个快照检出到一个临时工作区并开始运行，仓库是 remote 远端。这样类比，你就能理解"换个环境就能跑"为什么成立——镜像把环境固化了，容器运行时只是环境的实例化而已。
拉取和启动的常用命令需要放在手边：
docker pull registry.example.com/team-order/order-service:1.2.0 docker run -d --name order-service \ --network microservice-net \ -e SPRING_PROFILES_ACTIVE=prod \ -p 8082:8082 \ registry.example.com/team-order/order-service:1.2.0参数解释：-d后台运行，--name指定容器名，--network加入自定义网络让容器之间用服务名互通，-e注入环境变量覆盖配置，-p做端口映射。容器间通信用自定义网络，不推荐--link这种老机制，后面也会反复强调。docker ps -a查看全部容器状态，docker logs -f <容器名>跟踪日志排查启动问题，这两条命令是排障入口。
3. 微服务和 Docker 的选型理由：从单体到容器化服务的拆分策略
3.1 为什么微服务架构的落地必须借助容器而不是虚拟机
朝微服务拆的第一步通常是给每个服务独立部署，但独立部署和独立运行是两码事。没有容器时，一台机器上要部署多个服务实例，最直接的问题是端口冲突、JDK 版本冲突、配置文件互相污染。每个服务依赖的运行时底子可能不一样——这个服务要 Java 11，那个服务刚升级到 Java 17，还有用 Python 写的辅助服务。虚拟机确实能隔离，但一台虚拟机几个 GB 内存起步、启动分钟级，按服务数量开虚拟机，运维成本和资源成本都不可接受。
Docker 站在中间恰好解决了两难：同一台物理机可以同时跑几十个容器，容器之间共享内核、隔离文件与进程，内存开销只在进程实际使用量之上加一点点。更关键的是，镜像把 JDK、依赖库、配置文件全部固化，开发本机、测试环境、生产环境看到的是同一个启动产物，环境差异被压缩到只剩宿主机内核和系统调用层面。迁移部署从"配环境"变成"拉镜像、跑容器"，这是微服务规模化部署的前提。
按一个实际拆分过程的经验来看，拆服务不是按代码目录拆，而是按性能和团队 ownership 拆。最小可用拆分标准是：数据库表按业务域归属、服务间通过 API 通信且不直接读彼此的库表、每个服务独立发布和回滚。达不到这个标准的拆分只是把单体代码搬了几个模块，Docker 也救不了这种名义上的微服务。
适合先拆出来容器化的服务类型有这几类：跟主单体交互少的辅助功能（短信、邮件通知、导出任务），有明显的独立伸缩需求的功能（商品详情、搜索），外部依赖多但自己逻辑薄的中间层（对接微信、对接第三方 API）。这类服务往往体积小、部署频率高，容器化的收益在第一次上线时就能看到。
3.2 服务、配置、网关、注册中心：一张镜像规划表决定后续运维效率
微服务容器化之前先做镜像规划，比急着写 Dockerfile 更重要。这里说的规划不是指命名规范这类表面工作，而是确定每个服务的镜像基础、配置来源、运行方式。一个常见翻车场景是：所有 Spring Boot 服务都复制同一份 Dockerfile，基础镜像全用带完整 JDK 的版本，结果磁盘占用翻倍。合理的规划是把基础镜像分成两类。
应用类服务（业务后端）建议用openjdk:11-jre-slim这类精简 JRE 镜像，只保留运行环境；而构建类任务（需要编译代码、生成静态资源）才需要完整 JDK 镜像。另一个要点是启动内存参数：容器内的 JVM 需要显式限制堆内存，否则 JVM 默认按宿主机内存的 1/4 申请堆，一台 64G 的机器上十几个服务容器等于每个都宣称要 16G，实际跑起来虽然没立即崩，但系统内存会被预留机制拖垮。在启动命令里加JAVA_OPTS环境变量，控制每个容器的堆上限是必须做的。
网关、注册中心这类基础组件选型同样影响容器编排复杂度。Spring Cloud 体系下，注册中心用 Nacos 或 Eureka，网关用 Spring Cloud Gateway。Nacos 自身依赖 MySQL 存储配置，这意味着你要额外规划一个 MySQL 容器；Eureka 则是一个纯服务端不需要外部存储，自己就能跑。如果你只需要服务发现和配置管理，不想为配置中心单独搞一套数据库，Eureka 更省事；但 Nacos 的配置热更新和命名空间隔离在服务数量多之后更省心。
下面是一张给中小团队做参考的镜像规划表，不用严格按照列来执行，但每项都值得过一遍：
| 服务角色 | 基础镜像建议 | 进程数 | 端口策略 | 存储需求 |
|---|---|---|---|---|
| 注册中心/配置中心 | openjdk:11-jre-slim | 1 | 8848 或 8761 | 外部 MySQL（若用 Nacos） |
| API 网关 | openjdk:11-jre-slim | 1 | 8080 | 无 |
| 业务服务（订单、用户等） | openjdk:11-jre-slim | 1 | 不同段位不同服务 | 无，数据经 JDBC 写 DB |
| MySQL 5.7/8.0 | 官方mysql:8.0 | 1 | 3306（不对外暴露更佳） | 命名卷 |
| Redis 主从 | 官方redis:7-alpine | 1 主 + 1 从 | 6379/6380 | 命名卷或 AOF 文件目录 |
端口策略这块新手最容易孟浪：所有服务都把端口映射到宿主机上，导致端口规划冲突，服务数量一多很难记住谁占了哪个口。在 Docker 自定义网络里，容器之间通过服务名互访，根本不需要映射端口到宿主机。只有需要对外提供访问的服务——比如网关、管理后台——才做端口映射。数据库、注册中心这些内部组件，不映射到宿主机反而更安全。
3.3 服务拆分覆盖：独立部署、独立伸缩与独立排障
微服务的三个基本追求——独立部署、独立伸缩、独立故障域——用容器来表达有非常直接的对应关系。
独立部署对应"每个服务一个镜像，镜像 Tag 即版本"。回滚时只需要把编排文件里的镜像 Tag 改回上一版，重新部署即可，不需要重新构建。如果你把多个服务塞进同一个容器，就失去了这个能力——改其中一服务就要重新构建整体镜像，回到单体式部署。
独立伸缩对应"同一个镜像跑 N 个容器实例"。通过 Docker Compose 的--scale参数或 Kubernetes 的副本数控制，在流量高峰期临时扩容某服务。这里要提前做的一步是：服务实例数一多，负载均衡不再由网关轮询实现，而是要靠注册中心配合客户端负载均衡组件（比如 Spring Cloud LoadBalancer、OpenFeign）做服务间的调用均衡。容器化的下一步自然长出了这个需求。
独立故障域对应"容器崩溃不影响宿主机和其他容器"。容器进程异常退出、OOM 被杀，影响范围只在这个容器内，其他服务照常运行。真正的风险是服务挂了但容器没挂——比如 Spring Boot 应用端口监听失败，进程还活着，负载均衡还是会把请求转过去报错。应对措施是配置健康检查，容器化环境里的健康检查探活方式在后面会给出。
4. 用 Docker Compose 跑通一套微服务环境：最小可行配置与三处必调参数
4.1 Compose 文件结构：把服务、网络、数据卷一次定义
Docker Compose 是单机多容器编排的事实标准，不需要额外引入 Kubernetes 就能把注册中心、网关、三个业务服务、MySQL、Redis 一次性拉起。Compose 的核心价值是"声明式部署"——把服务列表、网络关系、卷挂载、环境变量写进一个 YAML 文件，docker compose up -d一键启动，docker compose down一键清理。
写一个最小的微服务环境定义文件，包含注册中心（这里用 Eureka，省去外部数据库）、网关、一个业务服务和 MySQL：
version: "3.8" services: eureka-server: image: registry.example.com/infra/eureka-server:1.0.0 container_name: eureka-server ports: - "8761:8761" environment: - EUREKA_INSTANCE_HOSTNAME=eureka-server networks: - microservice-net gateway: image: registry.example.com/infra/gateway:1.0.0 container_name: gateway ports: - "8080:8080" environment: - SPRING_PROFILES_ACTIVE=docker - EUREKA_CLIENT_SERVICEURL_DEFAULTZONE=http://eureka-server:8761/eureka/ depends_on: - eureka-server networks: - microservice-net order-service: image: registry.example.com/biz/order-service:1.2.0 container_name: order-service environment: - SPRING_PROFILES_ACTIVE=docker - EUREKA_CLIENT_SERVICEURL_DEFAULTZONE=http://eureka-server:8761/eureka/ - SPRING_DATASOURCE_URL=jdbc:mysql://mysql:3306/order_db?useSSL=false&serverTimezone=Asia/Shanghai - SPRING_REDIS_HOST=redis-master depends_on: - eureka-server - mysql - redis-master networks: - microservice-net mysql: image: mysql:8.0 container_name: mysql ports: - "3306:3306" environment: - MYSQL_ROOT_PASSWORD=root123456 - MYSQL_DATABASE=order_db volumes: - mysql-data:/var/lib/mysql networks: - microservice-net redis-master: image: redis:7-alpine container_name: redis-master command: ["redis-server", "--appendonly", "yes"] volumes: - redis-data:/data networks: - microservice-net volumes: mysql-data: redis-data: networks: microservice-net: driver: bridge这份配置要解释清楚三个层面的逻辑。services段定义每个容器实例，environment段注入环境变量来覆盖 Spring Boot 的配置。重点看 order-service 的数据库地址：jdbc:mysql://mysql:3306/order_db，这里用的主机名是mysql而不是localhost——因为在自定义网络里，容器之间通过服务名解析 IP。你不需要知道 MySQL 容器实际的 IP，网络自动做 DNS 解析。如果拿到外部团队的代码库，第一步找他们把数据库地址从localhost改掉，否则容器里连的是容器自己的回环地址。
depends_on控制启动顺序。但要注意它是等容器启动，不等待容器内的应用就绪。Eureka 容器起来了不代表 Eureka 进程已经能接受注册请求，所以 order-service 可能会在 Eureka 还没就绪时就开始注册然后报错。Spring Cloud 客户端有重试机制，通常会自动恢复，但如果你的服务没有注册失败重试，就需要在 depends_on 基础上再配合健康检查来控制真正就绪。
volumes段定义的命名卷是数据库和 Redis 数据持久化的核心，必须理解：容器删除后，写在可写层的数据全部消失。MySQL 的数据写在/var/lib/mysql，如果不挂卷，容器重建一次数据库就清空一次。命名卷由 Docker 管理，存储在宿主机/var/lib/docker/volumes/下，跨容器重建保留数据。redis-master的--appendonly yes开启 AOF 持久化，把写操作日志追加到/data下的文件里，防止 Redis 进程重启后丢数据。
4.2 构建并启动：从陌生项目到环境就绪的五步实操
到一个新项目仓库，想快速起一套容器化微服务环境，我通常会按下面五个步骤走。这套流程不是唯一正确答案，但能避免多数环境问题。
第一步，确认代码库里的配置是否面向容器环境。打开application.yml或application-docker.yml，检查三处：数据库连接地址是否为容器服务名、注册中心地址是否为容器服务名、Redis 地址是否为容器服务名。只要有一个还写着127.0.0.1，容器里就跑不通，先改配置再构建镜像。
第二步，构建镜像。在项目根目录执行：
mvn clean package -DskipTests docker build -t registry.example.com/biz/order-service:1.2.0 .构建标签（tag）包含 registry 地址、命名空间、服务名和版本号四段，这是为后续推送私有仓库做准备的规范。本地测试阶段不打 registry 地址也能跑，但建议从第一天就按完整 Tag 构建，避免以后推送时还要重新打 Tag。
第三步，编辑 Compose 文件。把镜像 Tag 改成刚构建好的版本，核对环境变量里的注册中心地址和数据库账号密码。这里建议不用${VAR}占位符，直接把默认值写清楚，至少在第一次跑通之前保持简单。
第四步，启动并观察：
docker compose up -d docker compose ps docker compose logs -f order-serviceup -d后台启动全部服务，ps查看各容器状态，logs -f跟踪单个服务的日志。服务启动失败时，先看日志尾部，而不是盯着ps显示的 Exited 状态猜原因。大部分启动失败在日志里有明确提示：配置中心地址连不上、数据库密码错、端口被占用。
第五步，验证链路。网关映射了宿主机8080端口，可以用 curl 测试：
curl http://localhost:8080/api/order/1这步能确认网关到注册中心到具体服务的转发链路是通的。返回 JSON 结构说明整条链路正常。如果返回 503 或连接拒绝，按日志逐层排查，排查方法在下一章展开。
4.3 必调参数：JVM 堆限制、Spring Profile、MySQL 时区
三个参数几乎每个 Java 微服务容器都要调，不调就等着踩坑。
第一个是 JVM 堆限制。容器内 JVM 如果不显式限制堆内存，它会按宿主机物理内存的 1/4 申请。一台 32G 的机器上跑八个服务容器，每个 JVM 都认为自己可以申请 8G 堆，系统可用内存很快被"虚拟承诺"耗尽，触发频繁 GC 甚至被操作系统 OOM Killer 杀进程。解决办法是在启动命令里加上堆限制：
ENTRYPOINT ["sh", "-c", "java $JAVA_OPTS -jar /app.jar"]配合 Compose 里设置环境变量：
environment: - JAVA_OPTS=-Xms256m -Xmx512m-Xms初始堆大小，-Xmx最大堆大小。小服务给 256m 起步，大服务按实际压测结果给到 1g—2g。原则是：尽量比单机部署时给的堆上限小，因为容器本身还需要一点非堆内存，宿主机还要承担所有容器累加的内存总和。
第二个是 Spring Profile。同一个镜像要能跑在开发、测试、生产环境，靠的是 Spring Boot 的多 Profile 配置机制。Compose 里的SPRING_PROFILES_ACTIVE=docker会让 Spring Boot 加载application-docker.yml，里面的配置覆盖application.yml。建议规范是：application.yml只保留公共配置，各环境的差异化配置（数据库地址、Redis 地址、日志级别）放进对应 Profile 文件。
第三个是 MySQL 时区。MySQL 8.0 默认时区是 UTC，而国内业务库通常需要东八区。连接串里不指定serverTimezone会出现 8 小时的时间差。两种解法：一是在 JDBC URL 后面加serverTimezone=Asia/Shanghai；二是在 MySQL 容器启动时加参数：
command: - --default-time-zone=+8:00推荐同时做。JDBC URL 保证应用侧连接是东八区，MySQL 侧参数保证直接连数据库查询时时间也正确。还有一个小坑：MySQL 8.0 默认认证插件是caching_sha2_password，老版本的连接驱动不支持，如果用的驱动版本旧，需要在 MySQL 容器加一条command: --default-authentication-plugin=mysql_native_password，新驱动（8.x 对应版本）没有这个问题。
5. 容器环境逃生手册：启动失败、网络不通、数据丢失的排障路径
5.1 Docker Desktop 启动失败：Virtualization support 检测不过
现象：Windows 上安装 Docker Desktop 后启动报virtualization support not detected或类似提示，Docker Desktop 无法进入运行状态。这在企业和个人 Windows 环境里出现频率极高，几乎一半以上首次安装失败都和这个有关。
原因：Docker Desktop 在 Windows 上跑本地容器引擎依赖 WSL2 或 Hyper-V 虚拟化，而主板 BIOS 的虚拟化开关没有打开，或 Windows 功能里没有启用 WSL2 子系统。还有一种情况：电脑上已经装了其他虚拟机软件（比如老版本 VirtualBox、VMware），占用了 Hyper-V 的冲突资源。
解决按三步走：先进 BIOS 开启 Virtualization Technology（VT-x），不同主板厂商入口不同，但关键词都是 Virtualization、SVM Mode 这类；再以管理员身份在 PowerShell 执行wsl --install安装 WSL2，装完重启；最后在 Windows 功能里勾选"适用于 Linux 的 Windows 子系统"和"虚拟机平台"。如果已经装过 Docker Desktop 且以上都开了，把 Docker Desktop 卸载重装一次能解决大部分"启动到一半退出来"的玄学问题。检查 WSL 状态用wsl --status和wsl --list --verbose。
5.2 docker pull 慢到超时的处理：镜像源配置与拉取策略
现象：docker pull mysql:8.0卡在某个层数小时不动，或报net/http: TLS handshake timeout。国内访问 Docker Hub 的公共仓库速度不稳定，尤其大镜像，失败率很高。
原因：镜像仓库的默认远端在国外，拉取链路跨地域、跨网络，中间任何一跳不稳定就会卡住或超时。
解决：在 Docker 守护进程配置里加国内可用的镜像加速地址。Linux 上编辑/etc/docker/daemon.json：
{ "registry-mirrors": [ "https://docker.m.daocloud.io", "https://dockerproxy.com" ] }保存后执行sudo systemctl restart docker或重启 Docker Desktop。Docker Desktop 用户是在设置界面里的 Docker Engine 选项中编辑这段 JSON，再点 Apply & Restart。注意：加速只对 Docker Hub 官方仓库生效，拉取自建私有仓库镜像不走加速器。另外一个小策略：给镜像打 Tag 时不要全部拉 latest，指定具体版本号可以复用到本地已有的层，减少实际下载的数据量。
5.3 容器间网络不通：自定义网络与服务名的正确用法
现象：order-service 容器内 ping 不通 mysql，或 Spring Boot 启动日志里报Communications link failure，连不上数据库。新手第一反应是去查 IP 地址，然后发现容器 IP 每次重建都在变。
原因：容器默认加入的是bridge网络，在这个网络里容器之间不能通过容器名直接互访，只有通过--link机制显式建立连接才能用别名访问。如果没有进入同一个用户自定义网络，它们之间的网络是隔离的，就算宿主机能 ping 通，容器之间也互不可见。更麻烦的是，桥接网络的容器 IP 是动态分配的，写死 IP 在容器重建后立刻失效。
解决：给所有服务加入同一个自定义网络，在 Compose 里已经演示过networks: microservice-net的写法。还有一种临时排障方式，手动创建一个网络并把容器加进去：
docker network create microservice-net docker network connect microservice-net mysql docker network connect microservice-net order-service验证连通性可以进入容器内 ping：
docker exec -it order-service ping mysql这条命令能直接验证网络层通不通。网络层通则继续检查 MySQL 的账号权限和监听地址，网络层都不通就先排查网络归属。
5.4 容器启动秒退：日志里到底写了什么
现象：docker compose up -d后观察ps发现容器状态是Exited (1)，几秒内退出。这类问题最容易让新手卡住，因为容器已经退出，看不到任何运行现场。
原因：启动即退出基本是应用进程自己退出，常见有三类——Spring Boot 端口被占用、配置中心连不上导致启动失败、启动命令不存在或权限不对。容器退出后不是什么都没有，日志照样保留。
解决：不要反复重启，先看日志：
docker logs order-service日志里有明确的异常堆栈，把关键行贴到搜索引擎往往能找到答案。如果日志为空，检查启动命令是否存在：docker inspect order-service查看Config.Cmd和Entrypoint是否拼写正确。还有一个容易忽略的情况：基础镜像的用户权限。如果基础镜像用的非 root 用户，而你的应用目录是 root 所有，应用没有权限写日志文件就会静默退出，解决方案是在 Dockerfile 里显式RUN chown或改用 root 用户运行（Java 应用这层通常问题不大）。
5.5 容器删除后 MySQL 数据丢了：数据卷与备份习惯
现象：某天为了清环境执行了docker compose down，再次up之后发现所有数据库表、用户账号全没了，几个月的数据烟消云散。
原因：Compose 文件里没有声明volumes挂载，MySQL 的数据只写在容器的可写层，容器一删，数据跟着没了。没有外挂数据卷，就没有后悔药。
解决：写 Compose 时务必为有状态服务声明命名卷（注意是volumes:顶层声明，而不是 service 内部写法）。这还不够，命名卷只是防止容器删除丢数据，宿主机磁盘损坏、误删/var/lib/docker/volumes依然丢。生产环境要有备份习惯，定时导出 MySQL：docker exec mysql mysqldump -uroot -p --all-databases > backup.sql，配合 cron 或 CICD 流水线，把备份文件传到独立存储。数据这东西，出一次事故比做一百次备份都贵。
6. 最后再上一个台阶：镜像瘦身与一条命令完成微服务环境清理与重建
到这步你已经能拉起整套微服务环境，接下来值得花时间做两件事：镜像瘦身和日常清理。微服务数量多起来后，镜像体积直接决定部署耗时和磁盘成本。Java 服务的镜像瘦身思路是多阶段构建——用完整 JDK 镜像做编译，用精简 JRE 镜像做运行时，最终产物只包含运行所需的最小集合。
一个典型的 Spring Boot 多阶段构建 Dockerfile 长这样：
FROM maven:3.8-openjdk-11 AS builder WORKDIR /build COPY pom.xml . RUN mvn dependency:go-offline COPY src ./src RUN mvn package -DskipTests FROM openjdk:11-jre-slim WORKDIR /app COPY --from=builder /build/target/order-service.jar ./app.jar EXPOSE 8082 ENTRYPOINT ["sh", "-c", "java $JAVA_OPTS -jar /app.jar"]逻辑说明：第一阶段叫 builder，用 Maven 镜像完成依赖下载和打包，dependency:go-offline先把依赖拉全并缓存，源码变动时不会重新下载依赖。第二阶段只有 JRE 和打好的 Jar，体积可能只有第一阶段的 1/3 甚至更小。这个方案还能顺带解决前面说的"Jar 包没变时每次重新拉依赖"的问题，因为mvn dependency:go-offline和mvn package是两个 RUN 层，依赖层缓存命中后 package 层才会执行。
日常维护微服务环境还习惯用一套清理命令。开发机上容器和镜像越积越多，磁盘告警是迟早的。我的习惯是：
docker compose down docker system prune -f docker image prune -f第一条把服务容器和自定义网络全部清掉；第二条清理停止的容器、未使用的网络和构建缓存；第三条清理悬空镜像（没有 Tag 的中间层镜像）。这三条命令的共性风险是：prune会删掉未使用的资源，如果有些容器只是临时停止还需要保留数据，确认在down之前数据已经进了数据卷。有 MySQL 数据卷的机器执行prune不受影响，因为卷不在prune默认清理范围里。
验证一套环境是否健康的最终手段是看两个指标：容器重启次数和日志中的 ERROR 密度。用下面这条命令能看到所有容器的运行时长和重启次数，任何频繁重启的服务都要打上问号：
docker ps -a --format "table {{.Names}}\t{{.Status}}\t{{.RestartCount}}"把这条命令放进日常巡检脚本里，第一次跑就能揪出那些"看起来活着其实天天重启"的问题容器。
这套 Docker 加微服务的组合我前后带过三个团队落地，最大的教训是同一个：技术选型不是瓶颈，团队愿不愿意在配置管理、镜像规范这些"看不到的东西"上花时间才是瓶颈。你照着本文把第一套环境跑通，只完成了 20% 的工作量，剩下 80% 是把镜像 Tag 规范、环境变量管理、数据备份节奏这些习惯固化到每天的开发流程里。希望帮到你。
本文还有配套的精品资源，点击获取
