批量服务器如何灰度发布

‘壹’ 如果安装了很多服务器，有没有软件可以同时对多个服务器进行批量操作，不用一个一个的去设置

如果是要管理站点的话，linux下试试zijidelu吧

‘贰’ 新版本发布如何不影响线上呢灰色发布，蓝绿发布

很多企业升级服务器端应用，需要将源码或程序包上传到服务器，然后停掉老版本，再启动新版本。但是这种发布方式存在两个问题，一方面，在新版本升级过程中，线上的服务是中断的无法访问和使用的，另一方面，如果新版本有BUG或更新后发现有问题，升级失败，回滚起来也非常麻烦，容易造成更长时间的服务不可用。

以下内容转自网络，仅供本人自己学习用，侵删，原文链接： https://blog.51cto.com/13886290/2162766 ，

为了解决这些问题，人们研究出了多种发布策略，下面我们一一介绍。

蓝绿部署

所谓蓝绿部署，是指同时运行两个版本的应用，如上图所示，蓝绿部署的时候，并不停止掉老版本，而是直接部署一套新版本，等新版本运行起来后，再将流量切换到新版本上。但是蓝绿部署要求在升级过程中，同时运行两套程序，对硬件的要求就是日常所需的二倍，比如日常运行时，需要10台服务器支撑业务，那么使用蓝绿部署，你就需要购置二十台服务器。

滚动发布

滚动发布能够解决掉蓝绿部署时对硬件要求增倍的问题。

所谓滚动升级，就是在升级过程中，并不一下子启动所有新版本，是先启动一台新版本，再停止一台老版本，然后再启动一台新版本，再停止一台老版本，直到升级完成，这样的话，如果日常需要10台服务器，那么升级过程中也就只需要11台就行了。

但是滚动升级有一个问题，在开始滚动升级后，流量会直接流向已经启动起来的新版本，但是这个时候，新版本是不一定可用的，比如需要进一步的测试才能确认。那么在滚动升级期间，整个系统就处于非常不稳定的状态，如果发现了问题，也比较难以确定是新版本还是老版本造成的问题。

为了解决这个问题，我们需要为滚动升级实现流量控制能力。

灰度发布

灰度发布也叫金丝雀发布，起源是，矿井工人发现，金丝雀对瓦斯气体很敏感，矿工会在下井之前，先放一只金丝雀到井中，如果金丝雀不叫了，就代表瓦斯浓度高。

在灰度发布开始后，先启动一个新版本应用，但是并不直接将流量切过来，而是测试人员对新版本进行线上测试，启动的这个新版本应用，就是我们的金丝雀。如果没有问题，那么可以将少量的用户流量导入到新版本上，然后再对新版本做运行状态观察，收集各种运行时数据，如果此时对新旧版本做各种数据对比，就是所谓的A/B测试。

当确认新版本运行良好后，再逐步将更多的流量导入到新版本上，在此期间，还可以不断地调整新旧两个版本的运行的服务器副本数量，以使得新版本能够承受越来越大的流量压力。直到将100%的流量都切换到新版本上，最后关闭剩下的老版本服务，完成灰度发布。

如果在灰度发布过程中（灰度期）发现了新版本有问题，就应该立即将流量切回老版本上，这样，就会将负面影响控制在最小范围内。

关于负载均衡的另一篇文章： https://www.jianshu.com/p/836a87355ea7

‘叁’ F5提出的“灰度发布”是什么意思呢

灰度发布是在软件开发过程中交付的一种方式
F5率先提出在应用交付控制器中支持“灰度发布”，并进一步完善了灰度发布的实现形式，除支持传统的A/B测试场景外，还可在线复制生产系统的流量到测试系统。在互联网产品的发布过程中也较多采用此种发布方式：产品的发布过程不是一蹴而就，而是逐步扩大使用用户的范围，从公司内部用户->忠诚度较高的种子用户->更大范围的活跃用户->所有用户。在此过程中，产品团队根据用户的反馈及时完善产品相关功能。此种发布方式，按照中国特色的叫法被冠以“灰度发布”、“灰度放量”、“分流发布”。

请采纳！

‘肆’ 部署的几种方式

由于之前只接触了单服务应用，并且是自己做的，所以部署的方式也比较随意，想要部署的话直接打一个war包部署上去就好了。接触过分布式的多服务后，事情就没有这么简单了，如果还是采用之前的方式，会存在两个问题，一方面，在新版本升级过程中，服务是暂时中断的，另一方面，如果新版本有BUG，升级失败，回滚起来也非常麻烦，容易造成更长时间的服务不可用。

