Spring Cloud Config原碼篇（十）

童話述說我的結局發表於2021-01-02

上篇中說到通過@Value註解獲取配置中心的內容進行注入，要想了解這個就要知道spring Environment原理，關於這原理我看了下網上分析的文章：https://blog.csdn.net/topdeveloperr/article/details/88063828

一、Environment的初始化

首先來看第一部分，就是spring boot需要解析的外部資原始檔的路徑是如何初始化的。在spring boot的啟動流程中，有一個 prepareEnvironment 方法，這個方法就是用來準備Environment這個物件的。找他的入中是從springApplication.run 開始的

進入ConfigurableEnvironment類這個方法主要就是建立和配置spring容器的環境資訊

private ConfigurableEnvironment prepareEnvironment(SpringApplicationRunListeners
listeners,ApplicationArguments
applicationArguments) {
  // 根據上下文，建立一個合適的Environment物件
  ConfigurableEnvironment environment = getOrCreateEnvironment();
  //配置Environment的propertySource、以及profile
  configureEnvironment(environment, applicationArguments.getSourceArgs());
  ConfigurationPropertySources.attach(environment);
  // 通知監聽器，載入配置檔案
  listeners.environmentPrepared(environment);
  bindToSpringApplication(environment);
  if (!this.isCustomEnvironment) {
    environment = new
EnvironmentConverter(getClassLoader()).convertEnvironmentIfNecessary(environment
,
                                       
       deduceEnvironmentClass());
 }
  ConfigurationPropertySources.attach(environment);
  return environment;
}

進入getOrCreateEnvironment看它是怎麼建立環境的，進去後發現這個方法，就是根據當前的webApplication型別匹配對應的environment，當前預設的應該就是StandardServletEnvironment ，如果是spring webflux，則是StandardReactiveWebEnvironment .

private ConfigurableEnvironment getOrCreateEnvironment() {
  if (this.environment != null) {
    return this.environment;
 }
  switch (this.webApplicationType) {
    case SERVLET:
      return new StandardServletEnvironment();
    case REACTIVE:
      return new StandardReactiveWebEnvironment();
    default:
      return new StandardEnvironment();
 }
}

StandardServletEnvironment 是整個spring boot應用執行環境的實現類，後面所有的關於環境相關的配置操作都是基於這個類，它的類的結構圖如下

StandardServletEnvironment的初始化過程會做一些事情，就是配置一些基本的屬性來源。StandardServletEnvironment 會初始化父類 AbstractEnvironment ，在這個類的構造方法中，會呼叫一個自定義配置檔案的方法，這個是spring中比較常見的實現手法，前面在看ribbon、eureka中都有看到。

public abstract class AbstractEnvironment implements ConfigurableEnvironment {
  public AbstractEnvironment() {
customizePropertySources(this.propertySources);
}
}

customizePropertySources 這個方法被 StandardServletEnvironment 重寫了，所以會呼叫StandardServletEnvironment 中的 customizePropertySources 方法。不難看出，這裡是將幾個不同的配置源封裝成 StubPropertySource 新增到
MutablePropertySources 中，呼叫 addLast 是表示一直往最後的位置新增。SERVLET_CONFIG_PROPERTY_SOURCE_NAME：servlet的配置資訊，也就是在中配置的SERVLET_CONTEXT_PROPERTY_SOURCE_NAME：這個是servlet初始化的上下文，也就是以前我們在web.xml中配置的 context-param 。JNDI_PROPERTY_SOURCE_NAME：載入jndi.properties配置資訊。

protected void customizePropertySources(MutablePropertySources propertySources)
{
  propertySources.addLast(new
StubPropertySource(SERVLET_CONFIG_PROPERTY_SOURCE_NAME));
  propertySources.addLast(new
StubPropertySource(SERVLET_CONTEXT_PROPERTY_SOURCE_NAME));
  if (JndiLocatorDelegate.isDefaultJndiEnvironmentAvailable()) {
    propertySources.addLast(new
JndiPropertySource(JNDI_PROPERTY_SOURCE_NAME));
 }
  super.customizePropertySources(propertySources);
}

繼續呼叫父類，也就是 StandardEnvironment 類中的 customizePropertySources 方法。SYSTEM_PROPERTIES_PROPERTY_SOURCE_NAME：系統變數，通過System.setProperty設定的變數，預設可以看到 java.version 、 os.name 等。SYSTEM_ENVIRONMENT_PROPERTY_SOURCE_NAME：系統環境變數，也就是我們配置JAVA_HOME的地方。

    @Override
    protected void customizePropertySources(MutablePropertySources propertySources) {
        propertySources.addLast(
                new PropertiesPropertySource(SYSTEM_PROPERTIES_PROPERTY_SOURCE_NAME, getSystemProperties()));
        propertySources.addLast(
                new SystemEnvironmentPropertySource(SYSTEM_ENVIRONMENT_PROPERTY_SOURCE_NAME, getSystemEnvironment()));
    }

