灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式。AB  test就是一种灰度发布方式，让一部用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面 来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。
　　Gmail Labs是一个新特性橱窗，用户可以自己选择一些未正式发布的新特性进行体验，不喜欢可以关闭，在这个过程中，吃了螃蟹，也当了Google的小白鼠。
　　这个做法比传统的灰度要高明很多，更加尊重用户：
　　1、它没有强X用户，用户是否愿意当小白鼠完全自愿
　　2、新特性不是打包在一起的一个大版本，可以选择某几个喜欢的螃蟹尝尝
　　3、螃蟹不好吃可以扔掉，不用硬吃进肚子里引发肠胃炎
　　当然这些好处也是有代价的：
　　1、要开发一个labs平台实现新特性上架、独立尝试的功能，这可能要改动Gmail的前后台架构
　　2、新特性要按照一定规范来写，才能发布到这个平台上，可能会增加一些工作量
　　3、小白鼠用户增多之后，对系统的压力可能会有一定提升，因为每个用户调用的界面都不一样了
　　既然Gmail  Labs能够顺利发布，那么说明对Google来说，以上这些问题都不算问题。另外，现在展示的新特性，都注明了开发者的名字，那么，Gmail  Labs可能会开放这个平台让外部开发者也能提交特性？这倒是很open的一种开发模式，非常适合Google的web app产品线。
　　互联网产品有一个特点，就是不停的升级，升级，再升级。我所在的项目组，基本上保持每周一次的发布频率，系统升级总是伴随着风险，新旧版本兼容的风险，用户使用习惯突然改变而造成用户流失的风险，系统down机的风险.....　　为了避免这些风险，很多产品都采用了灰度发布的策略，其主要思想就是把影响集中到一个点，然后再发散到一个面，出现意外情况后很容易就回退。
　　很长时间，我们都一直在改进搜索引擎的排序算法，尽量让最好的商品出现在搜索结果的第一屏。我 们尝试了很多中算法，不断调整各个排序因子所占的比重。但是我们无法确信我们的排序结果能满足所有用户的需求。所以我们采用了灰度发布，选取几个一级商品 类目，在其中应用不同的排序算法，比如在女装类目中，我们把卖家信用所占的比率调整到60%，在珠宝类目中，我们把销售量所占的比率调整到60%.. 然后发布出去，收集用户反馈，最终选择一种大部分人认为好的算法。
　　QZone是另外一个采用灰度发布的例子。大家都知道，QZone在过去的一年中改进是巨大 的，从以前慢悠悠的老爷爷变成了一个充满青春活力的小伙子。其中经历了大小无数次的发布，他们的发布也都是采用了灰度发布的策略，用户数据的升级并不是大 面积的一次性升级，而是通过一个用户升级标志服务器，如果用户数据没有升级，后台会把此用户的数据逐步迁移到新版本上，然后将升级标志位置1，升级过程 中，用户仍然可以访问旧的数据，升级完成后的访问都将转发给新的版本。

　　QQ的很多产品发布都采用灰度发布，有些是抽取部分QQ号段升级成新系统，然后根据用户反馈再大范围升级。我们的产品大部分也是采用灰度发布。

灰度发布引擎

   对于一般的小系统并不需要单独的灰度发布引擎，可以参考A/B测试中做法，在页面javascript或服务器端实现分流的规则即可。但对于大型的互联网应用而言，单独的用于管理用户分流的发布引擎就很有必要了。“钱掌柜”分流发布模式 提到了原来阿里软件所使用的灰度发布引擎，设计思路具有普遍性，可以供参考

本文来自 http://enki-ding-yeah-net.iteye.com/blog/1114565