下面是对集中常见部署方式的了解：

蓝绿部署是我可以不看其他推荐，自己想到了部署方式。直接运行两个版本的应用，并不停止旧版本的运行，而是等新版本运行正常后将流量切到新版本，但是缺点也很明显，我需要双倍的资源，平时10台服务器就可以解决的问题现在需要20台了。

滚动发布能够解决掉蓝绿部署时对硬件要求增倍的问题。在升级的时候不是把所有的服务都启动，而是启动一台新的服务就替换掉对应的老服务，这样正常需要10台服务器，现在只需要11台就好了，缺点也很明显，就是太不稳定了，出了问题不容易追溯。

灰度发布也叫金丝雀发布，起源是，矿井工人发现，金丝雀对瓦斯气体很敏感，矿工会在下井之前，先放一只金丝雀到井中，如果金丝雀不叫了，就代表瓦斯浓度高。

在灰度发布开始后，先启动一个新版本应用，但是并不直接将流量切过来，而是测试人员对新版本进行线上测试，启动的这个新版本应用，就是我们的金丝雀。如果没有问题，那么可以将少量的用户流量导入到新版本上，然后再对新版本做运行状态观察，收集各种运行时数据，如果此时对新旧版本做各种数据对比，就是所谓的A/B测试。

当确认新版本运行良好后，再逐步将更多的流量导入到新版本上，在此期间，还可以不断地调整新旧两个版本的运行的服务器副本数量，以使得新版本能够承受越来越大的流量压力。直到将100%的流量都切换到新版本上，最后关闭剩下的老版本服务，完成灰度发布。

如果在灰度发布过程中（灰度期）发现了新版本有问题，就应该立即将流量切回老版本上，这样，就会将负面影响控制在最小范围内。

‘伍’ 使用Nginx 简单实现灰度发布

灰度发布是指在黑与白之间, 能够平滑过渡的一种发布方式. AB test就是一种灰度发布试. 让一部分用户继续使用A, 一部分用户开始使用B, 如果用户对B没有什么反对意见, 那么逐步扩大范围, 把所有用户都迁移到B上面来.

灰度发布可以保证整体系统的稳定, 在初始灰度的时候就可以发现,调整问题, 以保证其影响度.

灰度发布常见一般有三种方式:

本文主要讲解 根据Cookie和来路IP这两种方式来实现简单的灰度发布, Nginx+LUA 这种方式涉及内容太多就不再本文展开了.

根据 Cookie 查询 Cookie 键为 version 的值, 如果该 Cookie 值为 V1 , 则转发到 hilinux_01 , 为 V2 则转发到 hilinux_02 , Cookie 的值都不匹配的情况下, 默认走 hilinux_01 所对应的服务器.

两个服务器分别定义为:

在Nginx里面配置一个映射, $COOKIE_version 可以解析出 Cookie 里面的version字段, $group 是一个变量, {}里面是映射规则.

如果一个 version 为 V1 的用户来访问， $group 就等于 hilinux_01 。在 server 里面使用就会代理到 http://hilinux_01 上。 version 为 V2 的用户来访问， $group 就等于 hilinux_02 。在 server 里面使用就会代理到 http://hilinux_02 上。 Cookie 值都不匹配的情况下默认走 hilinux_01 所对应的服务器。

如果是内部IP，则反向代理到hilinux_02(预发布环境)；如果不是则反向代理到hilinux_01(生产环境)。

如果你只有单台服务器，可以根据不同的IP设置不同的网站根目录来达到相同的目的。

到此最基本的实现灰度发布方法就讲解完了，如果要做更细粒度灰度发布可参考ABTestingGateway项目。

‘陆’ 蓝绿发布、红黑发布、灰度发布和滚动发布

总结:
蓝绿发布、红黑发布、灰度发布和滚动发布组最终的目标都是避免因发布导致流量的丢失或服务不可用的问题

四种方式均可以做到平滑式升级，在升级过程中服务仍然保持服务的连续性，升级对外界是无感知的。那生产上选择哪种部署方法最合适呢？这取决于哪种方法最适合你的业务和技术需求。如果你们运维自动化能力储备不够，肯定是越简单越好，建议蓝绿发布，如果业务对用户依赖很强，建议灰度发布。如果是K8S平台，滚动更新是现成的方案，建议先直接使用。

