5,服务网关:
zuul停更了,
13,GateWay
gateway之所以性能好,因为底层使用WebFlux,而webFlux底层使用netty通信(NIO)
GateWay的特性:
基于异步非阻塞模型
GateWay与zuul的区别:
zuul1.x的模型:
什么是webflux:
是一个非阻塞的web框架,类似springmvc这样的
GateWay的一些概念:
1,路由:
就是根据某些规则,将请求发送到指定服务上
2,断言:
就是判断,如果符合条件就是xxxx,反之yyyy
3,过滤:
路由前后,过滤请求
GetWay的工作流程
GateWay的工作原理:
使用GateWay:
想要新建一个GateWay的项目
名字: cloud_gateway_9527
1,pom
2,配置文件
3,主启动类
4,针对pay模块,设置路由:
修改GateWay模块(9527)的配置文件:
这里表示,
当访问localhost:9527/payment/get/1时,
路由到localhost:8001/payment/get/1
5,开始测试
启动7001,8001,9527
如果启动GateWay报错
可能是GateWay模块引入了web和监控的starter依赖,需要移除
访问:
localhost:9527/payment/get/1
6,GateWay的网关配置,
GateWay的网关配置,除了支持配置文件,还支持硬编码方式
7使用硬编码配置GateWay:
创建配置类:
8,然后重启服务即可
重构:
上面的配置虽然首先了网关,但是是在配置文件中写死了要路由的地址
现在需要修改,不指定地址,而是根据微服务名字进行路由,我们可以在注册中心获取某组微服务的地址
需要:
1个eureka,2个pay模块
修改GateWay模块的配置文件:
然后就可以启动微服务.测试
Pridicate断言:
我们之前在配置文件中配置了断言:
这个断言表示,如果外部访问路径是指定路径,就路由到指定微服务上
可以看到,这里有一个Path,这个是断言的一种,断言的类型:
After:
可以指定,只有在指定时间后,才可以路由到指定微服务
这里表示,只有在2020年的2月21的15点51分37秒之后,访问才可以路由
在此之前的访问,都会报404
如何获取当前时区?
before:
与after类似,他说在指定时间之前的才可以访问
between:
需要指定两个时间,在他们之间的时间才可以访问
cookie:
只有包含某些指定cookie(key,value),的请求才可以路由
使用Cmd > curl http://localhost:9557/payment
带上cookie访问 使用Cmd > curl http://localhost:9557/payment --cookie "usrname=zzyy"
就可以得到正确结果
Header:
只有包含指定请求头的请求,才可以路由
host:
只有指定主机的才可以访问,
比如我们当前的网站的域名是www.aa.com
那么这里就可以设置,只有用户是www.aa.com的请求,才进行路由
- Host=**.somehost.org,**.anotherhost.org
可以看到,如果带了域名访问,就可以,但是直接访问ip地址.就报错了
method:
只有指定请求才可以路由,比如get请求...
path:
只有访问指定路径,才进行路由
比如访问,/abc才路由
Query:
必须带有请求参数才可以访问
Filter过滤器:
生命周期:
在请求进入路由之前,和处理请求完成,再次到达路由之前
种类:
GateWayFilter,单一的过滤器
与断言类似,比如闲置,请求头,只有特定的请求头才放行,反之就过滤:
GlobalFilter,全局过滤器:
自定义过滤器:
实现两个接口
然后启动服务,即可,因为过滤器通过@COmponet已经加入到容器了
6,服务配置:
Spring Config分布式配置中心:
微服务面临的问题
可以看到,每个微服务都需要一个配置文件,并且,如果有几个微服务都需要连接数据库
那么就需要配4次数据库相关配置,并且当数据库发生改动,那么需要同时修改4个微服务的配置文件才可以
所以有了springconfig配置中心
使用配置中心:
0,使用github作为配置中心的仓库:
初始化git环境:
1,新建config模块:
名字: cloud-config-3344
2,pom
3,配置文件
4,主启动类
5,修改hosts:
6,配置完成
测试,3344是否可以从github上获取配置
启动3344 (要先启动eureka)
它实际上就是,读取到配置文件中的GitHub的地址,然后拼接上/master/config-dev.yml
7,读取配置文件的规则:
2,
这里默认会读取master分支,因为我们配置文件中配置了
3
注意,这个方式读取到的配置是json格式的
所有规则:
2,创建配置中心客户端:
1,创建config客户端项目
名字: cloud-config-client-3355
2,pom
3,配置文件
注意这个配置文件就不是application.yml
而是bootstrap.yml
这个配置文件的作用是,先到配置中心加载配置,然后加载到application.yml中
4,主启动类:
5,controller类
就是上面提到的,以rest风格将配置对外暴露
如果客户端运行正常,就会读取到github上配置文件的,config.info下的配置
6,测试:
启动3344,3355
访问3355的 /configInfo
7,问题::
上面3355确实获取到了配置文件,但是如果此时配置文件修改了,3355是获取不到的
3344可以实时获取到最新配置文件,但是3355(客户端)却获取不到
除非重启服务
8,实现动态刷新:
1,修改3355,添加一个pom依赖:
2,修改配置文件,添加一个配置:
3,修改controller:
4,此时重启服务
此时3355还不可以动态获取
因为此时,还需要外部发送post请求通知3355
此时在刷新3355,发现可以获取到最新的配置文件了,这就实现了动态获取配置文件,因为3355并没有重启
具体流程就是:
我们启动好服务后
运维人员,修改了配置文件,然后发送一个post请求通知3355
3355就可以获取最新配置文件
问题:
如果有多个客户端怎么办(3355,3356,3357…)
虽然可以使用shell脚本,循环刷新
但是,可不可以使用广播,一次通知??
这些springconfig做不到,需要使用springcloud Bus消息总线
消息总线:
SpringCloud Bus:
注意,这里两张图片,就代表两种广播方式
图1: 它是Bus直接通知给其中一个客户端,由这个客户端开始蔓延,传播给其他所有客户端
图2: 它是通知给配置中心的服务端,有服务端广播给所有客户端
为什么被称为总线?
就是通过消息队列达到广播的效果
我们要广播每个消息时,主要放到某个topic中,所有监听的节点都可以获取到
使用Bus:
1,配置rabbitmq环境:
2,之前只有一个配置中心客户端,这里在创建一个
复制3355即可,创建为3366
全部复制3355的即可
2,使用Bus实现全局广播
Bus广播有两种方式:
就是上面两个图片的两种方式
这两种方式,第二种跟合适,因为:
第一种的缺点:
配置第二种方式:
1,配置3344(配置中心服务端):
1,修改配置文件:
2,添加pom
springboot的监控组件,和消息总线
2,修改3355(配置中心的客户端)
1,pom:
和上面一样
2,配置文件:
注意配置文件的名字,要改为bootstrap.yml
3,修改3366(也是配置中心的客户端)
修改与3355是一模一样的
4,测试
启动7001,3344,3355,3366
此时修改GitHub上的配置文件
此时只需要刷新3344,即可让3355,3366动态获取最新的配置文件
其原理就是:
所有客户端都监听了一个rabbitMq的topic,我们将信息放入这个topic,所有客户端都可以送到,从而实时更新
配置定点通知
就是只通知部分服务,比如只通知3355,不通知3366
只通知3355
可以看到,实际上就是通过微服务的名称+端口号进行指定