- 综合排序
- 最热优先
- 最新优先
- 来自专栏devops_k8s
灰度发布实现及蓝绿发布
image.png 3.0 方案 3.1 灰度发布 灰度发布是一种常见的服务滚动升级或A/B测试策略。 原理图 image.png 发布过程 1 . 通过header实现灰度发布验证 image.png 待改进 1 . 2 . 3 . 3.2 蓝绿发布 不停老版本,部署新版本然后进行测试，确认ok，将流量切换到新版本，然后老版本升级到新版本 新旧接口不兼容; 故障定位困难; 后台删数据，更新数据; 当你切换蓝色环境时，需要妥当处理未完成业务和新的业务，如果你的数据库后端无法处理，会出现数据不一致问题; 需要提前考虑数据库与应用部署同步/回滚问题; 蓝绿部署需要有基础设施支持 ; 非隔离基础架构(VM,Docker)上执行蓝绿部署，蓝绿环境有被摧毁的风险;
1.9K21发布于 2021-08-08 - 来自专栏用户6296428的专栏
有赞灰度发布与蓝绿发布实践
（d）如果验证没有发现任何故障，则应用B的蓝绿发布完成，v2版本集群成为新的稳定集群。 3.2 为什么还需要蓝绿发布 有了灰度发布之后，为什么还需要蓝绿发布呢？ 蓝绿发布新集群验证完成后，已经处于正常服务状态，不会再引入不确定性的变更操作。 理论上，灰度发布的需求都可以用蓝绿发布解决，而且可以更好地解决。 3.3 发布流程 下面从产品层面介绍一下有赞蓝绿发布的流程，包括：蓝绿发布开始、蓝绿初始化、蓝绿验证、蓝绿取消或完成上线、蓝绿发布结束。 (1) 蓝绿发布开始。 用户从Ops管理系统，进入应用的发布页面，选择发布类型“蓝绿发布”，开始蓝绿发布。 (2)蓝绿初始化。首先推送路由规则，控制全部流量在老集群，保证新集群部署启动期间不会接收任何流量。 4.2 发布事件通知 发布事件通知是为了在发布过程中的一些重点事件发生时，及时的告知到对应的运维或开发人员，比如蓝绿发布开始、蓝绿发布取消、蓝绿发布完成上线、蓝绿发布验证过长等事件。
2.2K31发布于 2020-08-24 浅析蓝绿部署、滚动发布和灰度发布
这样传统的发布方式不仅使得服务中断，并且存在新版本上线失败的风险（如环境问题、版本问题等），少说用户抱怨、多则可能谈及经济损失。 显而易见的是，这三种发布方式都是为了实现更好的用户体验而诞生的，下文我们逐一解析。蓝绿部署蓝绿个人理解为两套独立硬件系统。绿色是现在跑的旧版，蓝色是将要发布的新版。 滚动发布即滚动升级，服务应用集群的服务器按一定顺序，逐步完成新旧替换。 其实个人在翻阅了一些文章后，觉得滚动发布和灰度发布的流程示意图差不多，都是逐步更新业务，相比之下 灰度发布更注重用户侧的分流。对流量的切换可以控制的更细，使得用户侧的切换体验更平滑。 灰度发布可以灵活的选择参与测试的用户，如：内部用户 > 活跃用户 > 所有用户。 更好的获取用户的需求和反馈，完善新业务。 比滚动发布具备更好的容灾能力。
54310编辑于 2024-12-26- 来自专栏Kirito的技术分享
一文搞懂蓝绿发布、灰度发布和滚动发布
长期以来，业务升级渐渐形成了几个发布策略：蓝绿发布、灰度发布和滚动发布，目的是尽可能避免因发布导致的流量丢失或服务不可用问题。 一、 蓝绿发布 项目逻辑上分为AB组，在项目系统时，首先把A组从负载均衡中摘除，进行新版本的部署。B组仍然继续提供服务。 ? 蓝绿发布在早期物理服务器时代，还是比较昂贵的，由于云计算普及，成本也大大降低。 如果你们运维自动化能力储备不够，肯定是越简单越好，建议蓝绿发布，如果业务对用户依赖很强，建议灰度发布。如果是K8S平台，滚动更新是现成的方案，建议先直接使用。 蓝绿发布：两套环境交替升级，旧版本保留一定时间便于回滚。 灰度发布：根据比例将老版本升级，例如80%用户访问是老版本，20%用户访问是新版本。 滚动发布：按批次停止老版本实例，启动新版本实例。
4.7K10发布于 2019-10-24 - 来自专栏PolarisMesh
PolarisMesh系列文章——灰度发布系列（蓝绿发布）
蓝绿发布什么是蓝绿发布蓝绿部署是一种应用发布模式，可将用户流量从先前版本的应用或微服务全量转移到新版本中（两者均保持在生产环境中运行）。旧版本可以称为蓝色环境，而新版本则可称为绿色环境。 图片蓝绿发布的适用场景机器资源有富余或者可以按需分配单体应用、调用复杂度不高的业务系统对用户体验具备一定的容忍度北极星如何支持蓝绿发布蓝绿发布需要依赖几个关键的技术点：流量入口侧需要支持按百分比进行流量切换 北极星提供以下功能，支持蓝绿发布：网关直通微服务：北极星支持直接打通网关到微服务的链路（支持主流网关Envoy/Kong/Nginx/Spring Cloud Gateway），网关侧可以直接将流量打通到微服务的节点 北极星支持Spring Cloud Tencent以及服务网格（Envoy）的方式接入使用蓝绿发布的能力。前置条件部署polaris如果已经部署好了polaris，可忽略这一步。 灰度完成的收尾动作灰度完成后，需要做以下事情：对老版本分组的实例进行缩容下线删除网关的路由规则在北极星控制台删除自定义路由规则一键部署体验北极星提供了一键部署demo，可以通过一键部署demo快速体验蓝绿发布
2K60编辑于 2022-10-06 - 来自专栏我的小碗汤
一文搞懂蓝绿发布、灰度发布和滚动发布
长期以来，业务升级渐渐形成了几个发布策略：蓝绿发布、灰度发布和滚动发布，目的是尽可能避免因发布导致的流量丢失或服务不可用问题。 一、 蓝绿发布 项目逻辑上分为AB组，在项目系统时，首先把A组从负载均衡中摘除，进行新版本的部署。B组仍然继续提供服务。 ? 蓝绿发布在早期物理服务器时代，还是比较昂贵的，由于云计算普及，成本也大大降低。 如果你们运维自动化能力储备不够，肯定是越简单越好，建议蓝绿发布，如果业务对用户依赖很强，建议灰度发布。如果是K8S平台，滚动更新是现成的方案，建议先直接使用。 蓝绿发布：两套环境交替升级，旧版本保留一定时间便于回滚。 灰度发布：根据比例将老版本升级，例如80%用户访问是老版本，20%用户访问是新版本。 滚动发布：按批次停止老版本实例，启动新版本实例。
2.3K40发布于 2019-10-25 - 来自专栏CODING DevOps
CODING CD + Nginx Ingress 实现蓝绿发布
发布流程 蓝绿发布的流程，包括：蓝绿发布开始、蓝绿初始化、蓝绿验证、蓝绿取消或完成上线。 蓝绿发布开始 在“发布策略”的人工确认阶段选择发布类型“蓝绿发布”，即可开始蓝绿发布。在“蓝绿发布”的预置条件检查阶段配置条件表达式：#judgment("发布策略") == '蓝绿发布'。 ，那么就可以完成蓝绿发布上线了。 效果 终于配置完成蓝绿发布的部署流程，接下来我们来看一下蓝绿发布效果。 初始化绿集群 蓝绿发布成功 蓝绿发布失败 结语 在上面的示例中，我们通过在 CODING CD 中配置一条流水线，实现了基于 Nginx Ingress 的蓝绿发布。
1.3K10发布于 2021-04-01 - 来自专栏木二天空
附032.Kubernetes实现蓝绿发布
蓝绿发布原理 蓝绿发布本质上是希望能优雅无误的迭代应用，以便于使应用平稳提供服务。通常是不停老版本的同时对新版本进行先发布，然后确认无误后进行流量切换，即并行部署。 Kubernetes中可以通过deployment来部署一个蓝发布，然后通过控制service，来决定使用的版本。即通过label selector 将流量转发至对应的版本。 蓝绿发布实践 构建环境 基础Kubernetes环境 需要部署一个处于健壮状态的Kubernetes，部署Kubernetes可参考 Kubernetes_v1.20.0高可用部署 准备测试文件 root 总结 在进行蓝绿发布的过程中，对外服务一直处于可用状态，绿版本部署成功之后，所有请求还是蓝应用，当流量切换后，立刻迭代至绿版本，若需要回滚只需要将流量切回蓝应用即可。 通常建议对外成功发布绿应用后，蓝应用保持并行一段时间，然后根据业务情况进行释放。
75130发布于 2021-04-02 - 来自专栏DevOps时代的专栏
蓝绿部署、滚动发布、灰度发布等方案对比总结
蓝绿发布（Blue/Green Deployment） 1. 定义 蓝绿部署是不停老版本，部署新版本然后进行测试。确认OK后将流量切到新版本，然后老版本同时也升级到新版本。 2. 特点 蓝绿部署无需停机，并且风险较小。 3. 部署过程 部署版本 1 的应用（初始的状态） 所有外部请求的流量都打到这个版本上。 蓝绿发布的注意事项 当你切换到蓝色环境时，需要妥当处理未完成的业务和新的业务。如果你的数据库后端无法处理，会是一个比较麻烦的问题。 可能会出现需要同时处理微服务架构应用和传统架构应用的情况，如果在蓝绿部署中协调不好这两者，还是有可能会导致服务停止。 需要提前考虑数据库与应用部署同步迁移/回滚的问题。 蓝绿部署需要有基础设施支持。 A/B 测试与蓝绿部署的区别在于， A/B 测试目的在于通过科学的实验设计、采样样本代表性、流量分割与小流量测试等方式来获得具有代表性的实验结论，并确信该结论在推广到全部流量可信；蓝绿部署的目的是安全稳定地发布新版本应用
2.7K20发布于 2019-08-09 - 来自专栏JAVA杂谈
科普：蓝绿部署、金丝雀发布（灰度发布）、AB测试
有风险，就对业务有影响，然后就有了一系列减少这种风险的部署方案：蓝绿部署、金丝雀发布（灰度发布），也有适应产品迭代频率的AB测试。 蓝绿部署 蓝绿色部署是一种通过运行两个相同的称为 BLUE 和 GREEN 的生产环境来减少停机时间和降低风险的技术。 蓝绿部署，以颜色命名，简单的理解就是，线上有两套集群环境，在架构图中，一套标记成蓝色，称为蓝色集群BLUE；一套标记为绿色，称为绿色集群GREEN。通过将流量引入两个集群，完成系统升级切换。 ? 金丝雀发布（灰度发布） 金丝雀发布，与蓝绿部署不同的是，它不是非黑即白的部署方式，所以又称为灰度发布。 ，它是为了进行效果验证的手段，其他两种是为了实现线上平稳发布的手段，这里把他们放在一起说，是因为这三个概念很容易弄混。
15.4K30发布于 2021-06-16 - 来自专栏物流IT圈
蓝绿部署、金丝雀发布（灰度发布）和AB测试
1.说明 蓝绿部署、A/B测试、金丝雀发布，以及灰度发布、流量切分等，经常被混为一谈，影响沟通效率。 根本原因是这些名词经常出现，人们耳熟能详能够熟练地谈起，对这些术语的理解却没有达成一致。 2.蓝绿部署 蓝绿部署的目的是减少发布时的中断时间、能够快速撤回发布。 蓝绿部署中，一共有两套系统：一套是正在提供服务系统，标记为“绿色”；另一套是准备发布的系统，标记为“蓝色”。两套系统都是功能完善的，并且正在运行的系统，只是系统版本和对外服务情况不同。 这个控制叫做“流量切分”，既可以用于金丝雀发布，也可以用于后面的A/B测试。 蓝绿部署和金丝雀发布是两种发布策略，都不是万能的。有时候两者都可以使用，有时候只能用其中一种。 A/B测试(A/B Testing) 首先需要明确的是，A/B测试和蓝绿部署以及金丝雀，完全是两回事。 蓝绿部署和金丝雀是发布策略，目标是确保新上线的系统稳定，关注的是新系统的BUG、隐患。
1.3K31发布于 2019-07-16 - 来自专栏Java课堂
灰度发布、蓝绿发布、滚动发布，有什么区别？这下明白了
01、蓝绿发布 蓝绿部署中，一共有两套系统：一套是正在提供服务系统(也就是上面说的旧版)，标记为“绿色”；另一套是准备发布的系统，标记为“蓝色”。 02、蓝绿发布特点 蓝绿部署的目的是减少发布时的中断时间、能够快速撤回发布。 两套系统没有耦合的时候才能百分百保证不干扰 03、蓝绿发布注意事项 蓝绿部署只是[上线策略中的一种，它不是可以应对所有情况的万能方案。 回滚困难 06、滚定发布注意事项 滚动发布没有一个确定可行的环境。使用蓝绿[部署，我们能够清晰地知道老版本是可行的，而使用滚动发布，我们无法确定。 修改了现有的环境。 回滚困难。 （否则就回滚） 08、A/B测试 A/B测试和蓝绿发布、滚动发布以及金丝雀发布，完全是两回事。 蓝绿发布、滚动发布和金丝雀是发布策略，目标是确保新上线的系统稳定，关注的是新系统的BUG、隐患。
8.6K23编辑于 2021-12-05 蓝绿部署-解决99%的发布问题(APISIX)
如何使用APISIX网关进行蓝绿部署背景名人名言：99%的问题都是发布导致的。无论在测试环境测试的多么充分，在上线正式环境时依然有可能发生问题。 目前我们发布线上新版本后发现问题主要有两种途径：灰度发布。一次发布一部分机器，然后观察监控是否有异常线上验证。人工到线上通过app或接口进行测试，观察结果是否符合预期。 我们能不能在灰度期间就进行线上验证，从而提前发现问题，杜绝发布导致的事故？答案是能。蓝绿部署在蓝绿发布过程中，有两套生产环境：蓝环境和绿环境。蓝色是当前版本并拥有实时流量，绿色是包含更新代码的环境。 如何使用蓝绿部署我们目前的路由方式有两种：NGINX。apisix网关nginx是非常传统的代理软件，根据我们的业务特点进行路由难度很高，故不做调研。 下面介绍两种方案实现根据uid路由，从而实现蓝绿部署。
31610编辑于 2025-08-27- 来自专栏Rainbond开源「容器云平台」
蓝绿部署、AB测试以及灰度发布
在有关于“微服务”、“DevOps”、“Cloud-native”的讨论中，蓝绿部署、A/B测试、灰度发布，这三种部署方式往往同时出镜。 那么问题来了，蓝绿部署、A/B测试、灰度发布，这三者之间究竟有何不同？ 蓝绿部署 Martin Flower曾在文章中阐述了蓝绿部署的整体要点，建议大家看看。 基本上，蓝绿部署是一种以可预测的方式发布应用的技术，目的是减少发布过程中服务停止的时间。 A/B测试与蓝绿部署的区别在于，A/B测试目的在于通过科学的实验设计、采样样本代表性、流量分割与小流量测试等方式来获得具有代表性的实验结论，并确信该结论在推广到全部流量可信；蓝绿部署的目的是安全稳定地发布新版本应用 不难想象，通过docker和kubernetes，我们可以很简单的实现蓝绿部署、A/B测试、灰度发布……比如好雨云，深度整合Docker和Kubernetes，提供给用户包括代码滚动上线、一键代码回滚等功能和特性在内的强大的
2.6K40发布于 2018-05-31 - 来自专栏瓜农老梁
No.177# 蓝绿发布提效方案梳理
先摘流--->运维变更--->再引流 这种方式应用到发布系统即为蓝绿发布。 ：独立灰度环境，上线前现在该环境验证 滚动发布 分批次发布 在灰度验证的基础上，通过发布系统选择发布批次方式一：按节点比例分批次发布方式二：按节点数量分批发布 蓝绿发布 流量调度实现 线上同时蓝绿两个应用组提供服务步骤一 颜色的划分不重要，红黑发布时另外一种蓝绿发布 灰度发布多种形式，金丝雀发布、染色区分、物理独立灰度环境等 二、蓝绿发布架构与流程 1、蓝绿架构图示 在业务基本容器化后，扩缩容变得容易，而线上的资源容量假设能够容纳业务增量的 2.蓝绿环境命名约定 部署需要发布新版本为「蓝色环境」 线上运行的稳定版本为「绿色环境」 3.流量调度发布流程 七层负载默认按照方法级将进入流量染色染成绿色 系统发布时先经过蓝色环境，当然服务不需要则跳过蓝绿发布 通过七层负载出递进式引流到绿色环境【1%~50%】 最后呈现的流量分布，蓝绿流量各50% 4.流量调度发布图示 三、优先组件改造点梳理 1、发布系统 发布系统支持蓝绿发布通道，支持将节点在蓝绿环境分配
92020编辑于 2022-12-03 - 来自专栏腾讯云原生团队
持续部署入门：基于 Kubernetes 实现蓝绿发布
在 Kubernetes 中有几种不同的方式发布应用，所以为了让应用在升级期间依然平稳提供服务，选择一个正确的发布策略就非常重要了，本篇文章将讲解在 Kubernetes 使用蓝绿更新的方式更新镜像。 原理 蓝绿发布是版本 1 与版本 2 会同时存在，通过控制 Service 来决定使用具体哪一个版本，也称为红黑部署。 蓝绿发布与滚动更新不同，版本 2 （绿） 与版本 1（蓝）一起部署，在测试新版本满足要求后，然后更新 Service 对象，通过替换 label selector 中的版本标签来将流量发送到新版本，更新过程如下图所示 蓝绿（红黑）发布配置 ? 基于 CODING CD 的蓝绿发布和一般的蓝绿发布略有不同，一旦 v2 版本的 pod 处于就绪状态后，他就会立即获得流量，而当所有的 v2 版本的 pod 处于就绪状态后，会禁用 v1 版本的 pod
82364发布于 2020-09-08 - 来自专栏微服务生态
基于Nginx+lua的蓝绿发布系统
一、什么是蓝绿发布 蓝绿部署是不停老版本，部署新版本然后进行测试，确认OK，将流量切到新版本，然后老版本同时也升级到新版本。 1、特点 蓝绿部署无需停机，并且风险较小。 2、蓝绿发布的注意事项 当你切换到蓝色环境时，需要妥当处理未完成的业务和新的业务。 如果你的数据库后端无法处理，会是一个比较麻烦的问题； 可能会出现需要同时处理“微服务架构应用”和“传统架构应用”的情况，如果在蓝绿部署中协调不好这两者，还是有可能会导致服务停止。 蓝绿部署需要有基础设施支持。 在非隔离基础架构（ VM 、 Docker 等）上执行蓝绿部署，蓝色环境和绿色环境有被摧毁的风险。 二、为什么需要蓝绿发布系统 1、新项目和新需求非常多 2、新需求的上线过程是，先上线一台服务器然后观察会不会出问题，如果没有问题则全部上线。 3、分流是关键，但是动态分流是痛点。
1.6K40发布于 2018-08-22 - 来自专栏k8s技术圈
Argo Rollouts 实现蓝绿金丝雀发布
Argo Rollouts 是一个 Kubernetes Operator 实现，它为 Kubernetes 提供更加高级的部署能力，如蓝绿、金丝雀、金丝雀分析、实验和渐进式交付功能，为云原生应用和服务实现自动化 支持如下特性： 蓝绿更新策略 金丝雀更新策略 更加细粒度、加权流量拆分 自动回滚 手动判断 可定制的指标查询和业务 KPI 分析 Ingress 控制器集成：NGINX，ALB 服务网格集成：Istio 蓝绿部署 金丝雀部署 与 Ingress 控制器和服务网格整合，实现高级流量路由 与用于蓝绿和金丝雀分析的指标提供者集成 根据成功或失败的指标，自动发布或回滚 渐进式交付 渐进式交付是以受控和渐进的方式发布产品更新的过程 ，从而降低发布的风险，通常将自动化和指标分析结合起来以驱动更新的自动升级或回滚。 Blue-Green(蓝绿)：蓝绿发布（有时称为红黑）指同时部署了新旧两个版本的应用程序，在此期间，只有旧版本的应用程序会收到生产流量，这允许开发人员在将实时流量切换到新版本之前针对新版本进行测试。
3.3K30发布于 2021-07-23 - 来自专栏憧憬博客分享
企业常用的几种发布方式(蓝绿发布 | 滚动升级 | 金丝雀发布)
常用部署方式存在以下几种: 蓝绿部署 滚动部署 灰度部署/金丝雀部署 蓝绿部署 正常将项目分为两组, 蓝组和绿组, 正常运转的情况下每组承载 50% 的流量. 优点 更新过程无需停机，风险较少 回滚方便，只需要更改路由或者切换DNS服务器，效率较高 缺点 需要部署两套机器，费用开销大 在非隔离的机器（Docker、VM）上操作时，可能会导致蓝绿环境被摧毁风险 正常监控也需要移除) 2、移除后的实例开始更新 3、上线测试后无异常开始接入负载均衡器或者路由 4、新增实例监控 5、继续上线后一批实例，直到集群中所有的实例都更新 优点 更新过程体验影响少，风险较少 费用对比蓝绿花费开销较少 金丝雀发布一般先发布一台, 或者小比例, 例如2%的服务器进行流量验证,国内也称为金丝雀测试, 流量测试通过, 慢慢将剩余机器也进行发布, 可以达到一个平滑过渡效果. 流程 首先部署少量服务器密切 观察是否因为版本产生预期结果 当结果满意时候再全量部署 优点 用户体验影响小，金丝雀发布过程出现问题只影响少量用户 缺点 发布自动化程度不够，发布期间可引发服务中断
2.7K230发布于 2020-07-21 - 来自专栏无敌码农
蓝绿发布、滚动发布、灰度发布等部署方案，这些你必须懂！
蓝绿发布 （Blue/Green Deployment） ---- 〓定义 蓝绿部署是不停老版本，部署新版本然后进行测试。确认OK后将流量切到新版本，然后老版本同时也升级到新版本。 〓特点 蓝绿部署无需停机，并且风险较小。 〓部署过程 ▼部署版本 1 的应用（初始的状态） 所有外部请求的流量都打到这个版本上。 ? 〓蓝绿发布的注意事项 当你切换到蓝色环境时，需要妥当处理未完成的业务和新的业务。如果你的数据库后端无法处理，会是一个比较麻烦的问题。 可能会出现需要同时处理微服务架构应用和传统架构应用的情况，如果在蓝绿部署中协调不好这两者，还是有可能会导致服务停止。 需要提前考虑数据库与应用部署同步迁移/回滚的问题。 蓝绿部署需要有基础设施支持。 A/B 测试与蓝绿部署的区别在于， A/B 测试目的在于通过科学的实验设计、采样样本代表性、流量分割与小流量测试等方式来获得具有代表性的实验结论，并确信该结论在推广到全部流量可信；蓝绿部署的目的是安全稳定地发布新版本应用
2.3K10发布于 2019-07-31
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号