SpringCloud-Bus

核心概念与原理

1. 是什么 (What is Spring Cloud Bus?)

   • 定义：一个用于将分布式系统的节点与轻量级消息代理连接起来的框架。
   • 本质：它是一个消息总线，使用消息中间件来广播状态变化（如配置更改）或管理指令。

2. 为什么 (Why use it? The Problem it Solves)

   • 解决痛点：在微服务架构中，当有大量客户端实例（比如 100 个）时，手动逐个刷新配置 (/actuator/refresh) 是不可能的。
   • 解决方案：通过 Bus，只需一次请求（通常发给 Config Server 或任意一个客户端），消息就会通过消息队列广播到所有客户端，所有客户端都会自动刷新。实现了批量操作和解耦。

3. 如何工作 (How it Works - The Magic)

   • 核心原理：“配置更改”作为一个事件（Message）被发布到消息队列的主题（Topic）中，所有监听该主题的微服务实例都会消费这个消息并执行刷新操作。
   • 掌握两个核心端点：
     • /actuator/bus-refresh (POST)：广播刷新所有客户端。
     • /actuator/bus-env (POST)：用于广播更新某个特定的环境属性（更精细的控制）。
   • 理解 @RefreshScope 在 Bus 环境下的作用。

基本使用

添加依赖
Config Server和Client添加maven依赖

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

如果是RabbitMQ的话就用spring-cloud-starter-bus-amqp

配置文件
Config Server和Client添加配置

spring:
  kafka:
    bootstrap-servers: localhost:9092

management:
  endpoints:
    web:
      exposure:
        include: bus-refresh, health, info

主要添加了kafka和bus-refresh的端点配置

测试
启动Config Server，查看kafka的topic会发现多了一个springCloudBus的topic

.\bin\windows\kafka-topics.bat --list --bootstrap-server localhost:9092

启动Config Client

curl -X GET "http://localhost:3355/config/getConfigInfo"
999

修改git上面的配置后测试

# 触发全局通知
curl -X POST "http://localhost:3344/actuator/bus-refresh"


curl -X GET "http://localhost:3355/config/getConfigInfo"
991

可以看到，触发Config Server的bus-refresh后，Config Client也更新了
也可以指定客户端来更新指定节点

# 触发定点通知 /actuator/bus-refresh/{spring.application.name}:{server.port}
curl -X POST "http://localhost:3344/actuator/bus-refresh/CONFIG-CLIENT-3355:3355"

架构图

flowchart TD A[运维人员/配置管理系统] -->|1.POST /actuator/bus-refresh| B[Config Server 或 任意Client] subgraph C [消息中间件 Message Broker] D[[Topic/Exchange<br>广播通道]] end B -->|2.发布RefreshRemoteApplicationEvent| D subgraph E [微服务集群 Microservices Cluster] F[Service A:8080] G[Service A:8081] H[Service B:9000] end D -->|3.广播事件| F D -->|3.广播事件| G D -->|3.广播事件| H F -->|4.刷新配置| I[Config Server] G -->|4.刷新配置| I H -->|4.刷新配置| I

总结

优点：实现了真正的配置动态化，是构建“响应式”微服务系统的关键一步，极大地提高了运维效率。
缺点：

• 引入了新的中间件（消息队列），增加了系统的复杂度。
• 广播机制是“fire-and-forget”（发射后不管），缺乏可靠的确认机制。在某些极端情况下，可能有个别客户端会错过消息（虽然概率极低）。
• 配置的最终一致性需要由 Bus 和消息队列来保证。
  替代方案：
• 阿里 Nacos：它不仅是一个配置中心，还是一个服务发现组件。其配置刷新机制基于长轮询 Pull 模式，内置了推送能力，无需额外引入消息队列，架构更简单，是目前非常流行的选择。
• Spring Cloud Consul：其配置功能基于 Watches 机制。

持续学习

1. 跟踪总线事件 (Trace)
   • 通过设置 spring.cloud.bus.trace.enabled=true 来启用事件跟踪。
   • 调用 /actuator/bus-refresh 后，可以访问 /actuator/httptrace 来查看哪些客户端实例处理了该事件，便于调试。
2. 安全考虑
   • 非常重要：/actuator/bus-refresh 端点拥有巨大的权力，必须将其保护起来，避免被未授权访问。
   • 如何做：通常通过 Spring Security 将该端点屏蔽或要求特定的权限/Token 才能访问。