互联网技术发展到今天，无论从开发角度还是从运维角度，都需要依靠灰度发布来控制版本质量、控制影响范围、搜集用户反馈等等，在接入层实现灰度策略是较为常见的一种方法。闲话少说，下面以haproxy为例说明如何在接入层实现灰度发布。

一、灰度原则

1.任何脱离应用场景的灰度都是耍流氓，所以每个应用的灰度策略需要针对具体应用场景和逻辑进行设计

2.实现灰度策略应尽可能少的代码入侵

3.在设计编码阶段，提前想好灰度入口，即一个请求过来，依据什么来判断是否走原始版本，还是走灰度版本

4.要做到走灰度版本的一直走灰度版本，做到对用户透明

二、搭建工作

1.使用idea快速搭建两个springboot应用，一个模拟原始版本，一个模拟灰度版本。两个应用都较为简单，访问/hello后原始版本输出hello world，灰度版本输出hello gray

原始版本访问地址：http://127.0.0.1:8081/hello

灰度版本访问地址：http://127.0.0.1:8080/hello

核心代码截图如下：

原始版本返回hello world

灰度版本返回hello gray

使用postman模拟访问两个地址，ok，基础服务已经搭建完毕

访问8081/hello

访问8080/hello

2.启动haproxy，建立frontend和backend灰度策略入口。

监听8079端口，默认访问hello world的原始版本

默认访问原始版本

3.目前访问haproxy，默认会一直访问原始版本，那么如何根据制定的策略访问灰度版本呢？我们不妨在header中增加userid参数，设定当userid小于100时，这部分用户去访问灰度版本，其他的用户则继续访问原始版本，修改haproxy配置如下

在本例中，我们将应用的业务参数userid置于请求的header中，haproxy以此进行灰度控制。放在header中可以在接入层实现灰度，而无需在应用层进行控制，减少了代码入侵。同理也可以将灰度策略的入口条件置于请求的cookie中

通过acl hdr匹配

通过配置acl规则，我们从header中提取userid的参数，正则校验符合小于100，则访问hellogray的灰度版本后端，否则就访问helloworld的原始版本后端，重启haproxy，测试如下：

userid=100，访问原始版本

userid<100访问灰度版本

3.通过以上配置，我们已经实现了通过haproxy灰度的目标，我们通过筛选合适的请求，将其分发至不同的后端上面，但是如何实现“一灰永灰”呢？即访问灰度版本的客户一直访问灰度版本，不可以再跳回原始版本。我们先看看目前的访问

userid=99时访问灰度版本，没有问题

当请求header中没有userid参数时，又会去访问原始版本

我们不难想到，在每个请求的header中都带有userid参数，也是一种解决方法，但是这样对代码的入侵过大，需要在每个请求中都置userid这个参数，我们能否做到只在应用入口的请求header中增加参数，做到一灰永灰？看看如下配置

当userid<100 或者 cookie中WEBVERSION=gary，访问灰度版本。原理在于所有访问灰度版本的请求中都由haproxy加上webversion的cookie，相当于给所有访问灰度版本的请求打上标签，以便该下次访问能继续访问灰度版本

访问灰度版本

当请求header中不勾选userid，继续访问灰度版本，没有问题

通过以上示例，我们利用haproxy的策略实现了灰度发布的目标，且做到了一灰永灰。总结起来，实现逻辑为：