两年前，我在学习K8s的时候有写过一篇基于Nginx Ingress实现灰度发布的博文。这次，我们基于Kong来实践一下。灰度发布的具体实现其实是流量切分，那就让我们先回顾一下流量切分的实现方式。
流量切分实现方式
Kong可以支持实现不同场景下的灰度发布和测试，可以满足金丝雀发布、蓝绿部署与 A/B 测试等业务场景。一般来说，有两种流量切分的方式：一是基于用户请求的流量切分，具体又包括了基于Request Header的流量切分与基于Cookie的流量切分两种方式；如下图所示：
二是基于服务权重的流量切分，如下图所示：
综上所述，我们可以知道，灰度发布与蓝绿部署的本质就是冗余，利用冗余来降低大版本发布带来的风险，从而提高发版上线的效率。
准备工作
在本系列前文的ASP.NET Core示例的基础上，部署两个新的sample-order-api实例，让它作为灰度版本，它和老版本的差别在于健康检查接口返回的是"ok-grey"，而老版本返回的是"ok"。
namespace EDT.MSA.Ordering.API.Controllers { [Route("api/Health")] [ApiController] [ApiExplorerSettings(IgnoreApi = true)] public class HealthController : ControllerBase { [HttpGet] public IActionResult Get() => Ok($"ok-grey"); ...... } }
那么，现在已有的微服务的信息为：
基于用户请求的流量切分
根据Request Header的流量切分方式的约定，适用于灰度发布及A/B测试。
对于同一个路由路径，如果加上了指定的Header，就会被转发到灰度版本的上游服务中。
需求明确了，我们就可以在Kong中来进行配置了：
（1）创建一个Upstream，命名为 sample-order-api-grey
具体配置内容和前面示例中的保持一致即可。
然后，添加目标节点，如下图所示：
（2）创建一个Service，命名为 sample-order-api-service-grey
具体配置内容见下图：
这里需要注意的仍然是Host选项，需要和Upstream的名字保持一致。
（3）为新添加的service添加一条路由route，命名为：sample-order-api-grey-route，具体的配置内容如下：
可以看到，和原有版本route唯一的区别就在于Headers选项，这里我们添加了一个Headers的匹配，只有当Headers中有canary:true的时候，才能匹配到这条路由，才能转发到灰度版本中。
（4）验证测试
这里我们借助PostMan来进行一个简单的验证测试，首先，在不带Header的情况下会转发到原有版本：
其次，在带了指定Header值的情况下会转发到灰度版本：
基于服务权重的流量切分
根据基于服务权重的流量切分方式的约定，适用于蓝绿部署，权重范围 0 - 100 按百分比将请求路由到指定的不同版本的上游服务。
权重为 0 意味着该金丝雀规则不会向 灰度版本 的服务发送任何请求。权重为 100 意味着所有请求都将被发送到 灰度版本。
在Kong中，我们只需要加灰度版本的目标节点也加入原有版本的目标节点列表中，配置一下权重即可：
我们来利用PostMan简单验证一下，需要注意的是这里配置的权重其实是一个近似分布值，可能实际中不会太精确。
参考资料
闫观涛，《Kong入门与实践-基于Nginx和OpenRestry的云原生微服务网关》
