设置用户标识策略

用于区分用户，辅助数据统计，保证灰度发布过程中用户体验的连贯性（避免用户在新旧版本中跳变，匿名Web应用比较容易有这个问题）。匿名Web应用可采用IP、Cookie等，需登录的应用可直接采用应用的帐号体系。

目标用户选取策略

即选取哪些用户先行体验新版本，是强制升级还是让用户自主选择等。可考虑的因素很多，包括但不限于地理位置、用户终端特性（如分辨率、性能）、用户自身特点（性别、年龄、忠诚度等）。对于细微修改（如文案、少量控件位置调整）可直接强制升级，对于类似新浪微博改版这样的大型升级，应让用户自主选择，最好能够提供让用户自主回滚至旧版本的渠道。对于客户端应用，可以考虑类似Chrome的多channel升级策略，让用户自主选择采用stable、beta、unstable channel的版本。在用户有明确预期的情况下自行承担试用风险。

提供数据反馈入口

用户数据反馈：在得到用户允许的前提下，收集用户的使用新版本应用的情况。如客户端性能、客户端稳定性、使用次数、使用频率等。用于与旧版本进行对比，决策后续是继续扩大新版本投放范围还是回滚。服务端数据反馈：新版本服务端性能、服务端稳定性等，作用与用户数据反馈类似。

新版本回滚策略

当新版本灰度发布表现不佳时，应回滚至旧版本。对于纯粹的Web应用而言，回滚相对简单。主要难点在于用户数据的无缝切换。对于客户端应用，如果期待用户自行卸载新版本另行安装旧版本，成本和流失率都太高。可以考虑通过快速另行发布新版本，利用升级来“回滚”，覆盖上次灰度发布的修改。对于移动客户端，新版本发布成本较高，需要Appstore、Market审核。尽量将客户端打造成Web App，会更有利于升级和回滚。

后端服务一般都会在负载均衡层（nginx）做灰度方案等，业界成熟的方案大多为：

1. 简单灰度逻辑通过 nginx 配置做规则判断（路由、参数、ip等）然后动态分配接口流量切换至a/b服务。

2. 复杂灰度逻辑通过 nginx+lua 结合自己业务来做流量的灰度、切换等。

前端静态资源要做到灰度或 A/B 测试的效果，几种方案为：

1. JS 代码中做埋点判断，通过对用户特征（UA、cookie、或后端提供字段等）的判断显示为不同功能等。

2. 服务端动态渲染，在服务端通过特征规则判断显示不同分支版本或功能。

3. 控制入口文件，使用 nginx 判断变量，动态分配接口流量切换至a/b服务，静态文件将流量切换至a/b路径或主机。

方案1，对业务的入侵性大，灰度规则与代码耦合，增加了文件的大小。

方案2，因为控制了渲染入口，能做的很多，但也增加了服务端渲染的复杂度，使用场景有限。

方案3，前端入口一般都是一个 html 文件，后再去加载各种静态资源，通过对入口文件的控制，结合 nginx 方案可以做到很好的灰度和 A/B 测试方案。

基于nginx的灰度发布方案

一般有三种方式：nginx + lua，nginx 根据cookie分流，nginx 根据来源IP分流