SpringCloud H版3服务网关、服务配置、消息总线(GateWay、Spring Config、Bus)

最新推荐文章于 2024-05-20 09:56:57 发布

原创最新推荐文章于 2024-05-20 09:56:57 发布 · 413 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#java #spring #zookeeper #数据库

SpringCloud 专栏收录该内容

7 篇文章

订阅专栏

本文围绕Spring Cloud展开，介绍了服务网关GateWay，包括其特性、与zuul区别、工作原理及使用方法，还涉及断言和过滤器。同时阐述了Spring Config分布式配置中心的使用，如创建模块、读取规则等，以及SpringCloud Bus消息总线实现全局广播和定点通知的配置与原理。

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,读取配置文件的规则:

在这里插入图片描述

这里默认会读取master分支,因为我们配置文件中配置了

在这里插入图片描述

注意,这个方式读取到的配置是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

在这里插入图片描述
$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-IyUUGnTP-1606975758549)(E:\杂\坚果云\共享\我的坚果云\java后端\spring\SpringCloud3服务网关.assets\Bus的4)]$

3,修改3366(也是配置中心的客户端)

修改与3355是一模一样的

4,测试

启动7001,3344,3355,3366

此时修改GitHub上的配置文件

此时只需要刷新3344,即可让3355,3366动态获取最新的配置文件

在这里插入图片描述

其原理就是:

在这里插入图片描述

所有客户端都监听了一个rabbitMq的topic,我们将信息放入这个topic,所有客户端都可以送到,从而实时更新

配置定点通知

就是只通知部分服务,比如只通知3355,不通知3366
在这里插入图片描述

在这里插入图片描述

只通知3355

在这里插入图片描述

可以看到,实际上就是通过微服务的名称+端口号进行指定