---

1 线上项目灰度发布的重大意义

上面这个软件相信大家一定不陌生，很多人和我一样一定还欠他钱！支付宝经历了十多年，从未停止更新过，app从最初简单设计到现在的扁平化设计，一直在更新，但奇怪的是它从未停过服务，而且越用越顺畅。不停服务就实现软件更新，这是怎么做到的呢？这个问题也是线上项目需要迫切解决的问题。除了支付宝，还有QQ、微信、抖音、头条等各大app，都是不停服务更新软件，他们用的都是什么黑科技呢？学习了灰度发布，也能让你的软件一样不停机优雅的更新。

2 项目发布问题剖析

项目发布的时候，普通程序员理解，大概是安装个Tomcat发布一下，域名解析一下保障项目能正常提供服务就可以了。但这种操作在真正打大型互联网公司中是一个都不值得拿出来说的基本过程，真正大型互联网公司发布一个稳定项目有很多因素考虑。

对于运维工程司而言，每次项目发布都是有风险，比如发布步骤遗漏、发布流程不规范、一些隐藏的BUG等都有可能导致线上的服务不稳定，如果项目对应库版本升级了，很有可能造成项目无法运行的后果。

对于产品经理而言， 在产品设计上他们都有各自不同的观点，都有各自的设计方案（A方案、B方案），如果每个方案都很优秀，该如何抉择？谁官大发布谁的？谁拍桌子拍的狠听谁的？都不是，应该由用户选择，针对不同用户进行试点使用，让部分特定用户使用A方案，部分用户使用B方案，其他用户仍然使用之前稳定的方案，最终哪套方案受欢迎就发布指定版本。

3 解决方案

3.1 蓝绿部署

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

3.2 滚动发布

所谓滚动升级，就是在升级过程中，并不一下子启动所有新版本，是先启动一台新版本，再停止一台老版本，然后再启动一台新版本，再停止一台老版本，直到升级完成，这样的话，如果日常需要10台服务器，那么升级过程中也就只需要11台就行了。
但是滚动升级有一个问题，在开始滚动升级后，流量会直接流向已经启动起来的新版本，但是这个时候，新版本是不一定可用的，比如需要进一步的测试才能确认。那么在滚动升级期间，整个系统就处于非常不稳定的状态，如果发现了问题，也比较难以确定是新版本还是老版本造成的问题。为了解决这个问题，我们需要为滚动升级实现流量控制能力。

3.3 灰度发布

灰度发布也叫金丝雀发布，起源是，矿井工人发现，金丝雀对瓦斯气体很敏感，矿工会在下井之前，先放一只金丝雀到井中，如果金丝雀不叫了，就代表瓦斯浓度高。在灰度发布开始后，先启动一个新版本应用，但是并不直接将流量切过来，而是测试人员对新版本进行线上测试，启动的这个新版本应用，就是我们的金丝雀。如果没有问题，那么可以将少量的用户流量导入到新版本上，然后再对新版本做运行状态观察，收集各种运行时数据，如果此时对新旧版本做各种数据对比，就是所谓的A/B测试。

当确认新版本运行良好后，再逐步将更多的流量导入到新版本上，在此期间，还可以不断地调整新旧两个版本的运行的服务器副本数量，以使得新版本能够承受越来越大的流量压力。直到将100%的流量都切换到新版本上，最后关闭剩下的老版本服务，完成灰度发布。如果在灰度发布过程中（灰度期）发现了新版本有问题，就应该立即将流量切回老版本上，这样，就会将负面影响控制在最小范围内。

3.4 灰度发布方法

灰度发布用户群体通知的方法比较多，可以有这些方式：
产品Q群、产品微信群：向固定群体发送产品更新链接，指定群体能使用新版本。
内部用户：通知公司内部用户测试试用。
app自升级：可以根据时间段，用户版本，升级请求数量，实际升级。
灰度发布分类：
1)web页面灰度：按照ip或者用户id切流啊。具有随机性，可以控制比例。
2)服务端灰度：考验主系分能力了，可以做逻辑切换开关，按照义务相关属性逐渐切流。
3)客户端灰度：一般按照用户逐渐推送包，主要是PC端(WIN，MAC)、移动端（安卓，OS）内部大规模内测。