一、Config
1.1）Config概述
git吞吐每秒钟就几十，请求量大就不行
1.2）构建Server端
文件临时存储，随着服务的关闭文件甚至路径都会删除
1.3）构建Client端
引入BootStrap是因为SpringCloud在2020.x.x版本之后禁用掉了，想去使用Config启动有问题所以需要手动引入
两种获取配置方式
1.4）基础架构
1.5）Config执行流程
1.6）配置git本地库
1.7）Server端连接的安全配置
1.8）Config集成Eureka提升高可用性
补充：spring-boot-starter-security依赖需要去掉
1.9）配置对Config Server的快速失败检测
快速失败检测默认为false的情况下，启动Client端应用
1.10）动态刷新配置
需要手动更新配置的原因在于配置首要是稳定性，在开启过程中起作用的比例大； 但也有特殊情况配置是在运行过程中需要改变的，比如双十一活动需要动态下掉或者添加某个活动，此时则可以使用动态刷新配置功能
告诉我们test.name有变化
二、Bus
2.1）Bus概述
Bus实际使用比率很小，但是也体现了自动配置的优势
2.2）构建服务端
加Kafka是希望通过其广播的功能让微服务中各个集群获得更新的通知
2.3）构建Client端
2.4）实现Config的全局刷新
Config通过Bus实现全局刷新，然后让Kafka实现消息分发
还是51jdbc
2.5）触发配置刷新的两种方式
ServiceA、ServiceB、ServiceC指微服务
两种方式多采用服务端刷新
2.6）消息通知解析
Refresh表示配置刷新事件，Ack表示应用成功收到消息
ApplicationEvent类型共有的属性
AckRemoteApplicationEvent类型独有的属性
2.7）事件驱动模型
Bus通知的逻辑
事件
事件监听者
获取配置两种方式，其中一种便是从Environment中获取
环境改变触发此Listener，那么是谁在广播导致环境改变事件呢
事件发布者
事件广播给新增监听器和移除监听器之后剩下的所有Listener——类似观察者模式可以往里加人减人但凡留存的都进行通知
spring中doXxx()方法都是真正执行处理的
三、Stream
3.1）Stream概述
让MQ使用更简便，不改变代码的前提下可轻松更换不同MQ——使用较少的原因在于支持的MQ少
3.2）简单例子入门
专门用来接收消息，input()方法会返回一个可订阅频道
针对Topic名字为input的输出流
3.3）核心概念说明——@EnableBinding
3.3）核心概念说明——@StreamListener
3.4）Stream的应用模型
Stream在中间将一个应用下不同的Message进行解耦
演示1：注入绑定接口——SinkSender
只要开启@EnableBinding注解，写入其中的类就会生成代理被注入IOC中
上文中自定义receive()方法已经接收到了信息
演示2：注入消息通道——MessageChannel
Spring在加载MultiSinkSender的同时将添加@Output注解的MessageChannel也进行了注入
演示3：Spring Integration原生支持
SpringCloud Stream包装了Spring Integration
演示4：消费组ConsumerGroup
向greetings通道两秒一次发送时间信息
消费者A
消费者B
