灰度发布的理解

基于灰度发布 首先要去思考的这些问题

第一 全量发布 我们更新服务的时候直接吧旧的服务干掉，吧新的服务启起来，这个就是全量发布
呢么全量发布有什么弊端呢
1. 回滚周期长，如果我们更新完应用周期后，我们在做线上回归的时候，发现有bug,我们此时要做回滚，
回滚就是要吧新的干掉，吧旧的启起来，这一过程整个服务是挂掉的，不会提供服务的，这段时间服务就是不可用的 不可用就会导致一部分用户群体流失，这个问题很严重也是产品不愿意看到的结果
2.一些bug可能会导致整个服务进行雪崩，在微服务集群的情况下实际上不止是部署一台机器，可能部署了多台机器
呢么我的代码有个内存泄露，而且我的代码可能刚刚部署，此时还是看不到问题，在经过几天或者一周之后，这段代码可能就会导致整个新版本的服务集群全线宕机，这样就会导致我们的服务可用性差，我们在互联网公司要保证我们的服务可用性99.999%
呢么我们的灰度发布能够解决我们的全量发布的那些问题呢
2. 降低发布的影响面，集群里面我可以先拿一个机器，我去部署一个新的版本 然后再放一部分请求流量，比如说一些用户
让他们去体验新的版本，如果在这个新的版本上面发现问题的化，呢么我就可以吧这一小部分流量转发到我的旧版本上去，呢么此时的他的影响面也仅仅在于呢个小的群体
3. 他可以做到不停机迁移 不停机迁移，我整个集群中我可能先拿一个机器，更新到新版再放流量进来，然后再吧另一个机器进行更新,在这个时候他会做到一个不停机升级
4. 回滚速度快，他的回滚只需要去改我们的Lb就可以了


呢么灰度发布的方案有那些
1. 蓝绿部署
2. 金丝雀发布
3. 全链路灰度发布 

蓝绿发布 首先第一个版本是我们的Lb上部署的是V1的版本,整个流量进来都打到我们的V1上面去，
然后这个时候我们需要做更新，我们剩余的2台空机器上面就部署我们的新的版本，
然后我们的LB流量切到我们的V2上，在经过一些比如说bug回滚,再稳定一周左右，呢么这个时候再吧V1版本的代码删除了。如果这个时候V2是有问题的 会直接切回到V1上面去，整个切的过程中不需要去重启服务
只需要LB做一个切换就可以了  这个就是蓝绿部署
但是他所耗费的机器资源比我们全量多

金丝雀发布  
我们有一个服务集群 我们先升级一台机器，然后看这个机器上的服务上有没有bug,他是不是会导致内存泄露的问题呢
如果都没有的化在经历过一个周期的验证后 再将其他机器去进行升级。

全链路灰度发布 我们前面说的只是一个服务级
全链路灰度发布可以做到一些流量标识

我们的流量在经过网关的时候 会根据流量标识进行分发，然后分发到不同的版本上，全链路灰度发布
可以在我们微服务中做到这种按照流量标签打标识，根据不同的需求发布到不同的服务器上

https://www.cnblogs.com/javastack/p/16847748.html