1、SpringCloud Config分布式服务配置中心
1.1 微服务面临的问题
可以看到,每个微服务都需要一个配置文件,并且,如果有几个微服务都需要连接数据库 那么就需要配4次数据库相关配置,并且当数据库发生改动,那么需要同时修改4个微服务的配置文件才可以
所以有了springconfig配置中心
1.2 使用配置中心
使用github作为配置中心的仓库:
初始化git环境:
1.2.1 新建config模块
名字: cloud-config-3344
1.2.2 修改pom
1.2.3 配置文件
1.2.4 主启动类
1.2.5 修改hosts
1.2.6 配置完成
测试,3344是否可以从github上获取配置
启动3344 (要先启动eureka)
它实际上就是,读取到配置文件中的GitHub的地址,然后拼接上/master/config-dev.yml
1.2.7 读取配置文件的规则
这里默认会读取master分支,因为我们配置文件中配置了
注意,这个方式读取到的配置是json格式的
所有规则:
1.3、创建配置中心客户端
1.3.1 创建config客户端项目
名字: cloud-config-client-3355
1.3.2 修改pom
1.3.3 配置文件
注意这个配置文件就不是application.yml
而是bootstrap.yml
这个配置文件的作用是,先到配置中心加载配置,然后加载到application.yml中
1.3.4 主启动类
1.3.5 controller类
就是上面提到的,以rest风格将配置对外暴露
如果客户端运行正常,就会读取到github上配置文件的,config.info下的配置
1.3.6 测试
启动3344,3355
访问3355的 /configInfo
1.3.7 问题
上面3355确实获取到了配置文件,但是如果此时配置文件修改了,3355是获取不到的 3344可以实时获取到最新配置文件,但是3355却获取不到 除非重启服务
1.4 实现动态刷新
1.4.1 修改3355,添加一个pom依赖:
1.4.2 修改配置文件,添加一个配置:
1.4.3 修改controller
1.4.4 重启服务
此时3355还不可以动态获取
因为此时,还需要外部发送post请求通知3355
此时在刷新3355,发现可以获取到最新的配置文件了,这就实现了动态获取配置文件,因为3355并没有重启
具体流程就是:
我们启动好服务后
运维人员,修改了配置文件,然后发送一个post请求通知3355
3355就可以获取最新配置文件
问题:
如果有多个客户端怎么办(3355,3356,3357…)
虽然可以使用shell脚本,循环刷新
但是,可不可以使用广播,一次通知??
这些springconfig做不到,需要使用springcloud Bus消息总线
2、SpringCloud Bus消息总线
2.1 概述
注意,这里年张图片,就代表两种广播方式
图1: 它是Bus直接通知给其中一个客户端,由这个客户端开始蔓延,传播给其他所有客户端
图2: 它是通知给配置中心的服务端,有服务端广播给所有客户端
为什么被称为总线?
就是通过消息队列达到广播的效果 我们要广播每个消息时,主要放到某个topic中,所有监听的节点都可以获取到
2.2 使用Bus
2.1.1 配置rabbitmq环境
2.1.2 之前只有一个配置中心客户端,这里在创建一个
复制3355即可,创建为3366
全部复制3355的即可
2.1.3 使用Bus实现全局广播
Bus广播有两种方式:
就是上面两个图片的两种方式
这两种方式,第二种跟合适,因为:
第一种的缺点:
2.1.4 配置第二种方式
- 配置3344(配置中心服务端)😗*
- 修改配置文件:
- 添加pom
springboot的监控组件,和消息总线
- 修改3355(配置中心的客户端)
- pom:
- 配置文件:
注意配置文件的名字,要改为bootstrap.yml
- 修改3366(也是配置中心的客户端)
修改与3355是一模一样的
2.1.5 测试
启动7001,3344,3355,3366
此时修改GitHub上的配置文件
此时只需要刷新3344,即可让3355,3366动态获取最新的配置文件
其原理就是:
所有客户端都监听了一个rabbitMq的topic,我们将信息放入这个topic,所有客户端都可以送到,从而实时更新
配置定点通知
就是只通知部分服务,比如只通知3355,不通知3366
只通知3355
可以看到,实际上就是通过微服务的名称+端口号进行指定
3、SpringCloud Stream消息驱动
3.1 概述
现在一个很项目可能分为三部分: 前端--->后端---->大数据 而后端开发使用消息中间件,可能会使用RabbitMq 而大数据开发,一般都是使用Kafka, 那么一个项目中有多个消息中间件,对于程序员,因为人员都不友好
而Spring Cloud Stream就类似jpa,屏蔽底层消息中间件的差异,程序员主要操作Spring Cloud Stream即可
不需要管底层是kafka还是rabbitMq
3.2 什么是Spring Cloud Stream
3.3 Spring Cloud Stream是怎么屏蔽底层差异的?
3.4 Spring Cloud Streamd 通信模式
3.5 Spring Cloud Stream的业务流程
类似flume中的channel,source,sink 估计是借鉴(抄袭)的 source用于获取数据(要发送到mq的数据) channel类似SpringCloudStream中的中间件,用于存放source接收到的数据,或者是存放binder拉取的数据
3.6 常用注解和api
3.7 使用SpringCloudStream
需要创建三个项目,一个生产者,两个消费者
3.7.1 创建生产者
- pom
- 配置文件
- 主启动类
- service和实现类
service定义发送消息
这里,就会调用send方法,将消息发送给channel,
然后channel将消费发送给binder,然后发送到rabbitmq中
- controller
- 测试
启动rabbitmq
启动7001,8801
确定8801后,会在rabbitmq中创建一个Exchange,就是我们配置文件中配置的exchange
访问8801的/sendMessage
3.7.2 创建消费者
- pom文件
- 配置文件
这里排版一点问题
input就表示,当前服务是一个消费者,需要消费消息,下面就是指定消费哪个Exchange中的消息
- 主启动类
- 业务类(消费数据)
生产者发送消息时,使用send方法发送,send方法发送的是一个个Message,里面封装了数据
- 测试:
启动7001.8801.8802
此时使用生产者生产消息
可以看到,消费者已经接收到消息了
3.7.2 创建消费者2
创建8803,
与8802创建一模一样,就不写了
创建8803主要是为了演示重复消费等问题
…
…
…
重复消费问题:
此时启动7001.8801.8802.8803
此时生产者生产一条消息
但是此时查询消费者,发现8802,8803都消费到了同一条数据
3.7.3 自定义分组
修改8802,8803的配置文件
现在将8802,8803都分到了A组
然后去重启02,03
然后此时生产者生产两条消息
可以看到,每人只消费了一条消息,并且没有重复消费
3.8 持久化问题
就是当服务挂了,怎么消费没有消费的数据??
这里,先将8802移除A组,
然后将02,03服务关闭
此时生产者开启,发送3条消息
此时重启02,03
可以看到,当02退出A组后,它就获取不到在它宕机的时间段内的数据
但是03重启后,直接获取到了宕机期间它没有消费的数据,并且消费了
总结:
也就是,当我们没有配置分组时,会出现消息漏消费的问题
而配置分组后,我们可以自动获取未消费的数据
4、Spring Cloud Sleuth链路追踪
4.1 sleuth要解决的问题
而来sleuth就是用于追踪每个请求的整体链路
4.2 使用sleuth
4.2.1 安装zipkin
运行jar包
java -jar xxxx.jar
然后就可以访问web界面, 默认zipkin监听的端口是9411
localhost:9411/zipkin/
可以看到,类似链表的形式
4.2.2 使用sleuth
不需要额外创建项目,使用之前的8001和order的80即可
- 修改8001
引入pom:
这个包虽然叫zipkin但是,里面包含了zpikin与sleuth
修改配置文件:
- 修改80
添加pom
与上面是一样的
添加配置:
与上面也是一样的
4.2.3 测试
启动7001.8001,80,9411
