SpringCloud系列：服務配置文件的進化歷程（程序內置、程序外置、實時更新）

1、概述

  最先以前的應用都直接把配置文件打包在應用內，這種方式簡單、容易上手，缺點也很明顯，每次更改參數都須要從新打包程序、從新部署；接下來是把配置文件放在應用外，修改參數內容不須要從新打包編譯，可是須要重啓服務才能生效；如今互聯網公司使用的配置文件都是支持分佈式實時推送、實時生效，無需編譯程序、也無需重啓服務。

2、配置文件內置

  這種方式比較簡單，一般都是把配置文件放在Resources下，而後經過Spring或者程序讀取配置文件內容，將參數加載到內存中以便應用使用。

優勢：簡單、方便

缺點：每次修改參數須要改動源代碼、從新編譯部署，開發、測試、生產環境要分別設置打包參數（經過maven參數設置）

3、配置文件外置

      配置文件放在程序裏，極大的限制了參數修改的便捷性；後來你們就想到把配置文件外置，這樣修改參數就不須要改動源碼，只須要修改外置的配置文件便可。通常maven項目經過配置spring就能夠直接讀取外置的配置文件，而後經過spel或者${}取值便可使用參數。

以下spring的配置，先從環境變量env.files讀取配置文件的路徑，而後加載到spring上下文中。若環境變量路徑不存在，則從classpath加載配置

<bean id="env"
		class="org.springframework.beans.factory.config.PropertiesFactoryBean">		<property name="locations" value="#{systemProperties['env.files'] ?: 'classpath:/dev/*.properties'}" />
		<property name="fileEncoding" value="UTF-8" ></property>
	</bean>

若是咱們的項目使用的是SpringCloud(或者基於SpringBoot)的項目，那就簡單多了，應該SpringBoot默認的加載順序就是jar外的配置文件優先級高於jar內配置文件。具體優先級以下

1. 命令行中傳入的參數

2.SPRING_APPLICATION_JOSN中的屬性。其是以JSON格式配置在系統環境變量中的內容

3. java：comp/env中的JNDI屬性

4. java的系統屬性，能夠經過System.getProperties()獲取的內容

5. 操做系統的環境變量

6. 經過random.*配置的隨機屬性

7. 位於當前應用jar包以外，針對不一樣{profile}環境的配置文件內容，例如application-{profile}.properties或YAML定義的配置文件

8.位於當前應用jar包以內，針對不一樣{profile}環境的配置文件內容，例如application-{profile}.properties或YAML定義的配置文件。

9.位於當前應用jar包以外的application.properties或YAML配置內容

10.位於當前應用jar包以內的application.properties或YAML配置內容

 

4、實時推送更新

    SpringCloud也提供了其本身的配置中心SpringCloud config，經過和BUS配合，也能作到從svn或者git倉庫實時推送更新配置文件。可是從我的使用來講，仍是以爲百度開源的分佈式配置中心Disconf和攜程開源的Apollo更勝一籌。接下來的文章準備介紹下SpringCloud結合Disconf和Apollo實現分佈式配置中心。

Disconf

Distributed Configuration Management Platform(分佈式配置管理平臺)

專一於各類「分佈式系統配置管理」的「通用組件」和「通用平臺」, 提供統一的「配置管理服務」

包括 百度、滴滴出行、銀聯、網易、拉勾網、蘇寧易購、順豐科技 等知名互聯網公司正在使用!

 

主要目標：

• 部署極其簡單：同一個上線包，無須改動配置，便可在 多個環境中(RD/QA/PRODUCTION) 上線

• 部署動態化：更改配置，無需從新打包或重啓，便可 實時生效

• 統一管理：提供web平臺，統一管理 多個環境(RD/QA/PRODUCTION)、多個產品 的全部配置

• 核心目標：一個jar包，處處運行

 

功能特色

• 支持配置（配置項+配置文件）的分佈式化管理

• 配置發佈統一化

  • 同一個上線包 無須改動配置 便可在 多個環境中(RD/QA/PRODUCTION) 上線

  • 配置存儲在雲端系統，用戶統一管理 多個環境(RD/QA/PRODUCTION)、多個平臺 的全部配置

  • 配置發佈、更新統一化:

  • 配置更新自動化：用戶在平臺更新配置，使用該配置的系統會自動發現該狀況，並應用新配置。特殊地，若是用戶爲此配置定義了回調函數類，則此函數類會被自動調用。

