通用的微服务中的解决方案如下图所示：通过配置管理平台下发恢复发布策略给网关层。

我们知道，一个RPC传输协议的请求报文中，会包含很多字段：

灰度发布策略要放在定长的header里组，可以根据上图红框标识字段做。

如果我们要做多层的灰度发布，就需要使用数据协议中的tag。

也就是说，通过网关层上层的NGINX做Header的过滤来转发流量，

那么，NGINX怎么过滤呢？

规则按优先顺序进行如下排序：canary-by-header - > canary-by-cookie- > canary-weight

也就是说，我们通过请求header中的tag进行匹配。将请求转发到对应版本的网关层。

在实际项目中，灰度发布还需要考虑数据库。即灰度和正常流量的数据，应该都是完整的两份。这样当灰度上线时，旧版本才能整套下线。

如下图所示，我们可以在新版数据访问层前面放一个MQ。当应用向旧的数据访问层写入数据时，数据也向MQ写入一份，保证新版数据访问层是数据是全量的。

在实际项目中，我不建议过度依赖代码实现灰度发布。原因很简单：客户的应用系统很多，不太可能把代码都改一遍。此外，微服务的环境本身是跨语言的，有Java，JS，python，go等。此外，可以的应用还可能跨物理机、VM、容器，全通过该代码是比较费劲的。

这里，我推荐使用Ansible这种“外科手术式”、“代码无侵入”的方式来实现。

通过Ansible发布NGINX的yaml配置文件（提前把配置写好，归类成不同的文件）、控制业务逻辑层到数据访问层的关系。例如在SpringBoot的application.properties中可以其访问的DB：

当然，这就还牵扯一个Ansible操作容器云平台的问题。

Ansible调用K8S、OpenShift有以下两种方式。我们知道，在K8S中，通过使用不同deployment或者修改一个deployment中的image，可以发布指定版本的应用。如果在OpenShift中，我们用ImageStream控制容器镜像的版本，就更方便了，还能结合S2I的技术，实现从源码构建应用。

最后，在介绍一个通过Ansible做混合云应用发布的场景。

也就说说，开发环境是容器云，生产环境有VM on AWS和容器云，需要一键式发布应用。

解决的方法就是：

对于生产环境容器云，发布容器镜像，通过Jenkins Pipeline部署过去。

对于生产环境是AWS VM，将开发环境的war包拷贝到VM的tomcat对应目录中。

拷贝war包到tomcat的范例如下：