摘要：我們是不是很好奇配置中心如何做到實(shí)時(shí)更新并且通知到客戶端的這也是一個(gè)面試中經(jīng)常會(huì)問(wèn)到的題目。客戶端得到狀態(tài)碼是并且會(huì)根據(jù)立即去服務(wù)端拉取最新的配置。

引言

記得我們那時(shí)候剛開(kāi)始學(xué)習(xí)Java的時(shí)候都只是一個(gè)單體項(xiàng)目，項(xiàng)目里面的配置基本都是寫(xiě)在項(xiàng)目里面的properties文件中，比如數(shù)據(jù)庫(kù)配置啥的，各種邏輯開(kāi)關(guān)，一旦這些配置修改了，還需要重啟項(xiàng)目這修改才會(huì)生效。隨著各種微服務(wù)的誕生，服務(wù)的拆分也越來(lái)越細(xì)，可能涉及的服務(wù)成千上百，服務(wù)基本也是集群部署，這樣再去一個(gè)一個(gè)項(xiàng)目修改配置，然后重啟這顯然是行不通的。所以分布式配置中心就誕生了，現(xiàn)在開(kāi)源的分布式配置中心也挺多的比如：開(kāi)源分布式配置中心有很多，比如spring-cloud/spring-cloud-config、淘寶/diamond、百度/disconf、攜程/apollo、netflix/archaius、Qconf、XDiamond、nacos等等。我們是不是很好奇配置中心如何做到實(shí)時(shí)更新并且通知到客戶端的這也是一個(gè)面試中經(jīng)常會(huì)問(wèn)到的題目。下面我們就以apollo為例吧去分析分析它是如何實(shí)現(xiàn)的。為什么選擇Apollo來(lái)分析列？因?yàn)楝F(xiàn)在的公司就在使用它作為配置中心。雖然Apollo是攜程開(kāi)源的，但是攜程內(nèi)部也不用它。

Apoll簡(jiǎn)介

要去了解一個(gè)玩意，就要先會(huì)去使用它。它的使用基本上很簡(jiǎn)單。雖然使用簡(jiǎn)單方便，但是它的設(shè)計(jì)還是挺復(fù)雜的，下面我們看一個(gè)它官網(wǎng)提供的架構(gòu)圖，是不是挺復(fù)雜的。
通過(guò)上述架構(gòu)圖我們可以看到ConfigService、AdminService、Client、Portal、 Meta Server、Eureka這幾個(gè)模塊，主要的還是前面四個(gè)模塊Meta Server、Eureka這兩個(gè)模塊只是Apollo本身內(nèi)部所需要的輔助模塊,我們暫時(shí)可以不需要關(guān)注它。

ConfigService

• 提供配置獲取接口
• 提供配置推送接口
• 服務(wù)于Apollo客戶端

AdminService

• 提供配置管理接口
• 提供配置修改發(fā)布接口
• 服務(wù)于管理界面Portal

Client

• 為應(yīng)用獲取配置，支持實(shí)時(shí)更新
• 通過(guò)MetaServer獲取ConfigService的服務(wù)列表/
• 使用客戶端軟負(fù)載SLB方式調(diào)用ConfigService

Portal

• 配置管理界面
• 通過(guò)MetaServer獲取AdminService的服務(wù)列表
• 使用客戶端軟負(fù)載SLB方式調(diào)用AdminService

Apoll更新配置

介紹完了上面這些Apollo組成的模塊回到正題，配置中心如何做到實(shí)時(shí)更新并且到客戶端如何感知配置被更新了？看這個(gè)問(wèn)題之前我們先回顧下每到周末我們?nèi)ト藲獗容^旺的餐廳吃飯的時(shí)候流程是什么樣的？

• 首先肯定是現(xiàn)場(chǎng)取號(hào)，或者手機(jī)端取號(hào)。
• 然后就是排隊(duì)刷手機(jī)等著被叫號(hào)。中途你還會(huì)主動(dòng)問(wèn)一問(wèn)還要等多久，服務(wù)員會(huì)告訴你等著吧，你前面還有幾桌。
  上面這個(gè)吃飯的例子怎么知道到號(hào)了列？?jī)煞N方式，一種使我們我每隔一段時(shí)間然后主動(dòng)去問(wèn)下服務(wù)員，是否到號(hào)，沒(méi)到號(hào)繼續(xù)刷手機(jī)，如果到號(hào)直接進(jìn)去吃飯，還有一種的話就是干脆一直坐在那里刷手機(jī)我反正不趕時(shí)間，等著被通知到號(hào)。同樣的配置中心的更新是如何通知到客戶端列？是服務(wù)端主（configService）動(dòng)通知到客戶端（client）告訴它某某你的應(yīng)用的配置被修改了，原來(lái)的值是啥被修改后的值是啥？還是說(shuō)客戶端（Client）每隔多久去問(wèn)下服務(wù)端我的配置有沒(méi)有被修改呀？如果是你你會(huì)怎么選擇列？你也許會(huì)說(shuō)我肯定兩種方式都要呀！小朋友才會(huì)做選擇？
  

客戶端長(zhǎng)鏈接獲取配置更新通知