這裡要明確一點，就是新增PropertySource的目的其實就是要告訴Environment，解析哪些位置的屬性檔案進行載入。而在這個新增過程中，所有的新增都是基於 addLast ，也就是最早新增的PropertySource會放在最前面。 systemEnvironment 是在 systemProperties 前面，這點很重要。因為前面的配置會覆蓋後面的配置，也就是說系統變數中的配置比系統環境變數中的配置優先順序更高

二、MutablePropertySources

在上面的程式碼中可以看到，所有的外部資源配置都是新增到了一個MutablePropertySources物件中，這個物件封裝了屬性資源的集合。而從 MutablePropertySources 命名來說，Mutable是一個可變的意思，也就是意味著它動態的管理了PropertySource的集合。

public class MutablePropertySources implements PropertySources {
private final List<PropertySource<?>> propertySourceList = new
CopyOnWriteArrayList<>();
}

接著，我們來看一下它怎麼用的，找到 AbstractEnvironment 這個類，在這裡定義了MutablePropertySources。並且把這個MutablePropertySources作為引數傳遞給了ConfigurablePropertyResolver 配置解析器中，而這個配置解析器是一個PropertySourcesPropertyResolver 例項。

public abstract class AbstractEnvironment implements ConfigurableEnvironment {
  private final MutablePropertySources propertySources = new
MutablePropertySources();
private final ConfigurablePropertyResolver propertyResolver =
new PropertySourcesPropertyResolver(this.propertySources);
}

通過下面類圖可以發現AbstractEnvironment 實現了檔案解析器ConfigurablePropertyResolver ，而在上面這段程式碼中我們把 MutablePropertySources 傳遞到PropertySourcesPropertyResolver 中。這樣就可以讓 AbstractEnvironment 具備檔案解析的功能，只是這個功能，委託給了PropertySourcesPropertyResolver來實現。

通過上面的程式碼，spring構造了一個 StandardServletEnvironment 物件並且初始化了一些需要解析的propertySource，現在回退到SpringApplication類的prepareEnvironment方法，我們繼續來看 configureEnvironment 這個方法，這個方法有兩個作用

addConversionService 新增型別轉化的服務，我們知道properties檔案中配置的屬性都是String型別的，而轉化為Java物件之後要根據合適的型別進行轉化，而 ConversionService 是一套通用的轉化方案，這裡把這個轉化服務設定到當前的Environment，很顯然，就是為Environment配置解析時提供一個型別轉化的解決方案。
configurePropertySources 配置Environment中的propertysources，
configureProfiles 配置profiles

protected void configureEnvironment(ConfigurableEnvironment environment,
String[] args) {
  if (this.addConversionService) {
    ConversionService conversionService =
ApplicationConversionService.getSharedInstance();
    environment.setConversionService((ConfigurableConversionService)
conversionService);
 }
  configurePropertySources(environment, args);
  configureProfiles(environment, args);
}

configurePropertySources方法中

設定 defaultProperties 屬性來源
設定commandLineProperties來源，如果設定了命令列引數，則會載入SimpleCommandLinePropertySource 作為propertySource

protected void configurePropertySources(ConfigurableEnvironment environment,
String[] args) {
  MutablePropertySources sources = environment.getPropertySources();
  if (this.defaultProperties != null && !this.defaultProperties.isEmpty()) {
    sources.addLast(new MapPropertySource("defaultProperties",
this.defaultProperties));
 }
  if (this.addCommandLineProperties && args.length > 0) {
    String name =
CommandLinePropertySource.COMMAND_LINE_PROPERTY_SOURCE_NAME;
    if (sources.contains(name)) {
      PropertySource<?> source = sources.get(name);
      CompositePropertySource composite = new
CompositePropertySource(name);
      composite.addPropertySource(
        new
SimpleCommandLinePropertySource("springApplicationCommandLineArgs", args));
      composite.addPropertySource(source);
      sources.replace(name, composite);
   }
    else {
      sources.addFirst(new SimpleCommandLinePropertySource(args));
   }
 }
}

到目前為止，還是在初始化外部化配置的資料來源。接著進入configureProfiles方法，這個方法就比較容易理解，就是配置當前啟用的profiles，將當前的activeProfiles設定到enviroment中。這樣就能夠使得我們完成不同環境下配置的獲取問題。

protected void configureProfiles(ConfigurableEnvironment environment, String[]
args) {
  Set<String> profiles = new LinkedHashSet<>(this.additionalProfiles);
  profiles.addAll(Arrays.asList(environment.getActiveProfiles()));
  environment.setActiveProfiles(StringUtils.toStringArray(profiles));
}

