5.SpringCloud -- 配置中心 Config消息总线 Bus链路追踪 Sleuth配置中心 Nacos

Posted 爱是与世界平行

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了5.SpringCloud -- 配置中心 Config消息总线 Bus链路追踪 Sleuth配置中心 Nacos相关的知识,希望对你有一定的参考价值。

一、引入配置中心

1.1 问题 与 解决

【问题:】
    通过前面几篇博客介绍,完成了基本项目创建、服务注册中心、服务调用、负载均衡、服务降级 以及 服务熔断。    
    
    即 各个模块 已经能正常通信、共同对外提供服务了,且有了一定的容错能力。
    
    对于一个复杂的分布式系统来说,可能存在数十个模块,每个模块都有不同的配置信息。
    
    而这就带来了一个问题 -- 如何修改配置信息?
    
【如何修改配置信息:】

    一般修改配置信息后,都得重新启动一下服务以应用新的配置。
    
    在开发阶段,频繁修改配置信息、启动服务是很正常的,但是对于一个正在运行的系统,每次修改配置信息,都得重新启动一下服务,这期间的损失必然是很大的。
    
举个例子: 
    游戏中的停服维护,你玩某个游戏玩得正嗨,结果接到通知需停服 3 天进行维护,那岂不很蛋疼,瞬间失去了玩游戏的兴趣。
    
    对于一个复杂的分布式系统来说,可能存在数十个模块,若一个模块一个模块的进行 修改、重启服务,这将是一个非常繁琐、且易出错的工作。
    
    所以需要一款软件,用来 集中式的管理 配置信息、并实现动态修改配置信息。
    
【解决:】
    集中式管理配置信息、动态修改配置信息。
注:
    集中式管理,类似于 Eureka 服务注册中心进行理解,即可以在某个地方进行配置信息的处理(可以查看到所有的微服务的配置信息)。
    动态修改,即不需要重启微服务,修改后可以直接应用到正在运行的系统上。
    
相关技术:
    Config
    Nacos(推荐使用)

二、配置中心 – Config

2.1 Config 是什么?

(1)Config 是什么?

【Config:】
    SpringCloud Config 为分布式系统提供了集中式的外部配置支持。
    分为 服务器端(Config Server) 以及 客户端(Config Client)。
Config Server:
    服务端也称为 分布式配置中心,属于一个独立的 微服务应用。
    其用于连接配置服务器,并向客户端提供配置信息。
    即使用 Config Server 可以集中管理所有环境的配置信息,其默认使用 Git 实现集中化管理的功能。
注:
    使用 Git 管理配置信息,便于进行版本控制(可以使用 Git 客户端工具进行操作)。

Config Client:
    客户端绑定指定的服务端,从配置中心获取配置信息。

【官网地址:】
    https://spring.io/projects/spring-cloud-config
    https://docs.spring.io/spring-cloud-config/docs/current/reference/html/

(2)Config 功能

【功能:】
    集中式的管理配置文件。
    可以指定环境进行配置。比如:dev、test、prod、release 等。
    运行期间动态修改配置(在配置中心修改后,微服务从配置中心获取配置信息,微服务无需重启)。
    配置信息以 Rest 接口的形式对外暴露。

2.2 搭建配置中心(Config Server)

(1)建立一个 Git 仓库

Config Server 默认使用 Git 实现集中化管理配置信息,即 使用 Git 存储配置信息,
  所以需要建立一个 Git 仓库,用于存储配置信息。
如下:
  进入 码云 (或者 Github) 中,创建一个名为 SpringCloudConfig 的 Git 仓库。
  仓库地址为:https://gitee.com/lyh-man/spring-cloud-config.git

(2)新建一个子工程 config_server_9100,作为 Config Server

Step1:
  修改 父工程、当前工程 pom.xml 文件,并引入相关依赖。
  此处以 Eureka 作为服务注册中心,需要引入相关依赖。

【依赖:】
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-config-server</artifactId>
</dependency>

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>

Step2:
  修改配置文件。

【application.yml】
server:
  port: 9100
