灰度发布的方案有很多，这里我结合公司使用的框架给出一套灰度发布方案。我们公司使用的是spring cloud框架，zuul做网关，ribbon做负载均衡，eureka做注册中心。
我自己对灰度发布的理解就是能够做到根据不同策略去区分用户，根据用户标签去展示不同的效果。比如当我们在线上发布一个新的功能时，由于我们无法预测这个功能带来的影响，所以我们想只让老用户能够访问这个新功能，然后收集用户反馈。如果用户反响不好，就把新功能关闭，把老用户切换回原来的逻辑；如果用户反馈满意，我们就把新功能对所有用户开放，但是这个切换的过程又不想去重启服务。
上面这个需求相信很多人在生产环境都会碰到，这里我们就可以使用灰度发布去解决这个需求。我上面说过我们采用eureka做注册中心，所有的服务都会向eureka中注册，然后ribbon从eureka的注册列表去读取可用的服务列表，根据一定的策略去分发请求。只要理解了这一点，灰度发布的实现就很容易了。
- 首先我们在往eureka注册服务时，对于服务名相同的服务，我们可以指定每个服务的版本，例如当前有一个服务ADMIN，然后我们通过eureka.instance.metadata-map.version为两个服务指定不同版本1.0/2.0，启动两个服务，此时eureka中就能看到ADMIN中有两个服务同时存在。
- 我们使用zuul做网关，所有的请求都经过网关转发，所以这里新建一个filter，在filter中设置想要转发请求的版本号（这个需要结合自己的业务去判断版本号，可能根据用户session，可能根据ip等等），这样ribbon在执行负载均衡策略时只会去找版本号匹配的节点转发
上述的后端的灰度发布解决方案，前端的灰度发布可以借助nginx+lua去实现。下面是我实验的代码，使用的环境是openresty-1.15.8.2-win64，代码中引用的部分外部函数大家可以网上百度