Spring Cloud Bus
Spring cloud bus通过轻量消息代理连接各个分布的节点。这会用在广播状态的变化(例如配置变化)或者其他的消息指令。Spring bus的一个核心思想是通过分布式的启动器对spring boot应用进行扩展,也可以用来建立一个多个应用之间的通信频道。目前唯一实现的方式是用AMQP消息代理作为通道,同样特性的设置(有些取决于通道的设置)在更多通道的文档中。
Spring cloud bus被国内很多都翻译为消息总线,也挺形象的。大家可以将它理解为管理和传播所有分布式项目中的消息既可,其实本质是利用了MQ的广播机制在分布式的系统中传播消息,目前常用的有Kafka和RabbitMQ。利用bus的机制可以做很多的事情,其中配置中心客户端刷新就是典型的应用场景之一,我们用一张图来描述bus在配置中心使用的机制。
根据此图我们可以看出利用Spring Cloud Bus做配置更新的步骤:
1、提交代码触发post给客户端A发送bus/refresh2、客户端A接收到请求从Server端更新配置并且发送给Spring Cloud Bus3、Spring Cloud bus接到消息并通知给其它客户端4、其它客户端接收到通知,请求Server端获取最新配置5、全部客户端均获取到最新的配置
改进版本
在上面的流程中,我们已经到达了利用消息总线触发一个客户端bus/refresh
,而刷新所有客户端的配置的目的。但这种方式并不优雅。原因如下:
打破了微服务的职责单一性。微服务本身是业务模块,它本不应该承担配置刷新的职责。破坏了微服务各节点的对等性。有一定的局限性。例如,微服务在迁移时,它的网络地址常常会发生变化,此时如果想要做到自动刷新,那就不得不修改WebHook的配置。
因此我们将上面的架构模式稍微改变一下
这时Spring Cloud Bus做配置更新步骤如下:
1、提交代码触发post请求给bus/refresh2、server端接收到请求并发送给Spring Cloud Bus3、Spring Cloud bus接到消息并通知给其它客户端4、其它客户端接收到通知,请求Server端获取最新配置5、全部客户端均获取到最新的配置
这样的话我们在server端的代码做一些改动,来支持bus/refresh
1、添加依赖
<dependencies><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-config-server</artifactId></dependency><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-bus-amqp</artifactId></dependency><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-eureka</artifactId></dependency></dependencies>复制代码
需要多引入spring-cloud-starter-bus-amqp
包,增加对消息总线的支持
2、配置文件
server:port: 8001spring:application:name: spring-cloud-config-servercloud:config:server:git:uri: /ityouknow/spring-cloud-starter/# 配置git仓库的地址search-paths: config-repo # git仓库地址下的相对地址,可以配置多个,用,分割。username: username# git仓库的账号password: password# git仓库的密码rabbitmq:host: 192.168.0.6port: 5672username: adminpassword: 123456eureka:client:serviceUrl:defaultZone: http://localhost:8000/eureka/ ## 注册中心eurka地址management:security:enabled: false复制代码
配置文件增加RebbitMq的相关配置,关闭安全验证。这样server端代码就改造完成了。
3、测试
依次启动spring-cloud-eureka、spring-cloud-config-server、spring-cloud-config-client项目,改动spring-cloud-config-client项目端口为8003、8004依次启动。测试环境准备完成。
按照上面的测试方式,访问server端和三个客户端测试均可以正确返回信息。同样修改neo-config-dev.properties
中neo.hello
的值为hello im dev update
并提交到代码库中。在win下使用下面命令来模拟webhook触发server端bus/refresh
.
curl -X POST http://localhost:8001/bus/refresh复制代码
其它
局部刷新
某些场景下(例如灰度发布),我们可能只想刷新部分微服务的配置,此时可通过/bus/refresh
端点的destination参数来定位要刷新的应用程序。
例如:/bus/refresh?destination=customers:8000
,这样消息总线上的微服务实例就会根据destination参数的值来判断是否需要要刷新。其中,customers:8000
指的是各个微服务的ApplicationContext ID。
destination参数也可以用来定位特定的微服务。例如:/bus/refresh?destination=customers:**
,这样就可以触发customers微服务所有实例的配置刷新。
跟踪总线事件
一些场景下,我们可能希望知道Spring Cloud Bus事件传播的细节。此时,我们可以跟踪总线事件(RemoteApplicationEvent的子类都是总线事件)。
跟踪总线事件非常简单,只需设置spring.cloud.bus.trace.enabled=true
,这样在/bus/refresh
端点被请求后,访问/trace
端点就可获得类似如下的结果:
{"timestamp": 1495851419032,"info": {"signal": "spring.cloud.bus.ack","type": "RefreshRemoteApplicationEvent","id": "c4d374b7-58ea-4928-a312-31984def293b","origin": "stores:8002","destination": "*:**"}},{"timestamp": 1495851419033,"info": {"signal": "spring.cloud.bus.sent","type": "RefreshRemoteApplicationEvent","id": "c4d374b7-58ea-4928-a312-31984def293b","origin": "spring-cloud-config-client:8001","destination": "*:**"}},{"timestamp": 1495851422175,"info": {"signal": "spring.cloud.bus.ack","type": "RefreshRemoteApplicationEvent","id": "c4d374b7-58ea-4928-a312-31984def293b","origin": "customers:8001","destination": "*:**"}}复制代码
这个日志显示了customers:8001
发出了RefreshRemoteApplicationEvent事件,广播给所有的服务,被customers:9000
和stores:8081
接受到了。想要对接受到的消息自定义自己的处理方式的话,可以添加@EventListener
注解的AckRemoteApplicationEvent和SentApplicationEvent类型到你自己的应用中。或者到TraceRepository类中,直接处理数据。
这样,我们就可清晰地知道事件的传播细节。
/bus/refresh BUG
/bus/refresh
有一个很严重的BUG,一直没有解决:对客户端执行/bus/refresh
之后,挂到总线的上的客户端都会从Eureka注册中心撤销登记;如果对server端执行/bus/refresh
,server端也会从Eureka注册中心撤销登记。再用白话解释一下,就是本来人家在Eureka注册中心注册的好好的,只要你对着它执行一次/bus/refresh
,立刻就会从Euraka中挂掉。
其实这个问题挺严重的,本来你利用/bus/refresh
给所有的节点来更新配置信息呢,结果把服务从Euraka中给搞掉了,那么如果别人需要调用客户端的服务的时候就直接歇菜了。不知道国内有童鞋公司在生产中用到这个功能没有,用了不就很惨烈。在网上搜索了一下,国内网友和国外网友都遇到过很多次,但是一直没有解决,很幸运就是我在写这篇文章的前三天,Netflix修复了这个问题,使用Spring Cloud最新版本的包就可以解决这个问题。由此也可以发现Spring Cloud还在快速的发展中,最新的版本可能也会有一些不稳定性,可见路漫漫而修远兮。
在pom中使用Spring Cloud的版本,解决这个bug.
<properties><project.build.sourceEncoding>UTF-8</project.build.sourceEncoding><project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding><java.version>1.8</java.version><spring-cloud.version>Dalston.SR1</spring-cloud.version></properties>复制代码
主要是这句:<spring-cloud.version>Dalston.SR1</spring-cloud.version>
整体架构如下:
完整项目的源码来源
Spring Cloud大型企业分布式微服务云构建的B2B2C电子商务平台源码请加企鹅求求:一零三八七七四六二六