灰度发布介绍
灰度发布其实是业界术语“abtest”的另一种叫法，一般用于做新发布版本与老版本的对比测试。在yhd，灰度发布与abtest的主要区别在于：灰度发布按照某个比例随机的将用户分为两类；而abtest按照某个属性将用户分为两类（例如男女）。其他方面，两者在实现上几乎没有区别。
为了实现将用户分为类，一般使用cookie实现；为了实现不同模块之间独立执行灰度发布功能，可选的方案有两个：1. 每个模块使用一个cookie，优点是灵活，缺点是扩展性差（cookie多了浪费带宽，体验差）；2. 使用相同的cookie，不同模块通过判断cookie的值决定某个用户是否应该走灰度发布。方案二已经能满足我们需求。
灰度发布其实是业界术语“abtest”的另一种叫法，一般用于做新发布版本与老版本的对比测试。在yhd，灰度发布与abtest的主要区别在于：灰度发布按照某个比例随机的将用户分为两类；而abtest按照某个属性将用户分为两类（例如男女）。其他方面，两者在实现上几乎没有区别。
原理
为了实现将用户分为类，一般使用cookie实现；为了实现不同模块之间独立执行灰度发布功能，可选的方案有两个：1. 每个模块使用一个cookie，优点是灵活，缺点是扩展性差（cookie多了浪费带宽，体验差）；2. 使用相同的cookie，不同模块通过判断cookie的值决定某个用户是否应该走灰度发布。方案二已经能满足我们需求。
具体来说，每个用户有一个名字为gray的cookie，类型是int，取值范围[0,1000000); 每个模块维护一个灰度区间的配置[start, offset], 当用户的gray值落入这个区间时, 这个用户在这个模块上进入灰度版本. 由于不同的模块可以维护不同灰度区间,从而实现模块之间相互独立.
[特别修正： 方案中期望每个用户使用一个cookie来代替，但由于cookie是基于域名和浏览器的，所以每个用户访问的每一个域名都有自己独立的cookie，而且不同的浏览器也会有独立的cookie。所有确切的描述灰度的粒度应该是：每个用户在某个浏览器中对某个域名的访问。这个粒度的差异有利有弊。好处是我们可以更精确的控制灰度的行为；坏处是我们不能对一个用户的保持灰度的一致性，也就是难以做到让一个用户始终访问灰度或非灰度的版本。]
另外, 由于网站的架构使得每个http请求会依次通过几个逻辑分层: 静态页面缓存->haproxy->具体业务->基础业务, 所以在灰度发布方案的实现上也是分层的, 每层都能独立实现.
配置说明
场景: 假设现在前端front、detail两个模块要做灰度发布；应用层也是front、detail两个模块要灰度发布；服务层gss、gps两个模块要灰度发布。我们对squid、haproxy都做了修改：
- squid 灰度逻辑： 如果一个http请求被判定为灰度的，那么在缓存这个http请求时，在缓存的url后面加上“_gray”后缀；在查找缓存时，灰度的请求也是加上这个后缀然后再查找。这样就能保证用户请求的一个url，在squid中有灰度和非灰度的两个缓存版本。squid的空间需要很可能要X2.
- haproxy灰度逻辑：haproxy的每个backend在逻辑上被分为灰度和非灰度两个组，这两个组独立调度（相当于在每个backend中起了两个子backend）。如果一个http请求被判定为灰度的，那么就走入灰度的子backend分配server，否则走非灰度的子backend分配backend）
下图，从用户访问路径的角度展示灰度发布的工作原理。不同颜色的线表示不同用户的http请求的访问路径。
从模块配置信息传递的角度看整个系统如何工作：
