概述
线上项目发布一般有以下几种方案:
- 停机发布
- 蓝绿部署
- 滚动部署
- 灰度发布
停机发布 这种发布一般在夜里或者进行大版本升级的时候发布,因为需要停机,所以现在大家都在研究 Devops
方案。
蓝绿部署 需要准备两个相同的环境。一个环境新版本,一个环境旧版本,通过负载均衡进行切换与回滚,目的是为了减少服务停止时间。
滚动部署 就是在升级过程中,并不一下子启动所有新版本,是先启动一台新版本,再停止一台老版本,然后再启动一台新版本,再停止一台老版本,直到升级完成。基于 k8s
的升级方案默认就是滚动部署。
灰度发布 也叫金丝雀发布,灰度发布中,常常按照用户设置路由权重,例如90%的用户维持使用老版本,10%的用户尝鲜新版本。不同版本应用共存,经常与A/B测试一起使用,用于测试选择多种方案。
上边介绍的几种发布方案,主要是引出我们接下来介绍的 spring-cloud-gateway
动态路由,我们可以基于动态路由、负载均衡和策略加载去实现 灰度发布
。当然现在有很多开源的框架可以实现 灰度发布
,这里只是研究学习。
动态路由
spring-cloud-gateway
默认将路由加载在内存中。具体可以参见 InMemoryRouteDefinitionRepository
类的实现。
这里我们基于 Redis
实现动态路由。基础项目见 spring-cloud-gateway简介
1. 将 actuator 的端点暴露出来。
1 | management: |
2. redis配置
1 |
|
3. 将原内存路由持久化到redis
1 |
|
4. 重写动态路由服务
1 |
|
5. 对外暴露接口
1 |
|
测试
测试前删除我们配置的静态路由,因为静态路由和redis动态路由同时存在时取并集。
- 访问 http://localhost:2000/actuator/gateway/routes , 可以看到只有默认路由。
1 | [ |
这个时候访问 http://192.168.124.5:2000/idc-provider1/provider1/1 根据结果可以推测能正确路由到 provider1
, 测试结果一致。
- 创建
provider1
路由,将路径设置为/p1/**
,测试是否生效。
POST
请求 http://localhost:2000/gateway/add
1 | { |
查看 redis
存储,或者请求 http://localhost:2000/actuator/gateway/routes , 都可以看到配置成功。
访问
1 | curl http://localhost:2000/p1/provider1/1 |
结果输出2001,与期望一致。
由此可见动态路由已经生效。
结语
本文到此结束。感兴趣的小伙伴后续可以通过加载配置文件,基于权重进行灰度。欢迎大家关注公众号【当我遇上你】。