什么是分布式配置中心？
我是敖丙的老婆，一年CRUD經(jīng)驗(yàn)用十年的markdown程序員???????常年被譽(yù)為優(yōu)質(zhì)八股文選手。
上次給大家安排了監(jiān)控的相關(guān)使用姿勢，不知道大家有沒有配置起來。但我可不管你們的進(jìn)度怎么樣，是不會(huì)等著你們的喲。
今天來跟大家聊下分布式配置中心這個(gè)話題
01、什么是分布式配置中心
在之前我就很早已經(jīng)提及過：分布式配置中心這種組件在后端就是標(biāo)配的。
要理解分布式配置中心很簡單：其實(shí)就是把一些配置的信息分離于自身的系統(tǒng)，而這些信息又能被應(yīng)用實(shí)時(shí)獲取得到。
要做到上面的核心功能并不難，但是作為中間件會(huì)需要更多的配套服務(wù)，包括但不限于
1、有后臺(tái)界面供我們修改配置 2、配置服務(wù)如果掛了有相關(guān)的容災(zāi)邏輯 3、支持不同環(huán)境下的配置信息（我們線上的配置一般是分不同的環(huán)境配置不同的值） 4、相關(guān)權(quán)限管理（只有負(fù)責(zé)人才能對配置進(jìn)行update） 5、簡單易用（有對應(yīng)的SDK支持或api支持） ...
有的公司會(huì)自研一套這種分布式配置中心的組件，實(shí)現(xiàn)了上面我提到的功能。作為個(gè)人或者小公司，直接上開源的就完事了。別老想著自研多么美妙，維護(hù)成本極大的。
02、為什么分布式配置中心
我們可以把常變動(dòng)的配置信息存放在分布式配置中心上，比如：請求的ip地址、限流值、系統(tǒng)的配置值、各種業(yè)務(wù)開關(guān)等等。
甚至，我老東家的規(guī)則引擎也是在分布式配置中心的基礎(chǔ)上干的，分布式配置中心用到的場景是在是太多了...
就以我們austin項(xiàng)目為例就好了，這期我們要實(shí)現(xiàn)丟棄消息。沒錯(cuò)，你沒看錯(cuò)。我們項(xiàng)目的核心是發(fā)消息，但需要在系統(tǒng)中實(shí)現(xiàn)丟棄消息的功能。
austin作為推送平臺(tái)，它的定位是面向整個(gè)公司的所有類型的消息推送。有了這個(gè)定位以后，我們很難去保證用這個(gè)系統(tǒng)的都是些什么人（自然在這里面就會(huì)有粗心的）。
從austin的實(shí)現(xiàn)架構(gòu)，我們可以發(fā)現(xiàn)的是：如果瞬間有大批量消息需要被下發(fā)時(shí)，數(shù)據(jù)會(huì)堵在MQ上等待消費(fèi)
我們是在austin-api層實(shí)現(xiàn)了判斷模板是否被刪除的校驗(yàn)，但很有可能的是：請求已經(jīng)全部被austin-api處理完畢了，消息已經(jīng)積壓在MQ了。
是可以在austini-handler再判斷一遍模板是否被刪除，但很多時(shí)候消息模板的擁有者并不是想把模板刪掉（刪掉意味著他們在控制臺(tái)就看不到該模板的配置消息了），可能他們就只是發(fā)錯(cuò)了而已，希望還沒下發(fā)的消息不再發(fā)送而已。
除此之外，我們還得在austin項(xiàng)目實(shí)現(xiàn)白名單攔截的功能，這功能作用于dev和pre環(huán)境。
對于austin項(xiàng)目而言，dev和pre環(huán)境跟線上環(huán)境其實(shí)沒有什么本質(zhì)上的區(qū)別。因?yàn)樽罱K是下發(fā)消息，只要環(huán)境能把消息下發(fā)到用戶手上，那就可以把他當(dāng)做線上環(huán)境在用。
一般業(yè)務(wù)在正式下發(fā)消息之前，都會(huì)在dev和pre環(huán)境走一遍流程。但我們是很難保證它們的測試一定是正常的，萬一業(yè)務(wù)方就出Bug導(dǎo)致dev/pre環(huán)境大批量推送了呢？
所以，我們會(huì)在dev/pre環(huán)境設(shè)置白名單，只有在白名單的內(nèi)的用戶才能收到消息。而白名單的列表我們又可以維護(hù)在分布式配置中心上
PS :相信大家多多少少都見過很多推送的事故（各大廠貌似都有過類似的新聞和經(jīng)歷）。在很大原因上，就是環(huán)境混用了。本來想用
dev或者pre環(huán)境去測試消息下發(fā)，不料使用了生產(chǎn)環(huán)境。（這種問題一般就需要通過權(quán)限和審批的干預(yù)了）
像之前的實(shí)現(xiàn)的去重功能，我在代碼硬編碼寫了具體的num和seconds值。這些值也許有一天都會(huì)隨著運(yùn)營規(guī)則有所變動(dòng)，所以也會(huì)抽到分布式配置中心上。
....
03、分布式配置中心 選擇
從我第一天把Apollo寫入到austin可能要引入的中間件，就有很多人問我：為什么選擇Apollo。我還挺納悶的，怎么就這個(gè)中間件問我的特別多呢？分布式配置中心可選擇的項(xiàng)目也是蠻多的：
在網(wǎng)上也有很多相關(guān)的對比，比如：
| 功能特性 | 重要性 | spring-cloud-config | Apollo | disconf | Nacos |
|---|---|---|---|---|---|
| 靜態(tài)配置管理 | 高 | 基于file | 支持 | 支持 | 支持 |
| 動(dòng)態(tài)配置管理 | 高 | 支持 | 支持 | 支持 | 支持 |
| 統(tǒng)一管理 | 高 | 無，需要github | 支持 | 支持 | 支持 |
| 多環(huán)境 | 中 | 無，需要github | 支持 | 支持 | 支持 |
| 本地配置緩存 | 高 | 無 | 支持 | 支持 | 支持 |
| 配置鎖 | 中 | 支持 | 不支持 | 不支持 | 不支持 |
| 配置校驗(yàn) | 中 | 無 | 無 | 無 | 無 |
| 配置生效時(shí)間 | 高 | 重啟生效，或手動(dòng)refresh生效 | 實(shí)時(shí) | 實(shí)時(shí) | 實(shí)時(shí) |
| 配置更新推送 | 高 | 需要手工觸發(fā) | 支持 | 支持 | 支持 |
| 配置定時(shí)拉取 | 高 | 無 | 支持 | 配置更新目前依賴事件驅(qū)動(dòng)， client重啟或者server端推送操 | 支持 |
| 用戶權(quán)限管理 | 中 | 無，需要github | 支持 | 支持 | 支持 |
| 授權(quán)、審核、審計(jì) | 中 | 無，需要github | 支持 | 無 | 支持 |
| 配置版本管理 | 高 | Git做版本管理 | 界面上直接提供發(fā)布?xì)v史和回滾按鈕 | 操作記錄有落數(shù)據(jù)庫，但無查詢接口 | 界面操作，支持回滾 |
| 配置合規(guī)檢測 | 高 | 不支持 | 支持（但還需完善） | 支持 | |
| 實(shí)例配置監(jiān)控 | 高 | 需要結(jié)合spring admin | 支持 | 支持，可以查看每個(gè)配置在哪些機(jī)器上加載 | 支持 |
| 灰度發(fā)布 | 中 | 不支持 | 支持 | 不支持部分更新 | 支持 |
| 告警通知 | 中 | 不支持 | 支持，郵件方式告警 | 支持，郵件方式告警 | 支持 |
總體來說：Apollo支持的功能齊全、社區(qū)活躍、中文文檔豐富。所以，我就選擇了Apollo。社區(qū)活躍太重要了，當(dāng)你使用某個(gè)框架時(shí)出現(xiàn)問題，然后網(wǎng)上一搜，發(fā)現(xiàn)都沒人有過類似的踩坑記錄，這時(shí)候頭都大了。
之前我就提到過：技術(shù)選型并往往不跟技術(shù)掛鉤。如果是個(gè)人項(xiàng)目，選個(gè)社區(qū)活躍的，并且該中間件已經(jīng)被踩了很多坑的，學(xué)習(xí)它的思想和原理就能舉一反三。等以后知識(shí)面上去了，覺得自己當(dāng)時(shí)腦子進(jìn)了屎選了個(gè)破玩意，切換成本一般也不會(huì)有多大。
如果是在公司，本身就有類似的中間件，該用什么就用什么，在這基礎(chǔ)上修修補(bǔ)補(bǔ)就好了。如果沒有類似的中間件，那就多點(diǎn)花時(shí)間調(diào)研，但我認(rèn)為在選取的時(shí)候最后還是離不開中間件的成熟度和社區(qū)活躍度（也有可能大老板按照以往的習(xí)慣一拍板...）
雖說如此，感興趣的還是可以多看看對比對比，這類文章在網(wǎng)上很多。（別老想著我什么都喂給你）
04、分布式配置中心原理
我以前的公司是自研的分布式配置中心，我曾經(jīng)就看過其原理思想。那時(shí)候看到公司自研的技術(shù)實(shí)現(xiàn)是利用長連接使配置能實(shí)時(shí)被客戶端監(jiān)聽到。這次引用了Apollo，我也去看了下設(shè)計(jì)文檔，也是通過長輪詢的方式實(shí)現(xiàn)客戶端實(shí)時(shí)感知
推薦大家去讀一讀，如果對分布式配置中心不太熟悉或者不了解它是什么東西的話。
https://www.apolloconfig.com/#/zh/design/apollo-design
對于這塊，我感覺我沒什么可講的，我平白無事也不會(huì)去撈源碼看（除非特別對某個(gè)技術(shù)實(shí)現(xiàn)感興趣，想看看人家是怎么實(shí)現(xiàn)的）。而Apollo文檔這塊做得是相當(dāng)不錯(cuò)了。
我針對性從頭讀到尾，感覺挺流暢的，貌似不太需要我補(bǔ)充什么內(nèi)容。
05、部署Apollo
部署Apollo跟之前一樣直接用docker-compose就完事了，在GitHub已經(jīng)給出了對應(yīng)的教程和docker-compose.yml以及相關(guān)的文件，直接復(fù)制粘貼就完事咯。
https://www.apolloconfig.com/#/zh/deployment/quick-start-docker
https://github.com/apolloconfig/apollo/tree/master/scripts/docker-quick-start
由于端口的占用問題，我換了下映射端口，最主要看兩個(gè)端口吧：8070是后臺(tái)控制頁面的端口，8080是服務(wù)的端口
06、SpringBoot 使用apollo
寫到這的時(shí)候，發(fā)現(xiàn)我是真的沒啥好寫的，我無非也是跟著官方文檔弄弄。唯一的好處是我有現(xiàn)成的代碼，跟著做的同學(xué)可以直接復(fù)制粘貼就完了。
1、引入maven的依賴
<dependency>
??<groupId>com.ctrip.framework.apollogroupId>
??<artifactId>apollo-client-config-dataartifactId>
??<version>1.9.1version>
dependency>
2、在配置文件上加入apollo的配置信息：
#?apollo??TODO
app:
??id:?austin
apollo:
??bootstrap:
????enabled:?true
????namespaces:?boss.austin
配置的信息是在apollo的后臺(tái)上新增的（這塊大家只要能打開后臺(tái)，問題就不大了，操作都挺簡單的，感覺也沒必要看啥文檔）
部門的創(chuàng)建其實(shí)也是一份"配置"，輸入organizations就能把現(xiàn)有的部門給改掉，我新增了boss股東部門，大家都是我的股東。
3、在Spring中直接使用ApolloConfig就完了
還值得一提的是，我們是在云服務(wù)器上使用docker部署的apollo的。一般獲取姿勢配置都是在內(nèi)網(wǎng)上暴露對應(yīng)的服務(wù)地址的，但我們這先體驗(yàn)的，所以可以直接跳過meta server
為了方便使用，直接在啟動(dòng)的時(shí)候設(shè)置下參數(shù)就好了（跟著做的同學(xué)可以換下自己的ip和端口）
08、總結(jié)
這篇文章簡單介紹了什么是分布式配置中心，以及分布式配置中心能用來干什么，介紹了如何入門Apollo，使用SpringBoot環(huán)境下使用Apollo。
我強(qiáng)烈建議如果不了解分布式配置中心的同學(xué)可以從Apollo入手，根據(jù)上面給出的鏈接閱讀下他的架構(gòu)由來以及它的設(shè)計(jì)理念。作為一個(gè)markdown程序員而言，我覺得寫得很不錯(cuò)的了。
對這感興趣的，也可以深入閱讀下源碼，看看關(guān)鍵的功能是怎么實(shí)現(xiàn)的（這不又是一條學(xué)習(xí)路徑？）
如果公司還沒有用到分布式配置中心的，看完文章看看自己的項(xiàng)目有沒有相關(guān)的場景，可以專研下來接入下（一整個(gè)Q的KPI/OKR就有了，不用愁了）