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,但是有时在可以对数据进行更复杂查询
的中央服务中执行此操作将很有用。或将其转发给专门的跟踪服务。
Spring Cloud Bus
最新推荐文章于 2024-07-13 09:55:32 发布