9.7（SpringCloud）Config

Config配置中心

为什么需要配置中心

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

SpringCloud提供了ConfigServer来解决这个问题，我们每一个微服务自己带着一个application.yml，上百个配置文件的管理…
/(ㄒoㄒ)/~~

大量的服务之间，可能存在相同的配置，避免修改的麻烦，使用一个Config进行统一管理

Config是什么

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

怎么玩

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

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

服务端搭建

首先服务端是需要进行GitHub中的连接，进行读取GitHub的内容。

我们有一个GitHub的访问路径，可以通过该路径进行远程拉去。

这里的GitHub中的文件可以写多个，指定的时候指定清楚即可。

文件放下目录下也可，在服务端进行指定。多个环境也可以写在一个配置文件中。

搭建新的服务

引入依赖

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

//这里config，当然也是需要，boot的web和注册中心等依赖的

编写启动类

@SpringBootApplication
@EnableConfigServer //表示了开启ConfigServer端
public class ConfigCenterMain3344
{
    public static void main(String[] args) {
            SpringApplication.run(ConfigCenterMain3344.class, args);
    }
}

编写yaml

server:
  port: 3344

spring:
  application:
    name:  cloud-config-center #注册进Eureka服务器的微服务名
  cloud:
    config:
      server:
        git:
          uri: git@github.com:zzyybs/springcloud-config.git #GitHub上面的git仓库名字  可以换成gitee进行操作
#          uri: https://gitee.com/si-liang-wang/config-test.git   #GitHub上面的git仓库地址


        ####搜索目录 gitee中存放想要访问的文件目录
          search-paths:
            - springcloud-config
      ####读取分支
      label: master

#服务注册到eureka地址
eureka:
  client:
    service-url:
      defaultZone: http://localhost:7001/eureka
 

服务端搭建完成之后就可以，启动服务，进行访问到GitHub上面的配置文件了

但是访问，存在5中规则，下面介绍3种规则

前缀是 ip+端口。下面的形式是将ip以别名的形式展示，修改ports文件

指定分支

默认分支为master，或者在服务端的label指定

如果访问不存在的就会返回 {} 空

分支最后

展示的效果是JSON形式，上面展示的就是yaml文件编写的内容

客户端的搭建

客户端通过连接服务端，不需要进行访问GitHub。得到GitHub上面的配置信息

引入依赖

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

主启动类

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

编写Bootstrap.yaml

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

#服务注册到eureka地址
eureka:
  client:
    service-url:
      defaultZone: http://localhost:7001/eureka

Bootstrap.yaml是什么

applicaiton.yml是用户级的资源配置项
bootstrap.yml是系统级的，优先级更加高

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

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

要将Client模块下的application.yml文件改为bootstrap.yml,这是很关键的，
因为bootstrap.yml是比application.yml先加载的。bootstrap.yml优先级高于application.yml

业务类测试

@RestController
public class ConfigClientController
{
    @Value("${config.info}")
    private String configInfo;

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

动态刷新问题

操作

在非配置微服务中进行配置

引入依赖

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
//进行监控，看一看需不需要改变等。这个监控很多地方都需要放置

bootstrap.yaml

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

添加业务类注解

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

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

端口服务的刷新

服务总线的出现

SpringCloudBus 配合SpringCloudConfig可以进行配置的动态刷新。不需要一个一个对应客户端进行发送 post请求刷新

Bus是什么

结合消息中间件。通过发送消息。其他服务进行订阅。从而进行异步的发送post请求。不需要我们手动的发送post请求

Bus支持两种消息代理RabbitMq和Kafka

所以下面会用到消息中间件

Bus的发送消息两种方式

将消息发送给一个客户端。从而进行客户端一一的操作传染

Bus发送消息给 Config服务端。从而进行将消息在分发给客户端

操作

这里以通过Config进行分发为主

1. 在Config服务端，进行引入Bus依赖。集成消息中间件。暴漏bus刷新端点
2. 在Config客户端，进行引入Bus依赖。集成消息中间件。等着接收Bus消息即可

对于定点通知和全局通知

定点通知语法

http://localhost:配置中心端口/actuator/bus-refresh/{指定要通知的服务名和端口}

全局通知就是，不去指定具体的即可