这是我参与更文挑战的第 20 天，活动详情查看： 更文挑战
《配置中心 Spring Cloud Config 详解》系列文章更新，一起在技术的路上精进！本系列文章将会介绍Spring Cloud 中提供了分布式配置中心Spring Cloud Config。应用服务中除了实现系统功能的代码，还需要连接资源和其它应用，经常有很多需要在外部配置的数据去调整应用的行为，如切换不同的数据库，设置功能开关等。随着微服务的不断增加，需要系统具备可伸缩和可扩展性，除此之外就是管理相当多的服务实例的配置数据。在应用的开发阶段由各个服务自治，但是到了生产环境之后会给运维带来很大的麻烦，特别是微服务的规模比较大，配置的更新更为麻烦。为此，系统需要建立一个统一的配置管理中心。
在前面的文章，我们主要介绍了 Spring Cloud Config 进阶应用之对称加密与解密以及非对称加密与解密。本文将会继续介绍 Spring Cloud Config 快速响应失败与重试机制。
快速响应失败
在某些情况下，当客户端不能连接到Config Server时，可能让服务启动失败更为适合。如果这种行为更为合适，设置启动配置的属性spring.cloud.config.failFast=true，则客户端会遇到异常而终止。
重试机制
当客户端应用启动时，config server可能因为网络抖动等问题请求超时造成不可用，我们可以使用重试机制进行不断尝试。当然，这是建立在上面快速响应失败关闭的情况下，我们需要添加如下依赖：
<dependency>
<groupId>org.springframework.retry</groupId>
<artifactId>spring-retry</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-aop</artifactId>
</dependency>
spring-retry默认会尝试6次，初始回退间隔为1000ms，后续回退的指数乘数为1.1。我们可以自定义这些配置：
spring:
cloud:
config:
retry:
max-attempts: 6
multiplier: 1.1
initial-interval: 1000
max-interval: 2000
本系列文章小结
微服务架构中，每个微服务的业务单位进一步细化，服务经过拆分，微服务的数量变得庞大。当这么多的服务需要测试并上产线，可能会存在多个环境，如集成测试、预发布和产线环境，每个环境的配置文件都会有所区别（如数据源的配置、开关量、路由规则等），如果没有一个集中的配置管理中心，每个环境的配置信息大规模更新就会非常麻烦，工作量大的同时也会容易造成认为的失误。
Spring Cloud Config 基于云端存储配置信息，它具有中心化，版本控制，支持动态更新，平台独立，语言独立等特性。Spring Cloud Config还是比较容易上手使用，同时也能够满足大部分公司的需求。
Spring Cloud Config 的精妙之处在于它的配置存储于 Git，这就天然的把配置的修改、权限、版本等问题隔离在外。通过这个设计使得 Spring Cloud Config整体很简单，不过也带来了一些不便之处。Spring Cloud Config的功能可以进一步增加和丰富，如：配置界面，一个界面管理不同环境、不同集群配置；实例配置监控，可以方便的看到当前哪些客户端在使用哪些配置
