具体的操作过程比较简单网上的资料也很多就不细说了，谈下注意事项，发现大家遇到最多的问题就是：

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配置文件仓库修改配置文件内容后会自动通知到客户端进行刷新。

================================================================================================

另外网上还查到了另外一种方法，但是尝试之后发现不起作用，不知道是不是哪里有错误，欢迎讨论

https://www.cnblogs.com/yfzhou/p/10203573.html