蓝绿部署与滚动更新可分层协同：Docker负责容器化隔离与实例编排，Nginx控制流量路由；先滚动升级绿环境，再通过Nginx切流实现零停机发布，并需健康检查、数据一致性保障。
蓝绿部署和滚动更新不是二选一的关系，而是可以分层协同使用的策略。在微服务架构中，Docker 负责容器化隔离与实例编排，Nginx 充当流量调度中枢，二者配合能兼顾“零停机”与“资源可控”——关键在于：用蓝绿做主干切换保障发布安全，用滚动更新在单个环境内做渐进式升级。
明确角色分工：Docker管实例，Nginx管路由
Docker（或 Swarm）不直接决定用户看到哪个版本，它只确保蓝色、绿色两个环境各自稳定运行；Nginx 才是真正控制请求走向的开关。因此，配置核心是：
- Nginx upstream 必须定义两个独立后端组，分别指向 blue 和 green 的服务地址（如 blue-app:8080 和 green-app:8080）
- 所有用户请求统一接入 Nginx，通过修改
proxy_pass指向或使用变量控制转发目标 - Docker 启动时需为不同环境分配固定网络别名（例如用 Docker network alias 或 Swarm service label），避免硬编码 IP
组合操作流程：先滚动升级绿环境，再一键切流
这不是纯蓝绿，也不是纯滚动，而是“滚动支撑蓝绿”的实用路径：
- 当前生产为蓝色环境（v1.0），绿色环境（v2.0）尚未部署 → 保持 Nginx 全量转发至 blue
- 在 green 环境中，用 Docker Swarm 启动新服务，并配置滚动更新参数：
--update-parallelism 1 --update-delay 15s --update-failure-action rollback - Swarm 自动逐个替换 green 服务的旧任务（如有），确保 green 内部升级过程平滑且可回退
- green 服务全部就绪后，执行一次 Nginx 配置热重载：
将proxy_pass从http://blue-backend改为http://green-backend，再nginx -s reload - 验证无误，停止 blue 服务；若异常，3 秒内改回配置并重载，即完成秒级回滚
健康检查与自动防护不能省略
仅靠人工切流风险高，必须嵌入自动化验证环节：
- 每个微服务容器内提供
/health接口，返回 HTTP 200 + JSON status=ready - Nginx upstream 配置
max_fails=2 fail_timeout=30s，自动屏蔽失联实例 - 在切流前，用脚本调用 green 后端的健康接口，连续 3 次成功才允许执行 Nginx reload
- 可搭配 Prometheus + Alertmanager，在切流后 2 分钟内监控 5xx 错误率突增，触发告警或自动回切
数据一致性是隐性关键点
蓝绿切换快，但数据库、Redis 缓存等有状态组件不会自动同步。常见做法：
- 读写分离：所有服务连接同一套数据库主从集群，blue/green 实例共用底层存储
- 双写兼容：v2.0 版本代码需兼容 v1.0 的数据库 schema（如新增字段设默认值、保留旧字段）
- 缓存灰度：在 green 环境首次请求时主动预热热点 key，避免切流后大量缓存穿透
- 禁止 green 环境执行 DDL 或清缓存操作，这些动作必须在切流完成后、blue 下线前由运维单独执行