再回到我們使用apollo的時(shí)候我們應(yīng)用里面引入的Apollo的Client在我們應(yīng)用啟動(dòng)的時(shí)候會(huì)有一個(gè)線程每隔5s向服務(wù)短發(fā)起一個(gè)http請(qǐng)求，不過(guò)這個(gè)http請(qǐng)求是不會(huì)立即返回的。它是一個(gè)長(zhǎng)鏈接如果配置沒(méi)有被更新，這個(gè)請(qǐng)求會(huì)被阻塞掛起，這個(gè)實(shí)現(xiàn)掛起的方式是通過(guò)Spring的DeferredResult來(lái)實(shí)現(xiàn)的，如果對(duì)這個(gè)Spring的DeferredResult不是很了解的推薦看下這個(gè)文章《5種SpringMvc的異步處理方式你都了解嗎？》
掛起60s后會(huì)返回HTTP狀態(tài)碼為304給到客戶端，如果再阻塞的過(guò)程中服務(wù)端配置有更新，這個(gè)Http請(qǐng)求會(huì)立馬返回，并且把變化的nameSpace信息返回出去，并且返回的http的狀態(tài)碼是200。客戶端得到狀態(tài)碼是200并且會(huì)根據(jù)nameSpace立即去服務(wù)端拉取最新的配置。

這里其實(shí)有一個(gè)問(wèn)題，為什么不直接在長(zhǎng)鏈接中返回變更后的結(jié)果，而是返回一個(gè)變更的通知，需要客戶端根據(jù)這個(gè)變更通知立即去拉取新的配置？

感興趣的可以參考下這個(gè)issue ：https://github.com/apolloconfig/apollo/issues/652
這樣推送消息就是有狀態(tài)了，做不到冪等了，會(huì)帶來(lái)很多問(wèn)題。目前推送是單連接走h(yuǎn)ttp的，所以問(wèn)題可能不大，不過(guò)在設(shè)計(jì)上而言是有這個(gè)問(wèn)題的，比如如果推送是走的tcp長(zhǎng)連接的話。另外，長(zhǎng)輪詢和推送之間也會(huì)有沖突，如果連續(xù)兩次配置變化，就可能造成雙寫(xiě)。還有一點(diǎn)，就是保持邏輯的簡(jiǎn)單，目前的做法推送只負(fù)責(zé)做簡(jiǎn)單的通知，不需要去計(jì)算客戶端的配置應(yīng)該是什么，因?yàn)橛?jì)算邏輯挺復(fù)雜的，需要考慮集群，關(guān)聯(lián)，灰度等，總而言之，就是在滿足冪等性，實(shí)時(shí)性的基礎(chǔ)上保持設(shè)計(jì)的簡(jiǎn)單。

客戶端定時(shí)任務(wù)全量拉取配置

這樣是不是就是很完美了，客戶端可以實(shí)時(shí)接收到配置的更新。但是客戶端如果接收服務(wù)端的更新內(nèi)容處理失敗，比如服務(wù)異常或者空指針的時(shí)候。這時(shí)候我們的客戶端配置如果不重啟是不是永遠(yuǎn)都不會(huì)被更新了。沒(méi)關(guān)系這種情況apollo也幫你想到啦，你既然告訴我更新失敗，那我就自己每隔一段時(shí)間主動(dòng)去把我所有的配置都拉到客服端，拉回客服端之后和客戶端的緩存配置做比較，如果一致直接結(jié)束，不一致就更新客戶端的緩存，并且還會(huì)去異步更新本地文件。通過(guò)定時(shí)任務(wù)的補(bǔ)充，可以讓配置達(dá)到最終的一致性。

客戶端本地文件緩存配置

主動(dòng)輪詢，和定時(shí)任務(wù)全量拉取配置是不是就萬(wàn)無(wú)一失呢？只要涉及到分布式我們就要考慮到其他系統(tǒng)的宕機(jī)，比如哪一天挖機(jī)直接把部署Apollo的機(jī)房的光纖給挖斷了，這樣整個(gè)配置服務(wù)直接掛了，這時(shí)候主動(dòng)輪詢以及定時(shí)任務(wù)都沒(méi)法起到作用了。是不是拉取不了配置，整個(gè)我們的客戶端應(yīng)用也要跟著受影響列，我們的配置基本上是改動(dòng)的頻率也是比較小的，即使我們的配置中心掛掉了，我們還有一份本地文件系統(tǒng)來(lái)兜底，這個(gè)文件目錄默認(rèn)是/opt/data或C:/opt/data，

所以即使配置中心掛了，對(duì)應(yīng)用的影響也比較小。因?yàn)樗€會(huì)去讀取本地文件來(lái)兜底。

小結(jié)

到現(xiàn)在為止我們應(yīng)該知道Apollo客戶端是如何感知服務(wù)端配置更新了的把？

• 主要是通過(guò)客戶端應(yīng)用發(fā)起一個(gè)長(zhǎng)連接去Apollo ConfigServer端，如果Apollo ConfigServer端有配置更改會(huì)告訴應(yīng)用端有配置修改，讓客戶端立馬去拉取全量的配置，并且把配置更新到本地緩存，并且還會(huì)異步去更新本地文件緩存。
• 客戶端還有一個(gè)默認(rèn)5min執(zhí)行一次的定時(shí)任務(wù)，去拉取全量的配置。拉回配置之后也是對(duì)比本地緩存和遠(yuǎn)程是否一致，如果不一致則更新本地進(jìn)程緩存為遠(yuǎn)程的，同時(shí)還去異步更新下本地文件。

結(jié)束

• 由于自己才疏學(xué)淺，難免會(huì)有紕漏，假如你發(fā)現(xiàn)了錯(cuò)誤的地方，還望留言給我指出來(lái),我會(huì)對(duì)其加以修正。
• 如果你覺(jué)得文章還不錯(cuò)，你的轉(zhuǎn)發(fā)、分享、贊賞、點(diǎn)贊、留言就是對(duì)我最大的鼓勵(lì)。
• 感謝您的閱讀,十分歡迎并感謝您的關(guān)注。
• 站在巨人的肩膀
  https://www.apolloconfig.com/#/zh/design/apollo-design?id=一、總體設(shè)計(jì)
  https://www.iocoder.cn/Apollo/client-polling-config/