經過上面的操作spring的配置資訊都已載入完成，但有一個很重要的配置還沒有載入，那就是springboot的配置資訊，現在回退到SpringApplication類的prepareEnvironment類

    private ConfigurableEnvironment prepareEnvironment(SpringApplicationRunListeners listeners,
            ApplicationArguments applicationArguments) {
        // Create and configure the environment
        ConfigurableEnvironment environment = getOrCreateEnvironment();
        configureEnvironment(environment, applicationArguments.getSourceArgs());
        ConfigurationPropertySources.attach(environment);
        //springboot的釋出事件
        listeners.environmentPrepared(environment);
        bindToSpringApplication(environment);
        if (!this.isCustomEnvironment) {
            environment = new EnvironmentConverter(getClassLoader()).convertEnvironmentIfNecessary(environment,
                    deduceEnvironmentClass());
        }
        ConfigurationPropertySources.attach(environment);
        return environment;
    }

    void environmentPrepared(ConfigurableEnvironment environment) {
        for (SpringApplicationRunListener listener : this.listeners) {
            listener.environmentPrepared(environment);
        }
    }

選擇EventPublishingRunListener類的environmentPrepared，進入事件的監聽

    @Override
    public void environmentPrepared(ConfigurableEnvironment environment) {
        this.initialMulticaster
                .multicastEvent(new ApplicationEnvironmentPreparedEvent(this.application, this.args, environment));
    }

選擇multicastEvent，進入SimpleApplicationEventMulticaster類的multicastEvent方法，這個方法是多緯度的監聽

    @Override
    public void multicastEvent(ApplicationEvent event) {
        multicastEvent(event, resolveDefaultEventType(event));
    }

    @Override
    public void multicastEvent(final ApplicationEvent event, @Nullable ResolvableType eventType) {
        ResolvableType type = (eventType != null ? eventType : resolveDefaultEventType(event));
        Executor executor = getTaskExecutor();
         //得到結果集
        for (ApplicationListener<?> listener : getApplicationListeners(event, type)) {
            if (executor != null) {
                //反射呼叫
                executor.execute(() -> invokeListener(listener, event));
            }
            else {
                invokeListener(listener, event);
            }
        }
    }

上面事件有反射呼叫就一定會有一個監聽，如果有興趣可以Debugger會發現這個getApplicationListeners的事件監聽中有一個叫ConfigFileApplicationListener，這個監聽器就是用來處理專案配置的，進入ConfigFileApplicationListener類會看到一個onApplicationEvent方法

    @Override
    public void onApplicationEvent(ApplicationEvent event) {
        if (event instanceof ApplicationEnvironmentPreparedEvent) {
            //環境的準備事件
            onApplicationEnvironmentPreparedEvent((ApplicationEnvironmentPreparedEvent) event);
        }
        if (event instanceof ApplicationPreparedEvent) {
          //Appliaction的準備事件 
            onApplicationPreparedEvent(event);
        }
    }

如果有人在我之前說的要debugger的地方debugger的話會發現，現在釋出的事件是一個ApplicationEnvironmentPreparedEvent事件，進入onApplicationEnvironmentPreparedEvent事件中

    private void onApplicationEnvironmentPreparedEvent(ApplicationEnvironmentPreparedEvent event) {
        List<EnvironmentPostProcessor> postProcessors = loadPostProcessors();
        postProcessors.add(this);
        AnnotationAwareOrderComparator.sort(postProcessors);
        for (EnvironmentPostProcessor postProcessor : postProcessors) {
            postProcessor.postProcessEnvironment(event.getEnvironment(), event.getSpringApplication());
        }
    }

最終執行到 ConfigFileApplicationListener.addPropertySources 方法中

    @Override
    public void postProcessEnvironment(ConfigurableEnvironment environment, SpringApplication application) {
        addPropertySources(environment, application.getResourceLoader());
    }

這個方法做兩個事情

新增一個RandomValuePropertySource到Environment的MutablePropertySources中
載入spring boot中的配置資訊，比如application.yml或者application.properties

    protected void addPropertySources(ConfigurableEnvironment environment, ResourceLoader resourceLoader) {
        RandomValuePropertySource.addToEnvironment(environment);
        new Loader(environment, resourceLoader).load();
    }

進入Load類load方法這個方法比較複雜，總的來說，就是載入所有可能的profiles首先我們來看，這裡實際上是呼叫了 FilteredPropertySource.apply 方法。然後傳遞了一個lambda表示式到apply方法中。

其中apply方法的主要邏輯是，判斷如果當前如果有預設配置，則將預設配置員增加一個FilteredPropertySource 。
執行匿名內部類

