好了，接着上一篇随笔，继续说下去吧。 上次我们说，要更新所有微服务的配置而不重新启动，只能依靠spring cloud config，但我们会为每个服务发送开机自检请求。
我们受得了吗？ 这比没有以前的配置中心好多了，我们如何避免继续向服务发送开机自检请求通知服务？ 你的配置信息发生了变化，需要立即修改内存中的配置信息。
此时，请不要忘记消息队列的公共订阅模式。 您可以为服务订阅此事件，并在此事件发生更改时通知所有微服务更新内存中的配置信息。 此时总线消息总线将解决。 只需在springcloud Config Server端发出刷新，即可触发所有微服务的更新。
请参阅以下体系结构图。
除了自动配置RabbitMQ外，Spring Cloud Bus还支持当前广泛使用的Kafka。 本文试图构建Kafka的本地环境，使用Spring Cloud Bus支持Kafka并实现消息总线的功能。
Kafka使用Scala实现，作为LinkedIn的活动流程和运营数据处理的管道，现在也在很多互联网企业广泛用作数据流管道和消息系统。
Kafak的体系结构图如下：
Kafka是一个基于消息传递/订阅模型实现的消息系统，其主要设计目标如下：
1 .消息持久化：以时间复杂度为o(1)的方式提供消息持久化能力，保证恒定时间复杂度对TB级以上数据的访问性能。
2 .高吞吐量：即使是廉价的商用机器，单体也能应对每秒100K瓶以上的吞吐量
3 .分布式：支持消息分区和分布式消费，保证分区中的消息顺序
4 .跨平台：支持不同技术平台的客户端，如Java、PHP和Python
5 .实时性：支持实时数据处理和离线数据处理
6 .伸缩性：支持水平扩展
与Kafka相关的一些基本概念：
1.Broker:Kafka群集包含一个或多个称为Broker的服务。
2.Topic :逻辑上类似于Rabbit的队列，发布到Kafka群集的所有消息都需要Topic。 (物理上不同的Topic消息分别存储，逻辑上一个Topic消息存储在一个或多个中介中，但用户只需指定消息的Topic即可生产数据，而无需考虑数据存储在何处
3.Partition:Partition是物理概念上的分区，每个Topic在物理上分为一个或多个Partition，每个Partition对应一个文件夹，以提供系统吞吐率。 (保存对应分区的消息内容和索引文件。
4.Producer :信息生产者，负责信息的生产并发送到Kafka Broker。
5.Consumer (消息消费者，Kafka中介读取并处理消息的客户端。
6.Consumer Group :您可以指定每个Consumer属于特定组，每个Consumer属于一个组。 如果未指定，则属于默认组。 (组可以用于实现功能，如一条消息被组中的多个成员消耗。)
从kafka的体系结构图中可以看到，kafka需要Zookeeper的支持。 您必须指定Zookeeper在kafka配置中的位置。 那个通过Zookeeper保证可靠性，做经纪人的主从。 kafka的消息也知道以主题格式作为组织发送，Producers作为主题发送。由于服务端还创建了几个分片，因此一个topic可能分布在不同的分片上，可以部署多台计算机Kafka天生就很分散。 在这里，为了演示，我们只需要使用默认配置在windows上创建一个小Demo。
这里主要针对Spring Cloud Bus对Kafka的支持，实现了消息总线的功能。 具体的Kafka，RabbitMQ消息队列想自己找资料学习。 有一些概念支持后，进行一些演示。
首先，创建新的springCloud-config-client1模块，如下所示： 为便于测试而引入的依赖项包括：
org.springframework.boot
spring-boot-starter-actuator
org.springframework.boot
spring-boot-starter-web
org.springframework.cloud
spring-cloud-starter-config
1.4.0 .版本
org.springframework.cloud
spring-cloud-starter-eureka
1.3.5 .发布
org.springframework.cloud
spring-cloud
-starter-bus-kafka1.3.2.RELEASE
接着要注意一下，client1的配置文件要改为bootstrap.yml，因为这种配置格式，是优先加载的，上一篇随笔有讲过，client1的配置如下：
server:
port: 7006
spring:
application:
name: cloud-config
cloud:
config:
#启动什么环境下的配置，dev 表示开发环境，这跟你仓库的文件的后缀有关，比如，仓库配置文件命名格式是cloud-config-dev.properties,所以profile 就要写dev
profile: dev
discovery:
enabled: true
#这个名字是Config Server端的服务名字，不能瞎写。
service-id: config-server
#注册中心
eureka:
client:
service-url:
defaultZone: http://localhost:8888/eureka/,http://localhost:8889/eureka/
#是否需要权限拉去，默认是true,如果不false就不允许你去拉取配置中心Server更新的内容
management:
security:
enabled: false
接着启动类如下：
@SpringBootApplication
@EnableDiscoveryClient
public class Client1Application {
public static void main(String[] args) {
SpringApplication.run(Client1Application.class, args);
}
}
接着将client中的TestController赋值一份到client1中，代码如下：
@RestController
//这里面的属性有可能会更新的，git中的配置中心变化的话就要刷新，没有这个注解内，配置就不能及时更新
@RefreshScope
public class TestController {
@Value("${name}")
private String name;
@Value("${age}")
private Integer age;
@RequestMapping("/test")
public String test(){
return this.name+this.age;
}
}
接着还要在先前的随笔中的模块中的Config Server加入如下配置：
#是否需要权限拉去，默认是true,如果不false就不允许你去拉取配置中心Server更新的内容
management:
security:
enabled: false
接着还要做一点就是，在config-client,config-client1,和config-Server都要引入kafka的依赖，如下：
org.springframework.cloud
spring-cloud-starter-bus-kafka
1.3.2.RELEASE
我们工程准备好了，暂时先放在这里，下面进行Kafka的安装下载，首先我们去Kafka官网kafka.apache.org/downloads 下来官网推荐的版本，
首先我们进到下载好的Kafka目录中kafka_2.11-1.1.0灵巧的荔枝windows 下编辑kafka-run-class.bat如下：
找到这条配置 如下：
set COMMAND=%JAVA% %KAFKA_HEAP_OPTS% %KAFKA_JVM_PERFORMANCE_OPTS% %KAFKA_JMX_OPTS% %KAFKA_LOG4J_OPTS% -cp %CLASSPATH% %KAFKA_OPTS% %*
可以看到%CLASSPATH%没有双引号，
因此用双引号括起来，不然启动不起来的，报你JDK没安装好，修改后如下：
set COMMAND=%JAVA% %KAFKA_HEAP_OPTS% %KAFKA_JVM_PERFORMANCE_OPTS% %KAFKA_JMX_OPTS% %KAFKA_LOG4J_OPTS% -cp "%CLASSPATH%" %KAFKA_OPTS% %*
接着，打开config文件夹中的server.properties配置如下：
可以看到是连接到本地的zookeeper就行了。
接着我们进行先启动zookeeper，再启动Kafka，如下：
当看到上面的信息证明启动Zookeeper启动成功。、
接下来再开一个CMD启动Kafka，如下：
看到这些信息说明Kafka启动成功了
好了，接下来把前面的工程，两个注册中心，一个springcloud-config-server,两个springcloud-config-client,springcloud-config-client1启动起来，
可以看到springcloudBus是在0分片上，如果两个config-client启动都出现上面信息，证明启动成功了。
好了现在我们进行访问一下config-server端，如下：
再访问两个client,如下：
好了，好戏开始了，现在我们去git仓库上修改配置中心的文件，将年龄改为24，如下：
接下来，我们我们用refresh刷新配置服务端配置，通知两个client去更新内存中的配置信息。用postman发送localhost:7000/bus/refresh,如下：
可以看到没有返回什么信息，但是不要担心，这是成功的通知所有client去更新了内存中的信息了。
接着我们分别重新请求config-server,两个client,刷新页面，结果如下：
两个client如下：
可以看到所有client自动更新内存中的配置信息了。
到目前为止，上面都是刷新说有的配置的信息的，如果我们想刷新某个特定服务的配置信息也是可以的。我们可以指定刷新范围，如下：
指定刷新范围
上面的例子中，我们通过向服务实例请求Spring Cloud Bus的/bus/refresh接口，从而触发总线上其他服务实例的/refresh。但是有些特殊场景下(比如：灰度发布)，我们希望可以刷新微服务中某个具体实例的配置。
Spring Cloud Bus对这种场景也有很好的支持：/bus/refresh接口还提供了destination参数，用来定位具体要刷新的应用程序。比如，我们可以请求/bus/refresh?destination=服务名字:9000，此时总线上的各应用实例会根据destination属性的值来判断是否为自己的实例名，
若符合才进行配置刷新，若不符合就忽略该消息。
destination参数除了可以定位具体的实例之外，还可以用来定位具体的服务。定位服务的原理是通过使用Spring的PathMatecher(路径匹配)来实现，比如：/bus/refresh?destination=customers:**，该请求会触发customers服务的所有实例进行刷新。
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持脚本之家。