怎么使用 Docker Compose 编排适配云原生架构的轻量级应用实战

Docker Compose 可作为云原生演进起点，需遵循松耦合、声明式配置、可观测性前置、无状态优先、配置与镜像分离原则；服务须真正解耦、API 明确、禁直连数据库；配置用环境变量或外部中心；健康检查、多阶段构建、非 root 用户、结构化日志、内嵌指标、OpenTelemetry 追踪、secrets/volumes/networks 预留 K8s 接口。

用 Docker Compose 编排轻量级应用，本身不是云原生的“生产就绪”方案，但它可以作为云原生演进的起点——关键在于设计时就遵循云原生原则：松耦合、声明式配置、可观测性前置、无状态优先、配置与镜像分离。

服务拆分要真正解耦，别只是“物理隔离”

很多团队把单体应用简单拆成多个容器（比如 web + db + cache），但代码仍强依赖、共享数据库、同步调用阻塞，这不算云原生。真正的轻量编排应体现职责分离：

• 每个服务只暴露明确的 API（如 REST/gRPC），禁止直连其他服务数据库
• 用环境变量或外部配置中心（如 Consul、etcd）管理连接参数，不在 docker-compose.yml 里硬编码 host:port
• 为每个服务单独定义健康检查端点（如 /healthz），并在 healthcheck 中启用，供后续迁移到 Kubernetes 的 readiness/liveness 做准备

镜像构建必须面向运行时，而非开发环境

Docker Compose 的 build 段容易写成“本地构建+复制源码”，这会污染镜像、增加体积、破坏可重现性。推荐做法：

• 使用多阶段构建（multi-stage），仅将编译产物（如 Go 二进制、Node.js dist/）复制到精简运行镜像（如 alpine 或 distroless）
• 基础镜像统一指定明确标签（如 node:20.15-alpine），避免 latest 引发不可控更新
• 在 Dockerfile 中设置非 root 用户（USER 1001）并限制能力（cap-drop: ALL），Compose 文件中通过 user: 和 cap_drop: 显式声明

可观测性从 Compose 阶段就要集成

不能等上 K8s 才加日志和指标。轻量级应用可在 Compose 中低成本落地可观测三要素：

• 日志：服务统一输出结构化 JSON 到 stdout/stderr；用 logging.driver: "json-file" 并配 max-size/max-file 防磁盘打满
• 指标：在应用内嵌 Prometheus client（如 Python 的 prometheus_client、Go 的 promhttp），暴露 /metrics；Compose 中为监控服务（如 Prometheus）配置静态 job，抓取各服务 http://service-name:port/metrics
• 追踪：接入轻量 OpenTelemetry Collector（用 otel/opentelemetry-collector-contrib 镜像），服务通过 OTLP 协议上报 span，Collector 转发至 Jaeger 或 Zipkin

配置与生命周期管理需预留云原生接口

让 Compose 文件成为向 Kubernetes 迁移的“草稿”而非障碍：

• 用 env_file: 加载 .env，但避免敏感信息明文；改用 secrets: 定义（即使本地用 file driver），未来可平滑对接 K8s Secrets
• 网络模式统一用 networks: 自定义桥接网络，禁用 host 或 default，便于后续映射为 K8s NetworkPolicy
• 卷挂载优先用命名卷（volumes: 声明 + volume: 引用），而非绑定宿主机路径，这样迁移时只需替换为 PersistentVolumeClaim