如何藉助配置中心ACM加速企業IT服務快速迭代

摘要： 在5月29日召開的第二屆研發效能嘉年華中，雲效邀請了阿里雲產品團隊的伏羿和來自阿里巴巴中間件技術部的彥林帶來了「如何藉助配置中心ACM加速企業IT服務快速迭代」的主題分享。 分別對配置中心ACM和ACM技術進行了講解，而且對ACM的主要應用場景進行了介紹，並進行了Demo環節。

在5月29日召開的第二屆研發效能嘉年華中，雲效邀請了阿里雲產品團隊的伏羿和來自阿里巴巴中間件技術部的彥林帶來了「如何藉助配置中心ACM加速企業IT服務快速迭代」的主題分享。 分別對配置中心ACM和ACM技術進行了講解，而且對ACM的主要應用場景進行了介紹，並進行了Demo環節。
精彩視頻請點擊
PPT下載請點擊
如下爲精彩內容整理：

配置中心基本形態介紹

有了配置中心之後，用戶或者管理員不須要再登陸到配置中心或者配置中心下面的操做系統去修改文件。取而代之的是到配置中心的平臺上去修改對應的配置，那麼配置會對後面不一樣的應用監聽到，當配置或者應用啓動要去得到配置的時候，經過配置中心和應用的交互來完成任務的分發。經過這種方式極大的提升了修改配置的這種效率、簡化了流程。

ACM簡介

應用配置管理(Application Configuration Management，簡稱 ACM)，ACM是由阿里中間件配置中心工具Diamond延伸出來的，在阿里內部爲被使用最普遍的中間件，於2017年10月正式成爲阿里雲產品。
ACM 來自於阿里配置中心管理工具Diamond，那麼Diamond在阿里內部究竟是什麼狀況呢？主要是幾點，第一點Diamond多是阿里內部應用最普遍的中間介，覆蓋量大概是80%，主要是由於他使用場景是很是多的。做爲一個配置中心工具，在阿里內部有極好的性能保證，對內承諾的SLA是保證在1秒之內，這個對不少上層的業務提供了能力的保證。當機房發生故障的時候，經過配置中心去推配置能保證不少的工做負載能在1秒鐘以內就能完成遷移。還有不少其餘各類各樣的場景，好比說經過很是方便的運維能力能幫助集團的不少其餘業務去作相似於限流降級。還有去作一些算法的場景，還有去作多環境管理，應用場景很是多，因此說這個是目前配置中心管理在阿里內部的一個使用現狀。
在外部來看同時期配置中心在行業的走向的歷史狀況是什麼樣的，到今天配置中心已經完成了從原始的無工具到有工具，成爲公有云上面一個正式產品的一個歷史發展路徑。從業界的發展歷程來看，配置中心已經完成了從沒有工具到有工具再到正式產品化的一個發展歷程。

ACM 技術詳解

配置中心基本功能

有了配置中心之後用戶不須要登錄到機器上去改配置文件，取而代之的是他到配置的管理控制檯上去發佈一個配置，相應的配置會寫到配置中心的服務器上，服務中心會把不一樣的配置推送到下面的應用上去。因此沉澱下來三個基本功能，第一個是發佈配置，第二個是獲取配置，第三個是動態配置的變化監聽。

基礎架構

ACM的服務端主要由三部分組成，第一個是地址服務器，提供ACM (Diamond)服務發現功能，實現了集羣擴容、下線等運維工做對於應用方的透明。第二個是ACM(diamond)-server組件，是ACM服務的核心。該組件經過Http協議嚮應用方提供配置的持久化管理、動態配置推送服務。實現上，ACM(diamond)-server組件是一個Web服務集羣，集羣節點間經過特定機制實現數據變動的增量同步，是無中心化的結構。第三個是Mysql存儲，是ACM(Diamond)服務持久化配置管理的基礎。在淘寶生產環境中，使用一主兩備的部署方式保障數據的安全。
總結來講，ACM的設計，使用集羣代替中心，作到無單點，以此提升系統的可靠性；使用Http無狀態協議暴露服務，使系統實現邏輯簡單，不易出錯。

基於Cache的配置發佈、獲取原理

ACM (Diamond) 的持久化配置保存在mysql中，額外的服務端每一個節點都以本地磁盤文件的形式保存了全量的配置數據做爲cache。引入服務端配置數據的緩存文件後，一次配置數據的讀取請求，其實就是一次靜態文件的Http請求。藉助0拷貝的優化，減小了配置數據在應用態和內核態之間無用的內存拷貝，大大提高了數據傳輸效率。
引入cache機制後，ACM (Diamond)在實現上能夠被定爲一個分佈式的緩存系統。在CAP方面，ACM (Diamond)選擇犧牲數據的強一致，提供了最終一致性；保證了系統的可用性和分區容忍性。經過實踐也證實了，提供最終一致性的配置併發讀寫，能夠知足幾乎全部的配置中心應用場景。

配置監聽

