版本发布之灰度发布

出现原因：

以前升级服务器应用版本时，会将应用源码或程序包上传到服务器，然后停止掉老版本服务，再启动新版本。
这种简单的发布方式存在两个问题：
一、在新版本升级过程中，服务是暂时中断的。
二、如果新版本有BUG，升级失败，回滚起来也非常麻烦，容易造成更长时间的服务不可用。

结果：

灰度发布诞生。

比喻描述：

灰度发布也称金丝雀发布。这是因为矿井工人发现，金丝雀对瓦斯特别敏感。所以工人在下井时，都会先放金丝雀下去，假如金丝雀还在叫，说明瓦斯浓度低，可以下井；反之，金丝雀不叫了，说明瓦斯浓度高，不可以下井。

场景运用

确定灰度发布开始后，先启动一个新版本应用，但是并不代表直接将所有的用户流量切过来，而是先让测试人员对新版本进行线上测试，测试人员就是我们的金丝雀。
假如测试人员觉得没有问题了，那么就可以将少量的用户流量导入到新版本中，然后此时再对新版本进行状态观察，收集各种运行时的数据，对新旧版本做各种数据对比，也就是所谓的A/B测试。
当确认新版本运行良好之后，再将更多的用户流量导入到新版本上，再此期间，还可以不断地调整新旧两个版本的运行的服务器的数量，以使得新版本能够承受越来越来的流量压力。
直到将100%的用户流量都切换到新版本上，最后关闭剩下的老版本服务，灰度发布完成。
（温馨提示：在灰度发布中，既灰度期中发现版本有问题，就应该立即将用户流量切回老版本。这样，就会将负面影响控制在最小范围内。）

补充延申

灰度发布常常和滚动发布一起出现。
都可以用矿工下矿洞的思想来解释。
矿工—>用户，下井—>使用的版本，旧矿井—>旧版本，新矿井—>新版本。
滚动发布：发现新矿井，直接让矿工排队下新矿井，结果瓦斯浓度过高，就是出现了bug，死伤惨重，就是版本回退。
灰度发布：矿工想了其它的方法了，决定在发现新矿井之后，矿工还是留在旧矿井工作，下新井的是金丝雀（测试人员，按规则负载均衡过来的部分用户）。直到确定新矿井没有问题之后，再让矿工全部从旧矿井中迁移到新矿井。