前言

介绍完服务的容错保护处理，接下来我们来了解下关于分布式配置中心的相关知识和使用。众所周知，随着项目的越来越多，日益庞大，每个子项目都会伴随着不同的配置项，于此也就多了很多的配置文件。倘若某些配置信息修改，可能就会伴随着一系列配置文件的更新和相应服务的重启操作了。这对于实施而言，也是噩梦一般的存在，增加了一系列运维成本，也会无形中提高出错的机率。所以在微服务越来越多时，就会引入今天要讲解的分布式配置中心，它就是来解决此类问题的。话不多说，开始吧~

• 一点知识
  • 为什么要统一管理微服务配置
• Spring-Cloud-config实践
  • 何为SpringCloudConfig
  • Server端
  • Client端
• 参考资料
• 总结
• 最后
• 老生常谈

一点知识

为什么要统一管理微服务配置

在写这篇文章之前，在公众号里有推送了一篇《为什么需要分布式配置中心》的文章。里面也大致说明了，大家可以看一看。简单来说，就是随着业务的发展、微服务架构的升级，服务的数量、程序的配置日益增多（各种微服务、各种服务器地址、各种参数），传统的配置文件方式和数据库的方式已无法满足开发人员对配置管理的要求，即

• 安全性：配置跟随源代码保存在代码库中，容易造成配置泄漏；

• 时效性：修改配置，需要重启服务才能生效；

• 局限性：无法支持动态调整：例如日志开关、功能开关；

其实说白了，就是当业务需求有变更时，可以通过修改配置文件或者参数的形式，能够自动更新配置。减少不必要的重启服务的操作。正常情况下，一般的业务系统都有个参数配置表的，里面记录着不同业务参数，以此来应对不同的需求场景，也就是需求口中常说的：要能灵活配置。

而在微服务中，由于每个微服务都是独立的数据库，传统的配置无法满足了。所以才出现了分布式配置中心服务，专门来解决此类问题的。

在微服务架构中，微服务的统一配置管理一般有以下需求：

• 集中管理配置：一个使用微服务架构的应用系统可能会包括成千上万个微服务，因此集中管理配置是非常有必要的。
• 不同环境不同配置：数据源配置在不同的环境(开发、测试、预发布、生产等)中是不同的。
• 运行期间可动态调整：可根据各个微服务的负载情况，动态调整数据源连接池大小或熔断阈值，并且在调整配置时不重启微服务。
• 配置修改后自动更新：如配置内容发生变化，微服务能够自动更新配置。

综上所述，对于微服务架构而言，一个通用的配置管理机制必不可少，常见做法是使用配置服务器管理配置。目前市面上开源的配置中心有很多，如

• Apollo（阿波罗）：携程框架部门研发的分布式配置中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景。
• Qconf：一个分布式配置管理工具，360出品。
• Disconf：专注于各种「分布式系统配置管理」的「通用组件」和「通用平台」, 提供统一的「配置管理服务」。

具体的可以看看之前说的文章《为什么需要分布式配置中心》，这里就不过多阐述了。

Spring-Cloud-config实践

何为SpringCloudConfig

Spring Cloud Config为分布式系统外部化配置提供了服务端和客户端的支持，它包括Config Server和Config Client两部分。目前支持git、svn、vault、

关键字：