官方文档地址为：http://cloud.spring.io/spring-cloud-static/Dalston.SR2/#_serving_alternative_formats

文中例子我做了一些测试在：http://git.oschina.net/dreamingodd/spring-cloud-preparation

官方项目：https://github.com/spring-cloud-samples/config-repo

6.提供替代格式

由于Spring应用直接映射到环境抽象，来自环境链接的默认JSON格式完全适用于Spring应用的消费。如果愿意，开发人员可以通过给资源路径加上后缀的方式来使用YAML或Java属性来消费同样的数据。这对于不关心JSON链接返回结构的应用消费或其提供的额外元数据可能很有帮助，例如一个不使用Spring的应用就可以直接用这种方式。

YAML和属性表示有一个额外的标识（作为布尔查询参数resolvePlaceholders提供）用于标记标准Spring ${}格式的源文件中的占位符，在渲染之前尽可能在输出中解析。对于不了解Spring占位符约定的消费者来说，这是一个有用的功能。

注意 使用YAML或属性格式有一些限制，主要是与元数据的丢失有关。JSON格式是一个属性源的有序列表结构，例如，名称与源相关联。即使属性值有多个源，而且源属性文件的名称已丢失，YAML和属性表会合并成一个映射。YAML表示不必是后端仓库中YAML源的忠实表示：它由明文属性源的列表构成，而且必须对密钥的形式作出假设。

7.Serving Plain Text 提供明文

应用程序根据环境可能需要通用的纯文本配置文件，而不是环境抽象（或YAML中的其他替代表示或属性格式）。配置中心提供这些附属链接，/{name}/{profile}/{label}/{path}，其中的"name","profile"等的含义与常规环境链接相同，只有"path"是一个文件名(如log.xml)。此链接的源文件通过和环境链接同样的方式定位：与属性或YAML文件具有相同的搜索路径，但它只匹配符合的第一个，而不是聚合所有匹配的资源。

当定位了一个源之后，有效环境中的普通格式(${...})的占位符解析为应用名称，profile和提供的label。资源链接和环境链接以这种方式紧密结合。例如，当存在这样的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 resource像这样:

server { listen 80; server_name example.com; }

而/foo/development/master/nginx.conf像这样:

server { listen 80; server_name develop.com; }

注意 就像环境配置的源文件一样，"profile"是用来解析文件名的，因为如果开发人员需要一个靠profile指定的文件，那么/sth/development/sth/logback.xml将被解析为logback-development.xml（而不是logback.xml）。

8. 嵌入配置中心

配置中心最好独立运行。但若需要嵌入其他应用，也只需要@EnableConfigServer注解。这种情况下，有一个可选属性-spring.cloud.config.server.bootstrap很有用，它是一个服务器是否从自己的远程仓库配置自己的标志。由于它拖慢启动，默认是关闭的，但当嵌入其他应用时，与其他应用一样初始化就说得通了。

注意 很明显，记住如果使用bootstrap标志，配置中心将需要在bootstrap.yml配置其名称和仓库URI。

可以设置spring.cloud.config.server.prefix-如"/config"，来修改服务器的链接地址，以为前缀下的资源提供服务。前缀应以"/"开始并不以"/"结束。适用于配置中心的@RequestMappings（即，在Spring Boot前面的server.servletPath和server.contextPath下）。

如果需要直接从后端仓库（不是配置中心）给应用读取配置，这基本上就是一个没有对外链接的内嵌配置中心。不使用@EnableConfigServer注解就可以彻底关闭对外链接（设置spring.cloud.config.server.bootstrap=true）。

9.推送通知和Spring Cloud Bus

很多源代码仓库提供方（例如像Github，Gitlab或Bitbucket）都会通过webhook通知用户仓库的修改。开发人员可以通过提供方的用户接口来配置webhook，URL或一些感兴趣的事件。例如Github会使用包含一串commits的JSON格式POST到webhook，header中的"X-Github-Event"表示"push"。如果在spring-cloud-config-monitor库中加入依赖并在配置中心激活Spring Cloud Bus，那么"/monitor"链接就启用了。

当webhook被激活时，配置中心会发送一个RefreshRemoteApplicationEvent事件，针对于它认为已经发生改变的应用。变更检测可以进行策略化，但默认它只查找与应用程序名称匹配的文件的更改（例如，"foo.properties"针对于"foo"应用，"application.properties"针对于所以应用）。如覆盖该行为的策略为PropertyPathNotificationExtractor，它接受请求头和主题作为参数并返回一个变更的文件路径列表。

默认配置与Github，Gitlab以及Bitbucket都是开箱即用。除Github，Gitlab或Bitbucket的JSON通知之外，开发人员可以触发一个变更通知，通过使用form-encoded参数体path={name}POSTing到"/monitor"。这样做会向匹配"{name}"的应用发送广播（可以包含通配符）。

注意 需要配置中心和客户端应用激活spring-cloud-bus才能传输RefreshRemoteAppli