互联网技术发展到今天，无论从开发角度还是从运维角度，都需要依靠灰度发布来控制版本质量、控制影响范围、搜集用户反馈等等，在接入层实现灰度策略是较为常见的一种方法。闲话少说，下面以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
核心代码截图如下：
使用postman模拟访问两个地址，ok，基础服务已经搭建完毕
2.启动haproxy，建立frontend和backend灰度策略入口。
3.目前访问haproxy，默认会一直访问原始版本，那么如何根据制定的策略访问灰度版本呢？我们不妨在header中增加userid参数，设定当userid小于100时，这部分用户去访问灰度版本，其他的用户则继续访问原始版本，修改haproxy配置如下
在本例中，我们将应用的业务参数userid置于请求的header中，haproxy以此进行灰度控制。放在header中可以在接入层实现灰度，而无需在应用层进行控制，减少了代码入侵。同理也可以将灰度策略的入口条件置于请求的cookie中
通过配置acl规则，我们从header中提取userid的参数，正则校验符合小于100，则访问hellogray的灰度版本后端，否则就访问helloworld的原始版本后端，重启haproxy，测试如下：
3.通过以上配置，我们已经实现了通过haproxy灰度的目标，我们通过筛选合适的请求，将其分发至不同的后端上面，但是如何实现“一灰永灰”呢？即访问灰度版本的客户一直访问灰度版本，不可以再跳回原始版本。我们先看看目前的访问
我们不难想到，在每个请求的header中都带有userid参数，也是一种解决方法，但是这样对代码的入侵过大，需要在每个请求中都置userid这个参数，我们能否做到只在应用入口的请求header中增加参数，做到一灰永灰？看看如下配置
三、总结
通过以上示例，我们利用haproxy的策略实现了灰度发布的目标，且做到了一灰永灰。总结起来，实现逻辑为：