蓝绿发布：两套环境交替升级，旧版本保留一定时间便于回滚。

红黑发布: 申请新环境,删除老版本

灰度发布：根据比例将老版本升级，例如80%用户访问是老版本，20%用户访问是新版本。

滚动发布：按批次停止老版本实例，启动新版本实例。

项目逻辑上分为AB组，在项目系统时，首先把A组从负载均衡中摘除，进行新版本的部署。B组仍然继续提供服务。

当A组升级完毕，负载均衡重新接入A组，再把B组从负载列表中摘除，进行新版本的部署。A组重新提供服务。

1.如果出问题，影响范围较小；
2.发布策略简单；
3.用户无感知，平滑过渡；
4.升级/回滚速度快。

1.需要准备正常业务使用资源的两倍以上服务器，防止升级期间单组无法承载业务突发；
2.短时间内浪费一定资源成本；
3.基础设施无改动，增大升级稳定性。

当前服务都运行在集群A上

在云上申请一个黑色集群 B，在 B 上部署新版本的服务； 等到 B 升级完成

最后一次性地把负载均衡全部指向 B,并把 A 集群从负载均衡列表中删除，并释放集群 A 中所有机器。

可以看到，与蓝绿部署相比，红黑部署只不过是充分利用了云计算的弹性伸缩优势，从而获得了两个收益：一是，简化了流程；二是，避免了在升级的过程中，由于只有一半的服务器提供服务，而可能导致的系统过载问题。

1.从LB摘掉灰度服务器，升级成功后再加入LB；
2.少量用户流量到新版本；
3.如果灰度服务器测试成功，升级剩余服务器。

1.保证整体系统稳定性，在初始灰度的时候就可以发现、调整问题，影响范围可控；
2.新功能逐步评估性能，稳定性和健康状况，如果出问题影响范围很小，相对用户体验也少；
3.用户无感知，平滑过渡。

自动化要求高

滚动发布是指每次只升级一个或多个服务，升级完成后加入生产环境，不断执行这个过程，直到集群中的全部旧版本升级新版本。

1.保证整体系统稳定性，在初始灰度的时候就可以发现、调整问题，影响范围可控；
2.新功能逐步评估性能，稳定性和健康状况，如果出问题影响范围很小，相对用户体验也少；
3.用户无感知，平滑过渡。

自动化要求高

‘柒’ 灰度发布

灰度发布又称金丝雀发布，起源是早起矿井工人发现金丝雀对瓦斯气体很敏感。因此旷工在下井之前都会先将一只金丝雀放到井中，如果金丝雀不叫了，就代表瓦斯浓度高。

度娘说的挺好的~

在灰度发布开始后，先启动一个新版本应用，但是并不直接将流量切过来，而是测试人员对新版本进行线上测试，启动的这个新版本应用，就是我们的金丝雀。如果没有问题，那么可以将少量的用户流量导入到新版本上，然后再对新版本做运行状态观察，收集各种运行时数据，如果此时对新旧版本做各种数据对比，就是所谓的A/B测试。

当确认新版本运行良好后，再逐步将更多的流量导入到新版本上，在此期间，还可以不断地调整新旧两个版本的运行的服务器副本数量，以使得新版本能够承受越来越大的流量压力。直到将100%的流量都切换到新版本上，最后关闭剩下的老版本服务，完成灰度发布。

如果在灰度发布过程中（灰度期）发现了新版本有问题，就应该立即将流量切回老版本上，这样，就会将负面影响控制在最小范围内。

‘捌’ 蓝绿发布、滚动发布、灰度发布（金丝雀发布）、A/B测试

在一般情况下，升级服务器端应用，需要将应用源码或程序包上传到服务器，然后停止掉老版本服务，再启动新版本。但是这种简单的发布方式存在两个问题，

（1）在新版本升级过程中，服务是会暂时中断的。

（2）如果新版本有BUG，升级失败，回滚起来也非常麻烦，容易造成更长时间的服务不可用。

（3）新功能体验不好，版本升级过程中带来的流量有损，造成用户流失。

为了解决这些问题，人们研究出了几种常见的服务发布策略，下面一一介绍。

所谓蓝绿部署，是指同时运行两个版本的应用，

