Spring Cloud Config（一）：聊聊分布式配置中心 Spring Cloud Config

目录

---

Spring Cloud Config（一）：聊聊分布式配置中心 Spring Cloud Config
Spring Cloud Config（二）：基于Git搭建配置中心
Spring Cloud Config（三）：基于JDBC搭建配置中心
Spring Cloud Config（四）：配置信息动态刷新
Spring Cloud Config（五）：配置中心服务端Config Server源码解析
Spring Cloud Config（六）：配置中心客户端Client源码解析
Spring Cloud Config（七）：配置中心自定义扩展
Spring Cloud Config（八）：Client 端覆盖Server端配置属性
Spring Cloud Config（九）：Config Server 端配置文件安全保护
Spring Cloud Config（十）：快速响应失败和重试机制

---

1、Spring Cloud Config 定义

Spring Cloud Config provides server and client-side support for externalized configuration in a distributed system. With the Config Server you have a central place to manage external properties for applications across all environments. The concepts on both client and server map identically to the Spring Environment and PropertySource abstractions, so they fit very well with Spring applications, but can be used with any application running in any language. As an application moves through the deployment pipeline from dev to test and into production you can manage the configuration between those environments and be certain that applications have everything they need to run when they migrate. The default implementation of the server storage backend uses git so it easily supports labelled versions of configuration environments, as well as being accessible to a wide range of tooling for managing the content. It is easy to add alternative implementations and plug them in with Spring configuration.

Spring Cloud Config 为分布式系统中的外部化配置提供服务器和客户端支持。 使用Config Server，您可以在所有环境中管理应用程序的外部属性。客户端和服务器上的概念与Spring Environment和PropertySource抽象相同，因此它们非常适合Spring应用程序，但可以与任何语言运行的任何应用程序一起使用。当应用程序通过部署管道从开发到测试并进入生产时，您可以管理这些环境之间的配置，并确保应用程序具有迁移时需要运行的所有内容。他默认的服务器存储后端实现使用git，因此它可以轻松支持配置环境的标签版本，并且可以访问各种用于管理内容的工具。 基于spring配置可以很方便的实现扩展。

2、为什么选择 Spring Cloud Config

那么有人可能会问了，业界关于分布式配置中心有多种开源的组件，如携程开源的 Apollo、 百度的 Disconf、淘宝的 Diamond 等，已经不少了，为啥还会诞生Spring Cloud Config呢？

应用服务除了实现系统功能，还需要连接资源和其它应用，经常需要调整服务的配置来改变应用的行为，如切换不同数据库，设置功能开关等。随着微服务数量的不断增加，需要系统具备可伸缩性和可扩展性，除此之外就是需要管理服务实例的配置数据。在开发阶段配置信息由各个服务自己管理，但是到了生产环境会给运维带来很多不便。因此系统需要建立一个统一的配置管理中心，常见配置中心的实现方法有：

• 硬编码，缺点就是需要修改代码

• 放在xml等配置文件中和应用一起打包，缺点就是配置修改需要重新打包和重启

• 放在文件系统中，缺点就是依赖操作系统

• 配置到系统环境变量，缺点是需要大量的配置工作，不方便管理

个人看来，Spring Cloud Config 在以下几方面还是有比较明显的优势，所以可能是为什么要再造一个轮子的原因吧：

1、基于应用、环境、版本三个维度管理

应用（application）

每个配置都是属于某一个应用的

环境（profile）

每个配置都是区分环境的，如dev, test, prod等

版本（label）

这个可能是一般的配置中心所缺乏的，就是对同一份配置的不同版本管理
Spring Cloud Config提供版本的支持，也就是说对于一个应用的不同部署实例，可以从服务端获取到不同版本的配置，这对于一些特殊场景如：灰度发布，A/B测试等提供了很好的支持。

2、多种存储方式

基于Git存储，一方面程序员非常熟悉，另一方面在部署上会非常简单，而且借助于Git天生就能非常好的支持版本，同时它还支持其它的存储如本地文件、SVN、jdbc等

3、Spring无缝集成

它无缝支持Spring里面Environment和PropertySource的接口
所以对于已有的Spring应用程序的迁移成本非常低，在配置获取的接口上是完全一致的

3、Spring Cloud Config 简介

上图简要描述了一个普通Spring Cloud Config应用的场景。其中主要有以下几个组件：

• Config Client

Client很好理解，就是使用了Spring Cloud Config的应用
Spring Cloud Config提供了基于Spring的客户端，应用只要在代码中引入Spring Cloud Config Client的jar包即可工作

• Config Server

Config Server是需要独立部署的一个web应用，它负责把git上的配置返回给客户端

• Remote Git Repository

远程Git仓库，一般而言，我们会把配置放在一个远程仓库，通过git客户端来管理配置

• Local Git Repostiory

Config Server接到来自客户端的配置获取请求后，会先把远程仓库的配置clone到本地的临时目录，然后从临时目录读取配置并返回

4、总结

Spring Cloud Config 项目

• 提供 服务端 和 客户端 支持

• 集中式 管理分布式环境下的应用配置

• 基于 Spring 环境，无缝 与 Spring 应用集成

• 可用于 任何 语言开发的程序

• 默认实现基于 git 仓库，可以进行 版本管理

• 可替换 自定义实现

Spring Cloud Config Server 作为配置中心服务端

• 拉取配置时更新 git 仓库副本，保证是最新结果

• 支持数据结构丰富，yml, json, properties 等

• 配合 eureke 可实现服务发现，配合 cloud bus 可实现配置推送更新

• 配置存储基于 git 仓库，可进行版本管理

• 简单可靠，有丰富的配套方案

Spring Cloud Config Client 默认客户端实现

SpringBoot 项目不需要改动任何代码，加入一个启动配置文件指明使用 ConfigServer 上哪个配置文件即可