spring:
  application:
    name: config_server
  cloud:
    config:
      # 获取配置文件的分支,默认为 master
      label: master
      server:
        git:
          # git 仓库地址
          uri: https://gitee.com/lyh-man/spring-cloud-config.git
          # 配置文件搜索路径
          search-paths:
            - SpringCloudConfig

eureka:
  instance:
    appname: config_server # 优先级比 spring.application.name 高
    instance-id: ${eureka.instance.appname} # 设置当前实例 ID
  client:
    register-with-eureka: true # 默认为 true,注册到 注册中心
    fetch-registry: true # 默认为 true,从注册中心 获取 注册信息
    service-url:
      # 指向 注册中心 地址,也即 eureka_server_7000 的地址。
      defaultZone: http://localhost:7000/eureka

Step3:
  在 config_server_9100 启动类上添加 @EnableConfigServer 注解。

Step4:
  启动 eureka_server_7000 以及 config_server_9100。
  新增一个文件 config-dev.yml,并提交到 master 分支,内容如下:

【config-dev.yml:】
server:
  port: 9100
spring:
  application:
    name: config_server
  cloud:
    config:
      # 获取配置文件的分支,默认为 master
      label: master
      server:
        git:
          # git 仓库地址
          uri: https://gitee.com/lyh-man/spring-cloud-config.git
          # 配置文件搜索路径
          search-paths:
            - SpringCloudConfig

eureka:
  instance:
    appname: config_server # 优先级比 spring.application.name 高
    instance-id: ${eureka.instance.appname} # 设置当前实例 ID
  client:
    register-with-eureka: true # 默认为 true,注册到 注册中心
    fetch-registry: true # 默认为 true,从注册中心 获取 注册信息
    service-url:
      # 指向 注册中心 地址,也即 eureka_server_7000 的地址。
      defaultZone: http://localhost:7000/eureka

此时访问:http://localhost:9100/master/config-dev.yml,即可获取到 master 分支下的 config-dev.yml 文件内容。

2.3 获取 Git 中配置文件的常见 HTTP 格式

(1)格式说明

【三个参数:】
    label:        分支名
    application:  应用名(服务名)
    profile:      环境
注:
    提交到 Git 的配置文件名 一般由 application 与 profile 组成。
    其命名风格一般为: application-profile.yml 或者 application-profile.properties。
比如:
    config-dev.yml 、config-prod.yml 等。
    
【HTTP 格式:】
    /{label}/{application}-{profile}.yml   或者  /{label}/{application}-{profile}.properties    
    /{application}/{profile}/{label}
比如:
    /master/config-dev.yml
等价于
    /config/dev/master
注:
    master 可以省略,默认为 master,即 也等价于 /config-dev.yml

2.4 搭建客户端(Config Client)

(1)新建一个子工程 config_client_9200,作为 Config Client

Step1:
  修改 父工程、当前工程 pom.xml 文件,并引入相关依赖。
  此处以 Eureka 作为服务注册中心,需要引入相关依赖。

【依赖:】
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-config-server</artifactId>
</dependency>

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>

Step2:
  修改配置文件(bootstrap.yml)。

【注意:】
    Config Client 配置文件是 bootstrap.yml,而非 application.yml。
注:
    bootstrap.yml 优先级比 application.yml 高(即 bootstrap.yml 先加载)。
    Config Client 启动后,会根据 bootstrap.yml 配置的 Config Server 信息与 Config Server 进行绑定,
    从而获取到 Config Server 中存储在 Git 的配置信息。 
    
【bootstrap.yml】
server:
  port: 9200
spring:
  application:
    name: config_client
  cloud:
    # 绑定配置中心,即 http://localhost:9100/master/config-dev.yml
    config:
      # 分支名称
      label: master
      # 配置文件的名称
      name: config
      # 后缀名
      profile: dev
      # config server 配置中心地址
      uri: http://localhost:9100

eureka:
  instance:
    appname: config_client # 优先级比 spring.application.name 高
    instance-id: ${eureka.instance.appname} # 设置当前实例 ID
  client:
    register-with-eureka: true # 默认为 true,注册到 注册中心
    fetch-registry: true # 默认为 true,从注册中心 获取 注册信息
    service-url:
      # 指向 注册中心 地址,也即 eureka_server_7000 的地址。
      defaultZone: http://localhost:7000/eureka

