https://kuaibao.qq.com/s/20180530G1O8RC00?refer=spider

一、介紹

 

在系統架構中，和安全、日志、監控等非功能需求一樣，配置管理也是一種非功能需求。配置中心是整個微服務基礎架構體系中的一個組件，如下圖，它的功能看上去並不起眼，無非就是簡單配置的管理和存取，但它是整個微服務架構中不可或缺的一環。另外，配置中心如果真得用好了，它還能推動技術組織持續交付和DevOps文化轉型。

 

 

本文介紹在分布式微服務環境下，應用配置管理背后的業務需求，配置的各種分類和一些高級應用場景。

 

二、配置定義和形態

 

配置其實是獨立於程序的可配變量，同一份程序在不同配置下會有不同的行為，常見的配置有連接字符串，應用配置和業務配置等。

配置有多種形態，下面是一些常見的：

程序內部hardcode，這種做法是反模式，一般我們不建議！

配置文件，比如Spring應用程序的配置一般放在文件中。

環境變量，配置可以預置在操作系統的環境變量里頭，程序運行時讀取，這是很多PaaS平台，比如Heroku推薦的做法，參考12 factor app[附錄9.1]。

啟動參數，可以在程序啟動時一次性提供參數，例如java程序啟動時可以通過方式配啟動參數。

基於數據庫，有經驗的開發人員會把易變配置放在數據庫中，這樣可以在運行期靈活調整配置，這個做法和配置中心的思路已經有點接近了。

 

 

 

三、傳統應用配置的痛點

 

在沒有引入配置中心之前，一般企業研發都會面臨如下痛點：

1. 配置散亂格式不標准

有的用properties格式，有的用xml格式，還有的存DB，團隊傾向自造輪子，做法五花八門。

2. 主要采用本地靜態配置，配置修改麻煩

配置修改一般需要經過一個較長的測試發布周期。在分布式微服務環境下，當服務實例很多時，修改配置費時費力。

3. 易引發生產事故

這個是我親身經歷，之前在一家互聯網公司，有團隊在發布的時候將測試環境的配置帶到生產上，引發百萬級資損事故。

4. 配置缺乏安全審計和版本控制功能

誰改的配置？改了什么？什么時候改的？無從追溯，出了問題也無法及時回滾。

 

四、現代應用配置核心需求

 

近年，持續交付和DevOps理念開始逐步被一線企業接受，微服務架構和容器雲也逐漸在一線企業落地，這些都對應用配置管理提出了更高的要求：

 

 

1. 交付件和配置分離

傳統做法應用在打包部署時，會為不同環境打出不同配置的包，例如為開發/測試/UAT/生產環境分別制作發布包，每個包里頭包含環境特定配置。

現代微服務提倡雲原生(Cloud Native)和不可變基礎設施（Immutable Infrastructure）的理念，推薦采用如容器鏡像這種方式打包和交付微服務，應用鏡像一般只打一份，可以部署到不同環境。這就要求交付件（比如容器鏡像）和配置進行分離，交付件只制作一份，並且是不可變的，可以部署到任意環境，而配置由配置中心集中管理，所有環境的配置都可以在配置中心集中配，運行期應用根據自身環境到配置中心動態拉取相應的配置。

2. 抽象標准化

企業應該由框架或者中間件團隊提供標准化的配置中心服務(Configuration as a Service)，封裝屏蔽配置管理的細節和配置的不同格式，方便用戶進行自助式的配置管理。一般用戶只需要關注兩個抽象和標准化的接口：

 

配置管理界面UI，方便應用開發人員管理和發布配置，

封裝好的客戶端API，方便應用集成和獲取配置。

3. 多環境多集群

 

現代微服務應用大都采用多環境部署，一般標准化的環境有開發/測試/UAT/生產等，有些應用還需要多集群部署，例如支持跨機房或者多版本部署。配置中心需要支持對多環境和多集群應用配置的集中式管理。

4. 高可用

配置中心必須保證高可用，不能隨便掛，否則可能大面積影響微服務。在極端的情況下，如果配置中心不可用，客戶端也需要有降級策略，保證應用可以不受影響。

5. 實時性

配置更新需要盡快通知到客戶端，這個周期不能太長，理想應該是實時的。有些配置的實時性要求很高，比方說主備切換配置或者藍綠部署配置，需要秒級切換配置的能力。

6. 治理

配置需要治理，具體包括：

配置審計，誰、在什么時間、修改了什么配置，需要詳細的審計，方便出現問題時能夠追溯。

