Push 通知（Push Notifications）和 Spring Cloud Bus

许多源代码存储库提供者(如 Github、Gitlab、Gitea、Gitee、Gogs 或 Bitbucket)通过 webhook 通知您存储库中的更改。 您可以通过提供者的用户界面将 webhook 配置为 URL 和订阅一组你感兴趣的事件。 例如，Github webhook 支持使用一个 POST 回调 ，它的 JSON 主体包含一个提交列表和一个设置为 push 的头(X-Github-Event)。 如果您添加了对 spring-cloud-config-monitor 库的依赖，并激活配置服务器中的 Spring Cloud Bus ，那么就启用了 /monitor 端点。

implementation 'org.springframework.cloud:spring-cloud-config-monitor'

只依赖如上依赖，启动程序后报错

org.springframework.context.ApplicationContextException: Failed to start bean 'outputBindingLifecycle'; nested exception is java.lang.IllegalArgumentException: A default binder has been requested, but there is no binder available

以上测试暂时不管了，后续看完再过来补充 Bus 到底是怎么用的

当 webhook 被激活时，配置服务器发送一个 RefreshRemoteApplicationEvent，目标是它认为可能已经更改的应用程序。 变更检测可以制定策略。但是，默认情况下，它查找与应用程序名称匹配的文件中的更改（如 foo.properties 是针对 foo 应用， 而 application.properties 是针对所有应用）。 当您想要覆盖行为时要使用的策略是 PropertyPathNotificationExtractor，它接受 headers 和 body 作为参数，并返回已更改的文件路径列表。

默认配置使用 Github、Gitlab、Gitea、Gitee、Gogs 或 Bitbucket。除了来自 Github、Gitlab、Gitee 或 Bitbucket 的 JSON 通知之外， 您还可以通过以 post form-encoded 方式 将参数 path={name} 发送到 /monitor 来触发更改通知。这样做向匹配 {name} 模式的应用程序广播(该模式可以包含通配符)。

以上 /monitor 路径在线上使用 Spring Clud Bus 的配置中心中没有找到，不知道是怎么弄的

TIP

只有在配置服务器和客户机应用程序中同时激活 spring-cloud-bus 时，才会传输 RefreshRemoteApplicationEvent。

默认配置还检测本地 git 存储库中的文件系统更改。在这种情况下，不使用 webhook。但是，只要编辑配置文件，就会广播刷新。

配置这一章看完了，关于 Spring Cloud Bus 需要查阅其他资料学习