Spring config的局部刷新和架构改进

一 局部刷新

某些场景下（例如灰度发布等），若只想刷新部分微服务的配置，可通过/bus/refresh端点的destination参数来定位要刷新的应用程序。

例如：/bus/refresh?destination=customers:9000，这样消息总线上的微服务实例就会根据destination参数的值来判断是否需要刷新。其中，customers:9000指的是微服务的ApplicationContext ID。

destination参数也可以用来定位特定的微服务。例如：/bus/refresh?destination=customers:**，这样就可以触发customers微服务的所有实例的配置刷新。

默认情况下：ApplicationContext ID参数的值是spring.application.name:server.port。

二 架构改进

通过请求某个微服务/bus/refresh端点的方式来实现配置刷新，这种方式并不优雅。原因如下：

1 破坏了微服务的职责单一原则。业务微服务只应关注自身业务，不应承担配置刷新的职责。

2 破坏了微服务各节点的对等性。

3 有一定的局限性。例如，微服务在迁移时，网络地址常常发生变化。此时如果想自动刷新配置，就不得不修改WebHook配置。

改进架构如下：

从图可知：将Config Server也加入到消息总线中，并使用Config Server的/bus/refresh端点来实现配置的刷新。这样，各个微服务只需要关注自身的业务，而不再承担配置刷新的职责。

三 跟踪总线事件

一些场景下如果希望知道Spring Cloud Bus事件传播的细节，可以跟踪总线事件。

想要跟踪总线事件非常简单，只需设置spring.cloud.bus.trace.enable=true，这样在/bus/refresh端点被请求后，访问/trace端点就可获得类似如下的结果。