具体的操作过程比较简单网上的资料也很多就不细说了,谈下注意事项,发现大家遇到最多的问题就是:
1. 通过手动发送post请求发现无效:
SpringCloud2.0以前的版本请求的路径是/bus/refresh
SpringCloud2.0以后的版本请求的路径是/actuator/bus-refresh
这些信息可以在Config Server服务端启动时的控制台中看到
2. 使用WebHooks发送/actuator/bus-refresh请求时,提示400错误,显示json数据异常:
这是因为Github在进行post请求时默认会在body加上一串载荷(payload),可以处理,但没必要。需要手动拦截请求然后进行处理,需要添加很多编码,所以不考虑此方法。
3. 使用SpringCloud2.0新增的/monitor请求。如果使用WebHooks发送/monitor时,提示404:
这是因为需要在Config服务端添加monitor的依赖才能发送
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-config-monitor</artifactId>
<version>2.1.0.RELEASE</version>
</dependency>
4. 添加完毕依赖后,在Github中设置了WebHooks路径,请求也正常发出,并且修改Git仓库中配置文件后服务端控制台也正常打印显示配置刷新,但是客户端没有任何反应,也无法读取到最新的配置:
查阅SpringCloud官方文档发现如下描述:
其大致意思是:
当Webhook被激活时,配置服务器发送一个refreshRemoteApplicationEvent,目标是它认为可能已更改的应用程序。变更检测可以制定策略。但是,默认情况下,它会查找与应用程序名称匹配的文件中的更改(例如,foo.properties针对的是foo应用程序,而application.properties针对的是所有应用程序)。当您想要重写行为时要使用的策略是PropertyPathNotificationExtractor,它接受请求头和主体作为参数,并返回已更改的文件路径列表。
默认配置与GitHub、Gitlab、Gitea、Gitee、Gogs或BitBucket一起使用。除了来自Github、Gitlab、Gitee或BitBucket的JSON通知之外,您还可以通过以path=name的模式将表单编码的主体参数发布到/monitor来触发更改通知。这样做会广播到与名称模式(可以包含通配符)匹配的应用程序。
看到这里是不是豁然开朗了?
我们只需在WebHooks配置的post请求路径后面添加上请求参数即可找到对应的客户端进行刷新
http://ucpwyf.natappfree.cc/monitor?path=testClient
或者直接使用通配符对所有客户端进行刷新
http://ucpwyf.natappfree.cc/monitor?path=test*
http://ucpwyf.natappfree.cc/monitor?path=*
到这里就大功告成,在Git配置文件仓库修改配置文件内容后会自动通知到客户端进行刷新。
================================================================================================
另外网上还查到了另外一种方法,但是尝试之后发现不起作用,不知道是不是哪里有错误,欢迎讨论