void load() {
  FilteredPropertySource.apply(this.environment, DEFAULT_PROPERTIES,
LOAD_FILTERED_PROPERTY,
                (defaultProperties) -> {
                  this.profiles = new LinkedList<>();
                  this.processedProfiles = new LinkedList<>
();
                  this.activatedProfiles = false;
                  this.loaded = new LinkedHashMap<>();
                  initializeProfiles();
                  while (!this.profiles.isEmpty()) {
                    Profile profile = this.profiles.poll();
                    if (isDefaultProfile(profile)) {
                     
addProfileToEnvironment(profile.getName());
                    }
                    load(profile,
this::getPositiveProfileFilter,
                     
 addToLoaded(MutablePropertySources::addLast, false));
                    this.processedProfiles.add(profile);
                  }
                  load(null, this::getNegativeProfileFilter,
addToLoaded(MutablePropertySources::addFirst, true));
                  addLoadedPropertySources();
                  applyActiveProfiles(defaultProperties);
                });
}

下面這個lambda表示式的主要邏輯是

呼叫initializeProfiles初始化預設的Profile，沒有設定的話就用預設，初始化之後儲存到 privateDeque<Profile> profiles; 中，它是一個LIFO佇列。因為 profiles 採用了 LIFO 佇列，後進先出。所以會先載入profile為null的配置檔案，也就是匹配 application.properties、application.yml 。
如果profiles不為空，則迴圈遍歷每一個profiles，呼叫 load方法進行載入。

