在项目开发完成经过测试并且Uat环境预发布成功后，再到实际生产环境部署还是会可能产生问题。为了减少正式环境发布后的影响，所以我们需要使用灰度发布，灰度验证，而这都要依赖我们有一套完整的流量分配规则。下面来谈谈微服务架构中的灰度发布实现：
先看图：
一、服务网关的流量分配
以Ocelot为例，具体怎么分配流量规则这是由业务决定的，我们只能设计通用规则去适用具体的业务。比如根据userid、clientip、storeid、app-version等等。
首先需要设计一个规则表，我们把服务器的新老版本分为A、B组
{
"rules": [
{ "serviceName":"OrderService","userId": [ 1, 2, 3 ],"tag": "B" }
]
}
serviceName：服务名称，匹配具体的微服务；userId：用户ID，匹配请求的用户ID；tag：服务器组。
在Ocelot负载均衡的时候通过拿到tag信息并设置到http的header信息中，并过滤下游服务器列表。很遗憾，Ocelot没有为我们实现tags过滤，只能自己拓展这个逻辑，貌似Zuul有根据Meta过滤的功能，具体待我分析了Zuul才清楚。通过分析源码只有在负载均衡时做才能根据不同请求分配下游服务器。
这样所有的微服务启动时在往Consul注册信息的时候需要添加tag信息。
通过上述这样的配置，我们userid为1，2，3，4的用户请求都只会请求新上线的B组机器。
到这里还没完，我们只实现了请求从网关来的流量分配，并没有实现服务之间调用的流量分配，所以我们还有下一步工作要做：
二、微服务出战请求的流量分配：
在.net core中我们在使用http调用时可以选用IHttpClientFactory，据说IHttpClientFactory创建的HttpClient做了很大的改进，以前在使用HttpClient时高并发情况下很坑的哦，所以.net core在2.1版本推荐使用IHttpClientFactory
在IHttpClientFactory创建的HttpClient使用时有了一个出战请求中间件的概念，这样我们可以在中间件这里做服务的发现、负载均衡、容错等等。同时我们可以在这里根据网关设置在header中的tag拿到我们的服务器组，这样我们一样可以过滤服务器了，这个流量分配过程就算是源码完成，还没有开始代码的实现，有空后面再贴代码。