Spring Cloud Bus

Spring Cloud Bus将轻量级消息代理程序链接到分布式系统的节点。然后可以将其用于广播状态更改（例如，配置更改）或其他管理指令。一个关键思想是，总线就像是可扩展的Spring Boot应用程序的分布式执行器，但它也可以用作应用程序之间的通信通道。当前唯一的实现是使用AMQP代理作为传输，但其他传输的路线图上仍具有相同的基本功能集（还有更多取决于传输）。
https://raw.githubusercontent.com/spring-cloud/spring-cloud-build/master/docs/src/main/asciidoc/contributing-docs.adoc
快速开始
如果Spring Cloud Bus在类路径中检测到自身，则通过添加Spring Boot autconfiguration来工作。启用总线所需要做的就是添加spring-cloud-starter-bus-amqp到依赖管理中，其余部分由Spring Cloud负责。确保RabbitMQ可用并配置为提供ConnectionFactory：可以在localhost上运行，但是您无需执行任何操作，但是，如果要远程运行，请使用Spring Cloud Connectors或Spring Boot约定来定义代理凭据，例如
application.yml
spring:
rabbitmq:
host: mybroker.com
port: 5672
username: user
password: secret
总线当前支持向所有侦听节点或特定服务的所有节点发送消息（由Eureka定义）。将来会添加更多选择器条件（即仅服务于数据中心Y中的X节点等）。http端点位于/bus/执行器名称空间下。当前有两个实现。首先，/bus/env发送键/值对以更新Spring Environment的每个节点。第二个，/bus/refresh将重新加载每个应用程序的配置，就像它们都在其/refresh端点上被ping一样。
寻址实例
HTTP端点接受“目的地”参数，例如“ / bus / refresh？destination = customers：9000”，其中目标是ApplicationContextID。如果该ID由总线上的某个实例所拥有，则它将处理该消息，而所有其他实例将忽略它。春天开机设置ID为您在ContextIdApplicationContextInitializer对的组合spring.application.name，积极配置文件和server.port默认。
处理服务的所有实例
Spring中使用“目标”参数PathMatcher（路径分隔符为冒号:）来确定实例是否将处理消息。使用上面的示例，“ / bus / refresh？destination = customers：**”将以“ customers”服务的所有实例为目标，而不考虑将配置文件和端口设置为ApplicationContextID。
应用程序上下文ID必须是唯一的
总线尝试消除两次处理事件，一次来自原始事件，一次来自ApplicationEvent队列。为此，它将再次检查发送的应用程序上下文ID，再检查当前的应用程序上下文ID。如果服务的多个实例具有相同的应用程序上下文ID，则将不处理事件。在本地计算机上运行，每个服务将在不同的端口上，并且将成为应用程序上下文ID的一部分。Cloud Foundry提供了一个区分索引。为确保应用程序上下文ID是唯一的，请spring.application.index为每个服务实例设置唯一的名称。例如，在格子中，spring.application.index=${INSTANCE_INDEX}在application.properties中设置（如果使用configserver ，则在bootstrap.properties中设置）。
自定义消息代理
Spring Cloud Bus使用 Spring Cloud Stream广播消息，因此要使消息畅通，您只需要在类路径中包括您选择的绑定器实现即可。对于配备AMQP，Kafka和Redis（spring-cloud-starter-bus-[amqp,kafka,redis]）的Bus，有一些方便的起动器。一般而言，Spring Cloud Stream依赖于Spring Boot自动配置约定来配置中间件，因此例如AMQP代理地址可通过spring.rabbitmq. 配置属性进行更改。Spring Cloud Bus中具有少数本机配置属性spring.cloud.bus.* （例如，spring.cloud.bus.destination是使用外部中间件的主题名称）。通常，默认值就足够了。
要了解有关如何自定义消息代理设置的更多信息，请参阅Spring Cloud Stream文档。
追踪Bus事件
RemoteApplicationEvent可以通过设置跟踪总线事件（的子类）spring.cloud.bus.trace.enabled=true。如果这样做，那么Spring Boot TraceRepository（如果存在）将显示每个发送的事件以及每个服务实例的所有确认。示例（从 /trace端点）：
{
“timestamp”: “2015-11-26T10:24:44.411+0000”,
“info”: {
“signal”: “spring.cloud.bus.ack”,
“type”: “RefreshRemoteApplicationEvent”,
“id”: “c4d374b7-58ea-4928-a312-31984def293b”,
“origin”: “stores:8081”,
“destination”: “😗*"
}
},
{
“timestamp”: “2015-11-26T10:24:41.864+0000”,
“info”: {
“signal”: “spring.cloud.bus.sent”,
“type”: “RefreshRemoteApplicationEvent”,
“id”: “c4d374b7-58ea-4928-a312-31984def293b”,
“origin”: “customers:9000”,
“destination”: ":"
}
},
{
“timestamp”: “2015-11-26T10:24:41.862+0000”,
“info”: {
“signal”: “spring.cloud.bus.ack”,
“type”: “RefreshRemoteApplicationEvent”,
“id”: “c4d374b7-58ea-4928-a312-31984def293b”,
“origin”: “customers:9000”,
“destination”: "*:”
}
}
此跟踪表明a RefreshRemoteApplicationEvent是从customers:9000所有服务发送 ，广播到所有服务，并由customers:9000和接收（确认）stores:8081。
要自行处理ack信号，你可以添加一个@EventListener 用于AckRemoteAppplicationEvent和SentApplicationEvent类型您的应用程序（并启用跟踪）。或者，您可以点击 TraceRepository并从那里挖掘数据。
注意 任何Bus应用程序都可以跟踪acks，但是有时在可以对数据进行更复杂查询
的中央服务中执行此操作将很有用。或将其转发给专门的跟踪服务。