转载 http://huhanlin.com/2018/06/15/springcloud-%E7%81%B0%E5%BA%A6%E5%8F%91%E5%B8%83%E6%96%B9%E6%A1%88/

       灰度发布的特性是混合部署，多版本共存，平滑升级，如果升级失败可以回滚至上一版本，新版本上线无需提供全套其余服务，节省资源。

       核心思想是，通过用户特定标识（ parameter 、header、body、ip、id），根据路由策略，将请求引流到不同版本的服务上。

接入层的三种方案

1、nginx+lua

       参考逻辑架构图，用户携带标识，最外层nginx的lua脚本添加控制策略，解析出导流标识，网关根据导流标识分发至不同版本服务。

优点：

①zuul无须负载策略压力，对于服务来讲灰度动作为黑盒，无须关心。

②即使没有加入服务中心的应用也可以通过nginx来做灰度。

缺点：

①内部请求无法控制灰度，比如Service1的v1需要请求Sservice2的v2。

②对于nginx来说，必须需要访问服务中心获取服务信息，否则服务集群情况相当于黑盒。

2、zuul+groovy

      此方案是将接入层下沉到zuul，并且配合groovy动态编译实现动态策略。

优点：

①zuul可以感知注册中心的服务，能够提供更灵活的分发策略。

②可以基于zuul的路由配置设置路由规则。

缺点：

①zuul需要添加filter处理分发策略，如果开启策略过多，会带来性能压力。

3、ribbon+rule

基于ribbon在客户端做负载均衡逻辑中添加分发逻辑。

优点：

①基于tag可以做长链路的灰度策略。

②分发策略在调用端，负载不会集中在某一服务端。

③ribbon支持restTemplate、zuul、feign请求。

缺点：

①采用jar包方式引用，只能是内部项目使用，无法对外部服务提供灰度发布支持。

由于我们目前项目都为内部使用，并不管理外部项目，所以推荐第三种实现方式。能够提供更好的负载，更好的策略控制。