Gateway实现动态路由和灰度发布
# 动态路由
# 什么是动态路由?
动态路由是与静态路由相对的一个概念,指路由器能够根据路由器之间的交换的特定路由信息自动地建立自己的路由表,并且能够根据链路和节点的变化适时地进行自动调整。当网络中节点或节点间的链路发生故障,或存在其它可用路由时,动态路由可以自行选择最佳的可用路由并继续转发报文。
——摘自百度百科
动态路由机制的运作依赖路由器的两个基本功能:对路由表的维护;路由器之间适时的路由信息交换。
# 为什么要有动态路由?
静态路由和动态路由 http/lb
# 动态路由的实现
# 基于Redis实现
# 测试用例
http://127.0.0.1:9001/gateway/add
{
"id":"freshman-modules-admin",
"predicates":[
{
"name":"Path",
"args":{
"_genkey_0":"/api/admin/**"
}
}
],
"filters":[],
"uri":"lb://freshman-modules-admin",
"order":0
}
2
3
4
5
6
7
8
9
10
11
12
13
14
# 基于Nacos分布式配置中心实现
演示
# 灰度发布
# 线上项目发布一般方案
- 停机发布
- 蓝绿部署
- 滚动部署
- 灰度发布
停机发布 这种发布一般在夜里或者进行大版本升级的时候发布,因为需要停机,所以现在大家都在研究 Devops
方案。
蓝绿部署 需要准备两个相同的环境。一个环境新版本,一个环境旧版本,通过负载均衡进行切换与回滚,目的是为了减少服务停止时间。
滚动部署 就是在升级过程中,并不一下子启动所有新版本,是先启动一台新版本,再停止一台老版本,然后再启动一台新版本,再停止一台老版本,直到升级完成。基于 k8s
的升级方案默认就是滚动部署。
灰度发布 也叫金丝雀发布,灰度发布中,常常按照用户设置路由权重,例如90%的用户维持使用老版本,10%的用户尝鲜新版本。不同版本应用共存,经常与A/B测试一起使用,用于测试选择多种方案。
上边介绍的几种发布方案,主要是引出我们接下来介绍的 spring-cloud-gateway
动态路由,我们可以基于动态路由、负载均衡和策略加载去实现 灰度发布
。当然现在有很多开源的框架可以实现 灰度发布
,这里只是研究学习。
# 灰度发布简介
灰度发布(又名金丝雀发布)是指在黑与白之间,能够平滑过渡的一种发布方式。在其上可以进行A/B testing,即让一部分用户继续用产品特性A,一部分用户开始用产品特性B,如果用户对B没有什么反对意见,那么逐步扩大范围,把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定,在初始灰度的时候就可以发现、调整问题,以保证其影响度。
灰度期:灰度发布开始到结束期间的这一段时间,称为灰度期。
——摘自百度百科
我们来简单的通过下图来看下,通俗的讲: 为了保证服务升级过程的平滑过渡提高客户体验,会一部分用户 一部分用户递进更新,这样生产中会同时出现多个版本的客户端,为了保证多个版本客户端的可用需要对应的多个版本的服务端版本。灰度发布就是通过一定策略保证 多个版本客户端、服务端间能够正确对应。
以下方式基于权重进行访问