(defaultProperties) -> {
  // 未處理的資料集合
  this.profiles = new LinkedList<>();
  // 已處理的資料集合
  this.processedProfiles = new LinkedList<>();
  this.activatedProfiles = false;
  this.loaded = new LinkedHashMap<>();
  //載入存在已經啟用的 profiles
  initializeProfiles();
  while (!this.profiles.isEmpty()) {//遍歷所有profiles
    Profile profile = this.profiles.poll();
    if (isDefaultProfile(profile)) {
      addProfileToEnvironment(profile.getName());
   }
    // 確定搜尋範圍，獲取對應的配置檔名，並使用相應載入器載入
    load(profile, this::getPositiveProfileFilter,
      addToLoaded(MutablePropertySources::addLast, false));
    // 將處理完的 profile新增到 processedProfiles列表當中，表示已經處理完成
    this.processedProfiles.add(profile);
 }
  load(null, this::getNegativeProfileFilter,
addToLoaded(MutablePropertySources::addFirst, true));
  addLoadedPropertySources();
  applyActiveProfiles(defaultProperties);// 更新 activeProfiles列表

點選上面的 initializeProfiles，進入Load類initializeProfiles方法，該方法的作用是載入存在已經啟用的 profiles

private void initializeProfiles() {
  // The default profile for these purposes is represented as null. We add it
  // first so that it is processed first and has lowest priority.
  this.profiles.add(null);
  Binder binder = Binder.get(this.environment);
  //判斷當前環境是否配置 spring.profiles.active屬性
  Set<Profile> activatedViaProperty = getProfiles(binder,
ACTIVE_PROFILES_PROPERTY);
  //判斷當前環境是否配置 spring.profiles.include屬性
  Set<Profile> includedViaProperty = getProfiles(binder,
INCLUDE_PROFILES_PROPERTY);
  //如果沒有特別指定的話，就是 application.properties 和 application-
default.properties配置
  List<Profile> otherActiveProfiles =
getOtherActiveProfiles(activatedViaProperty, includedViaProperty);
  this.profiles.addAll(otherActiveProfiles);
  // Any pre-existing active profiles set via property sources (e.g.
  // System properties) take precedence over those added in config files.
  this.profiles.addAll(includedViaProperty);
  addActiveProfiles(activatedViaProperty);
  // 如果 profiles集仍然為null，即沒有指定，就會建立預設的profile
  if (this.profiles.size() == 1) { // only has null profile
    for (String defaultProfileName : this.environment.getDefaultProfiles())
{
      Profile defaultProfile = new Profile(defaultProfileName, true);
      this.profiles.add(defaultProfile);
   }
 }
}

這個看明白後返回上一層點load進入Load類的load方法，繼續跟進load方法，通過 getSearchLoacations 進行搜尋，並且進行迭代。

private void load(Profile profile, DocumentFilterFactory filterFactory,
DocumentConsumer consumer) {
  getSearchLocations().forEach((location) -> {
    boolean isDirectory = location.endsWith("/");
    Set<String> names = isDirectory ? getSearchNames() : NO_SEARCH_NAMES;
    names.forEach((name) -> load(location, name, profile, filterFactory,
consumer));
 });
}

getSearchLocations的主要功能，就是獲取需要遍歷的目標路徑，預設情況下，會去DEFAULT_SEARCH_LOCATIONS中查詢，也就是

private Set<String> getSearchLocations() {
  Set<String> locations =
getSearchLocations(CONFIG_ADDITIONAL_LOCATION_PROPERTY);
  if (this.environment.containsProperty(CONFIG_LOCATION_PROPERTY)) {
    locations.addAll(getSearchLocations(CONFIG_LOCATION_PROPERTY));
 }
  else {
    locations.addAll(
      asResolvedSet(ConfigFileApplicationListener.this.searchLocations,
DEFAULT_SEARCH_LOCATIONS));
 }
  return locations;
}

拿到路徑地址之後，再拼接對應路徑，選擇合適的yml或者properties解析器進行解析。

private void load(Profile profile, DocumentFilterFactory filterFactory,
DocumentConsumer consumer) {
  getSearchLocations().forEach((location) -> {
    boolean isDirectory = location.endsWith("/");
    Set<String> names = isDirectory ? getSearchNames() : NO_SEARCH_NAMES;
    names.forEach((name) -> load(location, name, profile, filterFactory,
consumer));
 });
}

整理流程如下：
1）獲取預設的配置檔案路徑，有4種。

2）遍歷所有的路徑，拼裝配置檔名稱。

3）再遍歷解析器，選擇yml或者properties解析，將解析結果新增到集合MutablePropertySources當中。

至此，springBoot中的資原始檔載入完畢，解析順序從上到下，所以前面的配置檔案會覆蓋後面的配置檔案。可以看到 application.properties 的優先順序最低，系統變數和環境變數的優先順序相對較高

三、config中的environment

在Spring Cloud Config中，通過@Value註解注入了一個屬性，但是這個屬性不存在於本地配置中，那麼Config是如何將遠端配置資訊載入到Environment中的呢？這裡需要思考幾個問題

如何將配置載入到 Environment
配置變更時，如何控制 Bean 是否需要 create,重新觸發一次 Bean 的初始化，才能將 @Value 註解指定的欄位從 Environment 中重新注入。
配置變更時，如何控制新的配置會更新到 Environment 中，才能保證配置變更時可注入最新的值。

為了解決這三個問題，Spring Cloud Config規範中定義了三個核心的介面

PropertySourceLocator：抽象出這個介面，就是讓使用者可定製化的將一些配置載入到Environment。這部分的配置獲取遵循了 Spring Cloud Config 的理念，即希望能從外部儲存介質中來 loacte。
RefreshScope: Spring Cloud 定義這個註解，是擴充套件了 Spring 原有的 Scope 型別。用來標識當前這個 Bean 是一個refresh 型別的 Scope。其主要作用就是可以控制 Bean 的整個生命週期。
ContextRefresher：抽象出這個 Class，是讓使用者自己按需來重新整理上下文(比如當有配置重新整理時，希望可以重新整理上下文，將最新的配置更新到 Environment，重新建立 Bean 時，就可以從Environment 中注入最新的配置)。

下面就來了解下Environment是如何在啟動過程中從遠端伺服器上載入配置的

3.1、Config Client 配置載入過程

從前面的程式碼分析過程中我們知道，Environment中所有外部化配置，針對不同型別的配置都會有與之對應的PropertySource，比如（SystemEnvironmentPropertySource、CommandLinePropertySource）。以及PropertySourcesPropertyResolver來進行解析。
那Config Client在啟動的時候，必然也會需要從遠端伺服器上獲取配置載入到Environment中，這樣才能使得應用程式通過@value進行屬性的注入，而且我們一定可以猜測到的是，這塊的工作一定又和spring中某個機制有關係。

在spring boot專案啟動時，有一個prepareContext的方法，它會回撥所有實現了ApplicationContextInitializer 的例項，來做一些初始化工作。

public ConfigurableApplicationContext run(String... args) {
        StopWatch stopWatch = new StopWatch();
        stopWatch.start();
        ConfigurableApplicationContext context = null;
        Collection<SpringBootExceptionReporter> exceptionReporters = new ArrayList<>();
        configureHeadlessProperty();
        SpringApplicationRunListeners listeners = getRunListeners(args);
        listeners.starting();
        try {
            ApplicationArguments applicationArguments = new DefaultApplicationArguments(args);
            ConfigurableEnvironment environment = prepareEnvironment(listeners, applicationArguments);
            configureIgnoreBeanInfo(environment);
            Banner printedBanner = printBanner(environment);
            context = createApplicationContext();
            exceptionReporters = getSpringFactoriesInstances(SpringBootExceptionReporter.class,
                    new Class[] { ConfigurableApplicationContext.class }, context);
           //回撥所有實現
            prepareContext(context, environment, listeners, applicationArguments, printedBanner);
            refreshContext(context);
            afterRefresh(context, applicationArguments);
            stopWatch.stop();
            if (this.logStartupInfo) {
                new StartupInfoLogger(this.mainApplicationClass).logStarted(getApplicationLog(), stopWatch);
            }
            listeners.started(context);
            callRunners(context, applicationArguments);
        }
        catch (Throwable ex) {
            handleRunFailure(context, ex, exceptionReporters, listeners);
            throw new IllegalStateException(ex);
        }

        try {
            listeners.running(context);
        }
        catch (Throwable ex) {
            handleRunFailure(context, ex, exceptionReporters, null);
            throw new IllegalStateException(ex);
        }
        return context;
    }

前面說過prepareContext的方法，它會回撥所有實現了ApplicationContextInitializer 的例項然而PropertySourceBootstrapConfiguration 實現了 ApplicationContextInitializer 介面，其目的就是在應用程式上下文初始化的時候做一些額外的操作.根據預設的 AnnotationAwareOrderComparator 排序規則對propertySourceLocators陣列進行排序，獲取執行的環境上下文ConfigurableEnvironment，遍歷propertySourceLocators時

呼叫 locate 方法，傳入獲取的上下文environment
將source新增到PropertySource的連結串列中
設定source是否為空的標識標量empty

source不為空的情況，才會設定到environment中

返回Environment的可變形式，可進行的操作如addFirst、addLast
移除propertySources中的bootstrapProperties
根據config server覆寫的規則，設定propertySources
處理多個active profiles的配置資訊

@Override
public void initialize(ConfigurableApplicationContext applicationContext) {
  List<PropertySource<?>> composite = new ArrayList<>();
  //對propertySourceLocators陣列進行排序，根據預設的AnnotationAwareOrderComparator
  AnnotationAwareOrderComparator.sort(this.propertySourceLocators);
  boolean empty = true;
  //獲取執行的環境上下文
  ConfigurableEnvironment environment = applicationContext.getEnvironment();
  for (PropertySourceLocator locator : this.propertySourceLocators) {
    //回撥所有實現PropertySourceLocator介面例項的locate方法，
    Collection<PropertySource<?>> source =
locator.locateCollection(environment);
    if (source == null || source.size() == 0) {
      continue;
   }
    List<PropertySource<?>> sourceList = new ArrayList<>();
    for (PropertySource<?> p : source) {
      sourceList.add(new BootstrapPropertySource<>(p));
   }
    logger.info("Located property source: " + sourceList);
    composite.addAll(sourceList);//將source新增到陣列
    empty = false; //表示propertysource不為空
 }
  //只有propertysource不為空的情況，才會設定到environment中
  if (!empty) {
    MutablePropertySources propertySources =
environment.getPropertySources();
    String logConfig =
environment.resolvePlaceholders("${logging.config:}");
    LogFile logFile = LogFile.get(environment);
    for (PropertySource<?> p : environment.getPropertySources()) {
      if (p.getName().startsWith(BOOTSTRAP_PROPERTY_SOURCE_NAME)) {
        propertySources.remove(p.getName());
     }
   }
    insertPropertySources(propertySources, composite);
    reinitializeLoggingSystem(environment, logConfig, logFile);
    setLogLevels(applicationContext, environment);
    handleIncludedProfiles(environment);
 }
}

選擇locateCollection進入PropertySourceLoader類的locateCollection方法；這個方法會呼叫子類的locate方法，來獲得一個PropertySource，然後將PropertySource集合返回。接著它會呼叫 ConfigServicePropertySourceLocator 的locate方法。

static Collection<PropertySource<?>> locateCollection(PropertySourceLocator
locator,
                           Environment environment) {
  PropertySource<?> propertySource = locator.locate(environment);
  if (propertySource == null) {
    return Collections.emptyList();
 }
  if (CompositePropertySource.class.isInstance(propertySource)) {
    Collection<PropertySource<?>> sources = ((CompositePropertySource)
propertySource)
     .getPropertySources();
    List<PropertySource<?>> filteredSources = new ArrayList<>();
    for (PropertySource<?> p : sources) {
      if (p != null) {
        filteredSources.add(p);
     }
   }
    return filteredSources;
 }
  else {
    return Arrays.asList(propertySource);
 }
}

進入ConfigServicePropertySourceLocator類的locate方法這個就是Config Client的關鍵實現了，它會通過RestTemplate呼叫一個遠端地址獲得配置資訊，getRemoteEnvironment 。然後把這個配置PropertySources，然後將這個資訊包裝成一個OriginTrackedMapPropertySource，設定到 Composite 中。

public org.springframework.core.env.PropertySource<?> locate(
  org.springframework.core.env.Environment environment) {
  ConfigClientProperties properties =
this.defaultProperties.override(environment);
  CompositePropertySource composite = new
OriginTrackedCompositePropertySource(
    "configService");
  RestTemplate restTemplate = this.restTemplate == null
    ? getSecureRestTemplate(properties) : this.restTemplate;
  Exception error = null;
  String errorBody = null;
  try {
    String[] labels = new String[] { "" };
    if (StringUtils.hasText(properties.getLabel())) {
      labels = StringUtils
       .commaDelimitedListToStringArray(properties.getLabel());
   }
    String state = ConfigClientStateHolder.getState();
    // Try all the labels until one works
    for (String label : labels) {
      Environment result = getRemoteEnvironment(restTemplate, properties,
                           label.trim(), state);
if (result != null) {
        log(result);
        // result.getPropertySources() can be null if using xml
        if (result.getPropertySources() != null) {
          for (PropertySource source : result.getPropertySources()) {
            @SuppressWarnings("unchecked")
            Map<String, Object> map =
translateOrigins(source.getName(),
                                 (Map<String,
Object>) source.getSource());
            composite.addPropertySource(
              new OriginTrackedMapPropertySource(source.getName(),
                               map));
         }
       }
        if (StringUtils.hasText(result.getState())
          || StringUtils.hasText(result.getVersion())) {
          HashMap<String, Object> map = new HashMap<>();
          putValue(map, "config.client.state", result.getState());
          putValue(map, "config.client.version", result.getVersion());
          composite.addFirstPropertySource(
            new MapPropertySource("configClient", map));
       }
        return composite;
     }
   }
    errorBody = String.format("None of labels %s found",
Arrays.toString(labels));
 }
  catch (HttpServerErrorException e) {
    error = e;
    if (MediaType.APPLICATION_JSON
     .includes(e.getResponseHeaders().getContentType())) {
      errorBody = e.getResponseBodyAsString();
   }
 }
  catch (Exception e) {
    error = e;
 }
  if (properties.isFailFast()) {
    throw new IllegalStateException(
      "Could not locate PropertySource and the fail fast property is set,
failing"
      + (errorBody == null ? "" : ": " + errorBody),
      error);
 }
  logger.warn("Could not locate PropertySource: "
        + (error != null ? error.getMessage() : errorBody));
  return null;
}

四、Config Server獲取配置過程

伺服器端去遠端倉庫載入配置的流程就比較簡單了，核心介面是： EnvironmentRepository ，提供了配置讀取的功能。先從請求入口開始看；pring Cloud Config Server提供了EnvironmentController，這樣通過在瀏覽器訪問即可從git中獲取配置資訊；在這個controller中，提供了很多的對映，最終會呼叫的是 getEnvironment 。

public Environment getEnvironment(String name, String profiles, String label,
                 boolean includeOrigin) {
  name = Environment.normalize(name);
  label = Environment.normalize(label);
  Environment environment = this.repository.findOne(name, profiles, label,
                           includeOrigin);
  if (!this.acceptEmpty
    && (environment == null || environment.getPropertySources().isEmpty()))
{
    throw new EnvironmentNotFoundException("Profile Not found");
 }
  return environment;
}

this.repository.findOne ，呼叫某個repository儲存元件來獲得環境配置資訊進行返回。repository是一個 EnvironmentRepository 物件，它有很多實現，其中就包含RedisEnvironmentRepository 、 JdbcEnvironmentRepository 等。預設實現是MultipleJGitEnvironmentRepository ，表示多個不同地址的git資料來源。在MultipleJGitEnvironmentRepository類中代理遍歷每個 JGitEnvironmentRepository，JGitEnvironmentRepository 下使用 NativeEnvironmentRepository 代理讀取本地檔案。

@Override
public Environment findOne(String application, String profile, String label,
             boolean includeOrigin) {
  //遍歷所有Git源
  for (PatternMatchingJGitEnvironmentRepository repository :
this.repos.values()) {
    if (repository.matches(application, profile, label)) {
      for (JGitEnvironmentRepository candidate :
getRepositories(repository,
                                  
application, profile, label)) {
        try {
          if (label == null) {
            label = candidate.getDefaultLabel();
         }
          Environment source = candidate.findOne(application, profile,
                             label,
includeOrigin);
          if (source != null) {
            return source;
}
       }
        catch (Exception e) {
          if (this.logger.isDebugEnabled()) {
            this.logger.debug(
              "Cannot load configuration from " +
candidate.getUri()
              + ", cause: (" + e.getClass().getSimpleName()
              + ") " + e.getMessage(),
              e);
         }
          continue;
       }
     }
   }
 }
  JGitEnvironmentRepository candidate = getRepository(this, application,
profile,
                            label);
  if (label == null) {
    label = candidate.getDefaultLabel();
 }
  if (candidate == this) {
    return super.findOne(application, profile, label, includeOrigin);
 }
  return candidate.findOne(application, profile, label, includeOrigin);
}

在AbstractScmEnvironmentRepository類findOne方法中呼叫抽象類的findOne方法，主要有兩個核心邏輯

呼叫getLocations從GIT遠端倉庫同步到本地
使用 NativeEnvironmentRepository 委託來讀取本地檔案內容

@Override
public synchronized Environment findOne(String application, String profile,
                    String label, boolean includeOrigin) {
  NativeEnvironmentRepository delegate = new NativeEnvironmentRepository(
    getEnvironment(), new NativeEnvironmentProperties());
  Locations locations = getLocations(application, profile, label);
  delegate.setSearchLocations(locations.getLocations());
  Environment result = delegate.findOne(application, profile, "",
includeOrigin);
  result.setVersion(locations.getVersion());
  result.setLabel(label);
  return this.cleaner.clean(result, getWorkingDirectory().toURI().toString(),
               getUri());
}

Spring Cloud Config應用篇（九）
2020-12-30
SpringCloud
Spring Cloud Hystrix原碼篇（十一）
2021-01-02
SpringCloud
spring cloud config 原始碼分析
2020-11-04
SpringCloud原始碼
Spring Cloud（二）：Spring Cloud Config
2021-09-09
SpringCloud
spring cloud分散式微服務：Spring Cloud Config
2020-01-15
SpringCloud分散式微服務
Spring Cloud Config 規範
2018-12-12
SpringCloud
spring cloud config 整合svn
2018-05-03
SpringCloud
Spring Cloud Config 配置中心
2018-04-24
SpringCloud
Spring cloud系列教程第十篇- Spring cloud整合Eureka總結篇
2020-07-12
SpringCloud
Spring Cloud Config伺服器
2021-09-09
SpringCloud伺服器
跟我學SpringCloud | 第六篇：Spring Cloud Config Github配置中心
2019-07-06
SpringGCCloudGithub
Spring Boot系列(四) Spring Cloud 之 Config Client
2019-05-10
Spring BootCloudclient
Spring Cloud Config-Git後端
2019-04-08
SpringCloudGit後端
Spring Cloud Config 實現配置中心
2020-02-08
SpringCloud
Spring Cloud Config客戶端使用
2019-06-03
SpringCloud客戶端
Spring Cloud專題之五：config
2021-08-01
SpringCloud
Spring Cloud（八）高可用的分散式配置中心 Spring Cloud Config
2019-03-02
SpringCloud分散式
Spring Cloud實戰系列(六) - 分散式配置中心Spring Cloud Config
2019-02-02
SpringCloud分散式
[Spring Cloud Tutorial翻譯系列二]Spring Cloud Config Server與git整合
2019-04-04
SpringCloudServerGit
為Spring Cloud Config插上管理的翅膀
2018-07-29
SpringCloud
Spring Cloud 之 Config與動態路由.
2019-07-26
SpringCloud路由
java 教程 Spring Cloud Config環境庫
2019-06-02
JavaSpringCloud
Spring Cloud Config 實現配置中心，看這一篇就夠了
2019-07-25
SpringCloud
spring-cloud-square原始碼速讀(spring-cloud-square-okhttp篇)
2021-11-02
SpringCloud原始碼HTTP
Spring Cloud 學習筆記 ——Spring Cloud Config 請求失敗重試
2020-10-30
SpringCloud筆記
spring cloud微服務分散式雲架構-Spring Cloud Config環境庫
2019-03-14
SpringCloud微服務分散式架構
Spring Cloud雲架構-Config Git後端
2019-02-28
SpringCloud架構Git後端
Spring cloud config 使用gitHub或者gitee連線
2018-06-15
SpringCloudGithubGitee
Spring Cloud Config 分散式配置中心【Finchley 版】
2018-08-23
SpringCloud分散式
Spring Cloud Config Client 超時與重試
2019-03-04
SpringCloudclient
非spring boot (即spring) 使用／整合 Spring cloud Config 分散式配置中心
2019-03-04
Spring BootCloud分散式
Spring Cloud（九）高可用的分散式配置中心 Spring Cloud Config 整合 Eureka 服務
2019-02-17
SpringCloud分散式
微服務SpringCloud之Spring Cloud Config配置中心Git
2019-08-05
微服務SpringGCCloudGit
業餘草 SpringCloud教程 | 第六篇: 分散式配置中心(Spring Cloud Config)(Finchley版本)
2018-08-04
SpringGCCloud分散式
spring cloud config將配置儲存在資料庫中
2019-02-21
SpringCloud資料庫
spring-cloud-square原始碼速讀（retrofit + okhttp篇）
2021-11-04
SpringCloud原始碼HTTP
SpringCloud分散式微服務雲架構第六篇: 分散式配置中心(Spring Cloud Config)
2019-12-16
SpringGCCloud分散式微服務架構
spring cloud gateway 之限流篇
2018-12-18
SpringCloudGateway