概述

记得以前领导问过我一个问题，就是怎么更新不会导致服务中断，那时候学校刚出来，也没有听说过什么发布策略这个概念，于是采用最土的方法就是阿里云slb去来回切换机器，当a机器在线上时候去升级b机器，当b机器更新好之后把b机器放到线上a机器下线，这样做的好处就是可以方便回滚但是在切换机器时候会产生服务中断的问题，之后自己搭建了api网关，有了三台机器，一般两台机器在线上做负载均衡，当有版本更新的时候先更新不在线上的机器c，之后下线a上线c，看c里面日志没有报错正常的话再更新a，a更新完成下线b上线a。这样做的好处就是可以保证服务尽可能不会中断，版本出问题也可以及时回退，对于我们这种小公司就够用了，所以一直使用这个方法到现在。但是对于一家公司来说，使用这两个方法是不够的，一般的公司都是使用多个发布策略基于不同的场景去配合使用，所以我就总结了一下现代的发布策略，方便以后一个个去比对

蛮力发布

这种发布方式最简单，测试环境和个人应用部署的时候最经常使用，就是把前一个版本关闭，之后更新到新版本，在k8s中我们使用recreatecelve就可以实现这种方式的发布，这种发布的好处就是简单，弊端也显而易见就是服务肯定会中断，而且出了问题之后回退也比较费时间。

滚动发布

滚动发布，比如我线上三台机器全是v1版本，通过nginx去做负载均衡，当我要升级到v2的时候我去一个一个依次替换掉，这个叫滚动发布，当我在发布过程中如果发现v2有问题，那就把线上的v2版本再一个个回退成v1的。这种发布方式的优点就是不会像蛮力发布那样子长时间服务中断，坏处也很明显就是一个一个版本升级和回退的时间比较长，真的苦了我们这些运维狗。在k8s中使用rollingupdate策略即可实现这种方式的发布。

蓝绿发布

蓝绿发布就是当我要发布一个新的版本，首先我更新两台不在线上的机器到v2，更新完成之后我通过负载均衡把线上的流量全部切换到这两台机器上，这种更新方式的好处就是回退比较快，不足的地方也很明显，就是他的切换是权量的切换，如果出现问题那么受到影响是所有的用户。还有就是比较废机器，在k8s中我们可以设置service的label来实现流量的切换发布。

金丝雀发布

金丝雀发布就是当我要发布v2的时候先在集群中加入一台v2版本的机器，之后使用生产的流量测试验证v2版本，当v2版本没有问题之后我把线上的机器全部切换为v2版本，当v2版本有问题那么我们撤销这个v2版本的机器即可。这种发布机制的好处就是受影响的用户比较少，坏处的话就是用到的机器会比较多。如果使用k8s的话我们可以使用deployment的label去实现这种发布策略

A/B测试

所谓的ab测试就是在线上发布一个v2版本，然后通过负载均衡的流量过滤让携带某些header或者cookie的用户可以访问到v2版本，这就是a/b测试，这里的a指的是a组正常用户，b指的是b组特殊用户。如果在k8s中那么要加上istio才可以做到这一点。

影子测试

影子测试的意思就是我把生产的流量全部复制一份到要升级的版本中进行测试，如果你使用的nginx你可以使用ngx_http_mirror_module模块去进行流量复制，上面这种是软件实现方式，如果是硬件可以使用交换机的端口镜像功能去做。

功能开关

个人觉得这个不是一个发布策略，什么是功能开关呢，就是当一个用户请求过来时候，如果它符合某些情况，比如是2.0用户的那么给他开放2.0用户的功能，如果是1.0的那么就只给他1.0用户的功能。

欢迎关注我的博客www.bboy.app
Have Fun