Spring Cloud为开发人员提供了快速构建分布式系统中一些常见模式的工具（例如配置管理，服务发现，断路器，智能路由，微代理，控制总线）。分布式系统的协调导致了样板模式, 使用Spring Cloud开发人员可以快速地支持实现这些模式的服务和应用程序。他们将在任何分布式环境中运行良好，包括开发人员自己的笔记本电脑，裸机数据中心，以及Cloud Foundry等托管平台。

版本：Dalston.RELEASE

特性

Spring Cloud专注于提供良好的开箱即用经验的典型用例和可扩展性机制覆盖。

分布式/版本化配置

服务注册和发现

路由

service - to - service调用

负载均衡

断路器

分布式消息传递

云原生应用程序

云原生是一种应用开发风格，鼓励在持续交付和价值驱动开发领域轻松采用最佳实践。相关的学科是建立12-factor Apps，其中开发实践与交付和运营目标相一致，例如通过使用声明式编程和管理和监控。Spring Cloud以多种具体方式促进这些开发风格，起点是一组功能，分布式系统中的所有组件都需要或需要时轻松访问。

许多这些功能都由Spring Boot覆盖，我们在Spring Cloud中建立。更多的由Spring Cloud提供为两个库：Spring Cloud Context和Spring Cloud Commons。Spring Cloud上下文为Spring Cloud应用程序（引导上下文，加密，刷新范围和环境端点）的ApplicationContext提供实用程序和特殊服务。Spring Cloud Commons是一组在不同的Spring Cloud实现中使用的抽象和常用类（例如Spring Cloud Netflix vs. Spring Cloud Consul）。

如果由于“非法密钥大小”而导致异常，并且您正在使用Sun的JDK，则需要安装Java加密扩展（JCE）无限强度管理策略文件。有关详细信息，请参阅以下链接：

Java 6 JCE

Java 7 JCE

Java 8 JCE

将文件解压缩到JDK / jre / lib / security文件夹（无论您使用的是哪个版本的JRE / JDK x64 / x86）。

注意

Spring Cloud根据非限制性Apache 2.0许可证发布。如果您想为文档的这一部分做出贡献，或者发现错误，请在github中找到项目中的源代码和问题跟踪器。

Spring Cloud上下文：应用程序上下文服务

Spring Boot对于如何使用Spring构建应用程序有一个看法：例如它具有常规配置文件的常规位置，以及用于常见管理和监视任务的端点。Spring Cloud建立在此之上，并添加了一些可能系统中所有组件将使用或偶尔需要的功能。

引导应用程序上下文

一个Spring Cloud应用程序通过创建一个“引导”上下文来进行操作，这个上下文是主应用程序的父上下文。开箱即用，负责从外部源加载配置属性，还解密本地外部配置文件中的属性。这两个上下文共享一个Environment，这是任何Spring应用程序的外部属性的来源。Bootstrap属性的优先级高，因此默认情况下不能被本地配置覆盖。

引导上下文使用与主应用程序上下文不同的外部配置约定，因此使用bootstrap.ymlapplication.yml（或.properties）代替引导和主上下文的外部配置。例：

bootstrap.yml

spring:

application:

name: foo

cloud:

config:

