聊聊 Spring Cloud Config

一般服務器的應用都有以下幾種類型,

其中當屬業務部分最多也最繁雜。

當應用越來越龐大和複雜時,單機就肯定不能滿足需求了,然後就要考慮分佈式了,接下可能會應用不同的語言來開發應用。

比如 nginx 毫無疑問的是用的最多的反向代理組件,使用 OpenResty 便要用到 lua,再比如前端要 seo ,一個解決辦法就是使用 nodejs,到了後端分佈式,那就更繁多了,可能會需要把業務一個個拆分成不同的服務單獨運行...

然後就發現散落一地的配置文件:***properties***、***yml***、***json*** …

爲了解決這個問題,我們採取了這麼一種模式,通過 etcd 我們的項目就是這樣,來收集所有的配置,然後統一的寫到一個文件中去,任何應用都來訪問這一個文件來找到自己的配置並應用。

這很好的解決了配置散落的問題,可以集中管理了,但是又存在另一個問題,各種類型的配置在一個文件裏看起來好亂,而且在初始化時必須要完成這個文件才能啓動應用。

所以下一個解決方案便想到用一個配置中心來解決問題。

Spring Cloud Config 項目

提供 服務端 和 客戶端 支持 集中式 管理分佈式環境下的應用配置 基於 Spring 環境,無縫 與 Spring 應用集成 可用於 任何 語言開發的程序 默認實現基於 git 倉庫,可以進行 版本管理 可替換 自定義實現

Spring Cloud Config Server 作爲配置中心服務端

拉取配置時更新 git 倉庫副本,保證是最新結果 支持數據結構豐富,yml, json, properties 等 配合 eureke 可實現服務發現,配合 cloud bus 可實現配置推送更新 配置存儲基於 git 倉庫,可進行版本管理 簡單可靠,有豐富的配套方案

Spring Cloud Config Client 默認客戶端實現

SpringBoot 項目不需要改動任何代碼,加入一個啓動配置文件指明使用 ConfigServer 上哪個配置文件即可 簡單使用示例

新建一個 git 倉庫,添加一個配置文件。例如想要一個 billing的服務,性質是開發,運行環境是測試環境。

那麼就新建一個 testing 的分支,然後提交一個 billing-dev.properties 的文件

devMode = true spring.application.name = billing spring.jdbc.host = localhost spring.jdbc.port = 3306 spring.jdbc.user = root spring.jdbc.password = 123qwe loging.file = demo

然後新建一個標準 maven 項目

ConfigServer.java @ [email protected] class ConfigServer { public static void main(String[] args) { SpringApplication.run(ConfigServer.class, args); }} application.yml server: port: 8888spring: cloud: config: server: git: uri:https://git.coding.net/tiangao/demo-config-server.git clone-on-start: true pom.xml <?xml version="1.0" encoding="UTF-8"?><project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <parent> <artifactId>spring-cloud-demo</artifactId> <groupId>xyz.stg.cloud</groupId> <version>1.0-SNAPSHOT</version> </parent> <modelVersion>4.0.0</modelVersion> <artifactId>config-server</artifactId><parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>1.4.1.RELEASE</version> </parent> <dependencies> <!-- https://mvnrepository.com/artifact/org.springframework.cloud/spring-cloud-config-server --> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-config-server</artifactId> <version>1.2.1.RELEASE</version> </dependency> </dependencies></project>

好了,配置中心已經可以啓動了,配最簡單的可以用瀏覽器來訪問。

想要 json 格式的怎麼辦呢?

還有 yml, properties

OK, 就是這樣簡單。不過直接就能通過 url 得到,是不是有點不安全,這也不難,加上依賴。

java <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-security</artifactId> </dependency> 然後在 application.yml 配置用戶名和密碼,user 便是用戶名。 security: user: password: db1ab002-1fba-476d-a421-22113355

再訪問就能看到如下的效果

這是 ConfigSever 默認實現的基本的 HttpBasic 的認證。

服務端好了現在來看看 SpringBoot 客戶端

只需要添加一個啓動配置文件:

java cloud: config: uri: http://127.0.0.1:8888 profile: dev label: testing name: billing password: db1ab002-1fba-476d-a421-22113355 username: user

當啓動時看到下面標示的內容是即表示加載成功。

簡單示例就這樣,下面便是 Config 的使用示意圖。

吶,就是這樣,所有的配置都通過倉庫來管理,應用啓動時訪問配置中心能拿到自己的配置就OK,再接下來就是各自的事情了。

