【云原生&微服务＞SCG网关篇二】生产上那些灰度发布方式

【云原生&微服务＞SCG网关篇二】生产上那些灰度发布方式

一、前言

在前面的文章：

​​【SCG | 微服务网关一】为什么要有网关、生产环境如何选择网关​​

我们聊了网关的作用？网关的一些技术选型？

然而在网关中通常会涉及到灰度发布，通过分流规则，设置请求流量在新旧版本之间的比例；

二、灰度发布

通常生产部署的灰度发布方式有三种：蓝绿发布、A/B Test、金丝雀发布；

1、蓝绿发布

蓝绿发布需要对服务的新版本进行冗余部署，相当于给服务部署两套相同配置的环境，只不过此时旧版本用于对外提供服务，新版本作为热备。当服务进行升级时，只需要将流量全部切换到新版本，旧版本作为热备。如果新版本上线过后出现验证的bug，只需要重新将流量全部切回旧版本；这样可以大大缩减程序故障的时间。等旧版本的bug修复完毕之后，再将流量全部切回到新版本。<特点>：版本切换非常快，程序故障时恢复时间很快。但是浪费机器资源，需要两套完成相同配置的环境。

2、A/B Test

相比于蓝绿发布的流量切换方式，A/B Test是基于用户的元信息将部分流量路由到新版本；其是一种​​基于请求内容匹配​​的灰度发布模式。只有匹配特定规则的请求才会被路由到新版本，常见的方法是基于Header、Cookie：基于Header的方式，比如我系统升级，我想要安卓用户先尝鲜；可以在请求头中设置​​User-Agent​​为安卓；路由匹配后，安卓用户可以访问新版本，其他用户依旧访问旧版本。**基于Cookie的方式：**Cookie中通常包含具有业务语义的用户信息，比如用户是否为VIP；普通用户访问新版本，VIP用户访问稳定的旧版本。<特点>：根据请求的内容按规则进行转发；

3、金丝雀发布

金丝雀发布的思想在于将少量的流量引入到新版本，因此部署新版本只需要很少的机器资源；验证新版本符合预期之后，逐步调整流量权重比例，是的流量慢慢的从旧版本切到新版本；期间可以设置流量的比重，对新版本服务进行扩容，同时对老版本服务进行缩容，进而最大程度的利用现有的机器资源。

4、几种发布方式对比？

蓝绿发布：故障恢复时间最快，但是机器资源冗余程度太大，及其浪费机器资源。A/B Test：它​​基于请求内容匹配​​做流量转发，可以按需为新版本服务分配资源，相比于蓝绿发布其节省了一部分资源；金丝雀发布：只会将少量的流量路由到新版本服务，新版本服务只需要占用很少的机器资源，后续在扩容新版本服务的同时，对旧版本服务进行缩容；使底层的资源得到最大化利用。

正常而言，只有非常重要的功能迭代的时候才会搞灰度发布，一般的小需求、hotfix完全没必要。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。