灰度发布方案

一、灰度发布定义

灰度发布（又名金丝雀发布）是指在黑与白之间，能够平滑过渡的一种发布方式。在其上可以进行A/B testing，即让一部分用户继续用产品特性A，一部分用户开始用产品特性B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B 上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。

二、实现思路方向

1、在代码中做。

一套线上环境，代码中做开关，对于不同的用户走不同的逻辑

2、在接入层做。

多套(隔离的)线上环境，接入层针对不同用户转发到不同的环境中

两种方案的优缺点：

灵活的灰度方案一般需要在接入层实现，具体就是自定义负载均衡策略实现。

下面介绍在接入层使用的方式，第一是在nginx层实现（使用ngx+lua），第二是在网关层实现（spring-cloud-zuul）。

第三是dubbo的灰度，项目中如果使用dubbo，有可能会需要dubbo服务的灰度实现。

负载均衡又可分为服务端负载均衡和客户端负载均衡

服务器端负载均衡：例如Nginx，通过Nginx进行负载均衡，先发送请求，然后通过负载均衡算法，在多个服务器之间选择一个进行访问；即在服务器端再进行负载均衡算法分配。

客户端负载均衡：例如ribbon或者dubbo，客户端会有一个服务器地址列表，在发送请求前通过负载均衡算法选择一个服务器，然后进行访问，这是客户端负载均衡；即在客户端就进行负载均衡算法分配。

三、nginx灰度方案说明

Nginx是一款轻量级的Web服务器/反向代理服务器以及电子邮件代理服务器。

nginx.conf

负载均衡策略：轮询（默认）、weight、ip_hash、fair（响应时间）、url_hash

简单的根据cookie进行灰度

Openresty

Nginx有很多的特性和好处，但是在Nginx上开发成了一个难题，Nginx模块需要用C开发，而且必须符合一系列复杂的规则，最重要的用C开发模块 必须要熟悉Nginx的源代码，使得开发者对其望而生畏。为了开发人员方便，所以接下来我们要介绍一种整合了Nginx和lua的框架，那就是OpenResty。

OpenResty® 是一个基于 Nginx 与 Lua 的高性能 Web 平台，其内部集成了大量精良的 Lua 库、第三方模块以及大多数的依赖项。用于方便地搭建能够处理超高并发、扩展性极高的动态 Web 应用、Web 服务和动态网关。

Openresty学习地址：https://moonbingbing.gitbooks.io/openresty-best-practices/content/base/intro.html

新浪微博开源项目

git地址：https://github.com/CNSRE/ABTestingGateway

ABTestingGateway是一个可以动态设置分流策略的灰度发布系统，工作在7层，基于nginx和ngx-lua开发，使用 redis 作为分流策略数据库，可以实现动态调度功能。

ABTestingGateway是在 nginx 转发的框架内，在转向 upstream 前，根据 用户请求特征 和 系统的分流策略 ，查找出目标upstream，进而实现分流。

nginx实现的灰度系统中，分流逻辑往往通过 rewrite 阶段的 if 和rewrite 指令等实现，优点是性能较高，缺点是功能受限、容易出错，以及转发规则固定，只能静态分流。针对这些缺点， ABTestingGateway，采用ngx-lua 实现系统功能，通过启用lua-shared-dict和lua-resty-lock作为系统缓存和缓存锁，系统获得了较为接近原生nginx转发的性能。

架构图：

特性：

实现原理：在代理转发前，使用rewrite_by_lua_file模块重写到目标upstream

diversion.lua逻辑：

例：略

四、dubbo灰度方案说明

Dubbo架构

Dubbo服务调用过程

Loadbalance（负载均衡）说明

在集群负载均衡时，Dubbo 提供了多种均衡策略，缺省为 random 随机调用

负载均衡策略Random(随机)、RoundRobin（轮询）、LeastActive（最小活跃调用数）、ConsistentHash（一致性Hash）

负载均衡配置：

自定义负载均衡实现：

例：

实现LoadBalance接口，或者继承AbstractLoadBalance 重写策略；

根据dubbo SPI发现机制，还需要在resources下添加META-INF/dubbo/com.alibaba.dubbo.rpc.cluster.LoadBalance

demo逻辑：目标服务的端口和灰度服务端口的一致，并且请求方法的第一个参数类型是Long(userId)并且是灰度用户，则判断为灰度服务，否则按照默认随机调用其余非灰度服务

四、springCloud灰度方案说明

Ribbon 提供了几个负载均衡的组件，其目的就是让请求转给合适的服务器处理

默认轮询

自定义策略需要继承AbstractLoadBalancerRule

开源方案：

自定义DiscoveryEnabledRule继承PredicateBaseRule

首先在请求开始处，实现自己的灰度逻辑，比如下面的demo根据请求url如果包含‘version’向holder中添加route为A的标识，否则添加route为B的标识。 (Holder本质是一个localThread)

在目标服务添加matadateMap

PredicateBaseRule中使用google提供的pridicate，MetadataAwarePredicate中实现apply方法判断发现的服务是否是目标服务