怎么借助配置中心ACM加速企業(yè)IT服務(wù)快速迭代

怎么借助配置中心ACM加速企業(yè)IT服務(wù)快速迭代，針對這個(gè)問題，這篇文章詳細(xì)介紹了相對應(yīng)的分析和解答，希望可以幫助更多想解決這個(gè)問題的小伙伴找到更簡單易行的方法。

配置中心基本形態(tài)介紹

有了配置中心以后，用戶或者管理員不需要再登錄到配置中心或者配置中心下面的操作系統(tǒng)去修改文件。取而代之的是到配置中心的平臺上去修改對應(yīng)的配置，那么配置會對后面不同的應(yīng)用監(jiān)聽到，當(dāng)配置或者應(yīng)用啟動(dòng)要去獲得配置的時(shí)候，通過配置中心和應(yīng)用的交互來完成任務(wù)的分發(fā)。通過這種方式極大的提高了修改配置的這種效率、簡化了流程。

ACM簡介

應(yīng)用配置管理(Application Configuration Management，簡稱 ACM)，ACM是由阿里中間件配置中心工具Diamond延伸出來的，在阿里內(nèi)部為被使用最廣泛的中間件，于2017年10月正式成為阿里云產(chǎn)品。
ACM 來自于阿里配置中心管理工具Diamond，那么Diamond在阿里內(nèi)部到底是什么情況呢？主要是幾點(diǎn)，第一點(diǎn)Diamond可能是阿里內(nèi)部應(yīng)用最廣泛的中間介，覆蓋量大概是80%，主要是因?yàn)樗褂脠鼍笆欠浅６嗟?。作為一個(gè)配置中心工具，在阿里內(nèi)部有極好的性能保證，對內(nèi)承諾的SLA是保證在1秒以內(nèi)，這個(gè)對很多上層的業(yè)務(wù)提供了能力的保證。當(dāng)機(jī)房發(fā)生故障的時(shí)候，通過配置中心去推配置能保證很多的工作負(fù)載能在1秒鐘之內(nèi)就能完成遷移。還有很多其他各種各樣的場景，比如說通過非常方便的運(yùn)維能力能幫助集團(tuán)的很多其他業(yè)務(wù)去做類似于限流降級。還有去做一些算法的場景，還有去做多環(huán)境管理，應(yīng)用場景非常多，所以說這個(gè)是目前配置中心管理在阿里內(nèi)部的一個(gè)使用現(xiàn)狀。
在外部來看同時(shí)期配置中心在行業(yè)的走向的歷史情況是什么樣的，到今天配置中心已經(jīng)完成了從原始的無工具到有工具，成為公有云上面一個(gè)正式產(chǎn)品的一個(gè)歷史發(fā)展路徑。從業(yè)界的發(fā)展歷程來看，配置中心已經(jīng)完成了從沒有工具到有工具再到正式產(chǎn)品化的一個(gè)發(fā)展歷程。

ACM 技術(shù)詳解

配置中心基本功能

有了配置中心以后用戶不需要登陸到機(jī)器上去改配置文件，取而代之的是他到配置的管理控制臺上去發(fā)布一個(gè)配置，相應(yīng)的配置會寫到配置中心的服務(wù)器上，服務(wù)中心會把不同的配置推送到下面的應(yīng)用上去。所以沉淀下來三個(gè)基本功能，第一個(gè)是發(fā)布配置，第二個(gè)是獲取配置，第三個(gè)是動(dòng)態(tài)配置的變化監(jiān)聽。

基礎(chǔ)架構(gòu)

ACM的服務(wù)端主要由三部分組成，第一個(gè)是地址服務(wù)器，提供ACM (Diamond)服務(wù)發(fā)現(xiàn)功能，實(shí)現(xiàn)了集群擴(kuò)容、下線等運(yùn)維工作對于應(yīng)用方的透明。第二個(gè)是ACM(diamond)-server組件，是ACM服務(wù)的核心。該組件通過Http協(xié)議向應(yīng)用方提供配置的持久化管理、動(dòng)態(tài)配置推送服務(wù)。實(shí)現(xiàn)上，ACM(diamond)-server組件是一個(gè)Web服務(wù)集群，集群節(jié)點(diǎn)間通過特定機(jī)制實(shí)現(xiàn)數(shù)據(jù)變更的增量同步，是無中心化的結(jié)構(gòu)。第三個(gè)是Mysql存儲，是ACM(Diamond)服務(wù)持久化配置管理的基礎(chǔ)。在淘寶生產(chǎn)環(huán)境中，使用一主兩備的部署方式保障數(shù)據(jù)的安全。
總結(jié)來說，ACM的設(shè)計(jì)，使用集群代替中心，做到無單點(diǎn)，以此提高系統(tǒng)的可靠性；使用Http無狀態(tài)協(xié)議暴露服務(wù)，使系統(tǒng)實(shí)現(xiàn)邏輯簡單，不易出錯(cuò)。

