- 综合排序
- 最热优先
- 最新优先
- 来自专栏devops_k8s
灰度发布实现及蓝绿发布
发布前检查：预检查当前 Ingress 是否有且只关联了唯一的 Service 实例，且 Service 实例下有且只有唯一版本的 Deployment。 2 . 业务中维护白名单文件（存放在数据库中）; 2 . 通过header实现灰度发布验证 image.png 待改进 1 . 2 . 3 . 3.2 蓝绿发布 不停老版本,部署新版本然后进行测试，确认ok，将流量切换到新版本，然后老版本升级到新版本 : 将流量从版本1切换到版本2; 第四步: 如版本2测试正常，就删除版本1正在使用资源(例如实例1),从此正式使用版本2; 小结 从过程不难发现，部署过程中，应用始终在线，并且新版本上线过程中，并没有修改老版本的任何内容 ; 非隔离基础架构(VM,Docker)上执行蓝绿部署，蓝绿环境有被摧毁的风险;
1.9K21发布于 2021-08-08 - 来自专栏用户6296428的专栏
有赞灰度发布与蓝绿发布实践
用户从Ops管理系统，进入应用的发布页面，选择发布类型“灰度发布”，开始灰度发布。 (2) 灰度初始化。 （d）如果验证没有发现任何故障，则应用B的蓝绿发布完成，v2版本集群成为新的稳定集群。 3.2 为什么还需要蓝绿发布 有了灰度发布之后，为什么还需要蓝绿发布呢？ 3.3 发布流程 下面从产品层面介绍一下有赞蓝绿发布的流程，包括：蓝绿发布开始、蓝绿初始化、蓝绿验证、蓝绿取消或完成上线、蓝绿发布结束。 (1) 蓝绿发布开始。 用户从Ops管理系统，进入应用的发布页面，选择发布类型“蓝绿发布”，开始蓝绿发布。 (2)蓝绿初始化。首先推送路由规则，控制全部流量在老集群，保证新集群部署启动期间不会接收任何流量。 4.2 发布事件通知 发布事件通知是为了在发布过程中的一些重点事件发生时，及时的告知到对应的运维或开发人员，比如蓝绿发布开始、蓝绿发布取消、蓝绿发布完成上线、蓝绿发布验证过长等事件。
2.2K31发布于 2020-08-24 浅析蓝绿部署、滚动发布和灰度发布
这样传统的发布方式不仅使得服务中断，并且存在新版本上线失败的风险（如环境问题、版本问题等），少说用户抱怨、多则可能谈及经济损失。 显而易见的是，这三种发布方式都是为了实现更好的用户体验而诞生的，下文我们逐一解析。蓝绿部署蓝绿个人理解为两套独立硬件系统。绿色是现在跑的旧版，蓝色是将要发布的新版。 滚动发布即滚动升级，服务应用集群的服务器按一定顺序，逐步完成新旧替换。 其实个人在翻阅了一些文章后，觉得滚动发布和灰度发布的流程示意图差不多，都是逐步更新业务，相比之下 灰度发布更注重用户侧的分流。对流量的切换可以控制的更细，使得用户侧的切换体验更平滑。 灰度发布可以灵活的选择参与测试的用户，如：内部用户 > 活跃用户 > 所有用户。 更好的获取用户的需求和反馈，完善新业务。 比滚动发布具备更好的容灾能力。
56210编辑于 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，可忽略这一步。 具体部署方案请参考：单机版部署指南集群版部署指南阶段一：实例打标Spring Cloud Tencent 接入打标实例版本号Spring Cloud Tencent支持通过以下2种方式进行实例的版本号打标
2K60编辑于 2022-10-06 - 来自专栏我的小碗汤
一文搞懂蓝绿发布、灰度发布和滚动发布
长期以来，业务升级渐渐形成了几个发布策略：蓝绿发布、灰度发布和滚动发布，目的是尽可能避免因发布导致的流量丢失或服务不可用问题。 一、 蓝绿发布 项目逻辑上分为AB组，在项目系统时，首先把A组从负载均衡中摘除，进行新版本的部署。B组仍然继续提供服务。 ? 蓝绿发布在早期物理服务器时代，还是比较昂贵的，由于云计算普及，成本也大大降低。 如果你们运维自动化能力储备不够，肯定是越简单越好，建议蓝绿发布，如果业务对用户依赖很强，建议灰度发布。如果是K8S平台，滚动更新是现成的方案，建议先直接使用。 蓝绿发布：两套环境交替升级，旧版本保留一定时间便于回滚。 灰度发布：根据比例将老版本升级，例如80%用户访问是老版本，20%用户访问是新版本。 滚动发布：按批次停止老版本实例，启动新版本实例。
2.3K40发布于 2019-10-25 - 来自专栏木二天空
附032.Kubernetes实现蓝绿发布
蓝绿发布原理 蓝绿发布本质上是希望能优雅无误的迭代应用，以便于使应用平稳提供服务。通常是不停老版本的同时对新版本进行先发布，然后确认无误后进行流量切换，即并行部署。 Kubernetes中可以通过deployment来部署一个蓝发布，然后通过控制service，来决定使用的版本。即通过label selector 将流量转发至对应的版本。 蓝绿发布实践 构建环境 基础Kubernetes环境 需要部署一个处于健壮状态的Kubernetes，部署Kubernetes可参考 Kubernetes_v1.20.0高可用部署 准备测试文件 root 总结 在进行蓝绿发布的过程中，对外服务一直处于可用状态，绿版本部署成功之后，所有请求还是蓝应用，当流量切换后，立刻迭代至绿版本，若需要回滚只需要将流量切回蓝应用即可。 通常建议对外成功发布绿应用后，蓝应用保持并行一段时间，然后根据业务情况进行释放。
75430发布于 2021-04-02 - 来自专栏CODING DevOps
CODING CD + Nginx Ingress 实现蓝绿发布
发布流程 蓝绿发布的流程，包括：蓝绿发布开始、蓝绿初始化、蓝绿验证、蓝绿取消或完成上线。 额外部署了一个新集群，版本为 v2，该集群通过 version=v2 标签被 Service myapp-blue-svc 访问到。 通过流量控制，控制部分流量或全部流量到新集群，进行蓝绿验证，同时原稳定集群继续保持在线。 如果验证没有发现任何故障，则应用 myapp 的蓝绿发布完成，v2 版本集群成为新的稳定集群。 蓝绿发布开始 在“发布策略”的人工确认阶段选择发布类型“蓝绿发布”，即可开始蓝绿发布。在“蓝绿发布”的预置条件检查阶段配置条件表达式：#judgment("发布策略") == '蓝绿发布'。 效果 终于配置完成蓝绿发布的部署流程，接下来我们来看一下蓝绿发布效果。
1.3K10发布于 2021-04-01 - 来自专栏DevOps时代的专栏
蓝绿部署、滚动发布、灰度发布等方案对比总结
蓝绿发布（Blue/Green Deployment） 1. 定义 蓝绿部署是不停老版本，部署新版本然后进行测试。确认OK后将流量切到新版本，然后老版本同时也升级到新版本。 2. 蓝绿发布的注意事项 当你切换到蓝色环境时，需要妥当处理未完成的业务和新的业务。如果你的数据库后端无法处理，会是一个比较麻烦的问题。 A/B 测试与蓝绿部署的区别在于， A/B 测试目的在于通过科学的实验设计、采样样本代表性、流量分割与小流量测试等方式来获得具有代表性的实验结论，并确信该结论在推广到全部流量可信；蓝绿部署的目的是安全稳定地发布新版本应用 不足 1.发布和回退时间比较缓慢。 2.发布工具比较复杂，LB 需要平滑的流量摘除和拉入能力。 2.特点 这种部署方式相对于蓝绿部署，更加节约资源——它不需要运行两个集群、两倍的实例数。我们可以部分部署，例如每次只取出集群的 20% 进行升级。
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、蓝绿发布注意事项 蓝绿部署只是[上线策略中的一种，它不是可以应对所有情况的万能方案。 Server1 上, 然后Server1去替换正在运行的Server, 替换下来的物理机又可以继续部署Server2的新版本, 然后去替换正在工作的Server2 , 以此类推, 直到替换完所有的服务器 （否则就回滚） 08、A/B测试 A/B测试和蓝绿发布、滚动发布以及金丝雀发布，完全是两回事。 蓝绿发布、滚动发布和金丝雀是发布策略，目标是确保新上线的系统稳定，关注的是新系统的BUG、隐患。
8.7K23编辑于 2021-12-05 - 来自专栏Rainbond开源「容器云平台」
蓝绿部署、AB测试以及灰度发布
在有关于“微服务”、“DevOps”、“Cloud-native”的讨论中，蓝绿部署、A/B测试、灰度发布，这三种部署方式往往同时出镜。 那么问题来了，蓝绿部署、A/B测试、灰度发布，这三者之间究竟有何不同？ 蓝绿部署 Martin Flower曾在文章中阐述了蓝绿部署的整体要点，建议大家看看。 基本上，蓝绿部署是一种以可预测的方式发布应用的技术，目的是减少发布过程中服务停止的时间。 当你想要升级App2到version2，在蓝色环境中进行操作，即部署新版本应用，并进行测试。如果测试没问题，就可以把负载均衡器／反向代理／路由指向蓝色环境了。 ? 随后你需要监测新版本应用，也就是App2 version2是否有故障和异常。如果运行良好，就可以删除App2 version1使用的资源。
2.6K40发布于 2018-05-31 - 来自专栏腾讯云原生团队
持续部署入门：基于 Kubernetes 实现蓝绿发布
原理 蓝绿发布是版本 1 与版本 2 会同时存在，通过控制 Service 来决定使用具体哪一个版本，也称为红黑部署。 蓝绿发布与滚动更新不同，版本 2 （绿） 与版本 1（蓝）一起部署，在测试新版本满足要求后，然后更新 Service 对象，通过替换 label selector 中的版本标签来将流量发送到新版本，更新过程如下图所示 蓝绿（红黑）发布配置 ? 基于 CODING CD 的蓝绿发布和一般的蓝绿发布略有不同，一旦 v2 版本的 pod 处于就绪状态后，他就会立即获得流量，而当所有的 v2 版本的 pod 处于就绪状态后，会禁用 v1 版本的 pod 注意：基于 CODING CD 的蓝绿发布会出现 v1 版本和 v2 版本同时获得流量的情况，具体取决于 pod 的就绪探针，v2 版本的 pod 一旦就绪，那么它就会获得流量，所以需要合理设计就绪探针
83264发布于 2020-09-08 - 来自专栏瓜农老梁
No.177# 蓝绿发布提效方案梳理
颜色的划分不重要，红黑发布时另外一种蓝绿发布 灰度发布多种形式，金丝雀发布、染色区分、物理独立灰度环境等 二、蓝绿发布架构与流程 1、蓝绿架构图示 在业务基本容器化后，扩缩容变得容易，而线上的资源容量假设能够容纳业务增量的 2倍以上，将线上的运行的服务一分为二，分成蓝色环境和绿色环境。 2.蓝绿环境命名约定 部署需要发布新版本为「蓝色环境」 线上运行的稳定版本为「绿色环境」 3.流量调度发布流程 七层负载默认按照方法级将进入流量染色染成绿色 系统发布时先经过蓝色环境，当然服务不需要则跳过蓝绿发布 发布系统作为入口与其他系统联动简化操作 使用蓝绿发布的应用需要保持绿色环境有应用部署 2、RPC框架 优先根据链路蓝绿标，选择本环境节点调用 蓝色环境没有节点，选择绿色环境节点 绿色环境没有节点，选择不带颜色节点 需要根据场景是否启用，避免两个环境同时调度对业务影响 先暂缓实施，根据实际需要再考虑实施 2、数据库组件染色 数据库增加染色字段区分蓝绿 数据库组件根据链路标记更新染色字段 查询时在流量中赋值染色标记
92620编辑于 2022-12-03 蓝绿部署-解决99%的发布问题(APISIX)
如何使用APISIX网关进行蓝绿部署背景名人名言：99%的问题都是发布导致的。无论在测试环境测试的多么充分，在上线正式环境时依然有可能发生问题。 我们能不能在灰度期间就进行线上验证，从而提前发现问题，杜绝发布导致的事故？答案是能。蓝绿部署在蓝绿发布过程中，有两套生产环境：蓝环境和绿环境。蓝色是当前版本并拥有实时流量，绿色是包含更新代码的环境。 下面介绍两种方案实现根据uid路由，从而实现蓝绿部署。 Step 2: 修改原路由信息此时要修改原先的路由。修改包括两部分：高级匹配条件填写信息和step3要相反，打开非开关上游服务修改。 Step 2: 修改原路由信息在插件配置这里选择traffic-split(流量分割)插件，点击启用，输入如下配置。
35110编辑于 2025-08-27- 来自专栏微服务生态
基于Nginx+lua的蓝绿发布系统
一、什么是蓝绿发布 蓝绿部署是不停老版本，部署新版本然后进行测试，确认OK，将流量切到新版本，然后老版本同时也升级到新版本。 1、特点 蓝绿部署无需停机，并且风险较小。 2、蓝绿发布的注意事项 当你切换到蓝色环境时，需要妥当处理未完成的业务和新的业务。 蓝绿部署需要有基础设施支持。 在非隔离基础架构（ VM 、 Docker 等）上执行蓝绿部署，蓝色环境和绿色环境有被摧毁的风险。 二、为什么需要蓝绿发布系统 1、新项目和新需求非常多 2、新需求的上线过程是，先上线一台服务器然后观察会不会出问题，如果没有问题则全部上线。 3、分流是关键，但是动态分流是痛点。 2、修改完配置文件后，重启或者reload后才能生效。 3、不能实现太复杂的逻辑。 4、不能实现一些特殊分流方式。 四、新分流方案 ?
1.6K40发布于 2018-08-22 - 来自专栏k8s技术圈
Argo Rollouts 实现蓝绿金丝雀发布
蓝绿部署 金丝雀部署 与 Ingress 控制器和服务网格整合，实现高级流量路由 与用于蓝绿和金丝雀分析的指标提供者集成 根据成功或失败的指标，自动发布或回滚 渐进式交付 渐进式交付是以受控和渐进的方式发布产品更新的过程 Blue-Green(蓝绿)：蓝绿发布（有时称为红黑）指同时部署了新旧两个版本的应用程序，在此期间，只有旧版本的应用程序会收到生产流量，这允许开发人员在将实时流量切换到新版本之前针对新版本进行测试。 - pause: {duration: 10} - setWeight: 80 - pause: {duration: 10} revisionHistoryLimit: 2 watch rollouts 2. 可以看到 stable 版本已经切换到 revision:2 这个 ReplicaSet 了。
3.3K30发布于 2021-07-23 - 来自专栏憧憬博客分享
企业常用的几种发布方式(蓝绿发布 | 滚动升级 | 金丝雀发布)
服务变更的主要原因 1、修复错误 2、提高服务的质量 3、增加新的功能 服务变更需要注意哪些(或者说如何产生最小影响)？ SRE 经验告诉我们，大概 70% 的生产事故由某种部署的变更而触发。 2、每次部署前备份原始数据。 3、采用渐进式发布机制。 4、迅速而准确地检测到问题的发生。 5、当出现问题时，安全迅速地回退改动。 常用部署方式存在以下几种: 蓝绿部署 滚动部署 灰度部署/金丝雀部署 蓝绿部署 正常将项目分为两组, 蓝组和绿组, 正常运转的情况下每组承载 50% 的流量. 优点 更新过程体验影响少，风险较少 费用对比蓝绿花费开销较少，无需额外新增机器 缺点 上线/回滚完成时间相对较慢 需要监控和负载均衡器的移除和接入能力 金丝雀部署(灰度发布) 以前旷工开矿下矿洞前，先会放一只金丝雀进去探是否有有毒气体 金丝雀发布一般先发布一台, 或者小比例, 例如2%的服务器进行流量验证,国内也称为金丝雀测试, 流量测试通过, 慢慢将剩余机器也进行发布, 可以达到一个平滑过渡效果.
2.7K230发布于 2020-07-21 - 来自专栏无敌码农
蓝绿发布、滚动发布、灰度发布等部署方案，这些你必须懂！
蓝绿发布 （Blue/Green Deployment） ---- 〓定义 蓝绿部署是不停老版本，部署新版本然后进行测试。确认OK后将流量切到新版本，然后老版本同时也升级到新版本。 ▼部署版本 2 的应用 版本 2 的代码与版本 1 不同(新功能、Bug修复等)。 ▼将流量从版本 1 切换到版本 2。 ? 〓蓝绿发布的注意事项 当你切换到蓝色环境时，需要妥当处理未完成的业务和新的业务。如果你的数据库后端无法处理，会是一个比较麻烦的问题。 A/B 测试与蓝绿部署的区别在于， A/B 测试目的在于通过科学的实验设计、采样样本代表性、流量分割与小流量测试等方式来获得具有代表性的实验结论，并确信该结论在推广到全部流量可信；蓝绿部署的目的是安全稳定地发布新版本应用 相对于复杂的发布工具，实施比较简单，成本相对低廉。 研发能够灵活定制发布逻辑，支持 DevOps 自助发布。 ▼不足 切换是全量的，如果 V2 版本有问题，则对用户体验有直接影响。
2.3K10发布于 2019-07-31
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号