配置版本控制，每次變更需要版本化，出現問題時候能夠及時回滾到上一版本。

配置權限控制，配置變更發布需要認證授權，不是所有人都能修改和發布配置。

灰度發布，高級的配置治理支持灰度發布，配置發布時可以先讓少數實例生效，確保沒有問題再逐步放量。

 

五、配置分類

 

配置目前還沒有特別標准的分類方法，我簡單把配置分為靜態和動態兩大類，每一類再分為若干子類，如下圖：

 

 

1. 靜態配置

所謂靜態配置，就是在程序啟動前一次性配好，啟動時一次性生效，在程序運行期一般不會變化的配置。具體包括：

1.1 環境相關配置

有些配置是和環境相關的，每個環境的配置不一樣，例如數據庫、中間件和其它服務的連接字符串配置。這些配置一次性配好，運行期一般不變。

1.2 安全配置

有些配置和安全相關，例如用戶名，密碼，訪問令牌，許可證書等，這些配置也是一次性配好，運行期一般不變。因為涉及安全，相關信息一般需要加密存儲，對配置訪問需要權限控制。

2. 動態配置

所謂動態配置，就是在程序的運行期可以根據需要動態調整的配置。動態配置讓應用行為和功能的調整變得更加靈活，是持續交付和DevOps的最佳實踐。具體包括：

2.1 應用配置

和應用相關的配置，例如服務請求超時，線程池和隊列的大小，緩存過期時間，數據庫連接池的容量，日志輸出級別，限流熔斷閥值，服務安全黑白名單等。一般開發或者運維會根據應用的實際運行情況調整這些配置。

2.2 業務配置

和業務相關的一些配置，例如促銷規則，貸款額度，利率等業務參數，A/B測試參數等。一般產品運營或開發人員會根據實際的業務需求，動態調整這些參數。

2.3 功能開關

在英文中也稱Feature Flag/Toggle/Switch，簡單的只有真假兩個值，復雜的可以是多值參數。功能開關是DevOps的一種最佳實踐，在運維中有很多應用場景，比如藍綠部署，灰度開關，降級開關，主備切換開關，數據庫遷移開關等。功能開關在國外互聯網公司用得比較多，國內還沒有普及開，所以我在下一節會給出一些功能開關的高級應用場景。

 

六、配置中心高級應用場景

 

場景一、藍綠部署

藍綠部署的傳統做法是通過負載均衡器切流量來實現，如下圖左邊所示。這種做法一般研發人員無法自助操作，需要提交工單由運維介入操作，操作和反饋周期比較長，出了問題回退還需運維人員介入，所以回退也比較慢，總體風險比較高。

 

 

藍綠部署也可以通過配置中心+功能開關的方式來實現，如上圖右邊所示。開發人員在上線新功能時先將新功能隱藏在動態開關后面，開關的值在配置中心里頭配。剛上線時新功能暫不啟用，走老功能邏輯，然后開發人員通過配置中心打開開關，這個時候新功能就啟用了。一旦發現新功能有問題，可以隨時把開關關掉切回老功能。這種做法開發人員可以全程自助實現藍綠部署，不需要運維人員介入，反饋周期短效率高。

場景二、限流降級

當業務團隊在搞促銷，或者是系統受DDOS攻擊的時候，如果沒有好的限流降級機制，則系統很容易被洪峰流量沖垮，這個時候所有用戶無法訪問，體驗糟糕，如下圖左邊所示。

 

 

所以我們需要限流降級機制來應對流量洪峰。常見做法，我們一般會在應用的過濾器層或者是網關代理層添加限流降級邏輯，並且和配置中心配合，實現限流降級開關和參數的動態調整。如果促銷出現流量洪峰，我們可以通過配置中心啟動限流降級策略，比如對於普通用戶，我們可以先給出“網絡不給力，請稍后再試”的友好提示，對於高級VIP用戶，我們仍然保證他們的正常訪問。

國內電商巨頭阿里，它內部的系統大量采用限流降級機制，實現方式基於其內部的diamond+sentinel配置管理系統。如果沒有限流降級機制的保護，則阿里的系統也無法抵御雙十一帶來的洪峰流量沖擊。

場景三、數據庫遷移

LaunchDarkly是一家提供配置既服務(Configuration as a Service)的SAAS服務公司，它在其博客上給出了一片關於使用功能開關實現數據庫遷移的案例文章，該案例基於其內部一次成功的數據庫遷移實踐，從MongdoDB遷移到DynamoDB[參考附錄9.2]，下圖是展示了一個簡化的遷移流程：

 

 