Step3:
  编写 TestController 进行测试,
  其中使用 @Value 注解用于 引入 Git 中存储的配置文件中的内容。
注:
  初始启动服务时,若 config client 绑定 config server 失败,即获取不到 Git 中的配置信息时,@Value 将会导致服务启动失败。

TestControllerpackage com.lyh.springcloud.config_client_9200.controller;

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

@RestController
@RequestMapping("/config")
public class TestController {

    @Value("${config.info}")
    private String info;

    @GetMapping("/getInfo")
    public String getInfoAndMessage() {
        String result = "";
        if (info != null) {
            return "success " + info + "\\n";
        }
        return "error";
    }
}

Step4:
  修改 Git 仓库中 config-dev.yml 文件如下:

【config-dev.yml:】
config:
  info: helloworld!!!

Step5:
  测试。启动 eureka_server_7000、config_server_9100、config_client_9200。
  前面 bootstrap.yml 配置的是 获取 http://localhost:9100/master/config-dev.yml 中的内容。
  config client 成功启动后,即可获取 config-dev.yml 内容,从而 @Value 注入成功,成功返回。
注:
  若 config client 启动时,可能由于 @Value 注入失败,从而导致 服务将启动失败。
可能原因:
  config server 配置错误,config client 不能正常绑定 config server。
  config server 正常,但是 config-dev.yml 文件不存在。
  config-dev.yml 文件存在,但其中并不存在 config.info。

2.5 存在的问题(刷新问题)

(1)问题

【问题:】
    通过上面 config server 以及 config client 搭建,
    config client 已经能成功通过 config server 获取到 Git 存储的配置信息。
但是存在一个问题:
    在 config client 以及 config server 服务均启动后,再去修改 Git 中的配置文件,
    此时会发现 config server 能正常获取最新的 配置信息,但是 config client 获取的仍是原来的值。
    只有重启 config client 服务后才能正常获取到最新的配置信息。
    重启肯定是不可取的方案,那么如何解决呢?

【解决方案一:】
    引入 actuator,借助其进行刷新,重新加载。
