基于Nodejs的前端灰度发布方案_20190228

基于Nodejs的前端灰度发布方案

1. 灰度发布和A/B测试简介

灰度发布

将某个功能灰度发布（逐渐放量）给特定线上人群，避免新功能全量上线带来的风险。

上面的图可以通过两个方面来理解：

1. 蓝色实线和蓝色虚线访问Nginx服务器，nginx通过负载均衡将流量分摊到后端服务器。
2. 黄色的线是应用了灰度的流量（配置Nginx规则）可以将特定流量分发到特定的机房，以达到对特定用户应用产品新功能；

举个简单的例子：将http请求cookie中含有test=1字段的请求都转发到灰度代码的机房；

上面通过通过配置特定Nginx规则的方法来达到产品灰度的方法虽然可以满足一定业务量的需求，但是他也有很多的缺点：

1. 不灵活，每次上线新业务代码需要做灰度都要重新更新nginx规则，造成开发和运维负担；
2. 上线的代码要做机房区分，不能够将代码全量。本地的Git代码也要区分开发分支和测试分支，线上分支等若干分支，管理起开麻烦；
3. 不能满足业务量大或者业务需要频繁迭代，需要频繁做测试的业务；

那么有没有更好的方法来做灰度发布呢？当然是有的，A/B测试就能够弥补上面通过Nginx规则来做灰度的缺点。

A/B测试

将线上一部分真实人群流量随机拆分成多个组，对每个分组的人群应用不同策略或功能，通过计算每组人群的业务指标（转化率、成交率等）来衡量策略或功能的实际效果。

我们通过下面的这张图简单的了解下A/B测试的原理：

由上图我们可以知道A/B和传统的灰度方法的区别：

传统的灰度是通过Nginx分发流量到服务器，A/B测试是通过业务代码区分流量访问不同的代码块。

那么A/B测试的优缺点是什么呢？

优点：

1. 随着业务的变化不用频繁的变化Nginx规则，不用分机房上线业务代码，本地git分支不用为了做灰度而建专门的分支；
2. 流量区分是业务代码做的。所以上线代码的时候可以全量上线到所有机房；
   缺点：
3. 因为流量区分是业务代码做的。所以在代码中会存在很多的if...