稳定性保障，如何慢慢放量灰度
大家好，我是架构摆渡人。这是实践经验系列的第二篇文章，这个系列会给大家分享很多在实际工作中有用的经验，如果有收获，还请分享给更多的朋友。
上篇文章给大家分享了开关的应用技巧，通过开关去保证上线时的稳定性。但是开关还是属于一刀切的那种，如果流量特别大的情况下，影响面还是挺大的，所以今天就给大家再补充一种方式，灰度放量。
举个例子说明下：比如你在重构订单详情接口，这个接口之前是在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 {
// 走本地老逻辑
}
}
推荐阅读
- 考研英语阅读终极解决方案——阅读理解如何巧拿高分
- 如何寻找情感问答App的分析切入点
- mybatisplus如何在xml的连表查询中使用queryWrapper
- MybatisPlus使用queryWrapper如何实现复杂查询
- 如何在Mac中的文件选择框中打开系统隐藏文件夹
- 漫画初学者如何学习漫画背景的透视画法（这篇教程请收藏好了！）
- java中如何实现重建二叉树
- Linux下面如何查看tomcat已经使用多少线程
- thinkphp|thinkphp 3.2 如何调用第三方类库
- 2019女表什么牌子好（如何挑选女士手表？）