第十一章_Config分布式配置中心
1.Config分布式配置中心介绍
1.1分布式系统面临的配置问题
-
微服务意味着要将单体应用中的业务拆分成一个个子服务,每个服务的粒度相对较小,因此系统中会出现大量的服务。由于每个服务都需要必要的配置信息才能运行,所以一套集中式的、动态的配置管理设施是必不可少的。
-
SpringCloud提供了ConfigServer来解决这个问题,我们每一个微服务自己带着一个application.yml,上百个配置文件的管理…/(ㄒoㄒ)/~~
1.2是什么
SpringCloud Config为微服务架构中的微服务提供集中化的外部配置支持,配置服务器为各个不同微服务应用的所有环境提供了一个中心化的外部配置。
1.3怎么玩
SpringCloud Config分为 服务端 和 客户端 两部分。
- 服务端也称为分布式配置中心,它是一个独立的微服务应用,用来连接配置服务器并为客户端提供获取配置信息,加密/解密信息等访问接口
- 客户端则是通过指定的配置中心来管理应用资源,以及与业务相关的配置内容,并在启动的时候从配置中心获取和加载配置信息配置服务器默认采用git来存储配置信息,这样就有助于对环境配置进行版本管理,并且可以通过git客户端工具来方便的管理和访问配置内容。
1.4能干嘛
- 集中管理配置文件
- 不同环境不同配置,动态化的配置更新,分环境部署比如dev/test/prod/beta/release
- 运行期间动态调整配置,不再需要在每个服务部署的机器上编写配置文件,服务会向配置中心统一拉取配置自己的信息
- 当配置发生变动时,服务不需要重启即可感知到配置的变化并应用新的配置
- 将配置信息以REST接口的形式暴露:post、curl访问刷新均可…
1.5与GitHub/Gitee整合配置
由于SpringCloud Config默认使用Git来存储配置文件(也有其它方式,比如支持SVN和本地文件),但最推荐的还是Git,而且使用的是http/https访问的形式
官网:https://cloud.spring.io/spring-cloud-static/spring-cloud-config/2.2.1.RELEASE/reference/html/
2.Config配置总控中心搭建
2.1服务端远程仓库配置
用你自己的账号在Gitee上新建一个名为springcloud-config的新Repository
地址:https://gitee.com/linhaipengg/springcloud-config.git
在仓库下新建三个文件
2.2配置模块cloud-config-center-3344
新建Module模块cloud-config-center-3344,它即为Cloud的配置中心模块
(1)pom
<dependencies>
<!-- config Server -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-config-server</artifactId>
</dependency>
<!--eureka-client config Server也要注册进服务中心-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-devtools</artifactId>
<scope>runtime</scope>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
<dependency><!-- 引入自己定义的api通用包,可以使用Payment支付Entity -->
<groupId>springcloud</groupId>
<artifactId>cloud-api-commons</artifactId>
<version>${project.version}</version>
</dependency>
</dependencies>
(2)yml
(3)主启动类
(4)测试
2.3文件命名规则
{application} 是应用名称,对应到配置文件上来,就是配置文件的名称部分。
{profile} 是配置文件的版本,我们的项目有开发版本、测试环境版本、生产环境版本
对应到配置文件上来就是以 application-{profile}.yml 加以区分,
例如application-dev.yml,application-prod.yml。
2.4文件访问规则
3.Config客户端配置与测试
3.1搭建Config客户端模块3355
(1)pom
<dependencies>
<!-- config Client 和 服务端的依赖不一样 -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-config</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-devtools</artifactId>
<scope>runtime</scope>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
<!-- 引入自己定义的api通用包 -->
</dependency>
<dependency>
<groupId>springcloud</groupId>
<artifactId>cloud-api-commons</artifactId>
<version>${project.version}</version>
</dependency>
</dependencies>
(2)bootstrap.yml
- appllication.yml是用户级的资源配置项
- bootstrap.yml是系统级的,优先级更加高
SpringCloud会创建一个"Bootstrap Context"作为Spring应用的ApplicationContext的父上下文。
初始化的时候,Bootstrap Context负责从外部源加载配置属性并解析配置。这两个上下文共享一个从外部获取的Environment。
Bootstrap 属性有高优先级,默认情况下,它们不会被本地配置覆盖。BootstrapContext和ApplicationContext、有着不同的约定,所以新增了一个bootstrap.yml文件,保证BootstrapContext和ApplicationContext配置的分离。
(3)主启动类
(4)controller层
(5)测试
3.2修改远程仓库配置文件内容
直接在gitee官网进行修改
-
修改前:
-
修改后:
(1)观察3344_发生改变
(2)观察3355_没有改变
(3)存在的问题
当远程仓库配置文件被修改后,3344和3355都要变,3344变了,但是3355必须要重启才可以更新。
4.Config客户端之动态刷新
避免每次更新配置都要重启客户端微服务3355,我们需要它能动态刷新,下面来修改3355模块
4.1修改3355模块
(1)pom引入actuator监控
(2)修改yml,暴露监控端口
说明:因为==手动刷新需要自己调用一个类似于健康检查的端点(接口)==,所以呢,我们需要把这个端点给暴露出来,以便外部可访问
(3)Controller类添加@RefreshScope
(4)继续修改远程仓库的配置文件
(5)运维人员发送Post请求刷新3355
(6)查看3355查的数据是否发生变化
4.2思考存在的问题
想想还有什么问题?
- 假如有多个微服务客户端3355/3366/3377…,每个微服务都要执行一次post请求,手动刷新?
- 可否广播,一次通知,处处生效?
- 我们想大范围的自动刷新,求方法,定点刷新
于是就有下面的消息总线!
第十二章_Bus消息总线
1.SpringCloud Bus介绍
1.1消息总线的由来
回顾上一篇文章 Config分布式配置中心存在的问题
- 假如有多个微服务客户端3355/3366/3377…,每个微服务都要执行一次post请求,手动刷新?
- 可否广播,一次通知,处处生效?
- 我们想大范围的自动刷新,求方法
以上就是消息总线的产生由来
Spring Cloud Bus 配合 Spring Cloud Config 使用可以实现配置的动态刷新
1.2bus是什么
Spring Cloud Bus是用来==将分布式系统的节点与轻量级消息系统链接起来==的框架,它整合了Java的事件处理机制和消息中间件的功能。
Spring Cloud Bus目前支持RabbitMQ和Kafka。
1.3bus能干嘛
Spring Cloud Bus能管理和传播分布式系统间的消息,就像一个分布式执行器,可用于广播状态更改、事件推送等,也可以当作微服务间的通信通道。
1.4总线
(1)什么是总线
在微服务架构的系统中,通常会使用轻量级的消息代理来构建一个共用的消息主题,并让系统中所有微服务实例都连接上来。由于==该主题中产生的消息会被所有实例监听和消费==,所以称它为消息总线。
在总线上的各个实例,都可以方便地广播一些需要让其他连接在该主题上的实例都知道的消息。
(2)基本原理
ConfigClient实例都监听MQ中同一个topic(默认是springCloudBus)。当一个服务刷新数据的时候,它会把这个信息放入到Topic中,这样其它监听同一Topic的服务就能得到通知,然后去更新自身的配置。
2.RabbitMQ环境搭建
注意Erlang和RabbitMQ的版本要适应
2.1安装Erlang
下载地址:http://erlang.org/download/otp_win64_21.3.exe
2.2安装RabbitMQ
下载地址:Release RabbitMQ 3.7.14 · rabbitmq/rabbitmq-server (github.com)
-
进入RabbitMQ安装目录下的sbin目录,输入以下命令启动管理功能
-
启动RabbitMQ,发现闪退
2.3解决闪退
访问地址查看是否安装成功:http://localhost:15672/
输入账号密码并登录:guest guest
3.动态刷新全局广播
3.1搭建客户端微服务3306
(1)pom
<dependencies>
<!-- config Client 和 服务端的依赖不一样 -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-config</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-devtools</artifactId>
<scope>runtime</scope>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
<dependency><!-- 引入自己定义的api通用包,可以使用Payment支付Entity -->
<groupId>springcloud</groupId>
<artifactId>cloud-api-commons</artifactId>
<version>${project.version}</version>
</dependency>
</dependencies>
(2)yml
(3)主启动
(4)业务类
3.2设计思想
(1)消息总线触发客户端
利用消息总线触发一个客户端/bus/refresh,而刷新所有客户端的配置
(2)消息总线触发服务端
利用消息总线触发一个服务端ConfigServer的/bus/refresh端点,而刷新所有客户端的配置
图二的架构显然更加适合,图一不适合的原因如下:
- 打破了微服务的职责单一性,因为微服务本身是业务模块,它本不应该承担配置刷新的职责。
- 破坏了微服务各节点的对等性。
- 有一定的局限性。例如,微服务在迁移时,它的网络地址常常会发生变化,此时如果想要做到自动刷新,那就会增加更多的修改
3.3配置中心3344添加消息总线支持
(1)pom添加消息总线支持
<!--添加消息总线RabbitMQ支持-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-bus-amqp</artifactId>
</dependency>
(2)yml配置rabbitmq并暴露端点
spring:
#rabbitmq相关配置 15672是Web管理界面的端口;5672是MQ访问的端口
rabbitmq:
host: 192.168.16.106
port: 5672
username: guest
password: guest
# 暴露bus刷新配置的端点 actuator刷新配置
management:
endpoints:
web:
exposure:
include: 'bus-refresh' #Post /bus/refresh 官网架构图
说明:
因为手动刷新需要自己调用一个类似于健康检查的端点(接口),所以呢,我们需要把这个端点给暴露出来,以便外部可访问。
3.4客户端3355、3366添加消息总线支持
(1)pom添加消息总线支持
<!--添加消息总线RabbitMQ支持-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-bus-amqp</artifactId>
</dependency>
(2)yml添加rabbit相关配置
spring:
#rabbitmq相关配置 15672是Web管理界面的端口;5672是MQ访问的端口
rabbitmq:
host: localhost
port: 5672
username: guest
password: guest
3.5测试
修改Gitee上配置文件增加版本号
使用cmd发送POST请求
curl -X POST "http://localhost:3344/actuator/bus-refresh"
测试结果:一次修改,广播通知,处处生效
4.动态刷新定点通知
不想全部通知,只想定点通知:只通知3355,不通知3366
简单一句话:指定具体某一个实例生效而不是全部
公式:
http://localhost:配置中心的端口号/actuator/bus-refresh/{destination}
/bus-refresh请求不再发送到具体的服务实例上,而是发给config server并通过destination参数类指定需要更新配置的服务或实例
-
案例:
我们这里以刷新运行在3355端口上的config-client为例:只通知3355,不通知3366
curl -X POST "http://localhost:3344/actuator/bus-refresh/config-client:3355"
5.总结
6.Springboot Actuator的说明
6.1是什么
监控中心是针对微服务期间
- 查看服务器内存变化(对内存,线程,日志管理等)
- 检测服务配置连接池地址是否可用(模拟访问,懒加载)
- 统计现在有多个bean(是Spring容器中的bean)
- 统计SpringMVC@RequestMapping(统计http接口)
使用Actuator来查看这些信息,它是没有界面的返回的是json格式的数据
AdminUi底层使用的是Actuator实现的,只不过给它加了个可视化界面
6.2应用场景
用在生产环境
使用它的原因:它是springboot的一个附加功能,可帮助你在应用程序生产环境时监控和管理应用程序,可使用Http的各种请求来监管,审计,收集应用的运行情况,特别对于微服务管理十分有意义。
建议使用springboot2.0.5,因为它里面返回的信息更加全面。
springboot 提供了对项目的监控功能。
6.3如何使用
(1)导入依赖
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
<version>2.1.3.RELEASE</version>
</dependency>
(2)配置端点
在application.properties中配置端点,
暴露部分端点
management.endpoints.web.exposure.include=info,health,beans,env
暴露所有端点
management.endpoints.web.exposure.include=*
不暴露beans端点
management.endpoints.web.exposure.exclude=beans
在上述配置中,首先使用 management.endpoints.web.exposure.include 暴露所有的端点,接着使用management.endpoints.web.exposure.exclud 排除 beans 端点,这样就能够暴露除 beans 外的所有 actuator端点了。
(3)浏览器访问
例如:
http://127.0.0.1:8080/actuator/health
访问项目监控需要加前缀 /actuator
(4)端点说明
6.4总结
上面利用SpringCloud Config刷新客户端配置,以及消息总线触发服务端ConfigServer的/bus-refresh端点,而刷新所有客户端的配置,利用的就是actuator刷新配置文件。
因为手动刷新需要自己调用一个类似于健康检查的端点(接口),所以呢,我们需要把这个端点给暴露出来,以便外部可访问。
刷新客户端:
curl -X POST "http://localhost:3355/actuator/refresh"
刷新服务端:
curl -X POST "http://localhost:3355/actuator/refresh"