缺点:
    需要手动触发 POST 请求,访问 refresh 端口(http://localhost:9200/actuator/refresh)。
    当然可以写个脚本,定时发送请求,进行刷新。

【解决方案二:】
    方案一对于每个微服务可能都需要执行一次或多次 POST 请求,用于刷新配置信息。
    实现起来还是有点麻烦的,
    那么是否存在一种机制,使其一次通知,处处生效?
    这里就需要使用一下消息总线 SpringCloud Bus(后续介绍,此处暂时略过)。

(2)解决方案一(使用 actuator):

Step1:
  引入 actuator 依赖。

【依赖:】
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

Step2:
  配置暴露端口,主要是 refresh,其余的随意(可以直接用 * 表示所有)。

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

Step3:
  在 TestController 上添加 @RefreshScope 注解。

@RestController
@RequestMapping("/config")
@RefreshScope
public class TestController {

    @Value("${config.info}")
    private String info;

    @GetMapping("/getInfo")
    public String getInfoAndMessage() {
        String result = "";
        if (info != null) {
            return "success " + info + "\\n";
        }
        return "error";
    }
}

Step4:
  重新启动 config client,此时获取到的是最新的配置信息。

再次修改 config-dev.yml 内容如下:

config:
  info: refresh

此时 config server 访问到的是最新的配置信息

但 config client 获取的仍为上一次的配置信息

使用 Postman 发送 POST 请求 http://localhost:9200/actuator/refresh 后,
config client 再次获取的为最新的配置信息。

三、引入消息总线

3.1 问题与解决

【问题:】
前面使用 Spring Cloud Config 作为配置中心时,留了一个坑:
    更新 Git 存储的配置文件后, Config Client 并不能实时的获取到最新的配置, 
    Config Client 需要重启服务 或者 借助 actuator 刷新配置,从而获取到最新的配置文件信息。
    
而微服务中,Config Client 数量将会越来越多,若每个 Config Client 都需要重启 或者 发送 refresh 请求,其伴随的影响还是有一些的。
那么能否实现自动刷新? 即修改完 Git 的配置文件后,Config Client 自动刷新获取最新的配置。

【解决:】
    使用 Spring Cloud Bus 配合 Spring Cloud Config 可以实现配置的 自动刷新功能。

四、消息总线 – Bus

4.1 Bus 是什么?

(1)Bus 是什么?

【Spring Cloud Bus 是什么:】
    Spring Cloud Bus 是将 轻量级消息系统 链接到 分布式系统节点 的框架,整合了 事件处理机制 和 消息中间件的功能。
    其能 管理、传播 需要在分布式系统中传递的消息,可用于 广播状态变化(比如: 配置修改)、事件推送等,也可以作为微服务应用间的通信通道。

【Bus 支持的 消息系统:】
    Spring Cloud Bus 目前支持两种消息系统: RabbitMQ 和 Kafka。
    使用时需要引入对应的依赖: spring-cloud-starter-bus-amqp 或 spring-cloud-starter-bus-kafka。

【理解一下消息总线:】
    消息总线 可以理解为 一个消息中心(RabbitMQ、Kafka),系统中所有微服务实例 连接到 总线上,
    微服务实例可以向消息中心发送消息 或者 接收消息(监听消息中心的消息),
   消息中心 产生的消息被 所有微服务实例 监听并消费。
比如:
    微服务实例 A 发送一条消息到总线上,其余微服务实例 可以监听到 这个消息,并进行相应处理。
 
【官网地址:】
https://spring.io/projects/spring-cloud-bus
https://docs.spring.io/spring-cloud-bus/docs/current/reference/html/

(2)如何实现?

方式一:
  客户端 Config Client 刷新。

【基本流程:】
Step1:
    更新 Git Repository 中的配置文件。
    
Step2:
    向客户端 Config Client C 发送 POST 请求: /actuator/busrefresh,
    此时 Config Client C 根据 Config Server 获取最新的配置文件。
    并且 Config Client C 向 消息总线 Bus 发送一条消息(即 表示需要 刷新)。

Step3:
    Bus 接收消息后,将消息通知给其他 客户端实例(Config Client A、Config Client B)。
    
Step4:
    其他客户端实例 接收到信息后,即相当于刷新,根据 Config Server 获取最新的配置文件。

至此,所有客户端实例均可获得最新的配置信息。

【问题:】
    一般不使用 客户端刷新, 因为 客户端本身属于 业务模块,刷新功能并不属于其业务功能,会破坏了其职责单一性。

方式二:
  服务端 Config Server 刷新。

【基本流程:】
Step1:
    更新 Git Repository 中的配置文件。
    
Step2:
    向服务端 Config Server 发送 POST 请求: /actuator/busrefresh,
    并且 Config Server 向 消息总线 Bus 发送一条消息(即 表示需要 刷新)。

Step3:
    Bus 接收消息后,将消息通知给所有客户端实例(Config Client A、Config Client B、Config Client C)。
    
Step4:
    客户端实例 接收到信息后,即相当于刷新,根据 Config Server 获取最新的配置文件。

至此,所有客户端实例均可获得最新的配置信息。

4.2 使用 RabbitMQ 作为消息中间件

(1)使用 docker-compose 在 CentOS7 上构建基本环境
  docker-compose 基本使用可参照:https://www.cnblogs.com/l-y-h/p/12622730.html#_label8_2

【构建 docker-compose.yml 如下:】
# 指定 compose 文件版本,与 docker 兼容,高版本的 docker 一般使用 3.x。
version: '3.7'
# 定义需要管理的 所有服务 信息
services:
  # 此处指的是服务的名称
  rabbitmq:
    # 指定镜像路径(可以是远程仓库镜像 或者 本地镜像)
    image: rabbitmq:3.8.3-management
    # 指定容器的名称(等同于 docker run --name)
    container_name: rabbitmq
    # 定义容器重启策略,no 表示任何情况下都不重启(默认),always 表示总是重新启动。
    restart: always
    hostname: myRabbitmq
    # 定义 宿主机 与 容器的端口映射
    ports:
      - 15672:15672
      - 5672:5672
    # 定义 宿主机 与 容器的数据卷映射
    volumes:
      - /usr/mydata/rabbitmq/data:/var/lib/rabbitmq
    # 设置环境变量
    environment:
      # 设置 RabbitMQ 登陆用户为 root,登陆密码为 root(若未配置,默认为 guest)
      - RABBITMQ_DEFAULT_USER=root
      - RABBITMQ_DEFAULT_PASS=root

(2)启动 RabbitMQ
  通过 docker-compose up -d 启动 RabbitMQ 后,可以通过 15672 端口号访问其 Web 页面。
注:
  若为云服务器,需要配置安全组规则,开放 15672、5672 端口。
  15672 是 RabbitMQ 可视化 web 界面访问端口。
  5672 是 RabbitMQ 访问端口。

4.3 Config 整合 Bus

(1)Config Server 整合 Bus(RabbitMQ)
  此处采用方案二,在 服务端进行 刷新,所以 Config Server 需要引入 actuator 依赖。
Step1:
  在 config_server_9100 中引入 RabbitMQ 以及 actuator 依赖。

【依赖:】
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-bus-amqp</artifactId>
</dependency>

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

Step2:
  在配置文件中,添加 RabbitMQ 配置,并暴露 Bus 刷新的端口(busrefresh)。
  通过 /actuator/bus-refresh 访问 busrefresh。

【application.yml:】
spring:
  # rabbitmq 配置
  rabbitmq:
    username: root
    password: root
    host: 120.26.184.41
    port: 5672

# 暴露监控端点(busrefresh,或者直接写 *)
management:
  endpoints:
    web:
      exposure:
        # include: "*"
        include: "busrefresh"

(2)Config Client 整合 Bus(RabbitMQ)
Step1:
  config_client_9200 同样需要引入 RabbitMQ 依赖。

【依赖:】
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-bus-amqp</artifactId>
</dependency>

Step2:
  在配置文件中,添加 RabbitMQ 配置。

【bootstrap.yml:】
spring:
# RabbitMQ 相关配置
rabbitmq:
  username: root
  password: root
  host: 120.26.184.41
  port: 5672

(3)新增一个 Config Client
  新增一个与 config_client_9200 类似的 config_client_9201,模拟多实例刷新。
  构建步骤与 config_client_9200 相同,仅修改 端口号即可。
  为了与 config_client_9200 区别,config_client_9201 中不引入 actuator 依赖。

(4)测试。
  分别启动:eureka_server_7000、config_server_9100、config_client_9200、config_client_9201。

Step1:
  初始访问配置文件情况如下:

http://localhost:9100/master/config-dev.yml
http://localhost:9200/config/getInfo
http://localhost:9201/config/getInfo

Step2:
  修改配置文件后,再次获取配置文件如下:

http://localhost:9100/master/config-dev.yml
http://localhost:9200/config/getInfo
http://localhost:9201/config/getInfo

Step3:
  向 Config Server 发送 POST 请求 /actuator/bus-refresh,再次获取配置文件:

POST 请求: http://localhost:9100/actuator/bus-refresh
http://localhost:9100/master/config-dev.yml
http://localhost:9200/config/getInfo
http://localhost:9201/config/getInfo

Step4(方案一:客户端刷新,仅供参考):
  再次修改配置文件,此次给 9200 发送 POST 请求。
  由于 9200 配置了 actuator,且暴露端点为 *,可以执行 refresh、bus-refresh。
  当发送的 POST 请求为 refersh 时,此时只会更新自己的配置文件,9201 不会更改。

POST 请求: http://localhost:9200/actuator/refresh
http://localhost:9100/master/config-dev.yml
http://localhost:9200/config/getInfo
http://localhost:9201/config/getInfo

当发送的 POST 请求为 bus-refresh 时,9201 配置文件也会修改。

POST 请求: http://localhost:9200/actuator/bus-refresh
http://localhost:9100/master/config-dev.yml
http://localhost:9200/config/getInfo
http://localhost:9201/config/getInfo

Step5:
  指定端点进行更新,在 POST 请求后加上需要加上相关 微服务实例的信息,
  一般为: spring.application.name:server.port
比如:
  config_client:9201 表示仅指定 config_cliet_9201 这个微服务进行更新。
  config_client:** 表示 config_client 相关所有微服务进行更新。

POST 请求: http://localhost:9100/actuator/bus-refresh/config_client:9201
http://localhost:9100/master/config-dev.yml
http://localhost:9200/config/getInfo
http://localhost:9201/config/getInfo

五、分布式链路追踪

5.1 问题 与 解决

【问题:】
    在一个复杂的微服务系统中,一个客户端发送的请求 可能会经过 多个服务节点,这些服务节点协同工作产生最终的请求结果。
    此时可以将请求经过的微服务 看成一条 服务调用链路(分布式服务调用链路),
    链路中任何一个服务出现了 高延迟 或者 错误 都将引起 整个请求失败。
    
    当某个请求失败,如何确定是哪个服务出现了问题?
    逐行看日志肯定是不可取的方法,是否存在简便的工具帮助我们快速定位错误服务?

【解决:】
    采用 SpringCloud Sleuth,追踪并展示服务调用链路。

5.2 分布式链路追踪 – Sleuth

(1)Sleuth 是什么?

【什么是 Sleuth:】
    Spring Cloud Sleuth 提供了一套完整的分布式服务追踪解决方案,兼容 Zipkin。

    在一个复杂的微服务系统中,若某时处理了多个请求,那么仅通过 日志 很难判断出 一个请求 需要被哪些微服务关联,
    一般解决方法是 对于每个请求都传递一个唯一的 ID,并根据 ID 查找其日志。

    而 Sleuth 可以与 日志框架(Logback、SLF4J) 轻松集成,并通过独特的标识符来使用 日志跟踪,从而便于分析服务调用链路。

    Sleuth 在分布式系统中追踪 一个请求的处理过程(数据采集、数据传输、数据存储、数据分析、数据可视化),通过可视化界面,可以便于监控微服务调用链路。

【官网地址:】
https://spring.io/projects/spring-cloud-sleuth
https://docs.spring.io/spring-cloud-sleuth/docs/current/reference/html/getting-started.html

(2)下载、启动 Zipkin Server

Zipkin 用于可视化界面,下载 jar 包直接启动即可。

【下载地址:】
    http://dl.bintray.com/openzipkin/maven/io/zipkin/java/zipkin-server/
比如:
    http://dl.bintray.com/openzipkin/maven/io/zipkin/java/zipkin-server/2.12.9/zipkin-server-2.12.9-exec.jar

通过 java -jar zipkin-server-2.12.9-exec.jar 可以直接启动。

通过 9411 端口即可进入可视化 Web 界面。
比如:http://120.26.184.41:9411/

5.3 简单整合 Sleuth

(1)说明

【说明:】
    此处使用  eureka_server_7000、config_server_9100、config_client_9200、config_client_9201 进行演示。
其中:
    为了演示链路调用,请求经过 config_client_9201,调用 config_client_9200,再调用 config_server_9100。
    使用 openfeign 进行服务远程调用。

(2)改造 config_server_9100

Step1:
  引入 sleuth 依赖,并修改配置文件。

【依赖:】
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>
【bootstrap.yml:】
spring:
  zipkin:
    base-url: http://120.26.184.41:9411
  sleuth:
    # 采样率范围为 0 ~ 1,1 表示 全部采集
    sampler:
      probability: 1

Step2:
  编写业务代码。

SleuthControllerpackage com.lyh.springcloud.config_server_9100.controller;

import org.springframework.beans.factory.annotation.Value;
import org.springframework.w

以上是关于5.SpringCloud -- 配置中心 Config消息总线 Bus链路追踪 Sleuth配置中心 Nacos的主要内容,如果未能解决你的问题,请参考以下文章

5.springcloud微服务架构搭建 之 《springboot集成Hystrix》

dubbo学习dubbo监控中心

SpringCloud-分布式配置中心加密-非对称加密

分布式配置中心config-client配置报错:java.lang.IllegalStateException: duplicate key: spring

第163天学习打卡(项目 谷粒商城5 SpringCloud Alibaba Feign Nacos)

带你手写基于 Spring 的可插拔式 RPC 框架注册中心