基于Cache的配置發(fā)布、獲取原理

ACM (Diamond) 的持久化配置保存在mysql中，額外的服務(wù)端每個(gè)節(jié)點(diǎn)都以本地磁盤文件的形式保存了全量的配置數(shù)據(jù)作為cache。引入服務(wù)端配置數(shù)據(jù)的緩存文件后，一次配置數(shù)據(jù)的讀取請求，其實(shí)就是一次靜態(tài)文件的Http請求。借助0拷貝的優(yōu)化，減少了配置數(shù)據(jù)在應(yīng)用態(tài)和內(nèi)核態(tài)之間無用的內(nèi)存拷貝，大大提升了數(shù)據(jù)傳輸效率。
引入cache機(jī)制后，ACM (Diamond)在實(shí)現(xiàn)上可以被定為一個(gè)分布式的緩存系統(tǒng)。在CAP方面，ACM (Diamond)選擇犧牲數(shù)據(jù)的強(qiáng)一致，提供了最終一致性；保證了系統(tǒng)的可用性和分區(qū)容忍性。通過實(shí)踐也證明了，提供最終一致性的配置并發(fā)讀寫，可以滿足幾乎所有的配置中心應(yīng)用場景。

配置監(jiān)聽

配置監(jiān)聽需要達(dá)到的效果跟發(fā)布和獲取有點(diǎn)不一樣，一個(gè)配置發(fā)生變化了，怎么通過一個(gè)類似消息的方式把變化推送到客戶端，客戶端能及時(shí)知道變化了，同時(shí)內(nèi)部采取一些相應(yīng)的動(dòng)作。我們做的是一種類似于長輪詢的方式的方式去做，客戶端會定期的在發(fā)起監(jiān)聽的這個(gè)配置的時(shí)候會發(fā)起一個(gè)30秒的長連接，這個(gè)長連接會帶到他所需要配置，如果在這30秒里面沒有配置發(fā)生變化的時(shí)候，那么30秒內(nèi)就返回一個(gè)空值，在接下來的下一個(gè)30秒會再發(fā)起一個(gè)連接。那么在這30秒內(nèi)如果是發(fā)現(xiàn)了任何的變化的時(shí)候，服務(wù)端會把發(fā)生變化的配置及時(shí)的通過長連接，然后連接會返回這個(gè)客戶端，客戶端就可以拿到這個(gè)變化值。這種推拉結(jié)合的策略，做到了在長連接和短連接之間的平衡，實(shí)現(xiàn)了讓服務(wù)端不用太關(guān)注連接的管理，效果上又獲得了類似TCP長連接的信息推送的實(shí)時(shí)性。

ACM主要應(yīng)用場景

傳統(tǒng)的配置文件無法很好的解決分布式系統(tǒng)的配置管理訴求，雖然ACM是個(gè)工具，但是具有大能量，因?yàn)槟芡ㄟ^配置中心本身延伸出特別多的場景。對于配置安全管理、發(fā)布環(huán)境管理、程序包發(fā)布管理、業(yè)務(wù)場景動(dòng)態(tài)推送、動(dòng)態(tài)算法推送等方面ACM都可以很好的解決對應(yīng)的需求。

場景1 微服務(wù)應(yīng)用架構(gòu)下的配置管理

在傳統(tǒng)架構(gòu)的應(yīng)用發(fā)布過程中，修改一個(gè)應(yīng)用配置就需要將整個(gè)應(yīng)用重新打包發(fā)布，整個(gè)過程非常繁瑣，且容易出錯(cuò)。在基于 ACM 的微服務(wù)場景下，應(yīng)用的重要配置信息被發(fā)布到 ACM 中。新的配置發(fā)布并不依賴配置打包。在新版本的配置發(fā)布后，所有應(yīng)用立即生效，如圖所示。
采用 ACM 作為配置中心為微服務(wù)帶來的好處是，所有配置中心化，在應(yīng)用眾多的情況下配置管理變得更加方便。所有配置不依賴版本發(fā)布，使得配置變更更加靈活。ACM 天生支持灰度發(fā)布和回滾，使得配置的變更發(fā)布在微服務(wù)架構(gòu)下變得更加安全。

場景2 分布式架構(gòu)下的服務(wù)治理下的服務(wù)治理

怎么防止因?yàn)樾阅苓^載而導(dǎo)致的雪崩效應(yīng)，一定是要做些動(dòng)態(tài)的流控的。傳統(tǒng)方法是去改配置文件，有了配置中心以后可以把相應(yīng)的配置的變更也是呈現(xiàn)在配置中心里，那么當(dāng)流控發(fā)生變化的時(shí)候只需要在配置中心里面改流控的閾值，閾值會動(dòng)態(tài)的推到下面所有訂購閾值的客戶端，那么這樣就會做到一個(gè)相應(yīng)的流控。
采用ACM為分布式架構(gòu)下的服務(wù)治理帶來的好處是，良好的性能，通過采用配置推送的方式來監(jiān)聽服務(wù)治理信息，對性能幾乎無影響。相關(guān)的服務(wù)治理信息可以秒級推送到，響應(yīng)時(shí)間迅速。當(dāng)限流降級以后還可以通過秒級配置回滾來恢復(fù)狀態(tài)。

