当微服务数量从个位数增长到几十个时，最棘手的往往不是业务逻辑，而是运行环境的一致性。订单服务依赖的 JDK 版本、支付服务需要的原生库、网关对 OpenSSL 的兼容要求，任何一处差异都可能导致代码在开发机正常运行、上线后频繁崩溃。Docker 的镜像机制恰好把操作系统层、依赖库和应用代码打包成一个不可变单元，使得同一份构建产物可以无差别地运行在开发、测试和生产环境。下文从镜像构建、本地编排、网络通信和生产部署四个层面展开。
微服务与 Docker 的契合点：镜像分层与不可变交付
微服务架构的核心价值在于每个服务可以独立开发、独立部署、独立伸缩。但在传统虚拟机或物理机部署模式下，运维人员需要为每台机器安装相同版本的操作系统、中间件和依赖库。一旦某个服务的依赖升级，就不得不重新配置整台服务器，甚至影响其他服务。这种部署方式让微服务的独立性大打折扣。Docker 容器则把应用运行所需的一切都封装进镜像，开发团队交付的不再是代码包和部署文档，而是一个可以直接运行的镜像。
镜像分层机制是 Docker 高效构建和复用的基础。每一条 Dockerfile 指令都会创建一个新的只读层，例如基础镜像层、安装依赖层、复制代码层。多个微服务共享同一个基础镜像时，底层数据只需下载一次。这样不仅节省磁盘空间，也加快了构建和分发速度。更重要的是，镜像构建完成后内容不可变，任何配置变更都应当重新构建镜像，而不是进入容器内部手动修改。这种不可变交付的方式让开发、测试和生产环境的差异降到最低，也避免了因手工操作导致的环境漂移。
与虚拟机相比，容器共享宿主机内核，启动时间从分钟级缩短到秒级。微服务需要频繁启动、停止和扩容，容器的轻量特性能够显著提升弹性伸缩效率。例如一台 8 核 16G 内存的宿主机可能只能运行十几个虚拟机，却可以同时承载几十个甚至上百个容器。当然，容器也有资源隔离不如虚拟机的短板，因此对于数据库等需要强隔离的组件，仍然建议单独部署或使用裸金属。
高质量 Dockerfile 实践：多阶段构建与最小权限
构建微服务镜像时，最常见的问题是镜像体积过大。很多团队直接在基础镜像中安装编译工具链，然后打包应用，导致最终镜像包含大量构建期依赖。比如使用 golang:1.22 直接构建，镜像可能超过 800MB，而实际运行程序只有十几 MB。多阶段构建可以很好地解决这个问题。第一阶段使用完整编译环境生成二进制文件，第二阶段只复制编译产物到精简的运行镜像中，最终镜像只包含运行所必需的内容。
下面是一个 Go 微服务的多阶段构建示例。构建阶段使用官方 Go 镜像，运行阶段使用 Alpine Linux，并添加非 root 用户和健康检查，提升镜像的安全性和可维护性。
# 多阶段构建示例：Go 微服务 FROM golang:1.22-alpine AS builder WORKDIR /app COPY go.mod go.sum ./ RUN go mod download COPY . . RUN CGO_ENABLED=0 GOOS=linux go build -o /order-service FROM alpine:3.20 RUN adduser -D appuser USER appuser COPY --from=builder /order-service /usr/local/bin/order-service EXPOSE 8080 HEALTHCHECK --interval=30s --timeout=3s --start-period=10s \ CMD wget -q -O /dev/null http://127.0.0.1:8080/health || exit 1 ENTRYPOINT ["/usr/local/bin/order-service"]
这个 Dockerfile 有几个值得注意的细节。第一，COPY go.mod go.sum ./ 和 RUN go mod download 放在复制源代码之前，可以充分利用 Docker 的构建缓存。只要依赖文件不变，这一层就不会重新下载依赖，大幅提升构建速度。第二，运行阶段使用 adduser -D appuser 创建普通用户并用 USER 切换，避免容器内进程以 root 权限运行带来的安全风险。第三，HEALTHCHECK 指令定义了健康检查方式，为后续编排工具判断服务状态提供依据。
构建时还应当使用 .dockerignore 文件排除本地开发文件。例如排除 .git、.env、node_modules、测试报告等，避免将这些体积大且与运行无关的内容复制进构建上下文。否则不仅构建变慢，还可能把本机敏感配置打进镜像，造成安全隐患。
使用 Docker Compose 编排本地微服务
在本地开发微服务时，通常会同时启动网关、订单服务、库存服务、消息队列和缓存等多个组件。如果每次都用 docker run 手动启动，命令会非常冗长，而且难以维护服务间的依赖和网络关系。Docker Compose 通过 YAML 文件声明所有服务、端口、环境和依赖，开发人员只需执行一条 docker compose up -d 就能拉起整个环境。
以下是一个简化的微服务编排文件，包含网关和订单服务两个容器。订单服务暴露 8080 端口供网关内部调用，网关对外开放 8080 端口。通过 depends_on 结合健康检查，确保订单服务就绪后再启动网关，避免网关提前启动导致连接失败。
version: "3.9"
services:
gateway:
image: gateway:1.0
build: ./gateway
ports:
- "8080:8080"
environment:
ORDER_SERVICE_URL: http://order-service:8080
depends_on:
order-service:
condition: service_healthy
order-service:
image: order-service:1.0
build: ./order-service
expose:
- "8080"
healthcheck:
test: ["CMD", "wget", "-q", "-O", "/dev/null", "http://127.0.0.1:8080/health"]
interval: 10s
timeout: 3s
retries: 5
deploy:
replicas: 2
networks:
default:
driver: bridge
这里的 depends_on 配置了 condition: service_healthy，要求订单服务的健康检查连续通过后才会启动网关。如果只是用简单的 depends_on 而不加健康检查条件，Compose 只保证容器启动顺序，却不保证应用内部是否真正就绪。对于服务启动时间较长的场景，健康检查条件非常关键。另一个容易忽略的点是 expose 和 ports 的区别。expose 只在同一网络内开放端口，不会映射到宿主机，更安全；ports 则会将宿主机端口映射到容器，供外部访问。
容器网络与服务发现：让微服务互相访问
微服务之间的通信必须依赖稳定的服务发现机制。Docker 提供了内建的 DNS 解析功能，在自定义 bridge 网络中，每个容器都可以通过服务名或网络别名访问其他容器。例如在上面的 Compose 文件中，网关只需要访问 http://order-service:8080，不需要知道订单容器的 IP 地址。即使订单服务重启或扩容，Compose 也会通过网络别名将请求分发到健康的容器实例。
创建自定义网络能够让服务间的通信更加清晰，同时也可以隔离不同项目。可以使用以下命令手动创建网络，并让容器加入网络：
docker network create microservice-net docker run -d --name order-service --network microservice-net order-service:1.0 docker run -d --name gateway --network microservice-net -p 8080:8080 gateway:1.0
自定义 bridge 网络的一个重要优势是支持容器名解析。只要容器加入同一个网络，就能直接用 --name 指定的名称互相访问。生产环境中如果使用 Docker Swarm 或 Kubernetes，服务发现机制会更复杂，例如 Swarm 的 VIP 模式或 Kubernetes 的 Service 资源，但底层思路一致：不要让服务依赖具体 IP，而是使用稳定的逻辑名称。
网络隔离同样不容忽视。不要把数据库、缓存等内部组件暴露到宿主机公网端口。可以在 Compose 中定义多个网络，例如 frontend 和 backend，让网关同时连接两个网络，订单服务只连接 backend，数据库只连接 backend。这样即使网关被攻击，也较难直接访问到数据库，符合微服务纵深防御的原则。
生产部署的健康检查、日志与滚动更新
容器进入生产环境后，健康检查是第一道防线。通过 Dockerfile 中的 HEALTHCHECK 指令或编排文件中的健康检查配置，编排系统可以自动识别不健康的实例并将其从负载均衡池中摘除。健康检查命令应尽量轻量，可以单独实现一个 /health 接口，只检查程序是否存活以及依赖的核心资源是否可用，例如数据库连接是否正常。避免健康检查执行复杂的业务逻辑，否则会拖慢服务探活，甚至导致雪崩。
日志管理是容器化微服务的另一个重点。容器标准输出和标准错误是日志的默认出口，生产环境建议统一使用 json-file 或 journald 日志驱动，再配合 Filebeat、Fluentd 等采集器转发到集中日志平台。不要在容器内部写文件日志到可写层，这样不仅占用空间，还会在容器销毁时丢失。更合理的做法是让应用直接输出到 stdout，由宿主机或采集器统一处理。
滚动更新可以借助 Docker Swarm 或 Kubernetes 实现零停机发布。以 Swarm 为例，在服务定义中配置 update_config 的并行度和失败回滚策略，就能在发布新版本时逐个替换旧容器。每次更新都应当使用新的不可变镜像，而不是在旧容器中做原地修改。配合健康检查，如果新版本实例启动后探活失败，更新过程会自动暂停或回滚，避免影响线上流量。这种基于镜像版本和健康检查的发布方式，正是微服务频繁迭代与高可用要求之间的平衡点。