SpringCloud12-Config配置管理和Bus消息总线

最新推荐文章于 2023-06-14 09:28:14 发布

zdwhong

最新推荐文章于 2023-06-14 09:28:14 发布

阅读量245

点赞数

分类专栏： SpringCloud2.2.0 文章标签： Cloud Config Cloud Bus

本文链接：https://blog.csdn.net/zengdongwen/article/details/108148023

版权

SpringCloud2.2.0 专栏收录该内容

14 篇文章 2 订阅

订阅专栏

1、Spring Cloud Config

参考文章地址：https://www.cnblogs.com/jing99/p/11720834.html

1.1 概述

1.1.1 分布式系统面临的配置问题

在常规的开发中，每个微服务都包含代码和配置。其配置包含服务配置、各类开关和业务配置。如果系统结构中的微服务节点较少，那么常规的代码+配置的开发方式足以解决问题。当系统逐步迭代，其微服务会越来越复杂，慢慢演化成网状依赖结构，这个时候常规的代码+配置的开发方式就并不合适了，因为还要考虑整体系统的扩展性、伸缩性和耦合性等。这些问题中，配置的管理也是非常麻烦的。

如果还是以常规开发形式管理配置，则要承担反复修改编译代码、重启系统、重新打包等风险。所以，一个可以集中管理，带有版本控制的配置中心应运而生。

一般在一个比较大的分布式系统中，会存在很多的微服务，每个微服务都会有自己的配置文件application.yml(application.properties)，假设我们的多个微服务的很多配置都是相同的（比如使用的是同一个数据库），那么每个配置文件都要去配置一份。一旦这个配置修改了，那么就需要修改每个微服务的配置文件，同时需要重启各个微服务，这个工作量是比较大的。Spring Cloud Config就是来解决这个问题的。

Spring Cloud Config官网：https://cloud.spring.io/spring-cloud-static/spring-cloud-config/2.2.1.RELEASE/reference/html/

1.1.2 Spring Cloud Config是什么

spring cloud config就是一个配置中心。其采用集中式管理每个微服务的配置信息，并使用GIT等版本仓库统一存储配置内容，实现版本化管理控制。微服务与配置中心使用rest方式交互来实现可扩展的配置服务。

在这里插入图片描述

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

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

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

1.1.3 Spring Cloud Config作用

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

1.2 Config Server服务端

1.2.1 github环境准备

1 用自己的GitHub账号在GitHub上新建一个名为spring-cloud-config的新Repository

2 把刚才创建的git仓库克隆到本地：D:\Develop\idea\IntellijIDEA\IDEA20190301_WorkSpace\SpringCloud\zdw_cloud\sping-cloud-config

3 本地仓库sping-cloud-config中新建配置文件：application-dev.yml

spring:
  profiles:
    active:
      - dev
---
spring:
  profiles: dev     #开发环境
  application: 
    name: spring-cloud-config-dev
---
spring:
  profiles: test   #测试环境
  application: 
    name: spring-cloud-config-test
#  请保存为UTF-8格式

4 将上一步的application.yml文件推送到github远程仓库上

1.2.2 新建模块spring-cloud-config-3344

新建一个模块作为Cloud的配置中心模块，是Config的服务端

在这里插入图片描述

1、改pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <parent>
        <artifactId>springcloud2020</artifactId>
        <groupId>com.zdw.springcloud</groupId>
        <version>1.0-SNAPSHOT</version>
    </parent>
    <modelVersion>4.0.0</modelVersion>

    <artifactId>spring-cloud-config-3344</artifactId>

    <dependencies>
        <!--config server-->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-config-server</artifactId>
        </dependency>
        <!-- 添加消息总线RabbitMQ支持 -->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-bus-amqp</artifactId>
        </dependency>
        <!--引入自定义的公共包，回用到里面的实体-->
        <dependency>
            <groupId>com.zdw.springcloud</groupId>
            <artifactId>cloud-api-common</artifactId>
            <version>1.0-SNAPSHOT</version>
        </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>
        <!--eureka client-->
        <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>
    </dependencies>

</project>

2、application.yml

server:
  port: 3344

spring:
  application:
    name: spring-cloud-config
  cloud:
    config:
      server:
        git:
          #Github上的git仓库地址
          uri: https://github.com/zdwhong/spring-cloud-config.git
          #搜索目录.这个目录指的是github上的目录
          search-paths:
            - spring-cloud-config
      #读取分支
      label: master

