好家伙，分布式配置中心這種組件真的是神器

我是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，我還挺納悶的，怎么就這個中間件問我的特別多呢？分布式配置中心可選擇的專案也是蠻多的：

在網上也有很多相關的對比，比如：

總體來說：Apollo支持的功能齊全、社區活躍、中文檔案豐富，所以，我就選擇了Apollo，社區活躍太重要了，當你使用某個框架時出現問題，然后網上一搜，發現都沒人有過類似的踩坑記錄，這時候頭都大了，

之前我就提到過：技術選型并往往不跟技術掛鉤，如果是個人專案，選個社區活躍的，并且該中間件已經被踩了很多坑的，學習它的思想和原理就能舉一反三，等以后知識面上去了，覺得自己當時腦子進了屎選了個破玩意，切換成本一般也不會有多大，

如果是在公司，如果本身就有類似的中間件，該用什么就用什么，在這基礎上修修補補就好了，如果本身沒有類似的中間件，那就多點花時間調研，但最后還是離不開中間件的成熟度和社區活躍度（也有可能大老板按照以往的習慣一拍板，哎，這就選好了，不傷腦筋）

不過，感興趣的還是可以多看看對比對比，這類文章在網上很多，

04、分布式配置中心原理

我以前的公司是自研的分布式配置中心，我曾經就看過其原理思想，那時候看到公司自研的技術實作是利用長連接使配置能實時被客戶端監聽到，這次參考了Apollo，我也去看了下設計檔案，也是通過長輪詢的方式實作客戶端實時感知

推薦大家去讀一讀，如果對分布式配置中心不太熟悉或者不了解它是什么東西的話，

攜程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

標籤：Java

上一篇：【第三十三期】golang校招面試經歷分享 暢天游

下一篇：快速了解常用的訊息摘要演算法，再也不用擔心面試官的刨根問底