一、灰度发布定义 灰度发布（又名金丝雀发布）是指在黑与白之间，能够平滑过渡的一种发布方式。 灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。 ? 二、实现思路方向 1、在代码中做。 多套(隔离的)线上环境，接入层针对不同用户转发到不同的环境中 两种方案的优缺点： 方案 优点 缺点 在代码中做 灵活，粒度细；一套代码(环境)运维成本低 灰度逻辑侵入代码 在接入层做 无需（少）侵入代码 ；风险小 多套线上环境，运维成本高 灵活的灰度方案一般需要在接入层实现，具体就是自定义负载均衡策略实现。 例：略 四、dubbo灰度方案说明 Dubbo架构 ? Dubbo服务调用过程 ?
一个大型的前端项目在发布时，都会采取灰度策略。第一次听同事说灰度的时候，还是停留在疑惑阶段，对这个词不了解，后续做了一些功课，才明白灰度的意义。 前言 前段时间在面试的时候遇到过前端灰度发布相关的问题，刚好在之前公司有设计过前端灰度发布的方案，这套方案也在多个系统上得到过验证了，最近有时间整理，现在也拿出来和大家交流下，在结尾也给大家留下了一些的代码实现 、令牌算法等 什么是灰度发布 将某个功能灰度发布（逐渐放量）给特定线上人群，避免新功能全量上线带来的风险 上白话文，某项目当前处于1.0版本，但是想更新一个1.1版本，1.1版本内测没有问题了，但是由于改动了关键的功能 实现这种场景效果，就是灰度发布。 什么是灰度规则？ 1.0版本 常见灰度发布方案 灰度方案各式各样，既有多样就有对比，没有最好，只有最合适自己的业务场景，这里给大家介绍几种方案，以便大家做比较选择 1.
代金券、腾讯视频VIP、QQ音乐VIP、QB、公仔等奖励等你来拿！
微信公众号：[中间件兴趣圈] 作者简介：《RocketMQ技术内幕》作者 方案背景 背景：基于Dubbo服务的治理，是否可以支持业务级别的灰度发布、是否基于业务参数的路由转发。 的请求转发到新版本服务器，其他合作伙伴还是转发到旧版，实现业务级别的灰度发布，控制新版本的影响范围。 方案理论基础 Dubbo的服务调用原理图： ? 服务的灰度发布，其目标是希望根据请求，某些请求走新版本服务器，某些请求走旧版本服务器，其本质就是路由机制，即通过一定的条件来缩小服务的服务提供者列表，正好与Dubbo的Router相吻合。 总结 上述展示了Dubbo服务基于业务灰度发布的方案，以及基于合作伙伴的服务隔离机制（根据服务调用业务参数来决定服务调用者的筛选）。
灰度发布，对于大厂来说是必不可少的，对于我这种从来没有灰度发布过的，并不是很清楚，估计也有很多人不知道这个东西。以前只是直到灰度发布，这次稍微了解一下。 灰度发布是指新版本或者新功能通过一定策略选取一些用户，让他们先使用，通过使用情况对功能、性能、稳定性等指标评估是否扩大范围直至全面发布。 灰度发布开始到结束期间的这一段时间，称为灰度期。 如果是客户端的灰度发布，应该是可以按照用户逐渐推送更新安装包。而服务端的灰度发布则会相应容易一些，毕竟是在后台实现。 现在有专门的灰度发布模式A/B测试，通过业务代码区分流量访问不同代码。 灰度发布除了代码层面之外，对服务这块要求还是蛮大的，灰度发布不同于预发布，灰度发布是直接让线上用户参与，而一般预发布是发布到线上，由测试人员进行测试。 当然，会使用灰度发布的，一般来说都是千万级别用户的项目了，虽然很想使用灰度发布，但还是需要考虑实际场景，也希望以后能有机会使用灰度发布。 （完）
灰度发布浅析 定义 灰度发布就是已一种平滑过渡的方式来发布，通过切换线上新旧版本之间的路由权重，逐步从旧版本切换到新版本；比如要上线新功能，首先只是更新少量的服务节点，通过路由权重，让少部分用户体验新版本 灰度发布 一个系统往往有接入层比如nginx(Openresty)，网关层比如zuul，以及服务层比如各种rpc框架；在这几层都有路由功能，也就是说这几层都可以做灰度；接入层可以使用nginx+lua来实现灰度 ，网关层zuul可以结合ribbon来实现灰度，rpc框架如dubbo本身提供了路由功能可以直接做灰度处理；下面看看具体如何去实现； 接入层灰度 接入层我们这里使用功能更强大的Openresty，然后使用 ：旧路由规则 测试 启动zookeeper，然后分别启动两台生产者，启动消费者时通过修改tag然后观察路由； 总结 本文分别从接入层，网关层，服务层这三层简要的介绍了通过路由规则来实现灰度发布；已每层比较典型的中间件来介绍具体如何去实现简单的灰度发布 ；总体来说就是使用中间件的路由功能，动态加载外部自定义的一些路由策略脚本，以此来达到灰度发布的目的。
1、什么是灰度发布 以下是百度词条的解释： 灰度发布（又名金丝雀发布）是指在黑与白之间，能够平滑过渡的一种发布方式。 灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。 3、常用的灰度发布方式有哪些 1、按机器灰度 ? 线上有多台机器，先将新功能代码部署到其中的1台或多台机器，然后绑定到这些机器进行测试，测试完没问题再部署到所有机器。 打个比方，我们要做一个加密数据库字段的功能，先判断当前用户是否灰度，如果是则将其数据加密，否则不加密。 4、案例分析 我们以一个实际的例子来分析如何做灰度。 这种方案操作会比较复杂些，配置灰度用户可能需要分几批，如果配置中心等基础服务都上来了，操作还好，不然就得一台一台机器人肉了~ 另外这种方案对业务侵入性比较大，如果每个项目都需要这么实现，工作量就比较大
一、灰度发布 灰度发布是一种发布方式，也叫金丝雀发布，起源是矿工在下井之前会先放一只金丝雀到井里，如果金丝雀不叫了，就代表瓦斯浓度高。原因是金丝雀对瓦斯气体很敏感。 灰度发布的做法是：会在现存旧应用的基础上，启动一个新版应用，但是新版应用并不会直接让用户访问。而是先让测试同学去进行测试。 代表是否开启灰度功能 nginx.ingress.kubernetes.io/canary-by-cookie：灰度发布 cookie 的 key。当 key 值等于 always 时，灰度触发生效。 header去判断是否为灰度用户，再决定是否返回灰度版本服务。 二、滚动发布 滚动发布，则是我们一般所说的无宕机发布。其发布方式如同名称一样，一次取出一台/多台服务器（看策略配置）进行新版本更新。
本文将对目前常用的部署方案做一个简单的总结。 蓝绿发布（Blue/Green Deployment） 1. 定义 蓝绿部署是不停老版本，部署新版本然后进行测试。 灰度发布 1. 定义 灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式。 灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。 2. A/B Testing A/B 测试是用来测试应用功能表现的方法，例如可用性、受欢迎程度、可见性等等。 3.金丝雀发布 我们平常所说的金丝雀部署也是灰度发布的一种方式，在原有版本可用的情况下，同时部署一个新版本应用作为「金丝雀」服务器来测试新版本的性能和表现，以保障整体系统稳定的情况下，尽早发现、调整问题 除此之外灰度发布还可以设置路由权重，动态调整不同的权重来进行新老版本的验证。 优势和不足 优势 用户体验影响小，灰度发布过程出现问题只影响少量用户。
.因此本篇用灰度发布的例子来做前期的铺垫 灰度发布 先看看百度百科的概念 灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式。 AB test就是一种灰度发布方式，让一部分用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。 灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。 说人话就是,你发布应用的时候,不停止对外的服务,也就是让用户感觉不到你在发布.那么下面演示一下灰度发布 1.首先在192.168.56.2和192.168.56.3两台机器上启动Provider,然后启动 如果看过我前两篇dubbo源码解析dubbo源码解析-集群容错架构设计和dubbo源码解析-directory就明白,我的分析过程都是以官方文档为依据,所以这个问题的答案自然也在官方文档.下面引用一段官网文档的描述
.因此本篇用 灰度发布的例子来做前期的铺垫 灰度发布 先看看百度百科的概念 灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式。 AB test就是一种灰度发布方式，让一部分用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。 灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。 说人话就是,你发布应用的时候,不停止对外的服务,也就是让用户感觉不到你在发布.那么下面演示一下灰度发布 1.首先在 192.168.56.2和 192.168.56.3两台机器上启动 Provider, 如果看过我前两篇dubbo源码解析dubbo源码解析-集群容错架构设计和dubbo源码解析-directory就明白,我的分析过程都是以 官方文档为依据,所以这个问题的答案自然也在官方文档.下面引用一段官网文档的描述
本文将对目前常用的部署方案做一个简单的总结。 蓝绿发布 （Blue/Green Deployment） ---- 〓定义 蓝绿部署是不停老版本，部署新版本然后进行测试。 灰度发布 〓定义 灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式。 灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。 ▼灰度发布结构图 ? 〓金丝雀发布 我们平常所说的金丝雀部署也是灰度发布的一种方式，在原有版本可用的情况下，同时部署一个新版本应用作为「金丝雀」服务器来测试新版本的性能和表现，以保障整体系统稳定的情况下，尽早发现、调整问题。 除此之外灰度发布还可以设置路由权重，动态调整不同的权重来进行新老版本的验证。 〓优势和不足 ▼优势 用户体验影响小，灰度发布过程出现问题只影响少量用户。
存在以下痛点: 商品审核规则不够灵活，只支持校验阈值的快速变更 更改依赖代码修改发布，变更周期长 回归测试流程繁琐，不支持灰度 2.2 目标 ? 全流程配置化避免了代码的变更，通过规则的灰度发布简化了流程，并且一定程度降低了发布可能导致的风险。 三、整体设计 ? 整体分为2个大的模块：实时数据的聚合查询、规则执行系统。 3.1.1 数据源 数据源接入方式有 dubbo 接口、http 接口。其中，dubbo 使用泛化调用的方式实现，dubbo 数据源配置服务名、方法名和入参模板，调用业务方。 3.2.3 规则灰度发布流程 配置化导致了变更的便捷。但是便捷的流程如果没有可靠的保障，频繁变更之下就很容易出错。但是一个好的流程规范虽不能完全避免错误，但可以在一定程度上减少错误。 ? 四、总结 配置化的规则替代了硬编码的校验逻辑，减少了修改规则发布代码维护的成本，使原本的规则变更周期从一周的修改测试发布变成了实时更改。同时规则的灰度发布也使验证变得简单。
经过选型，我们选用更灵活的权重调节方案，通过Dubbo-Admin对需要下线机器的APP应用接口权限设置为0。 ? 图8 2 灰度发布实践 通过之前的平滑发布和小范围验证的摸索，开始进行灰度发布实践之路。 灰度发布，我相信大家对这个词都有各自的理解和体会，它也有很多相似的概念或变体。 通过这种方式，我们即完成在不需要停服的情况下，对线上APP进行灰度发布及验证，对应的各基础组件截图如下： 配置中心Disconf：通过版本来对应GROUP的功能 ? 细心的同学一定发现了，前面讲的灰度发布流程，应该是有一定先决条件的，体现在以下几个方面： 数据层的变化导致新老版本无法兼容的，不能使用灰度发布。 再次，如果需要长时间来验证灰度环境，线上会同时存在两个甚至以上的版本，不利于运维维护，且监控方面需要加强。 最后，能否利用灰度发布的方式，在线上进行流量回放及全链路压测，也是一个后续摸索的话题。
而灰度发布能带来什么样的好处呢？可以让你少伤害一部分用户啊~如果出了问题，回滚或者对影响到的用户进行补偿都很方便(毕竟钱能解决的问题都不是问题，但规模太大的时候补偿手段就不好使了。 这样说的话可能有些人会提出异议，我们在做代码发布的时候先发布一台机器，然后再发布十台，然后一百台这样的，似乎是叫小流量上线，这个和灰度发布有区别么？ 两者还是有一些区别的，小流量上线一般做的是系统的彻底升级，和灰度发布不一样。也即是前面提到的，灰度发布期间，线上的系统两套代码在同一台新发布的机器上也同时存在。 灰度发布一般人都比较熟悉的案例可能是微软的操作系统升级吧，其实腾讯qq或者微信发布也差不多。不过说到操作系统升级，灰度发布感觉还有另外的一层意思。可以控制用户流量对网络或者系统的负载的影响。 继续来说互联网公司的灰度发布系统。 一般的灰度发布都会有一些策略，其实就是分类/桶策略。
，蓝绿部署、滚动部署、灰度发布、金丝雀发布。。。 整个游戏的链条上，似乎大家都已经习惯，开发习惯，玩家也习惯 习惯麻痹了一切，没有提出更好的策略，大家都这么玩啊，无所谓啦~ 方案 细思极恐，我们应该，也需要做得更好 灰度发布／金丝雀发布 灰度发布是在原有版本可用的情况下 灰度发布／金丝雀发布由以下几个步骤组成： 准备好部署各个阶段的工件，包括：构建工件，测试脚本，配置文件和部署清单文件。 从负载均衡列表中移除掉“金丝雀”服务器。 在之前的架构图中，稍作修改，在玩家与Gameserver之间增加一层ha-proxy，这样就有了灰度发布的基础 玩家不再直接与game-server直连，而是与ha-proxy 透明性 对玩家来说，发版本就是透明的 结论 对于以上方案，不论是哪一种实现方式，仁者见仁，条条大路通罗马。 也可能你觉得这种想法本身就是个多余。 能卖1块钱的豆腐，为什么要卖5毛？
蓝绿发布 [zouhf7hpk5.png? 1650518920&q-header-list=&q-url-param-list=&q-signature=3f398079c973505209591401cb9401008dd76a12] 滚动发布 1650518935&q-header-list=&q-url-param-list=&q-signature=f2a6ceb02a224f84827c94410ec3fd6b3ca71073] 金丝雀/灰度发布 q-header-list=&q-url-param-list=&q-signature=f1e00c1938c3f637f272370811873e986e768d32] 实际使用过程中往往是AB测试+灰度结合使用 微服务中实现方案: provider 自定义元数据来区分服务版本 1.通过网关中filter进行路由, 2.服务间调用不通过网关时,通过重写Ribbon中路由接口, 用户id通过切面拦截请求,存储在ThreadLocal
灰度发布是实现新旧版本平滑过渡的一种发布方式，即让一部分服务更新到新版本，如果这部分服务没有什么问题，再将其它旧版本的服务更新。 而实现简单的灰度发布我们可以使用版本号控制，每次发布都更新版本号，新更新的服务就不会调用旧的服务提供者。 较复杂的灰度发布场景可以由版本号加路由功能实现。 发起一次RPC调用都是先经过路由过滤，再到负载均衡选出最终调用的服务提供者发起调用。 标签配置支持两种： 条件路由。支持以服务或Consumer应用为粒度配置路由规则。 标签路由。 以Provider应用为粒度配置路由规则。 本篇只介绍标签路由的使用及实现 dubbo版本：2.7.3 使用路由功能实现区域隔离 以区域隔离为例，介绍Dubbo路由功能的使用。 但dubbo使用模版方法模式，将路由器链的调用逻辑封装在了抽象类AbstractClusterInvoker，以实现通用逻辑的重用。
一、Dubbo介绍 Java开发的同学相信对Dubbo都有了解，Dubbo是阿里开源的RPC/服务治理框架，以下是百度的解释： Dubbo(读音[ˈdʌbəʊ])是阿里巴巴公司开源的一个高性能优秀的服务框架 Dubbo是一款高性能、轻量级的开源Java RPC框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。 ，可以作为蓝绿发布、灰度发布等场景的能力基础。 这个服务其中1台172.21.107.21，打了标签pre，后续Consumer调用时，只要带了pre的tag，就一定会调用到这台机；而没带tag的会调用到另1台机172.21.107.22，这样就可以实现灰度发布了 三、灰度发布 我们来看下如何通过tag路由做灰度，假设我们的应用架构是这样的： ?
基于系统稳定性和快速业务迭代的综合考虑，业务应用开发团队采取了新版本服务灰度上线的方式，即新版本服务并非全量发布到线上环境，而是发布少数几个实例进行灰度验证，没有问题后再全量发布。 Nginx层； 提供完整的流量控制方案，除了上面提到的黑白名单和百分比流量控制策略，项目还将深挖业务需求，提供更丰富的动态流量控制策略； 与Ops运维管理系统打通，实现易于使用和管理的灰度发布及其他服务治理产品 二、灰度发布 2.1 什么是灰度发布 灰度发布，是在生产环境稳定集群之外，额外部署一个小规模的灰度集群，并通过流量控制，引入部分流量到灰度集群，进行生产全量发布前的灰度验证。 2.2 发布流程 下面从产品层面介绍一下有赞灰度发布的流程，包括：灰度发布开始、灰度初始化、灰度验证、灰度取消或全量发布、灰度发布结束。 (1) 灰度发布开始。 有赞在灰度与蓝绿发布产品中，可观测性与可运维性方面也做了不少工作。主要包括发布应用监控、发布事件通知、全局发布状态以及周期统计报表。下面介绍一下有赞蓝绿发布产品在可观测性与可运维性方面的一些工作。
工行在分布式系统建设方面一直走在同业前列，积极探索分布式全链路灰度发布，致力于解决分布式架构下跨应用、跨服务的全链路灰度发布能力。 ? 业界传统灰度发布 灰度发布是业界一种规避发布风险的有效的手段，通常可以蓝绿部署、滚动发布、灰度发布等几种方式实现。 1. 截至 2019 年，工行各项目主要通过滚动升级、蓝绿发布、业务开关三种方式实施了灰度发布。 工行于 2020 年上半年已支持分布式全链路灰度发布方式，旨在复杂分布式场景中，针对行内重点产品线、重点应用、公共支撑平台，形成统一的灰度发布规范，为重点产品线提供了全链路灰度发布能力的技术支撑。 图 6 服务框架灰度路由 3）灰度标签链路透明传递 在业务服务层，服务框架负责灰度标签的传递。Dubbo 提供了优雅的隐式参数机制，方便地传递上下游的一些标记和控制消息，而实现对业务无感的能力。
Mesh 微服务平台提供了下一代微服务架构-服务网格的解决方案。Mesh 微服务平台支持跨编程语言、不同部署方式的应用生命周期管理、精细化的服务治理、立体化监控能力，帮助大型企业客户解决编程语言不统一、部署方式不统一等架构转型的困难；支持强大的服务流量路由能力，帮助用户实现灰度发布、故障注入等业务场景。
扫码关注云+社区
领取腾讯云代金券
云服务器
测试服务 WeTest
文件存储
命令行工具
SSL 证书