蓝绿部署是通过双环境+一次路由切换实现的发布模式，核心在于流量瞬间切换与快速回滚，不解决构建测试等问题，依赖外部代理和完备健康检查。
蓝绿部署不是“一种发布方式”，而是用双环境做流量切换的发布模式——它本身不解决构建、测试或配置问题，只解决“怎么切”和“切不动时怎么退”。选它，本质是在赌“新版本要么全好、要么全坏”，不接受中间态。
蓝绿部署的核心动作：两个环境 + 一次路由切换
它强制要求同时运行两套完全独立的服务实例（比如 myapp-blue 和 myapp-green），其中只有一个对外提供流量。发布时，你只做一件事：改路由规则，把所有请求从蓝色瞬间打到绿色。
- 典型实现依赖外部反向代理，比如 Traefik 或 Nginx Ingress，靠标签（
environment=blue）或 Host 规则控制转发 - 不能靠 Docker 自身完成切换——Docker Swarm 没有内置流量路由能力，必须配合服务发现+代理层
- 健康检查必须在切换前完成，否则切过去就 502；Kubernetes 中常用
readinessProbe配合ingress就绪等待 - 数据库迁移是最大盲区：蓝绿对无状态服务友好，但有状态服务（如带写操作的 DB）需额外处理 schema 变更兼容性
为什么滚动更新更常见，而蓝绿常被“高配化”？
滚动更新是 Kubernetes Deployment 的默认策略，靠 maxSurge 和 maxUnavailable 控制节奏；蓝绿却需要双倍资源、额外路由组件和人工/脚本干预切换时机——它不是更先进，只是把风险从“过程不可控”转移到“决策要果断”。
- 滚动更新适合日常小迭代：
maxSurge: 1+maxUnavailable: 0能做到“先扩后缩”，多数场景下用户感知不到抖动 - 蓝绿适合重大变更：比如前端框架升级、gRPC 接口大改、或合规审计要求“可瞬时回滚”的金融类服务
- 别迷信“零停机”：如果绿色环境的 Pod 启动慢、或代理未等就切流，照样丢请求——它保障的是“切换动作快”，不保障“新版本启动快”
Docker Swarm 下蓝绿落地最易卡住的三个点
Swarm 原生不支持声明式流量路由，所谓“蓝绿”实际是靠服务名+标签+外部代理拼出来的。很多人卡在这三步：
- 服务命名冲突：用
docker service create --name myapp部署两次会失败，必须用不同名字（如myapp-blue/myapp-green），且应用代码里不能硬编码服务名 - 网络隔离失效：没显式指定
--network，导致 blue/green 容器混在同一个 overlay 网络里，健康探测互相干扰 - 路由更新滞后：Traefik 依赖服务标签自动发现，但标签变更（如从
environment=blue改成environment=green）不会触发实时重载，得靠traefik.enable=true+ 动态配置热更新支持
真正难的从来不是“怎么搭出两个环境”，而是“怎么确认绿色环境真的准备好接流了”——健康检查通过 ≠ 业务逻辑就绪，比如缓存预热没做、下游依赖还没切、或者灰度期间没暴露出的竞态问题。蓝绿给的是回滚速度，不是质量担保。
