docker灰度发布核心在于镜像标签管理、流量调度与自动化协同，需通过语义化标签（如v1.3.1-canary）、nginx/service mesh分流、docker-compose/k8s平滑切换及自动校验回滚实现可识别、可分流、可验证、可回退的闭环流程。
用 Docker 实现快速灰度发布，关键不在容器本身，而在于镜像标签管理、流量调度和自动化协同。核心是让新版本“可识别、可分流、可验证、可回退”，整个过程不依赖复杂平台，但需要设计清晰的执行路径。
规范镜像标签，让版本一目了然
标签不是随便起的代号，而是灰度策略的起点。避免使用 latest，它不可追溯、易被覆盖、破坏可重现性。推荐语义化组合格式：
- v1.3.0-prod：当前全量上线的稳定版本
- v1.3.1-canary：金丝雀版本，固定几台节点运行
- v1.3.1-gray：灰度版本，面向 5% 流量或特定用户群（如 cookie 包含 beta 标识）
- v1.3.1-rc：预发布候选版，仅用于测试环境验证
所有标签应指向同一镜像 SHA256 摘要，确保内容不可变。构建时同步记录摘要（如 sha256:abc123...），生产环境 YAML 中优先使用 digest 而非 tag，防意外覆盖。
用 Nginx 或 Service Mesh 控制流量分发
Docker 自身不解析标签做路由，必须借助外部流量入口。裸跑场景下，Nginx 是最轻量可靠的方案：
- 启动两个服务容器：旧版监听 8081，新版监听 8082
- 在 Nginx upstream 中按权重分配：server 127.0.0.1:8081 weight=95，server 127.0.0.1:8082 weight=5
- 支持更精细规则：根据请求头、Cookie 或 IP 段路由，例如只将 Cookie: user-type=beta 的请求转发到新版
若使用 Kubernetes，可搭配 Istio VirtualService 或 Nginx Ingress 的 canary 注解，实现基于 Header、Query 或百分比的动态分流，无需改代码、不中断服务。
通过 docker-compose 或 Deployment 实现平滑切换
灰度不是“停旧启新”，而是并行运行+渐进替换：
- 在 docker-compose.yml 中定义 app-old 和 app-new 两个服务，各自指定不同镜像 tag 和端口
- 用 docker-compose up -d --scale app-new=2 先扩出少量新实例，再结合 Nginx 权重逐步调高流量比例
- Kubernetes 场景下，为 v1.3.1-gray 单独建 Deployment，打 label version: gray；稳定版用 version: prod；Service 不直接 selector version，交由 Istio 或 Ingress 控制路由
滚动更新也可用于灰度：修改单个 Deployment 的 image 字段为新 tag，设置 maxSurge=1、maxUnavailable=0，让新 Pod 逐个就位，旧 Pod 等健康检查通过后再销毁。
自动校验 + 一键回滚，闭环才算完整
灰度发布后必须触发验证，否则等于没监控：
- 发布后自动调用 HTTP 探针（如 /health）、检查日志关键词、拉取 Prometheus 指标（错误率、延迟 P95）
- 设定阈值（如错误率 > 1% 或响应超时 > 2s），超限则立即执行回滚命令：kubectl set image deploy/myapp myapp=myapp:v1.3.0-prod
- CI/CD 流水线中嵌入人工确认门禁：灰度运行 15 分钟无异常，才允许触发“升级 prod 标签”动作，即把 v1.3.0-prod 指向新镜像 digest
回滚本质就是切回已知稳定的标签或 digest，全程秒级完成，不需要重建镜像、不依赖备份卷——前提是镜像仓库保留历史 tag 且配置为不可覆盖。