倉庫也不僅僅只能用 git, 還有 svn 和本地目錄可以選擇

svn:///${user.home}/config-repo file://${user.home}/config-repo

從簡單的示例裏可以看出,我們只要提交一種格式的配置文件,通過不同的方式訪問即可得到不同格式的配置文件,這在ConfigServer裏是如何實現的呢?

先看一共有多少種訪問方式 /{name}/{profiles:.*[^-].*} /{name}/{profiles}/{label:.*} /{name}-{profiles}.properties /{label}/{name} /{profiles}.properties /{name}-{profiles}.json /{label}/{name}-{profiles}.json

然後就能發現有這麼一個類,裏面有各種資源類型的轉換操作。EnvironmentController 的所有方法如下所示:

原來內部只存在一種資源抽象,所有的資源對象都是由這種類型轉換而來。

一個應用的配置只需要應用名、屬性和標籤就可以定位到。嗯,原來這麼簡單,那 EnvironmentReposiroty 又是哪裏實現呢?

findOne 方式在 AbstractScmEnvironmentRepository 中可以找到。

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

這其中又由 SearcPathLocator 接口的 getLocations() 來實際加載內容,這個方法就由具體的實現類來完成。

Spring Cloud Config Server 內部除了 JGitEnvironmentRepository 實現外還有另外三種實現。

SvnKitEnvironmentRepository NativeEnvironmentRepository MultipleJGitEnvironmentRepository

見名知其意,分別是 svn 本地目錄以及多 git 倉庫的實現。

來到客戶端這邊,SpringBoot

項目只需要加載依賴就可以使用到遠程配置,現有項目遷移過去也不用改動任何代碼,感覺好神奇。

達到這樣的效果依賴於 springMVC 的抽象以及 springboot 的自動配置類加載。

```java

@Configuration

public class ConfigClientAutoConfiguration {

@Beanpublic ConfigClientProperties configClientProperties( Environment environment, ApplicationContext context) {...}[email protected] ConfigServerHealthIndicator configServerHealthIndicator( ConfigServicePropertySourceLocator locator, ConfigClientHealthProperties properties, Environment environment) { return new ConfigServerHealthIndicator(locator, environment, properties);}...

}

**ConfigClientAutoConfiguration** 這個是 ConfigClient 的自動配置類,加載時觸發新建一個 ConfigServicePropertySourceLocator 的 bean, java

@Order (0)

public class ConfigServicePropertySourceLocator

implements PropertySourceLocator {

private RestTemplate restTemplate;private ConfigClientProperties defaultProperties;[email protected]@Retryable(interceptor = "configServerRetryInterceptor")public org.springframework.core.env.PropertySource<?> locate( org.springframework.core.env.Environment environment) { ... // Try all the labels until one works for (String label : labels) { Environment result = getRemoteEnvironment(restTemplate, properties, label.trim(), state); ...

}

```

然後在 ApplicationContextInitializer 的 initialize 方法中被調用 locate 方法從 ConfigServer 拉取配置文件,注入到 ConfigurableEnvironment 中,

@ [email protected](PropertySourceBootstrapProperties.class)public class PropertySourceBootstrapConfiguration implementsApplicationContextInitializer<ConfigurableApplicationContext>, Ordered { [email protected] void initialize(ConfigurableApplicationContext applicationContext) {...ConfigurableEnvironment environment = applicationContext.getEnvironment();for (PropertySourceLocator locator : this.propertySourceLocators) {PropertySource<?> source = null;source = locator.locate(environment);if (source == null) {continue;}...}...}}

接着纔是應用的初始化過程。

從這個過程可以看到,其他任何應用需要使用 ConfigServer 時只需要在應用初始化之前通過 http 拉取到配置文件即可。

瞭解了大致原理,便可以看到集中式管理的優點。

沒有記憶負擔:大家都使用一個倉庫保存所有配置文件,方便查看。

降低衝突溝通成本:開發新功能是凡是有配置變動均向倉庫的提交,在合併後其他人碰到配置問題時也不用到處找人問,看看倉庫歷史就知道什麼發生了變化。

方便測試:測試環境下,測試人員也不用老是問開發環境配置的問題了,所有配置一目瞭然,更改配置也有記錄,有問題向開發反饋也能幫助快速定位問題範圍。

方便管理: 在模擬環境和生產環境下,通過分支保護和權限管理管理線上配置文件,由運維人員來管理。