簡化遷移騰挪流程如下：

 

開發人員先在應用端的DAO層埋好數據雙寫雙讀、以及數據比對邏輯。雙寫雙讀邏輯由開關控制，開關的值可在配置中心配。

先保證應用100%讀寫mongoDB，然后先放開10%的DynamoDB雙寫，也稱金絲雀寫(Canary Write)，確保金絲雀寫沒有功能和性能問題。

逐步放量DyanamoDB寫到100%，確保全量雙寫沒有功能和性能問題。

放開10%的DynamoDB雙讀，也稱金絲雀讀(Canary Read)，通過比對邏輯確保金絲雀讀沒有邏輯和性能問題。

逐步放量DynamoDB讀到100%，通過比對邏輯確保全量雙讀沒有邏輯和性能問題。

關閉對mongoDB的讀寫，遷移完成。

 

整個遷移流程受配置中心的開關控制，可以靈活調整開關和參數，有問題可以隨時回滾，大大降低遷移風險。

場景四、A/B測試

如果我們需要對電商平台的結賬(checkout)功能進行改版，考慮到結賬功能業務影響面大，一下子上線風險大，為了減低風險，我們可以在配置中心配合下，對結賬功能進行A/B測試，簡化邏輯如下圖：

 

 

我們在配置中心中增加一個開關，控制A/B測試邏輯：

 

如果A/B測試開關是關閉的()，那么就走老的結賬邏輯。

如果A/B測試開關是打開的(，並且是普通用戶(，可以檢查數據庫中用戶類型)，那么就走老的結賬邏輯。

如果A/B測試開關是打開的()，並且是beta用戶（），那么就走改版后的新結賬邏輯。

 

通過配置中心，我們可以靈活調整開關，先對新功能進行充分的beta試驗，再考慮全量上線，大大降低關鍵業務新功能的上線風險。

 

七、公司案例和產品

 

在一線前沿的互聯網公司，配置中心都是其技術體系中的關鍵基礎服務，下圖給出一些公司案例產品:

 

 

 

阿里巴巴中間件部門很早就自研了配置中心Diamond，並且是開源的。Diamond對阿里系統的靈活穩定性發揮了至關重要的作用。開源版本的Diamond由於研發時間比較早，使用的技術比較老，功能也不夠完善，目前社區不熱已經不維護了。

Facebook內部也有一整套完善的配置管理體系[可參考其論文，附錄9.3]，其中一個產品叫Gatekeeper，目前沒有開源。

Netflix內部有大量的微服務，它的服務的穩定靈活性也重度依賴於配置中心。Netflix開源了它的配置中心的客戶端，叫變色龍Archaius[參考附錄9.4]，比較可惜的是，Netflix沒有開源它的配置中心的服務器端。

Apollo[參考附錄9.5]是攜程框架部研發並開源的一款配置中心產品，企業級治理功能完善，目前社區比較火，在github上有超過5k星，在國內眾多互聯網公司有落地案例。如果企業打算引入開源的配置中心，那么Apollo是我推薦的首選。

百度之前也開源過一個叫Disconf[參考附錄9.6]的配置中心產品，作者是前百度資深工程師廖綺綺。在Apollo沒有出來之前，Disconf在社區是比較火的，但是自從廖琦琦離開百度之后，他好像沒有足夠精力投入維護這個項目，目前社區活躍度已經大不如前。

 

 

八、結論

 

 

配置中心是微服務基礎架構中不可或缺的核心組件，現代微服務架構和雲原生環境，對應用配置管理提出了更高的要求。

配置中心有眾多的應用場景，配置中心+功能開關是DevOps最佳實踐。用好配置中心，它能幫助技術組織實現持續交付和DevOps文化轉型。

攜程開源的Apollo配置中心，企業級功能完善，經過大規模生產驗證，社區活躍度高，是開源配置中心產品的首選。

 

九、附錄

 12 Factor App

https://12factor.net/config

使用功能開關實現數據庫遷移

https://blog.launchdarkly.com/feature-flagging-to-mitigate-risk-in-database-migration/

Facebook的配置管理體系論文

http://sigops.org/sosp/sosp15/current/2015-Monterey/printable/008-tang.pdf

Netflix開源的Archaius配置庫

https://github.com/Netflix/archaius

攜程開源的Apollo配置中心

https://github.com/ctripcorp/apollo

Disconf配置中心

https://github.com/knightliao/disconf