Spring Cloud Bus 和 Spring Cloud Stream

Spring Cloud Bus 和 Spring Cloud Stream 都是 Spring Cloud 生态中的消息通信组件，但它们的定位和使用场景有显著区别：

---

1. Spring Cloud Bus

核心定位：分布式系统的消息广播（配置刷新、事件传播）。
典型场景：

• 通过消息中间件（如 RabbitMQ、Kafka）广播配置变更事件，实现所有微服务配置的集中刷新（如结合 /actuator/refresh 或 /actuator/bus-refresh 端点）。
• 跨服务的事件通知（例如：注销全局缓存、批量触发操作）。

关键特性：

• 基于 轻量级事件驱动（如 RefreshRemoteApplicationEvent）。
• 依赖 Spring Cloud Config 实现配置的动态更新。
• 通常与 @RefreshScope 配合使用。

示例：

# 通过Bus广播配置刷新指令
POST http://config-server/actuator/bus-refresh

---

2. Spring Cloud Stream

核心定位：简化消息中间件的集成，提供统一的消息生产与消费模型。
典型场景：

• 构建事件驱动的微服务，如订单创建触发库存扣减。
• 需要与 Kafka、RabbitMQ 等中间件交互的业务逻辑。

关键特性：

• 抽象 Binder 层，屏蔽底层中间件差异（如 Kafka/RabbitMQ）。
• 提供 @StreamListener（旧版）或函数式编程模型（新版）处理消息。
• 支持消息分区、消费组、重试等高级特性。

示例：

// 生产者
@Bean
public Supplier<String> produce() {
    return () -> "Hello Stream";
}

// 消费者
@Bean
public Consumer<String> consume() {
    return message -> System.out.println("Received: " + message);
}

---

主要区别

维度	Spring Cloud Bus	Spring Cloud Stream
用途	系统级事件广播（如配置刷新）	业务级消息通信（如订单事件）
抽象层级	基于 Spring 事件机制 + 消息中间件广播	统一的消息中间件编程模型
使用复杂度	简单，主要依赖自动配置和端点触发	较高，需定义消息通道和绑定逻辑
依赖关系	通常与 Spring Cloud Config 配合使用	独立使用，直接处理业务消息流
典型中间件	RabbitMQ、Kafka（仅用于传输事件）	Kafka、RabbitMQ、RocketMQ 等

---

协作场景

两者可结合使用，例如：

1. Config Server 通过 Bus 广播配置变更。
2. 微服务接收到配置更新事件后，通过 Stream 发送业务通知到其他系统。

总结：Bus 是系统管理的“广播电台”，Stream 是业务消息的“收发器”。