eureka:
  client:
    service-url:
      defaultZone: http://eureka7001.com:7001/eureka/

3、主启动类

package com.zdw.springcloud;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.config.server.EnableConfigServer;

/**
 * @author ZDW
 * @create 2020-08-20 15:41
 */
@SpringBootApplication
@EnableConfigServer
public class CloudConfigMain3344 {
    public static void main(String[] args) {
        SpringApplication.run(CloudConfigMain3344.class,args);
    }
}

@EnableConfigServer - 开启配置中心，代表当前应用是一个配置中心服务端。
应用会根据全局配置文件访问GIT远程仓库，并将远程仓库中的配置内容下载到本地。

4、测试

启动7001和3344服务，浏览器访问：http://localhost:3344/master/application-dev.yml，可以看到内容如下：

spring:
  application:
    name: spring-cloud-config-dev
  profiles:
    active:
    - dev

5、配置读取规则

浏览器测试配置文件内容获取，从config server中获取配置文件有固定的访问方式。其格式为：

http://config-server-ip:port/applicationName/profile[/label]

config-server-ip - 配置中心服务端IP
applicationName - 服务应用名，代表的是配置中心客户端服务命名，就是真正的服务应用中的spring.application.name值。也是配置文件的核心命名。
profile - 环境命名，代表的是配置中心客户端使用的具体环境，和之前课程中的多环境内容一致。也是配置文件的核心命名。根据applicationName和profile的含义，决定了GIT仓库中保存的配置文件命名是有要求的，配置文件命名要求是：applicationName[-profile].properties | applicationName[-profile].yml。提供固定的命名规则是用于配置中心客户端和服务端友好交互定义的。
label - 是GIT中的分支命名，默认为master，即主干。如果不是主干分支，必须提供分支命名。

如：分支名称是abc，applicationName是testApp，环境是dev，那么请求路径是：http://config-server-ip:port/testApp/dev/abc

从浏览器获取的配置文件内容结果是JSON格式的字符串。内容大致如下：

{
  "name":"spring-cloud-config-client", // 服务名称
  "profiles":["dev"], // 环境名称
  "label":null, // 分支名称，默认为master
  "version":"a600c404267f5341933ce02b3f62672ce5791b16", // 版本，由spring-cloud-config-server生成管理
  "state":null,
  // 配置具体内容，从spring-cloud-config-server中获取的配置一定包含default配置内容。  // 如:获取环境配置文件路径为http://config-server-ip:port/spring-cloud-config-client/dev，  // 那么不仅会返回master分支的spring-cloud-config-client-dev.properties配置文件内容，还会返回master分支的spring-cloud-config-client.properties配置内容。
  "propertySources":[ 
    {
      "name":"https://gitee.com/kerwin_kim/test/spring-cloud-config-client-dev.properties", // 配置文件名，也是配置文件的远程GIT访问URL
      "source": // 配置文件内容
        {
      "test.config.db.url":"jdbc:oracle:thin@localhost:1521:xe",
      "test.config.db.password":"oracle-password",
      "test.config.db.driver-class-name":"oracle.jdbc.driver.OracleDriver",
      "test.config.db.username":"oracle"
    }
    },
    {　　//此处即为默认配置文件spring-cloud-config-client.properties
      "name":"https://gitee.com/kerwin_kim/test/spring-cloud-config-client.properties",
      "source":
        {
      "test.config.db.url":"jdbc:mysql://localhost:3306/test",
      "test.config.db.password":"mysql-password",
      "test.config.db.driver-class-name":"com.mysql.jdbc.Driver",
      "test.config.db.username":"mysql"
    }
    }
  ]
}

1.3 Config Client客户端

新建模块spring-cloud-config-client3355，作为Config Client客户端

在这里插入图片描述

1.3.1 pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <parent>
        <artifactId>springcloud2020</artifactId>
        <groupId>com.zdw.springcloud</groupId>
        <version>1.0-SNAPSHOT</version>
    </parent>
    <modelVersion>4.0.0</modelVersion>

    <artifactId>spring-cloud-config-client3355</artifactId>

    <dependencies>
        <!-- 添加消息总线RabbitMQ支持 -->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-bus-amqp</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-config</artifactId>
        </dependency>
        <!--引入自定义的公共包，回用到里面的实体-->
        <dependency>
            <groupId>com.zdw.springcloud</groupId>
            <artifactId>cloud-api-common</artifactId>
            <version>1.0-SNAPSHOT</version>
        </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>
        <!--eureka client-->
        <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>
    </dependencies>