如上图所示，蓝绿发布部署时候需要对服务的新版本进行冗余部署并不停止掉老版本，一般新版本的机器规格和数量与旧版本保持一致，相当于该服务有两套完全相同的部署环境，只不过此时只有旧版本在对外提供服务，新版本作为热备。当服务进行版本升级时，我们只需将流量全部切换到新版本即可，旧版本作为热备。由于冗余部署的缘故，如果新版本上线后出现严重的程序 BUG，那么我们只需将流量全部切回至旧版本，大大缩短故障恢复的时间。待新版本完成 BUG 修复并重新部署之后，再将旧版本的流量切换到新版本。

蓝绿发布通过使用额外的机器资源来解决服务发布期间的不可用问题，当服务新版本出现故障时，也可以快速将流量切回旧版本。

蓝绿部署的优点：

1、部署结构简单，运维方便；

2、服务升级过程操作简单，周期短。

蓝绿部署的缺点：

1、资源冗余，需要部署两套生产环境；

2、新版本故障影响范围大。

ps：当然，蓝绿发布也可以在系统非繁忙时段进行升级，把现有的集群服务器一分为二，一半升级一半保留并隔离，待到新系统稳定后升级另一半服务器，并解除隔离。从而充分利用现有服务器资源。

滚动发布能够解决掉蓝绿部署时对硬件要求增倍的问题。

所谓滚动升级，就是在升级过程中，并不一下子启动所有新版本，是先启动一台新版本，再停止一台老版本，然后再启动一台新版本，再停止一台老版本，直到升级完成，这样的话，如果日常需要10台服务器，那么升级过程中也就只需要11台就行了。

但是滚动升级有一个问题，在开始滚动升级后，流量会直接流向已经启动起来的新版本，这个时候，新版本是不一定可用的，比如需要进一步的测试才能确认。那么在滚动升级期间，整个系统就处于非常不稳定的状态，如果发现了问题，也比较难以确定是新版本还是老版本造成的问题。

为了解决这个问题，我们需要为滚动升级实现流量控制能力。

在灰度发布开始后，先启动一个新版本应用，但是并不直接将流量切过来，而是测试人员对新版本进行线上测试，启动的这个新版本应用，就是我们的金丝雀。验证新版本符合预期后，逐步调整流量权重比例，使得流量慢慢从老版本迁移至新版本，期间可以根据设置的流量比例，对新版本服务进行扩容，同时对老版本服务进行缩容，使得底层资源得到最大化利用。

相比于前两种发布策略，灰度发布的思想则是将少量的请求引流到新版本上，因此部署新版本服务只需极小数的机器。

灰度发布可以基于用户请求的元信息将流量路由到新版本，这是一种基于请求内容匹配的灰度发布策略。只有匹配特定规则的请求才会被引流到新版本，常见的做法包括基于 Http Header 和 Cookie。基于 Http Header 方式的例子，例如 User-Agent 的值为 Android 的请求 （来自安卓系统的请求）可以访问新版本，其他系统仍然访问旧版本。基于 Cookie 方式的例子，Cookie 中通常包含具有业务语义的用户信息，例如VIP可以访问新版本，普通用户用户仍然访问旧版本（或者相反）。

如图，某服务当前版本为 v1，现在新版本 v2 要上线。为确保流量在服务升级过程中平稳无损，采用金丝雀发布方案，逐步将流量从老版本迁移至新版本。

灰度发布期间再对新版本做运行状态观察，收集各种运行时数据，如果此时对新旧版本做各种数据对比， 就是所谓的A/B测试。 通过在监控平台观察旧版本与新版本的成功率、RT 对比，当新版本整体服务预期后，即可将所有请求切换到新版本。

灰度发布的优点：

1、可以对特定的请求或者用户提供服务新版本，新版本故障影响范围小；

2、发布期间逐步对新版本扩容，同时对老版本缩容，资源利用率高。

3、需要构建完备的监控平台，用于对比不同版本之间请求状态的差异（做A/B测试）。

灰度发布的缺点：

1、仍然可能存在资源冗余，因为无法准确评估请求容量；

2、如果流量无差别地导向新版本，可能会影响用户的体验；

3、发布周期长。

最佳实践：

在新版本应用发布时，为了服务器不停机升级且影响最小，使用灰度发布策略，

在灰度发布开始时，使用HTTP Header等策略 匹配指定测试人员的流量到新版本上，

