大型网站docker容器化核心在于分层解耦、按需隔离、统一编排与安全可控，涵盖服务分层（接入/应用/数据/支撑层）、跨主机网络（swarm/k8s overlay）、镜像治理（多阶段构建、语义化标签、secrets管理）、可观测性（metrics/healthz、统一日志、资源限制）及弹性更新（readiness/liveness探针）。
大型网站用 Docker 做容器化架构，核心不是“堆容器”，而是分层解耦、按需隔离、统一编排、安全可控。重点在服务拆分粒度、网络通信效率、数据持久性保障和跨节点调度能力，不是单个容器怎么跑，而是整套系统怎么稳。
服务分层与容器职责划分
把网站按功能切为可独立部署、伸缩、升级的单元：
- 接入层：Nginx 或 Envoy 容器，做 SSL 终结、路由转发、限流熔断；不挂业务逻辑，只负责流量调度
-
应用层：Web 服务（如 Django/Node.js）、API 网关、认证中心等，每个服务一个镜像，通过标签区分环境（
prod-v2.4） - 数据层：MySQL、Redis、Elasticsearch 等不直接用官方镜像裸跑；必须配专用 Volume + 持久化策略（如 Redis AOF + RDB 双写到 NFS），且数据库类容器通常不水平扩缩，而靠读写分离或分库分表
- 支撑层：日志收集（Fluentd / Filebeat）、监控上报（Prometheus Exporter）、配置中心（Consul 容器化）、消息队列（RabbitMQ/Kafka 集群模式部署）
网络与服务发现设计
单机 bridge 网络完全不够用，必须跨主机通信：
- 生产环境推荐 Docker Swarm overlay 或直接上 Kubernetes；Swarm 轻量，K8s 功能全，二者都支持内置 DNS（
web容器可直接curl http://api:8080） - 避免用
host网络模式——虽性能高，但端口冲突、安全边界模糊，大型站禁用 - 对外暴露统一入口：Ingress Controller（如 Nginx Ingress）统一处理 TLS、WAF 规则、灰度路由，后端服务全部走内部 Service 名称通信
镜像与部署策略
镜像不是越小越好，而是要兼顾构建速度、运行安全、调试便利：
- 用多阶段构建（multi-stage）：Go/Java 项目编译阶段用
golang:1.21，运行阶段 COPY 二进制到alpine:3.18或distroless基础镜像 - 禁止使用
latest标签；所有镜像打语义化标签（v1.2.0-20260729），配合 CI 流水线自动推送私有仓库（如 Harbor） - 敏感配置（数据库密码、密钥）不打进镜像，改用
docker secrets（Swarm）或Secret对象（K8s），挂载为文件或注入环境变量
可观测性与弹性保障
没有监控的容器集群等于黑盒：
- 每个容器必须暴露
/metrics（Prometheus 格式）和健康检查端点（/healthz），由统一采集器拉取 - 日志统一输出到 stdout/stderr，由日志代理收集到 ELK 或 Loki；禁止容器内写本地文件
- 设置资源限制：
--memory=2g --cpus=2防止某个服务吃光宿主机资源；同时配置 OOMScoreAdj 和重启策略（restart: on-failure:3） - 滚动更新必须带健康检查就绪探针（readinessProbe）和存活探针（livenessProbe），失败自动回滚，不中断流量