• 極簡的使用方式（註解式編程 或 XML無代碼侵入模式）：咱們追求的是極簡的、用戶編程體驗良好的編程方式。目前支持兩種開發模式：基於XML配置或者基於註解，便可完成複雜的配置分佈式化。

注：配置項是指某個類裏的某個Field字段。

其它功能特色

• 低侵入性或無侵入性、強兼容性：

  • 低侵入性：經過極少的註解式代碼撰寫，便可實現分佈式配置。

  • 無侵入性：經過XML簡單配置，便可實現分佈式配置。

  • 強兼容性：爲程序添加了分佈式配置註解後，開啓Disconf則使用分佈式配置；若關閉Disconf則使用本地配置；若開啓Disconf後disconf-web不能正常Work，則Disconf使用本地配置。

• 支持配置項多個項目共享，支持批量處理項目配置。

• 配置監控：平臺提供自校驗功能（進一步提升穩定性），能夠定時校驗應用系統的配置是否正確。

 

Apollo

Apollo（阿波羅）是攜程框架部門研發的配置管理平臺，可以集中化管理應用不一樣環境、不一樣集羣的配置，配置修改後可以實時推送到應用端，而且具有規範的權限、流程治理等特性。

服務端基於Spring Boot和Spring Cloud開發，打包後能夠直接運行，不須要額外安裝Tomcat等應用容器。

Java客戶端不依賴任何框架，可以運行於全部Java運行時環境，同時對Spring/Spring Boot環境也有較好的支持。

.Net客戶端不依賴任何框架，可以運行於全部.Net運行時環境。

 

功能特色

• 統一管理不一樣環境、不一樣集羣的配置

  • Apollo提供了一個統一界面集中式管理不一樣環境（environment）、不一樣集羣（cluster）、不一樣命名空間（namespace）的配置。

  • 同一份代碼部署在不一樣的集羣，能夠有不一樣的配置，好比zk的地址等

  • 經過命名空間（namespace）能夠很方便的支持多個不一樣應用共享同一份配置，同時還容許應用對共享的配置進行覆蓋

• 配置修改實時生效（熱發佈）

  • 用戶在Apollo修改完配置併發布後，客戶端能實時（1秒）接收到最新的配置，並通知到應用程序。

• 版本發佈管理

  • 全部的配置發佈都有版本概念，從而能夠方便的支持配置的回滾。

• 灰度發佈

  • 支持配置的灰度發佈，好比點了發佈後，只對部分應用實例生效，等觀察一段時間沒問題後再推給全部應用實例。

• 權限管理、發佈審覈、操做審計

  • 應用和配置的管理都有完善的權限管理機制，對配置的管理還分爲了編輯和發佈兩個環節，從而減小人爲的錯誤。

  • 全部的操做都有審計日誌，能夠方便的追蹤問題。

• 客戶端配置信息監控

  • 能夠方便的看到配置在被哪些實例使用

• 提供Java和.Net原生客戶端

  • 提供了Java和.Net的原生客戶端，方便應用集成

  • 支持Spring Placeholder, Annotation和Spring Boot的ConfigurationProperties，方便應用使用（須要Spring 3.1.1+）

  • 同時提供了Http接口，非Java和.Net應用也能夠方便的使用

• 提供開放平臺API

  • Apollo自身提供了比較完善的統一配置管理界面，支持多環境、多數據中心配置管理、權限、流程治理等特性。

  • 不過Apollo出於通用性考慮，對配置的修改不會作過多限制，只要符合基本的格式就可以保存。

  • 在咱們的調研中發現，對於有些使用方，它們的配置可能會有比較複雜的格式，如xml, json，須要對格式作校驗。

  • 還有一些使用方如DAL，不只有特定的格式，並且對輸入的值也須要進行校驗後方可保存，如檢查數據庫、用戶名和密碼是否匹配。

  • 對於這類應用，Apollo支持應用方經過開放接口在Apollo進行配置的修改和發佈，而且具有完善的受權和權限控制

• 部署簡單

  • 配置中心做爲基礎服務，可用性要求很是高，這就要求Apollo對外部依賴儘量地少

  • 目前惟一的外部依賴是MySQL，因此部署很是簡單，只要安裝好Java和MySQL就可讓Apollo跑起來

  • Apollo還提供了打包腳本，一鍵就能夠生成全部須要的安裝包，而且支持自定義運行時參數