uri: ${SPRING_CONFIG_URI:http://localhost:8888}

如果您的应用程序需要服务器上的特定于应用程序的配置，那么设置spring.application.name（在bootstrap.yml或application.yml）中是个好主意。

您可以通过设置spring.cloud.bootstrap.enabled=false（例如在系统属性中）来完全禁用引导过程。

应用程序上下文层次结构

如果您从SpringApplication或SpringApplicationBuilder构建应用程序上下文，则将Bootstrap上下文添加为该上下文的父级。这是一个Spring的功能，即子上下文从其父进程继承属性源和配置文件，因此与不使用Spring Cloud Config构建相同上下文相比，“主”应用程序上下文将包含其他属性源。额外的财产来源是：

“bootstrap”：如果在Bootstrap上下文中找到任何PropertySourceLocators，则可选CompositePropertySource显示为高优先级，并且具有非空属性。一个例子是来自Spring Cloud Config服务器的属性。有关如何自定义此属性源的内容的说明，请参阅下文。

“applicationConfig：[classpath：bootstrap.yml]”（如果Spring配置文件处于活动状态，则为朋友）。如果您有一个bootstrap.yml（或属性），那么这些属性用于配置引导上下文，然后在父进程设置时将它们添加到子上下文中。它们的优先级低于application.yml（或属性）以及作为创建Spring Boot应用程序的过程的正常部分添加到子级的任何其他属性源。有关如何自定义这些属性源的内容的说明，请参阅下文。

由于属性源的排序规则，“引导”条目优先，但请注意，这些条目不包含来自bootstrap.yml的任何数据，它具有非常低的优先级，但可用于设置默认值。

您可以通过简单地设置您创建的任何ApplicationContext的父上下文来扩展上下文层次结构，例如使用自己的界面，或使用SpringApplicationBuilder方便方法（parent()，child()和sibling()）。引导环境将是您创建自己的最高级祖先的父级。层次结构中的每个上下文都将有自己的“引导”属性源（可能为空），以避免无意中将值从父级升级到其后代。层次结构中的每个上下文（原则上）也可以具有不同的spring.application.name，因此如果存在配置服务器，则不同的远程属性源。普通的Spring应用程序上下文行为规则适用于属性解析：子环境中的属性通过名称和属性源名称覆盖父项中的属性（如果子级具有与父级名称相同的属性源，一个来自父母的孩子不包括在孩子中）。

请注意，SpringApplicationBuilder允许您在整个层次结构中共享Environment，但这不是默认值。因此，兄弟情境尤其不需要具有相同的资料或财产来源，尽管它们与父母共享共同点。

改变引导位置Properties

可以使用spring.cloud.bootstrap.name（默认“引导”）或spring.cloud.bootstrap.location（默认为空）指定bootstrap.yml（或.properties）位置，例如在系统属性中。这些属性的行为类似于具有相同名称的spring.config.*变体，实际上它们用于通过在其Environment中设置这些属性来设置引导ApplicationContext。如果在正在构建的上下文中有活动的配置文件（来自spring.profiles.active或通过EnvironmentAPI）），则该配置文件中的属性也将被加载，就像常规的Spring Boot应用程序，例如来自bootstrap-development.properties的“开发”简介。

覆盖远程Properties的值

通过引导上下文添加到应用程序的属性源通常是“远程”（例如从配置服务器），并且默认情况下，不能在本地覆盖，除了在命令行上。如果要允许您的应用程序使用自己的系统属性或配置文件覆盖远程属性，则远程属性源必须通过设置spring.cloud.config.allowOverride=true（在本地设置本身不起作用）授予权限。一旦设置了该标志，就会有一些更精细的设置来控制远程属性与系统属性和应用程序本地配置的位置：spring.cloud.config.overrideNone=true覆盖任何本地属性源，spring.cloud.config.overrideSystemProperties=false如果只有系统属性和env var应该覆盖远程设置，而不是本地配置文件。

自定义引导配置

可以通过在org.springframework.cloud.bootstrap.BootstrapConfiguration键下添加条目/META-INF/spring.factories来训练引导上下文来执行任何您喜欢的操作。这是用于创建上下文的Spring@Configuration类的逗号分隔列表。您可以在此处创建要用于自动装配的主应用程序上下文的任何bean，并且还有ApplicationContextInitializer类型的@Beans的特殊合同。如果要控制启动顺序（默认顺序为“最后”），可以使用@Order标记类。

警告

添加自定义BootstrapConfiguration时，请注意，您添加的类不是错误的@ComponentScanned到您的“主”应用程序上下文中，可能不需要它们。对于您的@ComponentScan或@SpringBootApplication注释配置类尚未涵盖的启动配置类，请使用单独的包名称。

引导过程通过将初始化器注入主SpringApplication实例（即正常的Spring Boot启动顺序，无论是作为独立应用程序运行还是部署在应用程序服务器中）结束。首先，从spring.factories中找到的类创建引导上下文，然后在ApplicationContextInitializer类型的所有@Beans添加到主SpringApplication开始之前。

自定义引导属性源

引导过程添加的外部配置的默认属性源是Config Server，但您可以通过将PropertySourceLocator类型的bean添加到引导上下文（通过spring.factories）添加其他源。您可以使用此方法从其他服务器或数据库中插入其他属性。

作为一个例子，请考虑以下微不足道的自定义定位器：

@Configuration

public class CustomPropertySourceLocator implements PropertySourceLocator {

@Override

public PropertySource locate(Environment environment) {

return new MapPropertySource("customProperty",

Collections.singletonMap("property.from.sample.custom.source", "worked as intended"));

}

}

传入的Environment是要创建的ApplicationContext的Environment，即为我们提供额外的属性来源的。它将已经具有正常的Spring Boot提供的资源来源，因此您可以使用它们来定位特定于此Environment的属性源（例如通过将其绑定在spring.application.name上，如在默认情况下所做的那样Config Server属性源定位器）。

如果你在这个类中创建一个jar，然后添加一个META-INF/spring.factories包含：

org.springframework.cloud.bootstrap.BootstrapConfiguration=sample.custom.CustomPropertySourceLocator

那么“customProperty”PropertySource将显示在其类路径中包含该jar的任何应用程序中。

环境变化

应用程序将收听EnvironmentChangeEvent，并以几种标准方式进行更改（用户可以以常规方式添加ApplicationListeners附加ApplicationListeners）。当观察到EnvironmentChangeEvent时，它将有一个已更改的键值列表，应用程序将使用以下内容：

重新绑定上下文中的任何@ConfigurationPropertiesbean

为logging.level.*中的任何属性设置记录器级别

请注意，配置客户端不会通过默认轮询查找Environment中的更改，通常我们不建议检测更改的方法（尽管可以使用@Scheduled注释进行设置）。如果您有一个扩展的客户端应用程序，那么最好将EnvironmentChangeEvent广播到所有实例，而不是让它们轮询更改（例如使用Spring Cloud总线）。

EnvironmentChangeEvent涵盖了大量的刷新用例，只要您真的可以更改Environment并发布事件（这些API是公开的，部分内核为Spring）。您可以通过访问/configprops端点（普通Spring Boot执行器功能）来验证更改是否绑定到@ConfigurationPropertiesbean。例如，DataSource可以在运行时更改其maxPoolSize（由Spring Boot创建的默认DataSource是一个@ConfigurationPropertiesbean），并且动态增加容量。重新绑定@ConfigurationProperties不会覆盖另一大类用例，您需要更多的控制刷新，并且您需要更改在整个ApplicationContext上是原子的。为了解决这些担忧，我们有@RefreshScope。

刷新范围

当配置更改时，标有@RefreshScope的Spring@Bean将得到特殊处理。这解决了状态bean在初始化时只注入配置的问题。例如，如果通过Environment更改数据库URL时DataSource有开放连接，那么我们可能希望这些连接的持有人能够完成他们正在做的工作。然后下一次有人从游泳池借用一个连接，他得到一个新的URL。

刷新范围bean是在使用时初始化的懒惰代理（即当调用一个方法时），并且作用域作为初始值的缓存。要强制bean重新初始化下一个方法调用，您只需要使其缓存条目无效。

RefreshScope是上下文中的一个bean，它有一个公共方法refreshAll()来清除目标缓存中的范围内的所有bean。还有一个refresh(String)方法可以按名称刷新单个bean。此功能在/refresh端点（通过HTTP或JMX）中公开。

注意

@RefreshScope（技术上）在@Configuration类上工作，但可能会导致令人惊讶的行为：例如，这并不意味着该类中定义的所有@Beans本身都是@RefreshScope。具体来说，任何取决于这些bean的东西都不能依赖它们在刷新启动时被更新，除非它本身在@RefreshScope（在其中将重新刷新并重新注入其依赖关系），那么它们将从刷新的@Configuration）重新初始化。

加密和解密

Spring Cloud具有一个用于在本地解密属性值的Environment预处理器。它遵循与Config Server相同的规则，并通过encrypt.*具有相同的外部配置。因此，您可以使用{cipher}*格式的加密值，只要有一个有效的密钥，那么在主应用程序上下文获取Environment之前，它们将被解密。要在应用程序中使用加密功能，您需要在您的类路径中包含Spring安全性RSA（Maven协调“org.springframework.security:spring-security-rsa”），并且还需要全面强大的JCE扩展你的JVM

如果由于“非法密钥大小”而导致异常，并且您正在使用Sun的JDK，则需要安装Java加密扩展（JCE）无限强度管理策略文件。有关详细信息，请参阅以下链接：

Java 6 JCE

Java 7 JCE

Java 8 JCE

将文件解压缩到JDK / jre / lib / security文件夹（无论您使用的是哪个版本的JRE / JDK x64 / x86）。

端点

对于Spring Boot执行器应用程序，还有一些额外的管理端点：

POST到/env以更新Environment并重新绑定@ConfigurationProperties和日志级别

/refresh重新加载引导带上下文并刷新@RefreshScopebean

/restart关闭ApplicationContext并重新启动（默认情况下禁用）

/pause和/resume调用Lifecycle方法（stop()和start()ApplicationContext）

Spring Cloud Commons：普通抽象

诸如服务发现，负载平衡和断路器之类的模式适用于所有Spring Cloud客户端可以独立于实现（例如通过Eureka或Consul发现）的消耗的共同抽象层。

@EnableDiscoveryClient

Commons提供@EnableDiscoveryClient注释。这通过META-INF/spring.factories查找DiscoveryClient接口的实现。Discovery Client的实现将在org.springframework.cloud.client.discovery.EnableDiscoveryClient键下的spring.factories中添加一个配置类。DiscoveryClient实现的示例是Spring Cloud Netflix Eureka，Spring Cloud Consul发现和Spring Cloud Zookeeper发现。

默认情况下，DiscoveryClient的实现将使用远程发现服务器自动注册本地Spring Boot服务器。可以通过在@EnableDiscoveryClient中设置autoRegister=false来禁用此功能。

ServiceRegistry

Commons现在提供了一个ServiceRegistry接口，它提供了诸如register(Registration)和deregister(Registration)之类的方法，允许您提供定制的注册服务。Registration是一个标记界面。

@Configuration

@EnableDiscoveryClient(autoRegister=false)

public class MyConfiguration {

private ServiceRegistry registry;

public MyConfiguration(ServiceRegistry registry) {

this.registry = registry;

}

// called via some external process, such as an event or a custom actuator endpoint

public void register() {

Registration registration = constructRegistration();

this.registry.register(registration);

}

}

每个ServiceRegistry实现都有自己的Registry实现。

服务部门自动注册

默认情况下，ServiceRegistry实现将自动注册正在运行的服务。要禁用该行为，有两种方法。您可以设置@EnableDiscoveryClient(autoRegister=false)永久禁用自动注册。您还可以设置spring.cloud.service-registry.auto-registration.enabled=false以通过配置禁用该行为。

服务注册执行器端点

Commons提供/service-registry致动器端点。该端点依赖于Spring应用程序上下文中的Registrationbean。通过GET调用/service-registry/instance-status将返回Registration的状态。具有String主体的同一端点的POST将将当前Registration的状态更改为新值。请参阅您正在使用的ServiceRegistry实现的文档，以获取更新状态的允许值和为状态获取的值。

Spring RestTemplate作为负载平衡器客户端

RestTemplate可以自动配置为使用功能区。要创建负载平衡RestTemplate创建RestTemplate@Bean并使用@LoadBalanced限定符。

警告

通过自动配置不再创建RestTemplatebean。它必须由单个应用程序创建。

@Configuration

public class MyConfiguration {

@LoadBalanced

@Bean

RestTemplate restTemplate() {

return new RestTemplate();

}

}

public class MyClass {

@Autowired

private RestTemplate restTemplate;

public String doOtherStuff() {

String results = restTemplate.getForObject("http://stores/stores", String.class);

return results;

}

}

URI需要使用虚拟主机名（即服务名称，而不是主机名）。Ribbon客户端用于创建完整的物理地址。有关如何设置RestTemplate的详细信息，请参阅RibbonAutoConfiguration。

重试失败的请求

负载平衡RestTemplate可以配置为重试失败的请求。默认情况下，该逻辑被禁用，您可以通过将Spring重试添加到应用程序的类路径来启用它。负载平衡RestTemplate将符合与重试失败请求相关的一些Ribbon配置值。如果要在类路径中使用Spring重试来禁用重试逻辑，则可以设置spring.cloud.loadbalancer.retry.enabled=false。您可以使用的属性是client.ribbon.MaxAutoRetries，client.ribbon.MaxAutoRetriesNextServer和client.ribbon.OkToRetryOnAllOperations。请参阅Ribbon文档，了解属性的具体内容。

注意

上述示例中的client应替换为您的Ribbon客户端名称。

多个RestTemplate对象

如果你想要一个没有负载平衡的RestTemplate，创建一个RestTemplatebean并注入它。要创建@Bean时，使用@LoadBalanced限定符来访问负载平衡RestTemplate。

重要

请注意下面示例中的普通RestTemplate声明的@Primary注释，以消除不合格的@Autowired注入。

@Configuration

public class MyConfiguration {

@LoadBalanced

@Bean

RestTemplate loadBalanced() {

return new RestTemplate();

}

@Primary

@Bean

RestTemplate restTemplate() {

return new RestTemplate();

}

}

public class MyClass {

@Autowired

private RestTemplate restTemplate;

@Autowired

@LoadBalanced

private RestTemplate loadBalanced;

public String doOtherStuff() {

return loadBalanced.getForObject("http://stores/stores", String.class);

}

public String doStuff() {

return restTemplate.getForObject("http://example.com", String.class);

}

}

小费

如果您看到错误java.lang.IllegalArgumentException: Can not set org.springframework.web.client.RestTemplate field com.my.app.Foo.restTemplate to com.sun.proxy.$Proxy89，请尝试注入RestOperations或设置spring.aop.proxyTargetClass=true。

忽略网络接口

有时，忽略某些命名网络接口是有用的，因此可以将其从服务发现注册中排除（例如，在Docker容器中运行）。可以设置正则表达式的列表，这将导致所需的网络接口被忽略。以下配置将忽略“docker0”接口和以“veth”开头的所有接口。

application.yml

spring:

cloud:

inetutils:

ignoredInterfaces:

- docker0

- veth.*

您还可以强制使用正则表达式列表中指定的网络地址：

application.yml

spring:

cloud:

inetutils:

preferredNetworks:

- 192.168

- 10.0

您也可以强制仅使用站点本地地址。有关更多详细信息，请参阅Inet4Address.html.isSiteLocalAddress（））是什么是站点本地地址。

application.yml

spring:

cloud:

inetutils:

useOnlySiteLocalInterfaces: true

Spring Cloud Config

Dalston.RELEASE

Spring Cloud Config为分布式系统中的外部配置提供服务器和客户端支持。使用Config Server，您可以在所有环境中管理应用程序的外部属性。客户端和服务器上的概念映射与SpringEnvironment和PropertySource抽象相同，因此它们与Spring应用程序非常契合，但可以与任何以任何语言运行的应用程序一起使用。随着应用程序通过从开发人员到测试和生产的部署流程，您可以管理这些环境之间的配置，并确定应用程序具有迁移时需要运行的一切。服务器存储后端的默认实现使用git，因此它轻松支持标签版本的配置环境，以及可以访问用于管理内容的各种工具。很容易添加替代实现，并使用Spring配置将其插入。

快速开始

启动服务器：

$ cd spring-cloud-config-server

$ ../mvnw spring-boot:run

该服务器是一个Spring Boot应用程序，所以您可以从IDE运行它，而不是喜欢（主类是ConfigServerApplication）。然后尝试一个客户端：

$ curl localhost:8888/foo/development

{"name":"development","label":"master","propertySources":[

{"name":"https://github.com/scratches/config-repo/foo-development.properties","source":{"bar":"spam"}},

{"name":"https://github.com/scratches/config-repo/foo.properties","source":{"foo":"bar"}}

]}

定位资源的默认策略是克隆一个git仓库（在spring.cloud.config.server.git.uri），并使用它来初始化一个迷你SpringApplication。小应用程序的Environment用于枚举属性源并通过JSON端点发布。

HTTP服务具有以下格式的资源：

/{application}/{profile}[/{label}]

/{application}-{profile}.yml

/{label}/{application}-{profile}.yml

/{application}-{profile}.properties

/{label}/{application}-{profile}.properties

其中“应用程序”作为SpringApplication中的spring.config.name注入（即常规的Spring Boot应用程序中通常是“应用程序”），“配置文件”是活动配置文件（或逗号分隔列表的属性），“label”是可选的git标签（默认为“master”）。

Spring Cloud Config服务器从git存储库（必须提供）为远程客户端提供配置：

spring:

cloud:

config:

server:

git:

uri: https://github.com/spring-cloud-samples/config-repo

客户端使用

要在应用程序中使用这些功能，只需将其构建为依赖于spring-cloud-config-client的Spring引导应用程序（例如，查看配置客户端或示例应用程序的测试用例）。添加依赖关系的最方便的方法是通过Spring Boot启动器org.springframework.cloud:spring-cloud-starter-config。还有一个Maven用户的父pom和BOM（spring-cloud-starter-parent）和用于Gradle和Spring CLI用户的Spring IO版本管理属性文件。示例Maven配置：

的pom.xml

org.springframework.boot

spring-boot-starter-parent

1.3.5.RELEASE

org.springframework.cloud

spring-cloud-dependencies

Brixton.RELEASE

pom

import

org.springframework.cloud

spring-cloud-starter-config

org.springframework.boot

spring-boot-starter-test

test

org.springframework.boot

spring-boot-maven-plugin

那么你可以创建一个标准的Spring Boot应用程序，像这个简单的HTTP服务器：

@SpringBootApplication

@RestController

public class Application {

@RequestMapping("/")

public String home() {

return "Hello World!";

}

public static void main(String[] args) {

SpringApplication.run(Application.class, args);

}

}

当它运行它将从端口8888上的默认本地配置服务器接收外部配置，如果它正在运行。要修改启动行为，您可以使用bootstrap.properties（如application.properties）更改配置服务器的位置，但用于应用程序上下文的引导阶段），例如

spring.cloud.config.uri: http://myconfigserver.com

引导属性将在/env端点中显示为高优先级属性源，例如

$ curl localhost:8080/env

{

"profiles":[],

"configService:https://github.com/spring-cloud-samples/config-repo/bar.properties":{"foo":"bar"},

"servletContextInitParams":{},

"systemProperties":{...},

...

}

（名为“configService：<远程存储库的URL> / <文件名>”的属性源包含值为“bar”的属性“foo”，是最高优先级）。

注意

属性源名称中的URL是git存储库，而不是配置服务器URL。

Spring Cloud Config服务器

服务器为外部配置（名称值对或等效的YAML内容）提供了基于资源的HTTP。服务器可以使用@EnableConfigServer注释轻松嵌入到Spring Boot应用程序中。所以这个应用程序是一个配置服务器：

ConfigServer.java

@SpringBootApplication

@EnableConfigServer

public class ConfigServer {

public static void main(String[] args) {

SpringApplication.run(ConfigServer.class, args);

}

}

像所有的默认端口8080上运行的所有Spring Boot应用程序一样，但您可以通过各种方式将其切换到常规端口8888。最简单的也是设置一个默认配置库，它是通过启动它的spring.config.name=configserver（在Config Server jar中有一个configserver.yml）。另一个是使用你自己的application.properties，例如

application.properties

server.port: 8888

spring.cloud.config.server.git.uri: file://${user.home}/config-repo

其中${user.home}/config-repo是包含YAML和属性文件的git仓库。

注意

在Windows中，如果文件URL为绝对驱动器前缀，例如file:///${user.home}/config-repo，则需要额外的“/”。

小费

以下是上面示例中创建git仓库的方法：

$ cd $HOME

$ mkdir config-repo

$ cd config-repo

$ git init .

$ echo info.foo: bar > application.properties

$ git add -A .

$ git commit -m "Add application.properties"

警告

使用本地文件系统进行git存储库仅用于测试。使用服务器在生产环境中托管配置库。

警告

如果您只保留文本文件，则配置库的初始克隆将会快速有效。如果您开始存储二进制文件，尤其是较大的文件，则可能会遇到服务器中第一个配置请求和/或内存不足错误的延迟。

环境库

您要在哪里存储配置服务器的配置数据？管理此行为的策略是EnvironmentRepository，服务于Environment对象。此Environment是SpringEnvironment（包括propertySources作为主要功能）的域的浅层副本。Environment资源由三个变量参数化：

{application}映射到客户端的“spring.application.name”;

{profile}映射到客户端上的“spring.profiles.active”（逗号分隔列表）;和

{label}这是一个服务器端功能，标记“版本”的配置文件集。

存储库实现通常表现得像一个Spring Boot应用程序从“spring.config.name”等于{application}参数加载配置文件，“spring.profiles.active”等于{profiles}参数。配置文件的优先级规则也与常规启动应用程序相同：活动配置文件优先于默认配置，如果有多个配置文件，则最后一个获胜（例如向Map添加条目）。

示例：客户端应用程序具有此引导配置：

bootstrap.yml

spring:

application:

name: foo

profiles:

active: dev,mysql

（通常使用Spring Boot应用程序，这些属性也可以设置为环境变量或命令行参数）。

如果存储库是基于文件的，则服务器将从application.yml创建Environment（在所有客户端之间共享），foo.yml（以foo.yml优先））。如果YAML文件中有文件指向Spring配置文件，那么应用的优先级更高（按照列出的配置文件的顺序），并且如果存在特定于配置文件的YAML（或属性）文件，那么这些文件也应用于优先级高于默认值。较高优先级转换为Environment之前列出的PropertySource。（这些规则与独立的Spring Boot应用程序相同。）

Git后端

EnvironmentRepository的默认实现使用Git后端，这对于管理升级和物理环境以及审核更改非常方便。要更改存储库的位置，可以在Config Server中设置“spring.cloud.config.server.git.uri”配置属性（例如application.yml）。如果您使用file:前缀进行设置，则应从本地存储库中工作，以便在没有服务器的情况下快速方便地启动，但在这种情况下，服务器将直接在本地存储库上进行操作，而不会克隆如果它不是裸机，因为配置服务器永远不会更改“远程”资源库）。要扩展Config Server并使其高度可用，您需要将服务器的所有实例指向同一个存储库，因此只有共享文件系统才能正常工作。即使在这种情况下，最好使用共享文件系统存储库的ssh:协议，以便服务器可以将其克隆并使用本地工作副本作为缓存。

该存储库实现将HTTP资源的{label}参数映射到git标签（提交ID，分支名称或标签）。如果git分支或标签名称包含斜杠（“/”），则应使用特殊字符串“（_）”指定HTTP URL中的标签，以避免与其他URL路径模糊。例如，如果标签为foo/bar，则替换斜杠将导致标签看起来像foo(_)bar。如果您使用像curl这样的命令行客户端（例如使用引号将其从shell中转出来），请小心URL中的方括号。

Git URI中的占位符

Spring Cloud Config服务器支持一个Git仓库URL，其中包含{application}和{profile}（以及{label}）的占位符，如果需要，请记住标签应用为git标签）。因此，您可以使用（例如）轻松支持“每个应用程序的一个repo”策略：

spring:

cloud:

config:

server:

git:

uri: https://github.com/myorg/{application}

或使用类似模式但使用{profile}的“每个配置文件一个”策略。

模式匹配和多个存储库

还可以通过应用程序和配置文件名称的模式匹配来支持更复杂的需求。模式格式是带有通配符的{application}/{profile}名称的逗号分隔列表（可能需要引用以通配符开头的模式）。例：

spring:

cloud:

config:

server:

git:

uri: https://github.com/spring-cloud-samples/config-repo

repos:

simple: https://github.com/simple/config-repo

special:

pattern: special*/dev*,*special*/dev*

uri: https://github.com/special/config-repo

local:

pattern: local*

uri: file:/home/configsvc/config-repo

如果{application}/{profile}不匹配任何模式，它将使用在“spring.cloud.config.server.git.uri”下定义的默认uri。在上面的例子中，对于“简单”存储库，模式是simple/*（即所有配置文件中只匹配一个名为“简单”的应用程序）。“本地”存储库与所有配置文件中以“local”开头的所有应用程序名称匹配（将/*后缀自动添加到任何没有配置文件匹配器的模式）。

注意

在上述“简单”示例中使用的“单行”快捷方式只能在唯一要设置的属性为URI的情况下使用。如果您需要设置其他任何内容（凭据，模式等），则需要使用完整的表单。

repo中的pattern属性实际上是一个数组，因此您可以使用属性文件中的YAML数组（或[0]，[1]等后缀）绑定到多个模式。如果要运行具有多个配置文件的应用程序，则可能需要执行此操作。例：

spring:

cloud:

config:

server:

git:

uri: https://github.com/spring-cloud-samples/config-repo

repos:

development:

pattern:

- */development

- */staging

uri: https://github.com/development/config-repo

staging:

pattern:

- */qa

- */production

uri: https://github.com/staging/config-repo

注意

Spring Cloud将猜测包含不在*中的配置文件的模式意味着您实际上要匹配从此模式开始的配置文件列表（因此*/staging是["*/staging", "*/staging,*"]）。这是常见的，您需要在本地的“开发”配置文件中运行应用程序，但也可以远程运行“云”配置文件。

每个存储库还可以选择将配置文件存储在子目录中，搜索这些目录的模式可以指定为searchPaths。例如在顶层：

spring:

cloud:

config:

server:

git:

uri: https://github.com/spring-cloud-samples/config-repo

searchPaths: foo,bar*

在此示例中，服务器搜索顶级和“foo /”子目录以及名称以“bar”开头的任何子目录中的配置文件。

默认情况下，首次请求配置时，服务器克隆远程存储库。服务器可以配置为在启动时克隆存储库。例如在顶层：

spring:

cloud:

config:

server:

git:

uri: https://git/common/config-repo.git

repos:

team-a:

pattern: team-a-*

cloneOnStart: true

uri: http://git/team-a/config-repo.git

team-b:

pattern: team-b-*

cloneOnStart: false

uri: http://git/team-b/config-repo.git

team-c:

pattern: team-c-*

uri: http://git/team-a/config-repo.git

在此示例中，服务器在启动之前克隆了team-a的config-repo，然后它接受任何请求。所有其他存储库将不被克隆，直到请求从存储库配置。

注意

在配置服务器启动时设置要克隆的存储库可以帮助在配置服务器启动时快速识别错误配置的源（例如，无效的存储库URI）。配置源不启用cloneOnStart时，配置服务器可能会成功启动配置错误或无效的配置源，而不会检测到错误，直到应用程序从该配置源请求配置为止。

认证

要在远程存储库上使用HTTP基本身份验证，请分别添加“username”和“password”属性（不在URL中），例如

spring:

cloud:

config:

server:

git:

uri: https://github.com/spring-cloud-samples/config-repo

username: trolley

password: strongpassword

如果您不使用HTTPS和用户凭据，当您将密钥存储在默认目录（~/.ssh）中，并且uri指向SSH位置时，SSH也应该开箱即用，例如“git@github.com：配置/云配置”。必须在~/.ssh/known_hosts文件中存在Git服务器的条目，并且它是ssh-rsa格式。其他格式（如ecdsa-sha2-nistp256）不受支持。为了避免意外，您应该确保Git服务器的known_hosts文件中只有一个条目，并且与您提供给配置服务器的URL匹配。如果您在URL中使用了主机名，那么您希望在known_hosts文件中具有这一点，而不是IP。使用JGit访问存储库，因此您发现的任何文档都应适用。HTTPS代理设置可以~/.git/config设置，也可以通过系统属性（-Dhttps.proxyHost和-Dhttps.proxyPort）与任何其他JVM进程相同。

小费

如果您不知道~/.git目录使用git config --global来处理设置的位置（例如git config --global http.sslVerify false）。

使用AWS CodeCommit进行认证

AWS CodeCommit认证也可以完成。当从命令行使用Git时，AWS CodeCommit使用身份验证助手。该帮助器不与JGit库一起使用，因此如果Git URI与AWS CodeCommit模式匹配，则将创建用于AWS CodeCommit的JGit CredentialProvider。AWS CodeCommit URI始终看起来像https：//git-codecommit.$ {AWS_REGION} .amazonaws.com / $ {repopath}。

如果您使用AWS CodeCommit URI提供用户名和密码，那么这些URI必须是用于访问存储库的AWS accessKeyId和secretAccessKey。如果不指定用户名和密码，则将使用AWS默认凭据提供程序链检索accessKeyId和secretAccessKey。

如果您的Git URI与CodeCommit URI模式（上述）匹配，则必须在用户名和密码或默认凭据提供程序链支持的某个位置中提供有效的AWS凭据。AWS EC2实例可以使用EC2实例的IAM角色。

注意：aws-java-sdk-core jar是一个可选的依赖关系。如果aws-java-sdk-core jar不在您的类路径上，则无论git服务器URI如何，都将不会创建AWS代码提交凭据提供程序。

Git搜索路径中的占位符

Spring Cloud Config服务器还支持具有{application}和{profile}（以及{label}（如果需要））占位符的搜索路径。例：

spring:

cloud:

config:

server:

git:

uri: https://github.com/spring-cloud-samples/config-repo

searchPaths: '{application}'

在资源库中搜索与目录（以及顶级）相同名称的文件。通配符在具有占位符的搜索路径中也是有效的（搜索中包含任何匹配的目录）。

力拉入Git存储库

如前所述Spring Cloud Config服务器克隆远程git存储库，如果某种方式本地副本变脏（例如，通过操作系统进程更改文件夹内容），则Spring Cloud Config服务器无法从远程存储库更新本地副本。

要解决这个问题，有一个force-pull属性，如果本地副本是脏的，将使Spring Cloud Config Server强制从远程存储库拉。例：

spring:

cloud:

config:

server:

git:

uri: https://github.com/spring-cloud-samples/config-repo

force-pull: true

如果您有多个存储库配置，则可以为每个存储库配置force-pull属性。例：

spring:

cloud:

config:

server:

git:

uri: https://git/common/config-repo.git

force-pull: true

repos:

team-a:

pattern: team-a-*

uri: http://git/team-a/config-repo.git

force-pull: true

team-b:

pattern: team-b-*

uri: http://git/team-b/config-repo.git

force-pull: true

team-c:

pattern: team-c-*

uri: http://git/team-a/config-repo.git

注意

force-pull属性的默认值为false。

版本控制后端文件系统使用

警告

使用基于VCS的后端（git，svn）文件被检出或克隆到本地文件系统。默认情况下，它们放在系统临时目录中，前缀为config-repo-。在linux上，例如可以是/tmp/config-repo-。一些操作系统会定期清除临时目录。这可能会导致意外的行为，例如缺少属性。为避免此问题，请通过将spring.cloud.config.server.git.basedir或spring.cloud.config.server.svn.basedir设置为不驻留在系统临时结构中的目录来更改Config Server使用的目录。

文件系统后端

配置服务器中还有一个不使用Git的“本机”配置文件，只是从本地类路径或文件系统加载配置文件（您想要指向的任何静态URL“spring.cloud.config.server .native.searchLocations“）。要使用本机配置文件，只需使用“spring.profiles.active = native”启动Config Server。

注意

请记住使用file:前缀的文件资源（缺省没有前缀通常是classpath）。与任何Spring Boot配置一样，您可以嵌入${}样式的环境占位符，但请记住，Windows中的绝对路径需要额外的“/”，例如file:///${user.home}/config-repo

警告

searchLocations的默认值与本地Spring Boot应用程序（所以[classpath:/, classpath:/config, file:./, file:./config]）相同。这不会将application.properties从服务器暴露给所有客户端，因为在发送到客户端之前，服务器中存在的任何属性源都将被删除。

小费

文件系统后端对于快速入门和测试是非常好的。要在生产中使用它，您需要确保文件系统是可靠的，并在配置服务器的所有实例中共享。

搜索位置可以包含{application}，{profile}和{label}的占位符。以这种方式，您可以隔离路径中的目录，并选择一个有用的策略（例如每个应用程序的子目录或每个配置文件的子目录）。

如果您不在搜索位置使用占位符，则该存储库还将HTTP资源的{label}参数附加到搜索路径上的后缀，因此属性文件将从每个搜索位置加载并具有相同名称的子目录作为标签（标记的属性在Spring环境中优先）。因此，没有占位符的默认行为与添加以/{label}/. For example `file:/tmp/config结尾的搜索位置与file:/tmp/config,file:/tmp/config/{label}相同

Vault后端

Spring Cloud Config服务器还支持Vault作为后端。

Vault是安全访问秘密的工具。一个秘密是你想要严格控制访问的任何东西，如API密钥，密码，证书等等。Vault为任何秘密提供统一的界面，同时提供严格的访问控制和记录详细的审核日志。

有关Vault的更多信息，请参阅Vault快速入门指南。

要使配置服务器使用Vault后端，您必须使用vault配置文件运行配置服务器。例如在配置服务器的application.properties中，您可以添加spring.profiles.active=vault。

默认情况下，配置服务器将假定您的Vault服务器正在运行于http://127.0.0.1:8200。它还将假定后端名称为secret，密钥为application。所有这些默认值都可以在配置服务器的application.properties中配置。以下是可配置Vault属性的表。所有属性前缀为spring.cloud.config.server.vault。

名称默认值

host

127.0.0.1

port

8200

scheme

HTTP

backend

秘密

defaultKey

应用

profileSeparator

,

所有可配置的属性可以在org.springframework.cloud.config.server.environment.VaultEnvironmentRepository找到。

运行配置服务器后，可以向服务器发出HTTP请求，以从Vault后端检索值。为此，您需要为Vault服务器创建一个令牌。

首先放置一些数据给你Vault。例如

$ vault write secret/application foo=bar baz=bam

$ vault write secret/myapp foo=myappsbar

现在，将HTTP请求发送给您的配置服务器以检索值。

$ curl -X "GET" "http://localhost:8888/myapp/default" -H "X-Config-Token: yourtoken"

在提出上述要求后，您应该会看到类似的回复。

{

"name":"myapp",

"profiles":[

"default"

],

"label":null,

"version":null,

"state":null,

"propertySources":[

{

"name":"vault:myapp",

"source":{

"foo":"myappsbar"

}

},

{

"name":"vault:application",

"source":{

"baz":"bam",

"foo":"bar"

}

}

]

}

多个Properties来源

使用Vault时，您可以为应用程序提供多个属性源。例如，假设您已将数据写入Vault中的以下路径。

secret/myApp,dev

secret/myApp

secret/application,dev

secret/application

写入secret/application的Properties可用于使用配置服务器的所有应用程序。名称为myApp的应用程序将具有写入secret/myApp和secret/application的任何属性。当myApp启用dev配置文件时，写入所有上述路径的属性将可用，列表中第一个路径中的属性优先于其他路径。

与所有应用共享配置

基于文件的存储库

使用基于文件（即git，svn和native）的存储库，文件名为application*的资源在所有客户端应用程序（所以application.properties，application.yml，application-*.properties等）之间共享）。您可以使用这些文件名的资源来配置全局默认值，并根据需要将其覆盖应用程序特定的文件。

#_property_overrides [属性覆盖]功能也可用于设置全局默认值，并且允许占位符应用程序在本地覆盖它们。

小费

使用“本机”配置文件（本地文件系统后端），建议您使用不属于服务器自身配置的显式搜索位置。否则，默认搜索位置中的application*资源将被删除，因为它们是服务器的一部分。

Vault服务器

当使用Vault作为后端时，可以通过将配置放在secret/application中与所有应用程序共享配置。例如，如果您运行此Vault命令

$ vault write secret/application foo=bar baz=bam

使用配置服务器的所有应用程序都可以使用属性foo和baz。

复合环境库

在某些情况下，您可能希望从多个环境存储库中提取配置数据。为此，只需在配置服务器的应用程序属性或YAML文件中启用多个配置文件即可。例如，如果您要从Git存储库以及SVN存储库中提取配置数据，那么您将为配置服务器设置以下属性。

spring:

profiles:

active: git, svn

cloud:

config:

server:

svn:

uri: file:///path/to/svn/repo

order: 2

git:

uri: file:///path/to/git/repo

order: 1

除了指定URI的每个repo之外，还可以指定order属性。order属性允许您指定所有存储库的优先级顺序。order属性的数值越低，优先级越高。存储库的优先顺序将有助于解决包含相同属性的值的存储库之间的任何潜在冲突。

注意

从环境仓库检索值时的任何类型的故障将导致整个复合环境的故障。

注意

当使用复合环境时，重要的是所有repos都包含相同的标签。如果您有类似于上述的环境，并且使用标签master请求配置数据，但是SVN repo不包含称为master的分支，则整个请求将失败。

自定义复合环境库

除了使用来自Spring Cloud的环境存储库之外，还可以提供自己的EnvironmentRepositorybean作为复合环境的一部分。要做到这一点，你的bean必须实现EnvironmentRepository接口。如果要在复合环境中控制自定义EnvironmentRepository的优先级，您还应该实现Ordered接口并覆盖getOrdered方法。如果您不实现Ordered接口，那么您的EnvironmentRepository将被赋予最低优先级。

属性覆盖

配置服务器具有“覆盖”功能，允许操作员为应用程序使用普通的Spring Boot钩子不会意外更改的所有应用程序提供配置属性。要声明覆盖，只需将名称/值对的地图添加到spring.cloud.config.server.overrides。例如

spring:

cloud:

config:

server:

overrides:

foo: bar

将导致配置客户端的所有应用程序独立于自己的配置读取foo=bar。（当然，应用程序可以以任何方式使用Config Server中的数据，因此覆盖不可强制执行，但如果它们是Spring Cloud Config客户端，则它们确实提供有用的默认行为。）

小费

通过使用反斜杠（“”）来转义“$”或“{”，例如${app.foo:bar}解析，可以转义正常的Spring具有“$ {}”的环境占位符到“bar”，除非应用程序提供自己的“app.foo”。请注意，在YAML中，您不需要转义反斜杠本身，而是在您执行的属性文件中配置服务器上的覆盖。

您可以通过在远程存储库中设置标志spring.cloud.config.overrideNone=true（默认为false），将客户端中所有覆盖的优先级更改为更为默认值，允许应用程序在环境变量或系统属性中提供自己的值。

健康指标

配置服务器附带运行状况指示器，检查配置的EnvironmentRepository是否正常工作。默认情况下，它要求EnvironmentRepository应用程序名称为app，default配置文件和EnvironmentRepository实现提供的默认标签。

您可以配置运行状况指示器以检查更多应用程序以及自定义配置文件和自定义标签，例如

spring:

cloud:

config:

server:

health:

repositories:

myservice:

label: mylabel

myservice-dev:

name: myservice

profiles: development

您可以通过设置spring.cloud.config.server.health.enabled=false来禁用运行状况指示器。

安全

您可以以任何对您有意义的方式（从物理网络安全性到OAuth2承载令牌）保护您的Config Server，并且Spring Security和Spring Boot可以轻松做任何事情。

要使用默认的Spring Boot配置的HTTP Basic安全性，只需在类路径中包含Spring Security（例如通过spring-boot-starter-security）。默认值为“user”的用户名和随机生成的密码，这在实践中不会非常有用，因此建议您配置密码（通过security.user.password）并对其进行加密（请参阅下文的说明怎么做）。

加密和解密

重要

先决条件：要使用加密和解密功能，您需要在JVM中安装全面的JCE（默认情况下不存在）。您可以从Oracle下载“Java加密扩展（JCE）无限强度管理策略文件”，并按照安装说明（实际上将JRE lib / security目录中的2个策略文件替换为您下载的文件）。

如果远程属性源包含加密内容（以{cipher}开头的值），则在通过HTTP发送到客户端之前，它们将被解密。这种设置的主要优点是，当它们“静止”时，属性值不必是纯文本（例如在git仓库中）。如果值无法解密，则从属性源中删除该值，并添加具有相同键的附加属性，但以“无效”作为前缀。和“不适用”的值（通常为“”）。这主要是为了防止密码被用作密码并意外泄漏。

如果要为config客户端应用程序设置远程配置存储库，可能会包含一个application.yml，例如：

application.yml

spring:

datasource:

username: dbuser

password: '{cipher}FKSAJDFGYOS8F7GLHAKERGFHLSAJ'

.properties文件中的加密值不能用引号括起来，否则不会解密该值：

application.properties

spring.datasource.username: dbuser

spring.datasource.password: {cipher}FKSAJDFGYOS8F7GLHAKERGFHLSAJ

您可以安全地将此纯文本推送到共享git存储库，并且保密密码。

服务器还暴露了/encrypt和/decrypt端点（假设这些端点将被保护，并且只能由授权代理访问）。如果您正在编辑远程配置文件，可以使用Config Server通过POST到/encrypt端点来加密值，例如

$ curl localhost:8888/encrypt -d mysecret

682bc583f4641835fa2db009355293665d2647dade3375c0ee201de2a49f7bda

注意

如果要加密的值具有需要进行URL编码的字符，则应使用--data-urlencode选项curl来确保它们已正确编码。

逆向操作也可通过/decrypt获得（如果服务器配置了对称密钥或全密钥对）：

$ curl localhost:8888/decrypt -d 682bc583f4641835fa2db009355293665d2647dade3375c0ee201de2a49f7bda

mysecret

小费

如果您使用curl进行测试，则使用--data-urlencode（而不是-d）或设置显式Content-Type: text/plain，以确保在有特殊字符时正确地对数据进行编码（'+'特别是棘手）。

将加密的值添加到{cipher}前缀，然后再将其放入YAML或属性文件中，然后再提交并将其推送到远程可能不安全的存储区。

/encrypt和/decrypt端点也都接受/*/{name}/{profiles}形式的路径，当客户端调用到主环境资源时，可以用于每个应用程序（名称）和配置文件控制密码。

注意

为了以这种细微的方式控制密码，您还必须提供一种TextEncryptorLocator类型的@Bean，可以为每个名称和配置文件创建不同的加密器。默认提供的不会这样做（所有加密使用相同的密钥）。

spring命令行客户端（安装了Spring Cloud CLI扩展）也可以用于加密和解密，例如

$ spring encrypt mysecret --key foo

682bc583f4641835fa2db009355293665d2647dade3375c0ee201de2a49f7bda

$ spring decrypt --key foo 682bc583f4641835fa2db009355293665d2647dade3375c0ee201de2a49f7bda

mysecret

要在文件中使用密钥（例如用于加密的RSA公钥），使用“@”键入键值，并提供文件路径，例如

$ spring encrypt mysecret --key @${HOME}/.ssh/id_rsa.pub

AQAjPgt3eFZQXwt8tsHAVv/QHiY5sI2dRcR+...

关键参数是强制性的（尽管有一个--前缀）。

密钥管理

Config Server可以使用对称（共享）密钥或非对称密钥（RSA密钥对）。非对称选择在安全性方面是优越的，但是使用对称密钥往往更方便，因为它只是配置的一个属性值。

要配置对称密钥，您只需要将encrypt.key设置为一个秘密字符串（或使用环境变量ENCRYPT_KEY将其从纯文本配置文件中删除）。

要配置非对称密钥，您可以将密钥设置为PEM编码的文本值（encrypt.key），也可以通过密钥库设置密钥（例如由JDK附带的keytool实用程序创建）。密钥库属性为encrypt.keyStore.*，*等于

location（aResource位置），

password（解锁密钥库）和

alias（以识别商店中使用的密钥）。

使用公钥进行加密，需要私钥进行解密。因此，原则上您只能在服务器中配置公钥，如果您只想进行加密（并准备使用私钥本地解密值）。实际上，您可能不想这样做，因为它围绕所有客户端传播密钥管理流程，而不是将其集中在服务器中。另一方面，如果您的配置服务器真的相对不安全，并且只有少数客户端需要加密的属性，这是一个有用的选项。

创建用于测试的密钥库

要创建一个密钥库进行测试，您可以执行以下操作：

$ keytool -genkeypair -alias mytestkey -keyalg RSA

-dname "CN=Web Server,OU=Unit,O=Organization,L=City,S=State,C=US"

-keypass changeme -keystore server.jks -storepass letmein

将server.jks文件放在类路径（例如）中，然后在您的application.yml中配置服务器：

encrypt:

keyStore:

location: classpath:/server.jks

password: letmein

alias: mytestkey

secret: changeme

使用多个键和键旋转

除了加密属性值中的{cipher}前缀之外，配置服务器在（Base64编码）密文开始前查找{name:value}前缀（零或多个）。密钥被传递给TextEncryptorLocator，它可以执行找到密码的TextEncryptor所需的任何逻辑。如果配置了密钥库（encrypt.keystore.location），默认定位器将使用“key”前缀提供的别名，即使用如下密码查找存储中的密钥：

foo:

bar: `{cipher}{key:testkey}...`

定位器将寻找一个名为“testkey”的键。也可以通过前缀中的{secret:…​}值提供一个秘密，但是如果不是默认值，则使用密钥库密码（这是您在构建密钥库时获得的，并且不指定密码）。如果你这样做提供一个秘密建议你也加密使用自定义SecretLocator的秘密。

如果密钥只用于加密几个字节的配置数据（即它们没有在其他地方使用），则密码转换几乎不是必需的，但是如果存在安全漏洞，有时您可能需要更改密钥实例。在这种情况下，所有客户端都需要更改其源配置文件（例如，以git格式），并在所有密码中使用新的{key:…​}前缀，当然事先检查密钥别名在配置服务器密钥库中是否可用。

小费

如果要让Config Server处理所有加密以及解密，也可以将{name:value}前缀添加到发布到/encrypt端点的明文中。

服务加密Properties

有时您希望客户端在本地解密配置，而不是在服务器中进行配置。在这种情况下，您仍然可以拥有/加密和解密端点（如果您提供encrypt.*配置来定位密钥），但是您需要使用spring.cloud.config.server.encrypt.enabled=false明确地关闭传出属性的解密。如果您不关心端点，那么如果您既不配置密钥也不配置使能的标志，则应该起作用。

服务替代格式

来自环境端点的默认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;

s