2. Docker Compose 编排进阶：多服务编排、依赖管理、健康检查、环境变量与配置管理

在微服务架构中，单一容器的管理远不能满足生产级需求。Docker Compose 作为多容器编排的核心工具，其进阶能力决定了服务集群的稳定性与可维护性。本章将深入剖析多服务编排、依赖管理、健康检查以及环境变量与配置管理四大核心模块，帮助你在压测与契约测试场景中构建高可用的服务拓扑。

2.1 多服务编排：从单体到拓扑

多服务编排的核心在于将多个相互依赖的容器定义为单一应用栈。通过 docker-compose.yml 文件，你可以声明式地定义服务、网络、卷与端口映射，实现一键启动与销毁。

以下是一个典型的多服务编排示例，包含 API 网关、用户服务、订单服务与数据库：

version: '3.8'

services:
  api-gateway:
    image: myapp/gateway:1.0
    ports:
      - "8080:8080"
    environment:
      - USER_SERVICE_URL=http://user-service:3001
      - ORDER_SERVICE_URL=http://order-service:3002
    networks:
      - frontend
      - backend

  user-service:
    image: myapp/user-service:1.0
    ports:
      - "3001:3001"
    environment:
      - DB_HOST=postgres-db
      - DB_PORT=5432
    depends_on:
      postgres-db:
        condition: service_healthy
    networks:
      - backend

  order-service:
    image: myapp/order-service:1.0
    ports:
      - "3002:3002"
    environment:
      - DB_HOST=postgres-db
      - DB_PORT=5432
    depends_on:
      postgres-db:
        condition: service_healthy
    networks:
      - backend

  postgres-db:
    image: postgres:15
    environment:
      POSTGRES_USER: app_user
      POSTGRES_PASSWORD: secure_pass
      POSTGRES_DB: microservices_db
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U app_user -d microservices_db"]
      interval: 10s
      timeout: 5s
      retries: 5
    networks:
      - backend

volumes:
  pgdata:

networks:
  frontend:
  backend:

2.2 依赖管理：启动顺序与条件控制

微服务之间存在明确的启动依赖关系。Docker Compose 通过 depends_on 指令控制服务启动顺序，但默认仅等待容器启动，不保证服务就绪。进阶用法需结合健康检查实现条件依赖。

2.3 健康检查：服务就绪的黄金标准

健康检查是确保服务真实可用的关键机制。Docker Compose 支持在服务级别定义 healthcheck 指令，通过周期性执行自定义命令判断服务状态。

健康检查的完整参数包括：

• test：执行的检查命令，支持 CMD、CMD-SHELL 或 NONE（禁用）。
• interval：检查间隔，默认 30s。
• timeout：单次检查超时，默认 30s。
• retries：连续失败次数后标记为 unhealthy，默认 3。
• start_period：启动宽限期，在此期间失败不计入 retries。

以下为不同服务的健康检查配置示例：

# PostgreSQL 数据库
healthcheck:
  test: ["CMD-SHELL", "pg_isready -U app_user -d microservices_db"]
  interval: 10s
  timeout: 5s
  retries: 5
  start_period: 30s

# Redis 缓存
healthcheck:
  test: ["CMD", "redis-cli", "ping"]
  interval: 5s
  timeout: 3s
  retries: 3

# Spring Boot 应用（通过 Actuator）
healthcheck:
  test: ["CMD", "curl", "-f", "http://localhost:8080/actuator/health"]
  interval: 15s
  timeout: 5s
  retries: 3
  start_period: 60s

2.4 环境变量与配置管理

环境变量是解耦配置与代码的核心手段。Docker Compose 提供多层级的变量注入方式，适用于不同环境（开发、测试、生产）。

2.4.1 变量注入方式对比

2.4.2 环境文件最佳实践

推荐使用 .env 文件管理环境变量，并通过 env_file 指令引用。以下为典型的分环境配置结构：

# 项目目录结构
project/
├── docker-compose.yml
├── .env.dev          # 开发环境
├── .env.test         # 测试环境
├── .env.prod         # 生产环境
└── secrets/
    ├── db_password.txt
    └── api_key.txt

docker-compose.yml 中引用方式：

services:
  user-service:
    image: myapp/user-service:1.0
    env_file:
      - .env.dev
    environment:
      - SERVICE_NAME=user-service  # 覆盖 env_file 中的同名变量
    secrets:
      - db_password

secrets:
  db_password:
    file: ./secrets/db_password.txt

2.5 配置管理进阶：Configs 与 Secrets

对于非敏感配置文件（如 Nginx 配置、Logback 配置），Docker Compose 提供 configs 机制；对于敏感数据，使用 secrets 机制。两者均支持文件挂载与运行时注入。

2.6 压测场景下的编排最佳实践

在契约测试与压测场景中，Docker Compose 编排需要额外关注以下要点：

• 资源限制：使用 deploy.resources.limits 为每个服务设置 CPU 和内存上限，避免压测时单服务耗尽宿主机资源。
• 日志驱动：配置 logging 驱动为 json-file 并设置 max-size 和 max-file，防止压测产生海量日志撑爆磁盘。
• 端口冲突规避：压测环境建议使用动态端口映射（ports: - "0:3001"），通过 docker compose port 获取实际端口。
• 网络延迟模拟：结合 tc 命令或专用网络插件，在 Compose 网络中注入延迟与丢包，模拟真实生产网络条件。