以下部分純屬個人理解，但是結果都是經過demo驗證。

一、spring cloud config介紹

　　spring cloud是spring家族中的一個微服務工具包，其中包含了很多微服務的工具。偏向於與spring boot類似的配置方式，有許多許多預設配置。spring cloud config是其中的一個工具包，用於配置的拉取更新。

　　舉一個小小的例子，當我們程式中有一個配置檔案需要修改，但是服務已經啟動，配置檔案中的配置已經讀取到記憶體中，為了修改配置，我們需要重啟服務；如果是一臺或者幾臺機器重啟，還算容易，但是如果是一個叢集，重啟就變成一個非常耗時的工作；如果我們使用spring cloud config，就可以在服務執行時，拉取git（svn等，下面以git為例）的配置，修改記憶體中的配置。

二、spring cloud config邏輯介紹

　　config-server：提供對git的連線，配置拉取，這裡的拉取是被動拉取。

　　config-client：連線config-server，通過URI請求對應的配置檔案，獲取配置屬性

　　如圖表示client從server拉取配置的過程：

　　1、client根據配置向server傳送配置請求

　　2、server根據配置從git拉取所有檔案（git clone的過程）

　　3、git將整個倉庫下發

　　4、server解析client的URI請求，返回相應的配置屬性或者錯誤資訊（不存在相應的配置屬性）

　　如圖表示client傳送重新整理配置請求的過程：

　　1、client向server傳送refresh請求

　　2、server向從git更新本地配置（git pull）

　　3、git下發更新

　　4、server對比更新，發現client需要的配置有更新時，會將更新資訊發給client

理解：1、在client第一次向server傳送URI請求時，server會根據配置的git地址，拉取對應倉庫的所有檔案（與git [email protected]{git adress}）（在config-server本地/tmp目錄下可以找到git本地倉庫）；

　　　2、值得注意的是，在client傳送重新整理配置請求（refresh）時，server會根據本地倉庫的情況處理：

　　　　　（1）如果server本地倉庫有未提交的commit和未commit的修改時，server就不會從git上拉取更新（不會git pull），只會將本地倉庫中對應的配置屬性傳給client；

　　　　　（2）如果server本地倉庫沒有任何修改和commit，server會從git上拉取更新（git pull），然後將本地倉庫對應的配置屬性傳給client。

　　　3、還有一個坑點，我在demo測試過程中發現，如果git倉庫過大，拉取過程很長，在server拉取的時候會出錯（有一個最大等待時長，超過會出現超時錯誤）。為了實現大的二進位制檔案的正常拉取，可以切到本地倉庫地址，手動拉取一次更新。

　　　　　（1）在建立本地倉庫時就採用手動拉取的方式：在配置檔案application.properties中，設定git的url地址為本地檔案地址，初始化時，手動git clone遠端倉庫地址到設定的本地檔案地址。在更新配置的時候，config-server也會自動從遠端拉取更新。

　　　　　（2）如果是更新的時候有大檔案的修改導致不能拉取更新：application.properties配置檔案中git的url為遠端倉庫地址，初始化時能夠自動拉取，如果有大檔案更新，利用git工具，手動切到本地/tmp目錄下，利用git命令手動拉取更新就可以拉取大檔案的更新，在之後的小檔案更新中，config-server就能夠正常自動更新。

總之就是，client向server傳送一個URI請求：“我要**屬性，你那裡有嗎？”，然後server根據自身的配置，拉取git倉庫，然後去找client需要的那個屬性，然後告訴client：“我這裡有（沒有）這個屬性，（有就給client）”；重新整理過程就是，client向server傳送一個URI請求：“我請求的屬性值變了嗎？”，然後server處理之後，回覆client：“變了，這是新的值。（沒變）”。

三、配置檔案介紹

1、client配置檔案如下：

spring.application.name = test                              1
spring.cloud.config.lable = master                          2
spring.cloud.config.profile = dev                           3 
spring.cloud.config.uri = http://localhost:8881/        　　 4

解釋：1和3組成了訪問的配置檔名，如test-dev.properties

　　　2決定了git的分支，此處為master分支

　　　4表示config-server的地址

請求的URI就是由這個配置決定的，網上關於這點的說明很多，此處不再贅述

2、server配置檔案如下：

spring.cloud.config.server.git.uri = https://github.com/lucknot/songxh_scse/　　　　1
spring.cloud.config.server.git.searchPaths = test　　　　　　　　　　　　　　　　　　　　2

解釋：1表示git倉庫的地址，這裡是我的github倉庫地址（並沒有乾貨）

　　　2表示配置搜尋的資料夾，在client請求配置時，只會在這個資料夾下進行搜尋

事實上將1和2拼接在一起就組成了搜尋配置屬性的URL地址。

針對配置檔案需要說明以下，label表示的分支只與client的配置相關：client中配置的是哪個分支就取哪個分支的配置

ps：在寫這篇部落格的時候突然想到一個問題，client在像server請求時是否只是請求需要的屬性的值，還是請求對應的屬性檔案。個人感覺是取對應檔名的配置檔案，在client拿到配置檔案後再將讀取對應的屬性，與spring boot中從配置檔案中讀取屬性類似（事實上就是兩個上下文，spring cloud的上下文有高優先順序）。