配置中心 Spring Cloud Config：Config Server 配置类的实现

配置中心 Spring Cloud Config：配置服务器之Config Server配置类

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

在前面的文章，我们介绍了 Spring Cloud Config 整体上的原理。本文将会介绍配置服务器实现中的 Config Server 配置类。

配置服务器

从上一篇文章的基础应用，可以总结出配置服务器的主要功能有：连接配置仓库、拉取远端的配置并缓存到本地、对外提供配置信息的REST接口。

Config Server配置类

注解@EnableConfigServer可以开启应用服务对配置中心的支持。

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Import(ConfigServerConfiguration.class)
public @interface EnableConfigServer {

}

该注解作为配置服务器的开关，引入了ConfigServerConfiguration配置类。下面是该配置类的具体实现。

@Configuration
public class ConfigServerConfiguration {
	class Marker {}

	@Bean
	public Marker enableConfigServerMarker() {
		return new Marker();
	}
}

该配置类不承担具体的实现，其内部定义了一个内部类Marker作为标志类，并将该对象注册到Bean工厂，由该类控制是否启用Config Server。

当启用了Config Server之后，配置服务器在启动时就需要对Config Server进行自动配置，在ConfigServerAutoConfiguration中引入了多个配置类如下：

• EnvironmentRepositoryConfiguration：环境变量存储相关的配置
• CompositeConfiguration：组合方式的环境仓储配置
• ResourceRepositoryConfiguration：资源仓储相关的配置
• ConfigServerEncryptionConfiguration：加密端点的配置
• ConfigServerMvcConfiguration：对外暴露的MVC端点控制器的配置
• TransportConfiguration：配置clone或fetch传输命令的回调

@Import注解导入了这些配置类，这些类也是Config Server的主要功能实现。下面重点介绍核心的配置类，通过配置类来引入Config Server核心功能。

获取指定服务的环境配置

EnvironmentRepositoryConfiguration

EnvironmentRepositoryConfiguration是环境仓库的配置，环境仓库支持如下的配置仓库形式：JDBC、Vault（HashiCorp开发的一款私密信息管理工具）、Svn、本地文件系统、Git库等形式，此处当然需要引入这些配置类。

• CompositeRepositoryConfiguration：组合的配置仓储配置类，对应的profie为“composite”
• JdbcRepositoryConfiguration：基于JDBC数据库存储的配置类，对应的profie为“jdbc”
• VaultRepositoryConfiguration：Vault方式的配置类，对应的profie为“vault”
• SvnRepositoryConfiguration：SVN方式的配置类，对应的profie为“subversion”
• NativeRepositoryConfiguration：本地文件方式的配置类，对应的profie为“native”
• GitRepositoryConfiguration：Git方式的配置类，对应的profie为”git“
• DefaultRepositoryConfiguration：默认方式的配置类，即不指定profile的情况，与profie为”git“的方式相同

环境仓库支持多种方式，每种方式的实现原理都是相同的，笔者这里将以其中最常用的默认方式，即使用Git方式配置环境仓库。

既然环境仓库支持多种方式，那么怎么指定配置服务器启动时使用哪种方式？回忆上一节基础应用时的配置为spring.cloud.config.server.git，这里的配置貌似没看出指定哪种配置仓库的方式，我们看一下该配置类的具体实现。

@Configuration
@ConditionalOnMissingBean(EnvironmentRepository.class)
class DefaultRepositoryConfiguration { // 1
	...
	@Bean
	public MultipleJGitEnvironmentRepository defaultEnvironmentRepository() {
		MultipleJGitEnvironmentRepository repository = new MultipleJGitEnvironmentRepository(
				this.environment); // 2
		repository.setTransportConfigCallback(this.transportConfigCallback); // 3
		if (this.server.getDefaultLabel() != null) {
			repository.setDefaultLabel(this.server.getDefaultLabel()); // 4
		}
		return repository;
	}
}

@Configuration
@Profile("jdbc")
class JdbcRepositoryConfiguration { // 5
	@Bean
	public JdbcEnvironmentRepository jdbcEnvironmentRepository(JdbcTemplate jdbc) {
		return new JdbcEnvironmentRepository(jdbc);
	}
}
//... 省略其他多种配置方式

1. 默认的环境仓库，在Config Server没有指定spring.profiles.active时，将会默认初始化DefaultRepositoryConfiguration中的配置；
2. 在默认初始化的配置类中，使用的是Git仓库的方式，构造一个新的MultipleJGitEnvironmentRepository对象，注册到Spring容器；
3. 设置JGit传输时的信息，执行clone等命令时，需要设置基于SSH的回调；
4. label对应于配置仓库的标签，参数缺失时，设置默认label为master；
5. 当Config Server服务的profile为jdbc时，激活jdbc配置仓库，还有多个profile对应的配置类，此处省略。

EnvironmentRepositoryConfiguration中还声明了多个其他的配置类，上面只截取了部分代码，可以看出，每种配置仓库的实现都对应声明的配置类，用@Profile注解来进行激活相应的配置类，并在配置服务器的application.properties或者application.yml中指定spring.profiles.active=jdbc。当我们没有设置的时候，使用的是默认的环境仓库为Git方式，所以看到DefaultRepository配置的注解有@ConditionalOnMissingBean(EnvironmentRepository.class)，当上下文中不在EnvironmentRepository对象时才会实例化该默认的环境仓库配置类。

小结

本文主要介绍了 Spring Cloud Config 服务端 Config Server 配置类的具体代码实现。接下来，我们将会介绍服务端存储相关的 EnvironmentRepository接口实现细节。