</project>

1.3.2 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配置的分离。

server:
  port: 3355

spring:
  application:
    name: cloud-config-client
  cloud:
    #Config客户端配置
    config:
      label: master #分支名称
      name: application #配置文件名称
      profile: dev #读取后缀名称 上诉3个综合就是 master分支上 application-dev.yml
      #本微服务启动后先去找3344号服务，通过SpringCloudConfig获取GitHub的服务地址
      uri: http://localhost:3344

eureka:
  client:
    service-url:
      defaultZone: http://eureka7001.com:7001/eureka/

1.3.3 主启动类

package com.zdw.springcloud;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.eureka.EnableEurekaClient;

/**
 * @author ZDW
 * @create 2020-08-20 16:41
 */
@SpringBootApplication
@EnableEurekaClient
public class ConfigClientMain3355 {
    public static void main(String[] args) {
        SpringApplication.run(ConfigClientMain3355.class,args);
    }
}

1.3.4 新建rest类，验证是否能从GitHub上读取配置

package com.zdw.springcloud.controller;

import org.springframework.beans.factory.annotation.Value;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class ConfigClientController {

    // 因为config仓库以rest形式暴露，所以所有客户端都可以通过config服务端访问到github上对应的文件信息
    @Value("${spring.application.name}")
    private String applicationName;

    @GetMapping("/applicationName")
    public String getConfigInfo() {
        return "applicationName: " + applicationName ;
    }
}

1.3.5 测试

启动7001，3344 和刚创建的3355服务

测试3344是否正常：http://localhost:3344/master/application-dev.yml

测试3355是否可以从3344上获取到信息：http://localhost:3355/applicationName

以上都能正确访问到内容

1.3.6 无法动态刷新问题

上面的测试是成功的，但是如果此时修改github仓库里面的内容，不重启服务，3344和3355能访问到修改后的内容吗？

经测试发现：3344可以立马访问到新内容，但是3355访问的内容还是修改之前的。只有重启只后才能访问到新内容。

1.3.7 客户端手动动态刷新

要想3355可以动态的获取git上修改的内容，3355工程需要进行如下修改：

1、pom添加下面的依赖

POM引入actuator监控

<!--监控-->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

2、bootstrap.yml添加下面的配置

修改YML,暴露监控端口

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

这个配置是顶格写的

3、业务类添加注解@RefreshScope

package com.zdw.springcloud.controller;

import org.springframework.beans.factory.annotation.Value;
import org.springframework.cloud.context.config.annotation.RefreshScope;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
@RefreshScope
public class ConfigClientController {

    // 因为config仓库以rest形式暴露，所以所有客户端都可以通过config服务端访问到github上对应的文件信息
    @Value("${spring.application.name}")
    private String applicationName;

    @GetMapping("/applicationName")
    public String getConfigInfo() {
        return "applicationName: " + applicationName ;
    }
}

4、需要手动刷新

需要运维人员发送POST请求刷新3355，必须是post请求

执行命令：curl -X POST “http://localhost:3355/actuator/refresh”

然后再次访问3355，成功实现了客户端3355刷新到最新配置内容

但是这种方式不好，如果我们有100个微服务都要刷新，那么就要执行100次这个命令吗？可否通过广播机制，进行自动刷新呢？下面要讲的就是通过消息总线Bus来实现这个需求。

2、Spring Cloud Bus

2.1 概述

分布式自动刷新配置功能需要使用到Spring Cloud Bus，他和Spring Cloud Config基本是一起捆绑使用的，Spring Cloud Bus配合Spring Cloud Config使用可以实现配置的动态刷新；

2.1.1 Spring Cloud Bus是什么

Spring Cloud Bus是用来将分布式系统的节点与轻量级消息系统连接起来的框架；它整合了Java的事件处理机制和消息中间件的功能；目前支持的消息中间件有：RabbitMQ和Kafka俩种。

Spring Cloud Bus能管理和传播分布式系统间的消息，就像一个分布式执行器，可用于广播状态更改，事件推送，也可以当作微服务间的通信通道。

2.1.2 为何称Spring Cloud Bus为消息总线

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

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

2.1.3 两种设计思想

1、由一个客户端通知其他客户端

