灰度发布是指在黑和白之间，能够平滑的过滤的一种发布方式，目前是为了试错，把功能影响范围降级到最小，实现可控范围的快递迭代。

灰度发布的好处：

从产品维度来讲,可以快速试错，根据目标用户反馈结果完善产品，从研发角度讲可以完成服务不断的迭代升级，发现问题及时回滚，A/B test其实也是灰度的一种，根据策略基于用户的反馈慢慢从A到B的过渡或者B到A的过渡。

灰度发布三大类型？

web页面灰度：按照ip或者用户id切流啊。具有随机性，可以控制比例

服务端灰度：考验主系分能力了，可以做逻辑切换开关，按照义务相关属性逐渐切流

客户端灰度：一般按照用户逐渐推送包，主要是PC端(WIN，MAC)、移动端（安卓，OS）内部大规模内测

web 页面灰度

web页面灰度基本是A/B测试居多，A/B效果需要数据的支撑，比如浏览量，下单量等，数据的展现通常是漏斗形，同时数据统计的前提必须埋点。

客户端灰度方案：

客户端灰度主要谈谈移动端的灰度，最常用的一个功能是客户端版本的升级。版本灰度发布一般基于UUID或者用户ID，ios和anroid灰度方式不一样，像android预先在服务端内置一个最新包的地址，在用户开发客户端的时候会触发一个版本信息的请求，服务端根据UUID或者PIN按照预先设置的规则来判定是否给用户返回升级包，先少量灰度，之后再慢慢过渡到全量，最后可以上传到一些大的应用市场。

IOS 的灰度发布有两种，一个企业包的安装，一个是可以通过 TestFlight 来邀请用户协助测试 App 。企业包的灰度测试适用于公司内部，在上传平台上传plist文件，根据策略给用户下发对应的下载链接。另一种TestFlight，先得再 iTunes Connect 上上传app,然后在其中填写用户邮箱信息，用户通过收到的邀请码来下载app,这种灰度属于定点灰度，有很大限制。

服务端灰度方案：

流量灰度：

有两个做法，一个是基于提供服务的机器数量来提供灰度功能，做法是从生产环境中选取一定数量的机器，选中新版本发布。 流量的比例基数取决于机器的总数量，

如果是10台机器，最少发布一台，灰度流量是10%，如果是100台机器，发布一台，灰度流量是1%，这种方式是建议机器的数量越多越好，机器越多灰度的影响范围会越少。

二是服务本身的流量灰度，做法是基于前置网关上流量配置灰度的api,按照流量百分比切分。

客户端灰度：

基于设备信息，地区，用户信息的灰度。有两种做法一个是在后台服务硬编码，像设备信息，用户信息取hashCode值，IP 转换地理位置信息，这种方案需要注意的是一定要做好回滚方案。一般情况下不建议采用这种方式，除非在做业务需求的时候本身带有灰度的特性或者属性。

二是 基于前置网关的灰度，把不同维度的算法前置到网关，好处是灰度代码没有浸入到具体业务里。

灰度发布平台

基于以上理解其实灰度发布平台至关重要，发布平台包含了发布规则设置，发布规则下发，数据路由等基本组件。