好傢伙，分散式配置中心真好用

我是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