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