「SpringCloud」08 Config分布式配置中心

SpringCloud—Config分布式配置中心

笔记整理自【尚硅谷】周阳SpringCloud框架开发教程

1. 概述

Ⅰ. 分布式系统面临的—配置问题

• 我们的模块越来越多，每个模块都要写一个application.yml。 我们想象这样一种情况： 10个微服务都要连接同一个数据库，我们在这10个微服务都配置了连接数据库yml。 当这个数据库发生了变化，怎么办？ 修改10个yml。 如果是100个微服务都连接这个数据库呢？ 东西多了，就需要统一管理。
• 上线后，发布版本了。有生产环境，有测试环境，预发布版本环境。 那么就是3套的配置的管理系统和业务要求，一个配置文件不能同时满足三种环境。
• 集中式的管理这些配置。微服务意味着要将单体应用中的业务拆分成一个个子服务，每个服务的粒度相对较小，因此系统中会出现大量的服务。 由于每个服务都需要必要的配置信息才能运行，所以一套集中式，动态的配置管理设施是必不可少的。 我们每个微服务自己带着一个application.yml，上百个配置文件的管理…o(╥﹏╥)o
• SpringCloud提供了ConfigServer来解决这个问题。

Ⅱ. Config是什么

官网

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

Ⅲ. Config怎么用

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

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

客户端则是通过指定的配置中心来管理应用资源，以及与业务相关的配置内容，并在启动的时候从配置中心获取和加载配置信息。

配置服务器默认采用git来存储配置信息，这样就有助于对环境配置进行版本管理，并且可以通过git客户端工具来方便的管理和访问配置内容。

Ⅳ. Config能做什么

• 集中管理配置文件
• 不同环境不同配置，动态化的配置更新，分环境部署比如 dev/test/prod/beta/release
• 运行期间动态调整配置，不再需要在每个服务部署的机器上编写配置文件，服务回想配置中心统一拉取配置自己的信息。
• 当配置发生变动时，服务不需要重启即可感知到配置的变化并应用新的配置。
• 将配置信息以Rest接口的形式暴露。

与GitHub整合配置

由于SpringCloud Config默认使用Git来存储配置文件（也有其它方式，比如支持SVN和本地文件），但最推荐的还是Git，而且使用的是 http/https 访问的形式。

2. Config服务端配置与测试

Ⅰ. GitHub配置

• 用你自己的账号在GitHub上新建一个名为springcloud-config的新Repository

  Repository中创建的文件，可以从周阳老师的github仓库克隆一份：

  

• 本地硬盘目录上新建git仓库并clone

  git clone https://github.com/chengchengzi666/springcloud-config.git
  

  

• 此时在本地D盘符下D:\44\SpringCloud2020\springcloud-config

  

  表示多个环境的配置文件

  保存格式必须为UTF-8

  如果需要修改，此处模拟运维人员操作git和github

  git add
  git commit -m "init yml"
  git push origin master
  

Ⅱ. 代码实现

• 建Module

  cloud-config-center-3344

  它即为Cloud的配置中心模块cloudConfig Center

• 改POM

  <dependency>
  	<groupId>org.springframework.cloudgroupId>
  	<artifactId>spring-cloud-config-serverartifactId>
  dependency>
  

  

• 写YML

  server:
    port: 3344
  
  spring:
    application:
      name:  cloud-config-center #注册进Eureka服务器的微服务名
    cloud:
      config:
        server:
          git:
            uri: https://github.com/chengchengzi666/springcloud-config.git #GitHub上面的git仓库名字
            #搜索目录
            search-paths:
              - springcloud-config
            username: chengchengzi666
            password: xxx
            skip-ssl-validation: true
        #读取分支
        label: main #以前是master
  
  #服务注册到eureka地址
  eureka:
    client:
      service-url:
        defaultZone: http://localhost:7001/eureka
  

  uri地址如果用https则需要配置username和password

  uri就是我们远程仓库的地址，search-paths表示远程仓库下有一个叫做springcloud-config的，label则表示读取master分支里面的内容（2020-10月开始master分支变为main分支）

  再加上skip-ssl-validation: true 跳过SSL验证

  新建的github分支已经默认为main，所以此处需指定label: main

  应该就可以解决所有Bug了。