然后当新版本内部测试通过后，可以再按百分比、白名单等，将用户流量一点一点导入到新版本中，直到将流量全部导入到新版本上，最后完成升级，

如果期间发现问题，就立即取消升级，将流量切回到老版本。

运用灰度发布，就再也不需要加班到深夜进行停机升级了，在白天就可以放心大胆地、安全地发布新版本^_^。

参考：

https://blog.csdn.net/luo15242208310/article/details/118888496

https://developer.aliyun.com/article/847533

‘玖’ Spring微服务灰度发布（热部署）的实现（二）

接着上篇说，我们微服务中用到的nepxion discovery主要采用了三种灰度发布方式，一种是web图形化界面发布，二是zuul过滤器灰度发布，三是业务参数策略灰度发布。下面将重点介绍三种方式的实现。

一、web图形化界面灰度发布

因为我们项目用到了eureka注册中心，所以选择web图形化界面灰度发布比较合适。

1） 首先需要建立一个discovery控制台工程console, 端口为2222，控制台工程负责web图形化界面请求的处理，运行console工程。

2） 下载discovery ui,地址：https://github.com/Nepxion/DiscoveryUI，运行discovery UI，端口为8090

3）浏览器中输入localhost:8090,即可打开控制台，如下

注意：全链路灰度发布需要在“配置中心”下才可用。灰度发布配置中心，负责存储全链路灰度发布规则，并将规则推送到各个微服务中。而配置中心可用nacos，redis等，Discovery 中提供了相应配置中心的插件包。

二、zuul网关过滤器灰度发布

通过网关过滤器传递Http Header的方式传递全链路灰度路由规则。下面代码只适用于Zuul和Spring Cloud Gateway网关，Service微服务不需要加该方式。

三、业务参数在策略类中自定义灰度路由规则

通过策略方式自定义灰度路由规则。下面代码既适用于Zuul和Spring Cloud Gateway网关，也适用于Service微服务，同时全链路中网关和服务都必须加该方式

上面说了具体灰度规则发布方式，那究竟怎么定义灰度规则呢？？

规则是基于XML或者Json为配置方式，存储于本地文件或者远程配置中心，可以通过远程配置中心修改的方式达到规则动态化。其核心代码参考discovery-plugin-framework以及它的扩展、discovery-plugin-config-center以及它的扩展和discovery-plugin-admin-center等，规则示例

XML示例（Json示例见discovery-springcloud-example-service下的rule.json）

黑/白名单的IP地址注册的过滤规则

微服务启动的时候，禁止指定的IP地址注册到服务注册发现中心。支持黑/白名单，白名单表示只允许指定IP地址前缀注册，黑名单表示不允许指定IP地址前缀注册。规则如何使用，见示例说明

最大注册数的限制的过滤规则

微服务启动的时候，一旦微服务集群下注册的实例数目已经达到上限（可配置），将禁止后续的微服务进行注册。规则如何使用，见示例说明

黑/白名单的IP地址发现的过滤规则

微服务启动的时候，禁止指定的IP地址被服务发现。它使用的方式和“黑/白名单的IP地址注册的过滤规则”一致

版本访问的灰度发布规则

版本权重的灰度发布规则

全局版本权重的灰度发布规则

区域权重的灰度发布规则

全局区域权重的灰度发布规则

网关端全链路路由策略的灰度发布规则

注意 路由策略的入口有三个（以{"discovery-springcloud-example-a":"1.0", "discovery-springcloud-example-b":"1.0", "discovery-springcloud-example-c":"1.0;1.2"}）为例：

其作用的优先级为外界传入>网关Filter指定>配置中心或者本地rule.xml配置

您可以根据自己需求，自由定义灰度发布规则，灵活实现微服务的灰度发布。

源码位置：https://github.com/Nepxion/Discovery

‘拾’ 计算机术语中“灰度发布”的英文是什么

Gray released in computer terms。

灰度发布（又名金丝雀发布）是指在黑与白之间，能够平滑过渡的一种发布方式。

灰度分布让一部分用户继续用产品特性A，一部分用户开始用产品特性B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。

注意事项

灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。

对于一般的小系统并不需要单独的灰度发布引擎，可以参考A/B测试中做法，在页面JavaScript或服务器端实现分流的规则即可。但对于大型的互联网应用而言，单独的用于管理用户分流的发布引擎就很有必要了。