这种设计不太好，因为客户端本来是负责接收消息的，不应该让它承担发送消息的责任，而且一旦它自身宕机了，那么它也就无法履行责任；

打破了微服务的职责单一性,因为微服务本身是业务模块,它本不应该承担配置刷新的职责
打破了微服务各节点的对等性
有一定的局限性.例如,微服务在迁移时，它的网络地址常常会发生变化，此时如果想要做自动刷新，那就会增加更多的修改。

从下面两个差不多的两个图可以理解下：

在这里插入图片描述

2、由Config Server通知客户端

由服务端来发布消息给各个客户端，这个是比较可行的，服务端本来应该承担的责任就是这个嘛

在这里插入图片描述

2.2 RabbitMQ的下载安装

2.2.1 下载和安装

RabbitMQ需要Erlang环境，所以需要先安装Erlang语言的

Erlang下载：https://www.erlang-solutions.com/resources/download.html
rabbitmq下载：https://www.rabbitmq.com/install-windows.html

我这里安装的RabbitMQ是3.8.7，要求的Erlang最低是21.x，我这里安装的是erlang_23.0

具体的下载和安装操作不多说了，百度即可。

2.2.2 启动RabbitMQ管理功能

进入安装目录的sbin下面：D:\OtherSoft\RabbitMQ\RabbitMQ Server\rabbitmq_server-3.8.7\sbin

执行cmd命令：rabbitmq-plugins enable rabbitmq_management

在这里插入图片描述

2.2.3 启动RabbitMQ并访问

在开始菜单中找到：

在这里插入图片描述

单击就能启动，启动成功之后，浏览器访问：http://localhost:15672/ 能看到登录界面就是成功的，默认的用户名和密码是：guest/guest

2.3 SpringCloud Bus动态刷新

2.3.1 新建模块3366

参照3355新建一个一样的模块3366，具体省略

业务类加入了端口：

package com.zdw.springcloud.controller;

import org.springframework.beans.factory.annotation.Value;
import org.springframework.cloud.context.config.annotation.RefreshScope;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
@RefreshScope
public class ConfigClientController {

    // 因为config仓库以rest形式暴露，所以所有客户端都可以通过config服务端访问到github上对应的文件信息
    @Value("${spring.application.name}")
    private String applicationName;

    @Value("${server.port}")
    private String serverPort;

    @GetMapping("/applicationName")
    public String getConfigInfo() {
        return "applicationName: " + applicationName +"serverPort: "+serverPort ;
    }
}

2.3.2 修改3344模块

1、pom添加bus依赖

<!-- 添加消息总线RabbitMQ支持 -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-bus-amqp</artifactId>
</dependency>

在之前的操作中，已经添加了该依赖，这里是着重强调一下

2、application.yml修改

加上RabbitMQ的配置和暴露 bus刷新配置的端点，完整的配置文件如下：

server:
  port: 3344

spring:
  application:
    name: spring-cloud-config
  cloud:
    config:
      server:
        git:
          #Github上的git仓库地址
          uri: https://github.com/zdwhong/spring-cloud-config.git
          #搜索目录.这个目录指的是github上的目录
          search-paths:
            - spring-cloud-config
      #读取分支
      label: master
  #rabbit相关配置 15672是web管理界面的端口，5672是MQ访问的端口，它要和cloud对齐，属于spring下面的配置
  rabbitmq:
    host: localhost
    port: 5672
    username: guest
    password: guest

eureka:
  client:
    service-url:
      defaultZone: http://eureka7001.com:7001/eureka/
#rabbitmq相关设置 ，暴露 bus刷新配置的端点
management:
  endpoints:
    web:
      exposure:
        include: 'bus-refresh'

2.3.3 修改3355模块

1、pom添加依赖

<!-- 添加消息总线RabbitMQ支持 -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-bus-amqp</artifactId>
</dependency>

2、bootstrap.yml修改

加上RabbitMQ的配置和暴露 bus刷新配置的端点，完整的配置文件如下：

server:
  port: 3355

spring:
  application:
    name: cloud-config-client
  cloud:
    #Config客户端配置
    config:
      label: master #分支名称
      name: application #配置文件名称
      profile: dev #读取后缀名称 上诉3个综合就是 master分支上 application-dev.yml
      #本微服务启动后先去找3344号服务，通过SpringCloudConfig获取GitHub的服务地址
      uri: http://localhost:3344
  #rabbit相关配置 15672是web管理界面的端口，5672是MQ访问的端口，它要和cloud对齐，属于spring下面的配置
  rabbitmq:
    host: localhost
    port: 5672
    username: guest
    password: guest