• 主启动

  @EnableConfigServer

  

• windows下修改hosts文件，增加映射

  127.0.0.1 config-3344.com
  

• 测试通过Config微服务是否可以从GitHub上获取配置内容

  启动微服务3344

  http://config-3344.com:3344/main/config-dev.yml

  

Ⅲ. 配置读取规则

官网上有五种：

我们这里只讲常用的三种，其实都差不多。

1️⃣ /{label}/{application}-{profile}.yml

• 最推荐，格式很清晰

2️⃣ /{application}-{profile}.yml

• 默认去main (master) 分支找，所以这里不写分支。

3️⃣ /{application}/{profile}[/{label}]

• 逆写法

• 得到的结果是Json字符串：

总结

        /{name}-{profiles}.yml
 
/{label}-{name}-{profiles}.yml

label: 分支(branch)
name:  服务名
profiles: 环境(dev/test/prod)

成功实现了用SpringCloud Config通过GitHub获取配置信息。

3. Config客户端配置与测试

• 建Module

  cloud-config-client-3355

• 改POM

  <dependency>
  	<groupId>org.springframework.cloudgroupId>
  	<artifactId>spring-cloud-starter-configartifactId>
  dependency>
  

  

• 写YML

  bootstrap.yml

  ➢ 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。

  

  说明

  

  此时的master也要换成main。

• 主启动

  

• 业务类

  

• 测试

  ➢ 启动Config配置中心3344微服务并自测

  http://config-3344.com:3344/main/config-dev.yml

  ➢ 启动3355作为Client准备访问（这里启动3355可能会遇到坑 参考）

  http://localhost:3355/configInfo

  

  成功实现了客户端3355访问SpringCloud Config3344通过GitHub获取配置信息。

• 问题随时而来，分布式配置的动态刷新问题

  Linux运维修改GitHub上的配置文件内容做调整

  修改config-dev.yml配置并提交到GitHub中，比如加个变量age或者版本号version，这里把version改成 $2$

  ➢ 刷新3344，发现ConfigServer配置中心立刻响应

  

  ➢ 刷新3355，发现ConfigClient客户端没有任何响应

  

  ➢ 3355没有变化除非自己重启或者重新加载

  

  难道每次运维修改配置文件，客户端都需要重启？？噩梦

4. Config客户端之动态刷新

避免每次更新配置都要重启客户端微服务3355。

动态刷新（手动）

• 修改3355模块

• POM引入actuator监控

  之前已引入

  <dependency>
      <groupId>org.springframework.bootgroupId>
      <artifactId>spring-boot-starter-actuatorartifactId>
  dependency>
  

• 修改YML，暴露监控端口

  

• 业务类Controller修改

  @RefreshScope

  

• 此时修改github => 3344 =>3355

  ➢ http://localhost:3355/configInfo

  ➢ 3355改变没有？没有，/(ㄒoㄒ)/~~

  ➢ 为什么？需要运维人员发送Post请求刷新3355 必须是POST请求

  curl -X POST "http://localhost:3355/actuator/refresh"
  

  

• 再测试

  http://localhost:3355/configInfo

  OK，O(∩_∩)O

  成功实现了客户端3355刷新到最新配置内容。避免了服务重启。

• 想想还有什么问题？

  假如有多个微服务客户端3355/3366/3377…

  每个微服务都要执行一次post请求，手动刷新？

  可否广播，一次通知，处处生效？

  我们想大范围的自动刷新，怎么实现呢？

  所以引出下一章的内容：SpringCloud Bus——消息总线。