配置監聽須要達到的效果跟發佈和獲取有點不同，一個配置發生變化了，怎麼經過一個相似消息的方式把變化推送到客戶端，客戶端能及時知道變化了，同時內部採起一些相應的動做。咱們作的是一種相似於長輪詢的方式的方式去作，客戶端會按期的在發起監聽的這個配置的時候會發起一個30秒的長鏈接，這個長鏈接會帶到他所須要配置，若是在這30秒裏面沒有配置發生變化的時候，那麼30秒內就返回一個空值，在接下來的下一個30秒會再發起一個鏈接。那麼在這30秒內若是是發現了任何的變化的時候，服務端會把發生變化的配置及時的經過長鏈接，而後鏈接會返回這個客戶端，客戶端就能夠拿到這個變化值。這種推拉結合的策略，作到了在長鏈接和短鏈接之間的平衡，實現了讓服務端不用太關注鏈接的管理，效果上又得到了相似TCP長鏈接的信息推送的實時性。

ACM主要應用場景

傳統的配置文件沒法很好的解決分佈式系統的配置管理訴求，雖然ACM是個工具，可是具備大能量，由於能經過配置中心自己延伸出特別多的場景。對於配置安全管理、發佈環境管理、程序包發佈管理、業務場景動態推送、動態算法推送等方面ACM均可以很好的解決對應的需求。

場景1 微服務應用架構下的配置管理

在傳統架構的應用發佈過程當中，修改一個應用配置就須要將整個應用從新打包發佈，整個過程很是繁瑣，且容易出錯。在基於 ACM 的微服務場景下，應用的重要配置信息被髮布到 ACM 中。新的配置發佈並不依賴配置打包。在新版本的配置發佈後，全部應用當即生效，如圖所示。
採用 ACM 做爲配置中心爲微服務帶來的好處是，全部配置中心化，在應用衆多的狀況下配置管理變得更加方便。全部配置不依賴版本發佈，使得配置變動更加靈活。ACM 天生支持灰度發佈和回滾，使得配置的變動發佈在微服務架構下變得更加安全。

場景2 分佈式架構下的服務治理下的服務治理

怎麼防止由於性能過載而致使的雪崩效應，必定是要作些動態的流控的。傳統方法是去改配置文件，有了配置中心之後能夠把相應的配置的變動也是呈如今配置中內心，那麼當流控發生變化的時候只須要在配置中內心面改流控的閾值，閾值會動態的推到下面全部訂購閾值的客戶端，那麼這樣就會作到一個相應的流控。
採用ACM爲分佈式架構下的服務治理帶來的好處是，良好的性能，經過採用配置推送的方式來監聽服務治理信息，對性能幾乎無影響。相關的服務治理信息能夠秒級推送到，響應時間迅速。當限流降級之後還能夠經過秒級配置回滾來恢復狀態。

場景3 應用業務場景動態推送

如今的電商總會有一些的運營活動，好比說六一兒童節就會在相應的時間段推一些和小朋友相關的產品。最常規的方法你們立刻會想到的多是作一個新的發佈，到那個時間點推一批應用上去，這樣應用程序就會相應的變動。可是用了配置中心之後，這一過程會獲得很是大的簡化。具體的就是把對應的場景寫到配置中內心，在服務端展現的業務代碼裏面，實際上是訂閱配置中內心一段的代碼，代碼若是須要根據場景發生變化的時候把這個代碼在配置中心進行一個變動，全部的業務代碼會及時的推送到服務器中，那麼對應的場景就會發生變動。經過這種方式大大下降了發佈的頻次提升了業務的敏捷性。

場景4 大數據實時計算算法調整

這是業界作監控很是典型的一個例子，咱們在作性能監控的時候，會有操做系統和應用的數據經過消息對進到流計算裏作一些彙總。監控的時候實時報警怎麼作？在作計算的時候分佈式節點不少，當報警的閾值發生變動的時候是須要通知到全部的節點的。在這塊阿里也是經過配置中心去作的，應用計算參數動態配置，動態生效，生效時間塊，性能影響低。

場景5 企業級互聯網架構下的異地多活場景

在異地多活裏面有不少場景會用到ACM，這裏只講一個簡單的例子。在阿里巴巴內部，容災多活架構的核心算法，ID分片和對應的的路由規則均採用ACM來動態推送。其中，相應的客戶端和服務端，如RPC，MQ，DB都植入了路由路徑。當容災演練或者真實災難發生時，管理員只須要動態的推送規則，相應的規則會影響到全部架構組件。使得基礎架構和容災邏輯解耦，具體的路由邏輯由容災規則切換決定。生效快，理論上容災的切換規則能夠秒級推送到十萬級別機器。
Demo
在對用戶進行用戶中心改造的時候發現用戶有兩點需求，第一點是從運維效率去考慮，將配置變動從以前的幾個小時的級別變成幾分鐘到幾秒的級別，帶來了效率的極大提高，運維成本的大幅降低。第二點是安全的訴求。
爲何用了配置中心之後它的代碼裏面就不須要出現這些敏感信息了？
使用配置中心以後把這些業務的數據所有抽離出來，放到配置中內心，發佈以後全部的這些鏡像都是同樣的，當須要配置變動的時候只須要到控制檯去修改發佈便可。
在ACM上把發佈環節跳過的話，怎麼保證配置能快速回滾，怎麼能記錄歷史發佈記錄？
ACM在這方面作了一個歷史版本的特性，當用戶須要改錯的時候，能夠去查以前發佈的歷史版本，找到對應的版本點進去當即回滾就能夠回到以前的版本。
咱們ACM產品目前預計會長期免費，因此歡迎你們去使用。

原文連接