蓝绿发布/灰度发布和AB测试

之前想做过一个多版本发布的系统, 当时了解了不少微服务部署的概念, 其中就包括蓝绿发布, 灰度发布以及AB测试.

但是当时对这些概念理会的不是很深, 大致认为他们都是差不多的东西. 这次研究ServiceMesh的时候, 这些概念又出现了, 所以现在写个文章把这些概念理清楚.

内容不少节选自这篇文章和这篇文章

蓝绿发布

蓝绿部署中，一共有两套系统：一套是正在提供服务系统，标记为“绿色”；另一套是准备发布的系统，标记为“蓝色”。两套系统都是功能完善的，并且正在运行的系统，只是系统版本和对外服务情况不同。

蓝绿发布最大的特点就是:

1. 两套运行环境
2. 流量一把切

特别要注意的, 两套运行环境只要是指无状态服务那个一部分, 对于原数据库或者其他有状态的实例, 始终使用的都是同一套系统.

如果想要将这些有状态实例进行切换, 必须保证数据同步的, 这样来就必然会涉及到了CAP理论, 整个系统复杂性就高了.

灰度发布

灰度发布又叫做金丝雀发布，以前矿工下矿洞前，会放一只金丝雀去试探是否有瓦斯（金丝雀对瓦斯很敏感），映射到这里就是先发布一小部分来试探整体是否能够正常运行，如果能正常运行则进行完全部署的发布方式，目前仍然是不少成长型技术组织的主流发布方式

灰度发布最大特点是:

1. 流量渐切
2. 影响可控

蓝绿发布的时候, 流量一把切导致变更出现严重bug的时候, 是无法评估影响的, 因为你无法知道变更时间窗口之中, 有多少用户使用了你的服务.

而灰度发布可以指定新版本的用户, 收集金丝雀的反馈意见, 然后进行决策是否放开流程, 或者回退版本.

A/B测试

A/B测试指的是同时上线V1和V2版本，根据一定条件将流量分别导入V1和V2版本，收集感兴趣的数据，来对比产品功能的效果。

A/B测试经常会和灰度发布在一起说, 因为:

1. 两者都有多个版本(蓝绿发布一般只有两个版本, 而灰度可以存在多个版本)
2. 两者都有流量路由控制

但是A/B测试是一种测试方法, 关注的是旧版本和新版本的效果好坏，比如流量转化率、用户体验等等
因此, 两者不是一个维度的事情, 只是一般合起来使用: 应用通过灰度发布, 然后进行A/B测试,发现问题, 进行改进.

游戏领域经常有内测活动或者体验服, 是一个典型的A/B测试

A/B测试存在的问题是金丝雀可能会死, 因此还有一种通过流量回放技术做的测试方法, 将现网的流程全部回放, 测试新版本的时候将现网的业务全部测试一遍. 但这种技术实现复杂, 因为客户的应用不一定全是幂等的, 所以必须同步备份数据库以及运行环境, 还得有环境版本控制. 总之, 不是那种质量非常高的应用, 一般不会去搞这么一套系统的.

总结

比较两种发布模式:

1. 蓝绿发布的实现更加简单, 但是部署资源占用多, 并且影响不可控
2. 灰度发布的实现确实复杂, 但影响小, 部署也可以采用滚动升级的方式

现在一般大多采用灰度发布为多.