分布式中的配置问题

微服务意味着要将单体应用中的业务拆分成一个个子服务,每个服务的粒度相对较小,因此系统中会出现大量的服务。由于每个服务都需要必要的配置信息才能运行,所以一套集中式的、动态的配置管理设施是必不可少的

SpringCloud Config为微服务架构中的微服务提供集中化的外部配置支持,配置服务器为各个不同微服务应用的所有环境提供了一个中心化的外部配置。

SpringCloud Config分为服务端和客户端两部分。

服务端也称为分布式配置中心,它是一个独立的微服务应用,用来连接配置服务器并为客户端提供获取配置信息,加密/解密信息等访问接口

客户端则是通过指定的配置中心来管理应用资源,以及与业务相关的配置内容,并在启动的时候从配置中心获取和加载配置信息配置服务器默认采用git来存储配置信息,这样就有助于对环境配置进行版本管理,并且可以通过git客户端工具来方便的管理和访问配置内容。

SpringCloud Config 能干嘛

image-20220102111201981

SpringCloud Config 服务端获取Gitee配置

image-20220102111504607

pom.xml

<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-config-server</artifactId>
</dependency>

application.yml

server:
port: 3344

spring:
application:
name: cloud-config-center #注册进Eureka服务器的微服务名
cloud:
config:
server:
git:
# uri: git@github.com:zzyybs/springcloud-config.git #GitHub上面的git仓库名字
# uri: git@gitee.com:fl1906249647/springcloud-config.git
uri: https://gitee.com/fl1906249647/springcloud-config.git
####搜索目录
search-paths:
- springcloud-config
####读取分支
label: master

主启动类

@SpringBootApplication
@EnableConfigServer
public class ConfigCenterMain3344
{
public static void main(String[] args) {
SpringApplication.run(ConfigCenterMain3344.class, args);
}
}

访问端口http://localhost:3344/master/config-dev.yml

image-20220102111944347

image-20220102112029624

SpringCloud客户端配置

即通过客户端访问服务端 访问Gitee上的配置文件

pom.xml

<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-config</artifactId>
</dependency>

配置文件bootstrap.yml

applicaiton.yml是用户级的资源配置项

bootstrap.yml是系统级的,优先级更加高

Spring Cloud会创建一个“Bootstrap Context”,作为Spring应用的Application Context的父上下文。初始化的时候,Bootstrap Context负责从外部源加载配置属性并解析配置。这两个上下文共享一个从外部获取的Environment

Bootstrap属性有高优先级,默认情况下,它们不会被本地配置覆盖。 Bootstrap contextApplication Context有着不同的约定,所以新增了一个bootstrap.yml文件,保证Bootstrap ContextApplication Context配置的分离。

要将Client模块下的application.yml文件改为bootstrap.yml,这是很关键的,

因为bootstrap.yml是比application.yml先加载的。bootstrap.yml优先级高于application.yml

server:
port: 3355

spring:
application:
name: config-client
cloud:
#Config客户端配置
config:
label: master #分支名称
name: config #配置文件名称
profile: dev #读取后缀名称 上述3个综合:master分支上config-dev.yml的配置文件被读取http://config-3344.com:3344/master/config-dev.yml
uri: http://localhost:3344 #配置中心地址k
# uri: http://CLOUD-CONFIG-CENTER # 配置中心地址 Erueka 这里直接写服务端地址即可无需用到注册中心地址否则会报错

#rabbitmq相关配置 15672是Web管理界面的端口;5672是MQ访问的端口
rabbitmq:
host: 106.14.154.114
port: 5672
username: admin
password: 123456

#服务注册到eureka地址 这一步可不用
eureka:
client:
service-url:
defaultZone: http://localhost:7001/eureka,http://localhost:7002/eureka

## 暴露监控端点
management:
endpoints:
web:
exposure:
include: "*"

读取服务端读取远程文件内容

@RestController
@RefreshScope
public class ConfigClientController
{
@Value("${fl}")
private String configInfo;

@GetMapping("/configInfo")
public String getConfigInfo()
{
return configInfo;
}
}

image-20220102115510278

客户端动态刷新问题

引出:

image-20220102115830487

动态刷新解决方案

引入actuator监控 + @RefreshScope

运维人员发送Post请求: http://localhost:335/actuator/refresh

image-20220102145045390

刷新成功

image-20220102145108341

方法1存在问题:

image-20220102145140868

动态解决方案2 引入Bus消息总线

  • 分布式自动刷新配置功能
  • SpringCloud Bus +SpringCloud Config 实现配置的动态刷新

什么是总线

在微服务架构的系统中,通常会使用轻量级的消息代理来构建一个共用的消息主题,并让系统中所有微服务实例都连接上来。由于该主题中产生的消息会被所有实例监听和消费,所以称它为消息总线。在总线上的各个实例,都可以方便地广播一些需要让其他连接在该主题上的实例都知道的消息。

基本原理

ConfigClient实例都监听MQ中同一个topic(默认是springCloudBus)。当一个服务刷新数据的时候,它会把这个信息放入到Topic中,这样其它监听同一Topic的服务就能得到通知,然后去更新自身的配置

(类似于公众号订阅发布)

image-20220102150746719

步骤

  • 客户端和服务端分别添加消息总线依赖

    <!--添加消息总线RabbitMQ支持-->
    <dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-bus-amqp</artifactId>
    </dependency>
  • yml 中配置RabbitMq的连接消息

    #rabbitmq相关配置 15672是Web管理界面的端口;5672是MQ访问的端口
    rabbitmq:
    host: 106.14.154.114
    port: 5672
    username: admin
    password: 123456
  • 服务端暴露刷新端口

    ##rabbitmq相关配置,暴露bus刷新配置的端点
    management:
    endpoints: #暴露bus刷新配置的端点
    web:
    exposure:
    include: "bus-refresh"
  • 发送刷新请求 即发送消息到各个消费者

image-20220102151743036

定点刷新

image-20220102152021544