一文带你吃透 Spring Cloud 相关微服务组件及 Spring Cloud Config 框架
当应用程序通过部署管道从开发到测试并进入生产时，SpringCloud Config 可以管理这些环境之间的配置，并确保应用程序具有迁移时需要运行的所有内容。服务器存储后端的默认实现使用 git，因此它可以轻松支持配置环境的标记版本，以及可用于管理内容的各种工具，当然也可以很容易地替换 git 的实现，具体运行原理如图 3.1 所示。
下面来看看具体是如何使用 Spring Cloud Config 的 Server 和 Client 的。
1. Spring Cloud Config Server
首先，可以去 SpringInitializr 的网站（ https://start.spring.io/） 初始化我们的代码库，在 Dependencies 中添加 Config Server，下面还是以 Gradle 为例，生成的配置如下。
其实需要引入
spring-cloud-config-server 这个依赖，然后在对应的 Spring Boot 的启动类上增加 @EnableConfigServer 注解，代码如下。
之前提到过，Spring Cloud Config 其实默认是使用的 git 作为配置文件的存储的，那么这里还需要配置 Git 仓库的地址、用户名密码等相关信息，所以在 application.yml 中添加如下配置。
当然，可以把配置中心作为一个 Eureka Client 注册到我们的注册中心，添加配置代码如下。
最后，可能配置信息会有些敏感，不希望公开访问，最简单的方式是集成 Spring Security，Spring Cloud 提供对应的 Security 的 starter 版本，这里可以引入
spring-cloud-starter-security 的依赖库，在 build.gradle 中添加如下依赖配置。
然后，在 application.yml 文件中添加安全的配置，代码如下。
这时，有关 Spring Cloud Config Server 的配置就基本完成了。在服务正常启动后，即可通过 Spring Cloud Config Client 从 git 中读取配置信息了，如果此时 Git 仓库已经有了一些配置，那么可以通过 HTTP 的请求来认证是否配置成功，请求的规则如下。
假设我们现在要对项目的测试环境编写配置文件，在指定的 GitHub 地 址 中 的 chapter 3/config-resources 目 录 下 添加 application-name-test.yml 文 件 （ 在客户端不指定 spring.profile.active 时会默认读取 application-name.yml 的配置，和本地配置文件规则一致），内容如下。
然后在浏览器访问 URL:?
http://localhost:64949/applicationname/default（64949 是因为配置了 port 是 0 而产生的随机端口号地址），如果配置了 Spring Security，那么在浏览器中还需要输入用户名与密码，最后得到如下结果就证明 Config Server 配置成功了。
那么，在客户端如何与配置中心集成呢？Spring Cloud Config 也提供了友好的客户端支持，不需要我们写任何代码，即可像读取本地配置一样读取配置中心的配置，下面来了解一下 Spring Cloud Config Client 的用法。
2. Spring Cloud Config Client
首先，我们在想要集成配置中心的项目中引入 Spring CloudConfig Client 的依赖包“
spring-cloud-starter-config”，然后需要在本地配置注册中心的信息。build.gradle 需要引入依赖包如下。
因为需要先加载配置中心的信息，然后才能读取项目所需的配置信息，所以一般把 Spring Cloud Config 的配置写在 bootstrap.yml 文件中，bootstrap.yml 文件的配置会先于 application.yml 加载。
当然，如果配置中心集成了 Eureka，那么注册中心的配置也需要挪到 bootstrap.yml 文件中，具体的配置如下。
由上面的配置信息可以看到，因为是集成的注册中心，所以不需要关心配置中心具体的服务地址和端口，只需写上相应配置中心的应用名即可。由于在服务端加了安全组件，这里还需要配置正确的用户名和密码，然后就可以像读取本地配置一样获取配置中心的配置了，具体配置如下。
集成消息总线
======
在上述配置完成后，我们在微服务架构中所需的关于配置信息管理的大部分功能似乎已被满足，但项目中的场景往往没有这么简单，在有的项目中，配置信息还需要动态获取。若项目要求每次修改配置不重启服务器，则使用 Spring Cloud Config 应该怎么做？
一般的做法是把这些配置信息加到数据库中，通过数据库来存储和读取这些信息，只要数据库的数据发生变化，不需要重启服务器就能直接查询到最新的配置。但 Spring Cloud Config 使用 git 作为存储，这种方式可以满足动态获取配置的需求吗？答案是可以的，而且 Spring Cloud Config 做到的不只是可以动态获取，就连更新内存中的配置都不需要多写一行代码，在检测到配置发生变化时，Spring Cloud Config 就能自动完成配置信息的更新，这是如何做到的呢？
Spring Cloud Config 是通过集成了 Spring Cloud Bus（消息总线）框架完成的这个功能，也就是说，当 Spring Cloud Config 的服务端检测到配置发生变化时，通过消息机制通知其他的客户端。这里不介绍 Spring Cloud Bus 的全部功能，只了解一下 Spring Cloud Bus 和 Spring Cloud Config 是如何配合工作的。
首先，我们知道 Spring Cloud Bus 并不是消息中间件，本身并不具备消息中间件的能力，只不过是集成了第三方的消息中间件，Spring Cloud Bus 提 供 了 两 个 消 息 中 间 件 的 starter 、AMQP（RabbitMQ）和 Kafka。这里选择 RabbitMQ 作为我们的消息中间件，假设已经成功启动 RabbitMQ，具体方法可以参考 RabbitMQ 的官网，有 Docker 环境的可以通过以下指令快速启动 RabbitMQ。
其次，我们在之前 Spring Cloud Config 的 Client 端中引入新的包：spring-cloud-starter bus-amqp。build.gradle 中的配置如下。
再次，在 application.yml 中添加关于 RabbitMQ 的配置，具体如下。
最后，需要引入 actuator 框架 ，提供配置刷新的入口 ，build.gradle 中依赖如下。
并且在 application.yml 中开启 actuator 的端点（Endpoint），内容如下。
可以访问
http://localhost:port/actuator 查询所有的端点，在集成消息总线后，refresh 的端点地址为/actuator/bus-refresh，我们可以通过 POST 请求该地址主动刷新配置，通过 @RefreshScope 注解可以指定配置刷新的范围，具体代码如下。
还未添加个人签名 2021.03.18 加入
还未添加个人简介
评论