Spring Cloud Config 其他配置

最新推荐文章于 2024-04-02 05:01:44 发布

Carrieº

最新推荐文章于 2024-04-02 05:01:44 发布

阅读量405

点赞数

Spring Cloud 专栏收录该内容

36 篇文章 1 订阅

订阅专栏

服务替代格式

来自环境端点的默认JSON格式对于Spring应用程序的消费是完美的，因为它直接映射到Environment抽象。如果您喜欢，可以通过向资源路径（“.yml”，“.yaml”或“.properties”）添加后缀来使用与YAML或Java属性相同的数据。这对于不关心JSON端点的结构的应用程序或其提供的额外的元数据的应用程序来说可能是有用的，例如，不使用Spring的应用程序可能会受益于此方法的简单性。

YAML和属性表示有一个额外的标志（作为一个布尔查询参数resolvePlaceholders提供）），以标示Spring ${…?}形式的源文档中的占位符，应在输出中解析可能在渲染之前。对于不了解Spring占位符惯例的消费者来说，这是一个有用的功能。

注意

使用YAML或属性格式存在局限性，主要是与元数据的丢失有关。JSON被构造为属性源的有序列表，例如，名称与源相关联。即使源的起源具有多个源，并且原始源文件的名称丢失，YAML和属性表也合并成一个映射。YAML表示不一定是后台存储库中YAML源的忠实表示：它是由平面属性源的列表构建的，并且必须对键的形式进行假设。

服务纯文本

您的应用程序可能需要通用的纯文本配置文件，而不是使用Environment抽象（或YAML中的其他替代表示形式或属性格式）。配置服务器通过/{name}/{profile}/{label}/{path}附加的端点提供这些服务，其中“name”，“profile”和“label”的含义与常规环境端点相同，但“path”是文件名（例如log.xml ）。此端点的源文件位于与环境端点相同的方式：与属性或YAML文件相同的搜索路径，而不是聚合所有匹配的资源，只返回匹配的第一个。

找到资源后，使用正确格式（${…?}）的占位符将使用有效的Environment解析为应用程序名称，配置文件和标签提供。以这种方式，资源端点与环境端点紧密集成。例如，如果您有一个GIT（或SVN）资源库的布局：

application.yml
nginx.conf

其中nginx.conf如下所示：

server {
    listen              80;
    server_name         ${nginx.server.name};
}

和application.yml这样：

nginx:
  server:
    name: example.com
---
spring:
  profiles: development
nginx:
  server:
    name: develop.com

那么/foo/default/master/nginx.conf资源如下所示：

server {
    listen              80;
    server_name         example.com;
}

和/foo/development/master/nginx.conf这样：

server {
    listen              80;
    server_name         develop.com;
}

注意	就像环境配置的源文件一样，“配置文件”用于解析文件名，因此，如果您想要一个特定于配置文件的文件，则`//development//logback.xml`将由一个名为`logback-development.xml`的文件解析（优先于`logback.xml`）。

嵌入配置服务器

配置服务器最好作为独立应用程序运行，但如果需要，可以将其嵌入到另一个应用程序中。只需使用@EnableConfigServer注释。在这种情况下可以使用的可选属性是spring.cloud.config.server.bootstrap，它是一个标志，表示服务器应该从其自己的远程存储库配置自身。该标志默认关闭，因为它可能会延迟启动，但是当嵌入在另一个应用程序中时，以与其他应用程序相同的方式初始化是有意义的。

注意	应该是显而易见的，但请记住，如果您使用引导标志，配置服务器将需要在`bootstrap.yml`中配置其名称和存储库URI。

要更改服务器端点的位置，您可以（可选）设置spring.cloud.config.server.prefix，例如“/ config”，以提供前缀下的资源。前缀应该开始但不以“/”结尾。它被应用于配置服务器中的@RequestMappings（即Spring Boot前缀server.servletPath和server.contextPath）之下。

如果您想直接从后端存储库（而不是从配置服务器）读取应用程序的配置，这基本上是一个没有端点的嵌入式配置服务器。如果不使用@EnableConfigServer注释（仅设置spring.cloud.config.server.bootstrap=true），则可以完全关闭端点。

推送通知和Spring Cloud Bus

许多源代码存储库提供程序（例如Github，Gitlab或Bitbucket）将通过webhook通知您存储库中的更改。您可以通过提供商的用户界面将webhook配置为URL和一组感兴趣的事件。例如， Github 将使用包含提交列表的JSON主体和“X-Github-Event”等于“push”的头文件发送到webhook。如果在spring-cloud-config-monitor库中添加依赖关系并激活配置服务器中的Spring Cloud Bus，则启用“/ monitor”端点。

当Webhook被激活时，配置服务器将发送一个RefreshRemoteApplicationEvent针对他认为可能已经改变的应用程序。变更检测可以进行策略化，但默认情况下，它只是查找与应用程序名称匹配的文件的更改（例如，“foo.properties”针对的是“foo”应用程序，“application.properties”针对所有应用程序）。如果要覆盖该行为的策略是PropertyPathNotificationExtractor，它接受??请求标头和正文作为参数，并返回更改的文件路径列表。

默认配置与Github，Gitlab或Bitbucket配合使用。除了来自Github，Gitlab或Bitbucket的JSON通知之外，您还可以通过使用表单编码的身体参数path={name}通过POST为“/ monitor”来触发更改通知。这将广播到匹配“{name}”模式的应用程序（可以包含通配符）。