蓝绿部署适合关键服务，滚动更新适合无状态服务。蓝绿部署通过两套环境切换实现零停机，需注意环境一致性、切换方式和回滚机制；滚动更新逐步替换实例，依赖健康检查和最小可用数控制，适用于 kubernetes 等编排平台；选择策略时需考虑服务状态、接口兼容性和技术栈；实际部署中均需关注优雅终止、探针设置、dns 缓存及日志追踪等问题。
在 Golang 微服务部署中，实现零停机更新是保障系统高可用的重要手段。常见的做法有两种：蓝绿部署和滚动更新。它们各有适用场景，也都有需要注意的细节。
下面从实际操作角度出发，讲讲这两种策略怎么用、什么时候用，以及容易踩坑的地方。
蓝绿部署：两套环境切换，适合关键服务
蓝绿部署的核心思想是维护两套完全相同的生产环境（蓝和绿），一次只有一套对外提供服务。新版本部署到空闲的一套后，通过负载均衡器或反向代理切换流量。
立即学习“go语言免费学习笔记（深入）”；
实现要点：
- 环境一致性：两个环境必须配置一致，包括依赖服务、数据库版本等。
- 切换方式：可以通过 Nginx、Kubernetes Service 或云厂商提供的负载均衡器来切换流量。
- 回滚快速：如果新版本出问题，只需要切回原来的环境即可。
适合场景：
- 对稳定性要求极高，不能容忍任何请求失败的服务
- 版本之间改动较大，需要完整验证新环境是否正常
注意事项：
- 成本较高，需要双倍资源
- 如果有状态服务（如本地缓存、文件存储），处理起来会比较麻烦
滚动更新：逐步替换实例，适合无状态服务
滚动更新是 Kubernetes 等编排系统默认支持的一种策略，它会逐步替换旧版本的 Pod，同时确保始终有一定数量的健康实例在运行。
实现要点：
- 分批更新：每次更新一部分 Pod，其余继续处理请求
- 健康检查配合：Liveness 和 Readiness 探针要设置合理，避免将流量导到未就绪的实例
-
最小可用数控制：设置
minReadySeconds和maxUnavailable，防止更新过程中服务不可用
适合场景：
- 服务本身是无状态的
- 请求可以容忍短暂中断（比如前端调用有重试机制）
- 使用 Kubernetes 等容器编排平台
常见问题：
- 新旧版本共存期间，如果有接口不兼容，可能导致部分请求失败
- 数据库迁移如果没有同步处理，可能引发数据结构不一致
如何选择：蓝绿还是滚动？
这取决于你的业务特点和技术栈：
- 如果你使用的是 Kubernetes 并且服务是无状态的，滚动更新更轻量高效
- 如果你希望新版本上线前完全准备好，并且能快速回滚，蓝绿部署更适合
- 如果服务对可用性要求极高，又担心滚动更新过程中的兼容问题，也可以先在灰度环境中测试后再全量更新
实际部署建议
不管用哪种策略，下面几点都需要注意：
- ✅ 优雅终止：Golang 应用要监听
SIGTERM，完成当前请求再退出 - ✅ 探针设置合理：Readiness Probe 不要太激进，否则刚启动的服务会被误判为异常
- ✅ DNS 缓存注意：客户端如果缓存了 IP 地址，可能会导致流量还打到旧 Pod 上
- ✅ 日志追踪配合：新旧版本混跑时，日志要有版本号标识，方便排查问题
基本上就这些。两种策略都不复杂，但要真正做到“零停机”，还得结合具体服务的特点做调整。