場景3 應(yīng)用業(yè)務(wù)場景動(dòng)態(tài)推送

現(xiàn)在的電商總會有一些的運(yùn)營活動(dòng)，比如說六一兒童節(jié)就會在相應(yīng)的時(shí)間段推一些和小朋友相關(guān)的產(chǎn)品。最常規(guī)的方法大家馬上會想到的可能是做一個(gè)新的發(fā)布，到那個(gè)時(shí)間點(diǎn)推一批應(yīng)用上去，這樣應(yīng)用程序就會相應(yīng)的變更。但是用了配置中心以后，這一過程會得到非常大的簡化。具體的就是把對應(yīng)的場景寫到配置中心里，在服務(wù)端展示的業(yè)務(wù)代碼里面，其實(shí)是訂閱配置中心里一段的代碼，代碼如果需要根據(jù)場景發(fā)生變化的時(shí)候把這個(gè)代碼在配置中心進(jìn)行一個(gè)變更，所有的業(yè)務(wù)代碼會及時(shí)的推送到服務(wù)器中，那么對應(yīng)的場景就會發(fā)生變更。通過這種方式大大降低了發(fā)布的頻次提高了業(yè)務(wù)的敏捷性。

場景4 大數(shù)據(jù)實(shí)時(shí)計(jì)算算法調(diào)整

這是業(yè)界做監(jiān)控非常典型的一個(gè)例子，我們在做性能監(jiān)控的時(shí)候，會有操作系統(tǒng)和應(yīng)用的數(shù)據(jù)通過消息對進(jìn)到流計(jì)算里做一些匯總。監(jiān)控的時(shí)候?qū)崟r(shí)報(bào)警怎么做？在做計(jì)算的時(shí)候分布式節(jié)點(diǎn)很多，當(dāng)報(bào)警的閾值發(fā)生變更的時(shí)候是需要通知到所有的節(jié)點(diǎn)的。在這塊阿里也是通過配置中心去做的，應(yīng)用計(jì)算參數(shù)動(dòng)態(tài)配置，動(dòng)態(tài)生效，生效時(shí)間塊，性能影響低。

場景5 企業(yè)級互聯(lián)網(wǎng)架構(gòu)下的異地多活場景

在異地多活里面有很多場景會用到ACM，這里只講一個(gè)簡單的例子。在阿里巴巴內(nèi)部，容災(zāi)多活架構(gòu)的核心算法，ID分片和對應(yīng)的的路由規(guī)則均采用ACM來動(dòng)態(tài)推送。其中，相應(yīng)的客戶端和服務(wù)端，如RPC，MQ，DB都植入了路由路徑。當(dāng)容災(zāi)演練或者真實(shí)災(zāi)難發(fā)生時(shí)，管理員只需要?jiǎng)討B(tài)的推送規(guī)則，相應(yīng)的規(guī)則會影響到所有架構(gòu)組件。使得基礎(chǔ)架構(gòu)和容災(zāi)邏輯解耦，具體的路由邏輯由容災(zāi)規(guī)則切換決定。生效快，理論上容災(zāi)的切換規(guī)則可以秒級推送到十萬級別機(jī)器。
Demo
在對用戶進(jìn)行用戶中心改造的時(shí)候發(fā)現(xiàn)用戶有兩點(diǎn)需求，第一點(diǎn)是從運(yùn)維效率去考慮，將配置變更從之前的幾個(gè)小時(shí)的級別變成幾分鐘到幾秒的級別，帶來了效率的極大提升，運(yùn)維成本的大幅下降。第二點(diǎn)是安全的訴求。
為什么用了配置中心以后它的代碼里面就不需要出現(xiàn)這些敏感信息了？
使用配置中心之后把這些業(yè)務(wù)的數(shù)據(jù)全部抽離出來，放到配置中心里，發(fā)布之后所有的這些鏡像都是一樣的，當(dāng)需要配置變更的時(shí)候只需要到控制臺去修改發(fā)布即可。
在ACM上把發(fā)布環(huán)節(jié)跳過的話，怎么保證配置能快速回滾，怎么能記錄歷史發(fā)布記錄？
ACM在這方面做了一個(gè)歷史版本的特性，當(dāng)用戶需要改錯(cuò)的時(shí)候，可以去查之前發(fā)布的歷史版本，找到對應(yīng)的版本點(diǎn)進(jìn)去立即回滾就可以回到之前的版本。

關(guān)于怎么借助配置中心ACM加速企業(yè)IT服務(wù)快速迭代問題的解答就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關(guān)注億速云行業(yè)資訊頻道了解更多相關(guān)知識。