然而，既然已经做出了决定……
我们无法轻松地将文件名应用程序添加到 webhook，因为 DevOps webhook 实际上并不知道哪些文件被更新了。当然，我们可以将其添加到管道或配置存储库中，但这意味着我们进一步扩大了所有应用程序对 Azure 的依赖，并且与 Microsoft 环境的耦合更加紧密。因此，我们决定将刷新逻辑保留在我们的应用程序中，并与任何 CI/CD 实现分离。
1. 我们将在每个应用程序中嵌入配置服务器
2. 我们将允许所有嵌入式配置服务器进行自我配置
3. 我们将删除 Kafka 事件，因为我们不再需要触发其他应用程序
4. 我们将轮询存储库以了解应用程序的更改，而不是依赖来自 DevOps 的 webhook。
5. 如果配置发生变化，我们将自行重新加载 Camel。
嵌入配置服务器并自行配置
这很容易。我们只需将服务器的 bootstrap.yml 中的配置 开曼群岛号码数据 添加到每个客户端：
这涵盖了第 2 点：使应用程序能够从远程存储库进行自我配置。如果没有它，它将只为其他应用程序提供配置。
老实说，这里发生了很多 Spring Boot 魔法。只是假设它有效并且不要进一步质疑它。这确实是您所需要的一切。
轮询远程服务器以了解更改
我们这里面临着许多问题。所有配置文件都位于单个存储库中。在推送时刷新所有应用程序是不可行的，所以我们需要一种方法来知道哪些文件已更新。其次，Spring Cloud 仅支持应用程序上的 webhook。这是可行的，但需要 Azure 能够访问我们所有的应用程序，并且需要我们为 DevOps 中的每个新应用程序设置一个 webhook，使用消息代理来传播事件或提出其他方法。
经过反复考虑，我们决定采用以下解决方案：
- 我们将进行自我轮询以检查是否有变化并检查哪些文件已更新。根据更改的文件，我们仅在需要时重新加载应用程序。
Spring Config Server 已经使用 git 作为配置源。它在底层使用 JGitRepository，我们也可以在我们的应用程序中使用它 @Autowire。这将是正确的 git 存储库的入口点。通过使用此功能，我们可以使用现有的配置，并避免仅针对轮询进行单独的配置。