随着微服务架构的普及，线上服务越来越多，随之而来的就是产品迭代的频率越来越快，部署越来越频繁；而同时要求服务上线速度也要快速提升。然后鱼与熊掌不可兼得，有上线、有部署，就有风险，有风险，就对业务有影响，因为也就反向引导了更优的部署方案：诸如蓝绿部署、金丝雀发布（灰度发布），也有适应产品迭代频率的AB测试。
1、蓝绿发布
概要说明
蓝绿发布需要对服务的新版本进行冗余部署，一般新版本的机器规格和数量与旧版本保持一致，相当于该服务有两套完全相同的部署环境，只不过此时只有旧版本在对外提供服务，新版本作为热备。当服务进行版本升级时，我们只需将流量全部切换到新版本即可，旧版本作为热备。由于冗余部署的缘故，所以不必担心新版本的资源不够。如果新版本上线后出现严重的程序BUG，那么我们只需将流量全部切回至旧版本，大大缩短故障恢复的时间。待新版本完成 BUG 修复并重新部署之后，再将旧版本的流量切换到新版本。
蓝绿发布通过使用额外的机器资源来解决服务发布期间的不可用问题，当服务新版本出现故障时，也可以快速将流量切回旧版本。
如图，某服务旧版本为 v1，对新版本 v2 进行冗余部署。版本升级时，将现有流量全部切换为新版本 v2。
当新版本 v2 存在程序 BUG 或者发生故障时，可以快速切回旧版本 v1。
优缺点
优点
1）部署结构简单，运维方便；
2）服务升级过程操作简单，周期短。
缺点
1）资源冗余，需要部署两套生产环境；
2）新版本故障影响范围大。
2、A/B 测试
概要说明
相比于蓝绿发布的流量切换方式，A/B测试基于用户请求的元信息将流量路由到新版本，这是一种基于请求内容匹配的灰度发布策略。只有匹配特定规则的请求才会被引流到新版本，常见的做法包括基于Http Header 和 Cookie。
-
基于 Http Header 方式的例子，例如 User-Agent 的值为 Android的请求 （来自安卓系统的请求）可以访问新版本，其他系统仍然访问旧版本。
-
基于 Cookie 方式的例子，Cookie中通常包含具有业务语义的用户信息，例如普通用户可以访问新版本，VIP 用户仍然访问旧版本。
如图，某服务当前版本为 v1，现在新版本 v2 要上线。希望安卓用户可以尝鲜新功能，其他系统用户保持不变。
通过在监控平台观察旧版本与新版本的成功率、RT 对比，当新版本整体服务预期后，即可将所有请求切换到新版本v2，最后为了节省资源，可以逐步下线到旧版本 v1。
优缺点
优点
1）可以对特定的请求或者用户提供服务新版本，新版本故障影响范围小；
2）需要构建完备的监控平台，用于对比不同版本之间请求状态的差异。
缺点：
1）仍然存在资源冗余，因为无法准确评估请求容量；
2）发布周期长。
3、金丝雀发布（灰度发布）
概要说明
在蓝绿发布中，由于存在流量整体切换，所以需要按照原服务占用的机器规模为新版本克隆一套环境，相当于要求原来1倍的机器资源。在 A/B测试中，只要能够预估中匹配特定规则的请求规模，我们可以按需为新版本分配额外的机器资源。相比于前两种发布策略，金丝雀发布的思想则是将少量的请求引流到新版本上，因此部署新版本服务只需极小数的机器。验证新版本符合预期后，逐步调整流量权重比例，使得流量慢慢从老版本迁移至新版本，期间可以根据设置的流量比例，对新版本服务进行扩容，同时对老版本服务进行缩容，使得底层资源得到最大化利用。
如图，某服务当前版本为 v1，现在新版本v2要上线。为确保流量在服务升级过程中平稳无损，采用金丝雀发布方案，逐步将流量从老版本迁移至新版本。
优缺点
优点
1）按比例将流量无差别地导向新版本，新版本故障影响范围小；
2）发布期间逐步对新版本扩容，同时对老版本缩容，资源利用率高。
缺点
1）流量无差别地导向新版本，可能会影响重要用户的体验；
2）发布周期长。
4、一句话总结：
蓝绿发布是两套相同的环境，类似于互为主备的关系；
AB测试属于一套环境基于域名的匹配规则，从请求信息进行流量的引流，属于测试的范畴；
灰度发布是一套环境中通过流量请求的调整，逐步实现新版服务的平滑升级。
都到这儿了，更多文章，详见个人微信公众号ALL In Linux，来扫一扫吧！
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
