稳定性保障，如何慢慢放量灰度

大家好，我是架构摆渡人。这是实践经验系列的第二篇文章，这个系列会给大家分享很多在实际工作中有用的经验，如果有收获，还请分享给更多的朋友。

上篇文章给大家分享了开关的应用技巧，通过开关去保证上线时的稳定性。但是开关还是属于一刀切的那种，如果流量特别大的情况下，影响面还是挺大的，所以今天就给大家再补充一种方式，灰度放量。

举个例子说明下：比如你在重构订单详情接口，这个接口之前是在A服务里面，由于后续服务拆分更精细化，新拆了一个服务，需要将这个接口迁移到新服务里面去。此时最简单的做法就是把代码复制过去，然后让客户端用新的详情接口。

但是这样老版本的APP怎么办？这个方案只能新版本的APP可以使用。所以对外的接口是不能变的，内部需要去做路由动作，那么最方便的肯定是在网关做了，所以网关是特别适合做灰度逻辑的地方，下面我们先来看网关如何做灰度。

网关统一灰度

网关默认是路由的/v1/order/detail接口，现在新加了/v2/order/detail接口，如果全部切过去，万一有问题，所有用户都会受到影响，所以需要灰度放量来将风险降到最低。

网关内部可以对指定的用户路由到v2版本的接口，也可以根据地区路由，方式有很多种，常用的路由方式有哪些我会在下面进行讲解。

应用内部自己灰度

除了在网关进行灰度，另一种方案就是应用内部自己灰度。也就是说APP请求到网关，网关到具体的服务，这个服务此时还是之前的老服务，需要在这个老服务调用新服务的接口，然后返回，这就是应用内部自己灰度的方式。

一旦灰度完成，老服务内部的代码就可以删除，当请求过来的时候只需要路由到请服务即可。然后可以将网关路由的地址直接改成新服务的地址，此时老服务内的接口可以直接删除，完成迁移动作。

灰度方式介绍

用户白名单灰度

此方式较为简单，就是构建一个用户的白名单，可以用手机号或者用户ID，白名单可以放在数据表里面，也可以放在配置中心。从性能角度考虑放配置中心更合适，更新后也能实时生效。

也就是当前请求的用户在你配置的白名单里面，就让他访问新版本的接口，不在就默认还是旧接口。通过这种方式观察一段时间，如果没有问题，就可以加大灰度人数或者全量放开。

用户百分比灰度

提取用户ID的后两位，然后产生一个随机数，如果匹配上了，这个用户就灰度中了。

百分比灰度

百分比灰度也是一种常用的灰度方式，此方式不会固定用户，而是采用随机的方式进行。如果设置了10%的灰度比例，也就是100次请求中有10次请求会被灰度中，会访问新的接口。

当然为了影响降到最低，也可以实现千分比，万分比，慢慢调高比例，一点点往上灰度，这种方式非常稳妥。

伪代码如下：

public static void main(String[] args) {
    // 灰度比例，配在配置中心
    int grayScale = 10;
    int probability = new Random().nextInt(100);
    if (probability < grayScale) {
        // 调用 /v2/order/detail
    } else {
        // 走本地老逻辑
    }
}