配置中心 Spring Cloud Config：整体的工作原理

配置中心 Spring Cloud Config：工作原理

《配置中心 Spring Cloud Config 详解》系列文章更新，一起在技术的路上精进！本系列文章将会介绍Spring Cloud 中提供了分布式配置中心Spring Cloud Config。应用服务中除了实现系统功能的代码，还需要连接资源和其它应用，经常有很多需要在外部配置的数据去调整应用的行为，如切换不同的数据库，设置功能开关等。随着微服务的不断增加，需要系统具备可伸缩和可扩展性，除此之外就是管理相当多的服务实例的配置数据。在应用的开发阶段由各个服务自治，但是到了生产环境之后会给运维带来很大的麻烦，特别是微服务的规模比较大，配置的更新更为麻烦。为此，系统需要建立一个统一的配置管理中心。

在前面的文章，我们介绍了 Spring Cloud Config 使用过程中服务端的实现，完整介绍了客户端和服务端实现的具体内容。本文将会介绍 Spring Cloud Config 工作原理，以此来了解 Spring Cloud Config 客户端和服务端交互的细节。

Spring Cloud Config 工作原理

通过上一篇文章的基础应用，我们可以知道配置中心包括如下元素：

• 配置服务器：为配置客户端提供其对应的配置信息，配置信息的来源为配置仓库，启动时即拉取配置仓库的信息，缓存到本地仓库中。
• 配置客户端：除了配置服务器之外的应用服务，启动时从配置服务器拉取其对应的配置信息。
• 配置仓库：为配置服务器提供配置源信息，配置仓库的实现可以支持多种方式。

基于Config服务器，就可以集中管理各种环境下的各种应用的配置信息。客户端和服务端匹配到Spring中的Environment和PropertySource的概念，所以这不仅非常适用于所有的Spring应用，而且对于任意语言的应用都能够适用。一个应用可能有多个环境，从dev开发到test测试，再到生产环境，你可以管理这些不同环境下的配置，而且能够确保应用在环境迁移后有完整的配置能够正常运行。

配置中心的应用架构图如下：

在部署环境之前，需要将相应的配置信息推送到配置仓库；先将配置服务器启动，启动之后，将配置信息拉取并同步至本地仓库；然后，配置服务器对外提供REST接口，其他所有的配置客户端启动时根据spring.cloud.config配置的{application}/{profile}/{label}信息去配置服务器拉取相应的配置。配置仓库支持多样的源，如Git、SVN、jdbc数据库和本地文件系统等。最后，其他应用启动，从配置服务器拉取配置。配置中心还支持动态刷新配置信息，不需要重启应用，通过spring-cloud-config-monitor监控模块，其中包含了/monitor刷新API，webhook调用该端点API，达到动态刷新的效果。

总的来说，Spring Cloud Config具有如下特性：

• 提供配置的服务端和客户端支持；
• 集中式管理分布式环境下的应用配置；
• 基于 Spring 环境，可以无缝与Spring应用集成；
• 可用于任何语言开发的程序，为其管理与提供配置信息；
• 默认实现基于git仓库，可以进行版本管理

下面我们分别来对配置服务器和客户端的主要功能进行源码解析。

小结

本文主要介绍了 Spring Cloud Config 服务端与客户端交互的基本过程，配置服务端是分布式应用配置的源，同时其自身也能实现高可用和高并发。接下来，我们将会具体剖析服务端和客户端的实现细节。