在我前面的章节已经为大家介绍了Spring Cloud Config，可以实现将分布式微服务的配置进行集中管理。但是，就目前而言，我们目前仅限于在应用程序启动时更新此类配置。将属性的新值推送到Git之后，我们将需要手动重新启动每个应用程序进程以获得新值，或者通过手动发送“/actuator/refresh”请求的方式实现配置刷新。如果我们想要实现应用配置的热更新，单纯依靠Spring Cloud Config就无能为力了，那就需要结合我们本节开始为大家讲的Spring Cloud Bus才能够实现。 ## 一、Spring Cloud Bus简介 Spring Cloud Bus将分布式系统的微服务通过轻量级的消息中间件连接起来，通过消息中间件广播状态更改（例如配置更改）或其他管理指令。总线就像是横向扩展的Spring Boot应用程序的分布式的actuator，它也可以用作微服务之间的通信渠道。  * **消息总线的核心工作逻辑**：将收到的消息（事件）批量分发到所有或部分的微服务节点应用，微服务应用在接到消息之后做出相应的业务处理相应。 * Spring Cloud Bus不仅可以分发配置刷新消息（事件），还可以应用到整个微服务系统中的其他业务 * Spring Cloud Bus是基于消息队列产品实现的，从官网来看目前支持的消息队列有两种：rabbitMQ和kafka。（[Bus官网](https://spring.io/projects/spring-cloud-bus#learn)简陋到连一张图都没有，版本实时性很差） * Spring Cloud Bus的消息分发机制，是基于消息队列的:发布/订阅模式实现的。 ## 二、Spring Cloud Bus与Config实现应用配置热加载原理 * 如果消息总线收到并分发的消息（事件）是配置刷新的消息，微服务收到该消息之后就会主动的去config server加载最新的配置。从而达到微服务配置热更新的效果（如下图所示） * Bus是通过eureka找到配置分发刷新目标服务的，为了降低核心架构图复杂度，下图没有体现eureka * 第1步发送“/bus/refresh”请求，可以在git仓库代码修改后由git仓库webhook自动执行。但基于笔者之前章节《config客户端配置刷新》已经说过的原因，这样做的可操作性不强。不建议使用。  > 笔者要说明的是：目前互联网上的很多关于Spring Cloud Bus的架构图都有一个错误，那就是“/bus/refresh”数据刷新请求是由config server接收的。实际这种理解是错误的，接收“/bus/refresh”请求的是Spring Cloud Bus。比如下面的这张图就是错误的。 >  > 在Spring Boot2.0中“/bus/refresh”服务端点不再被开放，而是使用“/actuator/bus-refresh”代替。需要结合Spring Cloud Bus与spring-boot-starter-actuator一起使用。 上面这种图的笔者之所以会画错，我猜可能是因为这个原因：我们在使用Spring cloud微服务架构的时候，为了降低微服务组件的复杂度，Spring cloud Bus和Spring CLoud Config通常是一起使用的，也就是说将Spring Cloud Bus是集成到Spring Cloud Config Server里面的，使用同一个JVM进程实例。**导致Config Server看上去就是Spring Cloud Bus，二者是物理集成，逻辑分离。** 架构图如下所示：