133
現代應用架構中的配置管理麵臨的挑戰和應對之道
摘要：過去15年中，互聯網產業開始蓬勃發展，基於互聯網的各類應用大放異彩，而在信息技術上，企業應用架構也逐漸從傳統的ERP，JavaEE集中式應用開始走向互聯網、雲計算、分布式服務化架構的轉型，在這個過程中，數據中心及應用的配置管理這個領域也發生了深刻的變化。本文簡單介紹了在現代企業應用架構中，傳統的圍繞分散的配置文件為中心的配置管理方式在麵對諸如微服務、DevOps、容器服務、雲計算等新技術形式下麵臨的挑戰，同時會探討如何通過獨立的配置中心服務集中式管理數據中心中的所有配置來解決這一挑戰，同時會簡單介紹在阿裏雲上，應用配置管理產品 ACM 如何幫助阿裏雲用戶更輕鬆的管理應用配置來應對這些挑戰。
配置
配置(Configuration) 這個概念每個技術人都不陌生，可以說一個不提供幾個配置參數的係統都不好意思上線跟別的係統打招唿。那麼為什麼會是這個樣子呢，究其本質是我們人類無法掌控和預知一切，映射到軟件領域上，我們總是需要對係統的某些功能特性預留出一些控製的線頭(配置項)，以便我們在未來需要的時候，可以人為的撥弄這些線頭(配置項變更)從而控製係統的行為特征，我們把它叫做 "***係統運行時(runtime)飛行姿態的動態調整***"
配置管理
- 配置管理是軟件生命周期的重要組成部分
在過去的大約15年左右，軟件工程學在如何持續演進軟件以滿足不斷變化的業務需求的方法論上有了很多的突破和大量的實踐，在這個領域裏，從最初的麵向對象設計方法論，到後來出現的極限編程，到敏捷開發、單元測試驅動、持續集成，再到後來的DevOps等等，其理論和實踐都已經比較成熟，而無論是在持續交付還是在DevOps中，配置管理都是其中極其重要的一個環節,在這個環節中我們會完成構建的“靜態”軟件與“動態”的實際的運行環境的適配過程，完成軟件以及依賴的資源的部署過程，使靜態的軟件代碼變成可以滿足業務需求的在線運行的業務係統。如下圖所示:
- 雲計算與配置管理
利用雲計算在雲上構建現代企業應用已經被無數事例證明是極為有效地方式，在這個過程中可以方麵的利用雲計算提供的按需購買和使用，基礎設施虛擬化帶來的彈性和自動化以及易生成和易運維等特性大大的降低了維護基礎設施的成本，同時也為用戶在雲計算上實施更為有效、更為自動化以及更為低成本的配置管理帶來的可能性，從廣義上講，在雲上，配置管理涵蓋了包括硬件基礎計算資源如主機和網絡設備配置，主機、操作係統和基礎軟件配置以及應用自身配置三個方麵的配置。而前兩者一般已經包含在雲計算基礎設施交付的過程中，應用隻需要更關注應用自身的配置。而利用雲計算無疑可以更好的實施和真正實現Infrastructure as Code(IaC)。
分布式係統中的配置管理
- 分布式係統給配置管理帶來的挑戰
關於什麼是分布式係統，本文不再贅述。關於分布式係統的一個重要論題是如何演進係統(Software Evolution),一個係統或者說軟件從被創造出來之後會經曆研發、測試、到最後的go live，上了生產係統。那麼這個之後，如何持續並且無痛的為其添加新行為或者調整已有行為的表現特征? 這確實非常複雜，尤其是要達到無痛(Painless)的這個目標，畢竟線上係統，調整即意味著可能出故障。而係統的動態配置管理毫無疑問是其中的一個小部分，如果每一個係統行為的任何一個微調都需要將整個係統停機，重啟或者甚至重新構建、發布部署來實現，那要達到無痛這個目標恐怕難度更高。
在分布式係統中，一次構建、發布、上線是非常非常重的一個過程，它不像單機時代那樣重啟一台機器、一個進程就可以了，在分布式係統中，它涉及到將軟件包(例如war)分發到可能超過幾千台機器，然後將幾千台機器上的應用進程一一重啟這麼一個過程，如何通過更有效的動態配置管理手段介紹分布式係統發布值得認真思考。
傳統的軟件開發方式中，配置以配置文件的方式將隨著軟件構建過程中打包在構建的工件裏(Artifact)，這意味著配置是分散在各個工件裏的，這種管理配置的方式，在分布式係統中，將麵臨諸多挑戰
配置變更的熱生效
配置的本質是為調整應用運行時的飛行姿態，修改配置文件之後，如何讓配置在多台生產機器上熱生效？如果每次對生產環境配置的微調都要觸發一次完整的應用構建、發布、灰度、上線的pipeline無疑是不可接受的。配置文件在哪裏？
分布式架構和微服務架構都倡導對於單塊複雜係統的拆分，並由獨立的團隊自治的負責每個子係統的演進和發展，甚至允許選擇不同的技術棧，但從整個分布式係統的角度看，當需要整體控製分布式係統的行為時，這種方式給配置管理帶來了很大的麻煩，我們甚至無法知道每個應用開放了哪些配置? 配置文件在哪個目錄?登上20台機器改配置文件？
當機器多於2台時，一一登上機器修改配置文件將變得不可接受，並且往往需要依靠運維人員的自律性來並確保每台機器配置狀態的一致性。配置值生效了麼?
配置變更之後，變更生效了麼？什麼時間點生效的? 應用運行一段時間後，當前的所有配置值是什麼?配置變更審計
係統故障是否與某次不恰當的配置變更有關?如果是，是誰修改的?何時修改的?配置如何容災
配置文件如何防止誤刪除，保證多級容災?如何在整個數據中心層麵控製配置變更?
當業務計劃或者需要一次大規模的諸如雙11大促，新品發布這種活動時，在諸如關係國計民生的係統在諸如重大政治活動期間（如19大），控製係統的穩定性風險將變得非常重要，而如何在封網期間，禁止所有的配置變更也就成了理所當然的訴求。
微服務與配置中心
微服務架構的主旨在於將大的單塊應用通過合理的服務化拆分為一個個獨立的微服務，並授權給不同的小規模團隊負責來實現係統之間更好的解耦合和獨立演進，進而實現諸如xx,xx,xx(TODO)的目標，微服務係統天然是個分布式係統。在分布式係統中配置管理遇到的挑戰微服務架構同樣會遇到,在微服務架構關注點上，配置管理同樣是不可或缺的一部分。
在微服務架構中，將配置管理服務獨立抽象成一個服務，成為其它微服務的基礎依賴，有助於實現配置狀態的分離，從而使其它提供業務服務的微服務無狀態化，利於每個服務快速的彈性部署和水平擴展，即時響應業務需求。
容器化、調度與配置管理
在著名的 十二要素應用宣言 中無論是關於應用無狀態化還是多環境一致性
- Execute the app as one or more stateless processes (以一個或多個無狀態進程運行應用)
而在容器服務與調度中，當服務因為機器故障需要遷移或者需要實施水平擴展的過程中，配置狀態的遷移會給調度係統帶來極大的挑戰。而嚴格實施代碼與配置狀態的分離是智能的自動調度應用的前提，配置是一種狀態，一個微服務在bootstrap的時候，應該向配置中心詢問其應該達到的配置狀態，從而與已經在運行的其它服務副本保持一致。所以我們相信在未來，麵向容器和調度親和的應用應該滿足如下的結構:
- Keep development, staging, and production as similar as possible (盡可能的保持開發、預發布、線上環境相同)
如過要問，是什麼導致了應用在各個環境不能保持一樣，其答案往往就是配置! 舉幾個容易理解的表述，來幫助理解配置的環境屬性
- 在開發環境中將logLevel設置為DEBUG,在預發環境logLevel設置為INFO,生產環境裏logLevel設置為WARNING
- 在開發環境中使用4核8G的機器跑數據庫，而在生產中用32核96G機器跑數據庫
- 在日常環境執行線程池的最大線程數應該設置為15，而生產環境上這個值應該大一點，默認設為150
- 在線上環境中，中心機房，應用數據源需要連接A庫，而深圳機房，應用應該就近連接使用B庫
- 隻有在小淘寶環境，雙向同步開關才應該關閉
- 這次的改動有點大，新的特性僅在線上的杭州單元把該特性開放出來，其它的單元環境先不要開放出來
相信你一定發現了，某個配置項，其具體的值域的定義往往跟具體的環境相關聯，現實中相當一部分配置在不同的環境必須設定不同的值，但是也有相當的另一部分配置在不同的環境要設定為完全一致的值。所以從應用的視角看，其100個配置項，可能有50個是每個環境要不同的值的，而另50個是不區分環境，所有環境其配置值都是需要完全一致的。這種異化給配置管理係統的設計帶來了複雜性，而且這個最終語義的解釋，很顯然不應該在配置管理係統本身，應該交給應用，配置管理係統應該做的是提供方便的交互方式保證這兩種不同的一致性訴求同時得到很好的滿足，這種訴求分為3個方麵，如下示意圖:
從配置文件到配置中心
前麵我們詳細介紹了傳統的圍繞分散的配置文件為中心的配置管理方式在麵對諸如微服務、DevOps、容器服務、雲計算等新技術形式下麵臨的挑戰.
在這些年中，行業內在配置管理方麵做出了很多被證明是有益的探索和實踐，逐漸走向了外部化(Externalized)、集中化(Centralized)、不隻是文件的(Not just a “file”) 的配置管理方式。
而下麵產品都是中心化管理配置思想的著名代表，雖然這些產品各自涵蓋的領域和解決方案各不相同，但集中化管理應用配置的思想是驚人的一致
- 阿裏巴巴 Diamond
- Spring Cloud Config
- Hashicorp Consul
這其中，誕生於2007年淘寶進行服務化拆分和整體技術架構升級的配置中心產品Diamond，無疑是這條配置管理變革之路最早的踐行者。
ACM 產品介紹
阿裏集團在2007年進行從去IOE集中式應用架構升級為互聯網分布式服務化架構的時候，就意識到在分布式環境中，傳統的分散式的、基於配置文件的、應用自包含的配置管理方式將麵臨重大挑戰，亟需設計匹配新架構的新的配置管理解決方案，解決諸如分布式服務治理，數據源容災切換，異地多活，預案，限流規則等場景下的配置變更以及熱生效問題，這直接導致了今天阿裏集團內部被廣泛使用的配置中心的誕生，而這也是目前世界上最大的生產配置中心，存儲了超過100萬的生產配置，在集團內部支持了包括淘寶、天貓、菜鳥、阿裏雲、高德等全網所有的應用，每天產生近10億次的配置變更推送，可以說阿裏集團的每一台生產機器每一刻都與配置中心有不間斷的連接和交流。
阿裏雲開放公測的ACM產品就脫胎於阿裏巴巴10年來的配置中心實踐。該產品旨在幫助阿裏雲用戶更好的管理應用的所有配置，通過提供諸如配置推送及推送狀態追蹤，配置曆史版本管理，多環境管理，灰度發布，敏感配置加密等一係列的常用工具幫助企業提高配置管理效率和減少因配置變更引起的係統可用性風險，幫助企業更好的實施DevOps.
企業級應用配置中心
這裏討論一下一個可以用戶企業級生產，大規模應用的配置中心產品，需要在哪些關鍵點上有必要的設計約束
SLA保障
容災考慮
灰度能力
配置審計及曆史追蹤
ACM 開放公測功能列表
阿裏巴巴配置中心10年實踐過程中的經驗既複雜又龐大，在麵向外部更廣泛的用戶市場時，很多特性需要麵向外部用戶重構以讓它們變得更容易理解和使用，所以，在第一期我們僅開放公測部分核心功能，完整的特性將在未來逐步開放給用戶，下麵是主要的特性列表：
更多ACM產品信息
最後更新：2017-10-24 15:34:09