eureka:
  client:
    service-url:
      defaultZone: http://eureka7001.com:7001/eureka/

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

2.3.4 修改3366模块

1、pom添加依赖

<!-- 添加消息总线RabbitMQ支持 -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-bus-amqp</artifactId>
</dependency>

2、bootstrap.yml修改

加上RabbitMQ的配置和暴露 bus刷新配置的端点，完整的配置文件如下：

server:
  port: 3366

spring:
  application:
    name: cloud-config-client
  cloud:
    #Config客户端配置
    config:
      label: master #分支名称
      name: application #配置文件名称
      profile: dev #读取后缀名称 上诉3个综合就是 master分支上 application-dev.yml
      #本微服务启动后先去找3344号服务，通过SpringCloudConfig获取GitHub的服务地址
      uri: http://localhost:3344
  #rabbit相关配置 15672是web管理界面的端口，5672是MQ访问的端口，它要和cloud对齐，属于spring下面的配置
  rabbitmq:
    host: localhost
    port: 5672
    username: guest
    password: guest
eureka:
  client:
    service-url:
      defaultZone: http://eureka7001.com:7001/eureka/

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

2.3.5 测试

启动7001，然启动3344，再启动3355和3366服务；

修改git仓库application.yml文件dev（profiles）的spring.application.name的值

浏览器访问：http://localhost:3344/master/application-dev.yml 测试3344是正常获取到修改之后的值

然后cmd窗口执行命令：curl -X POST “http://localhost:3344/actuator/bus-refresh” （执行之后需要等待一会）

然后浏览器访问：http://localhost:3355/applicationName 和 http://localhost:3366/applicationName 都能访问到修改之后的值

可以反复多测试几次。

2.3.6 定点通知某个微服务

在上面的测试中，3355和3366都会得到3344的消息，然后进行刷新，如果我们只想通知3355，而不想通知3366呢？

此时只有刷新的命令是不同的，在刷新的命令中指定只通知哪个，

公式：http://localhost:配置中心端口号/actuator/bus-refresh/{destination}

解释：/bus/refresh请求不再发送到具体的服务实例上，而是发给config server并通过destination参数类指定需要重新配置的服务或实例；

efaultZone: http://eureka7001.com:7001/eureka/

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




### 2.3.5 测试

启动7001，然启动3344，再启动3355和3366服务；

修改git仓库application.yml文件dev（profiles）的spring.application.name的值

浏览器访问：http://localhost:3344/master/application-dev.yml 测试3344是正常获取到修改之后的值

然后cmd窗口执行命令：curl -X POST "http://localhost:3344/actuator/bus-refresh"  （执行之后需要等待一会）

然后浏览器访问：http://localhost:3355/applicationName 和 http://localhost:3366/applicationName 都能访问到修改之后的值

可以反复多测试几次。



### 2.3.6 定点通知某个微服务

在上面的测试中，3355和3366都会得到3344的消息，然后进行刷新，如果我们只想通知3355，而不想通知3366呢？

此时只有刷新的命令是不同的，在刷新的命令中指定只通知哪个，

公式：http://localhost:配置中心端口号/actuator/bus-refresh/{destination}

解释：/bus/refresh请求不再发送到具体的服务实例上，而是发给config server并通过destination参数类指定需要重新配置的服务或实例；

所以我们在修改了git仓库的内容之后，执行命令：curl -X POST "http://localhost:3344/actuator/bus-refresh/cloud-config-client:3355" （cloud-config-client是3355的bootstrap.yml中配置的spring.application.name的值）

zdwhong

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
SpringCloud12-Config配置管理和Bus消息总线

1、Spring Cloud Config参考文章地址：https://www.cnblogs.com/jing99/p/11720834.html1.1 概述1.1.1 分布式系统面临的配置问题在常规的开发中，每个微服务都包含代码和配置。其配置包含服务配置、各类开关和业务配置。如果系统结构中的微服务节点较少，那么常规的代码+配置的开发方式足以解决问题。当系统逐步迭代，其微服务会越来越复杂，慢慢演化成网状依赖结构，这个时候常规的代码+配置的开发方式就并不合适了，因为还要考虑整体系统的扩展性、伸缩性和
复制链接

扫一扫