筆者在工作中遇到如下問題，隨著程式功能越多，配置檔案不斷增加，一些功能的開關、伺服器地址、介面地址、不同環境的一些配置檔案不同，這些在每次釋出不同環境、更新專案時都比較繁瑣，後來學習微服務時接觸到了Spring Cloud Config配置中心，用了一段時間發現比之前方便不少，但是還是比較繁瑣和麻煩，而且功能還達不到生產級，只能小規模場景下使用，在中大規模企業場景下不建議採用。後來瞭解到攜程Apollo配置中心，Apollo支援完善的管理介面，支援多環境，配置變更實時生效，許可權和配置審計等多種生產級功能，而且在攜程到微服務架構體系中也運用了這個，在國內眾多網際網路公司也有落地案例，就開始去接觸瞭解。最後結合工作和學習的一些經驗分享給大家Apollo的入門使用和一些走過的坑，本篇文章主要介紹了Apollo架構體系、Apollo執行原理、Apollo配置中心概念、特性簡單介紹。

部分資料來源：

攜程Apollo配置中心架構深度解析：https://www.cnblogs.com/davidwang456/articles/9154260.html

Apollo配置中心簡單介紹：https://blog.csdn.net/Michael_HM/article/details/79412461

推薦部落格：

Apollo架構體系、Apollo執行原理、Apollo配置中心簡單介紹：https://blog.csdn.net/zjh_746140129/article/details/86179522

Linux下配置安裝Apollo、Centons下配置安裝Apollo：https://blog.csdn.net/zjh_746140129/article/details/86179601

Spring Boot專案整合Apollo配置中心：https://blog.csdn.net/zjh_746140129/article/details/86361168

Spring boot專案整合apollo錯誤：for env UNKNOWN from com.ctrip.framework.apollo.internals.DefaultMetaServer​​​​​​​

 

一、Apollo簡介

Apollo（阿波羅）是攜程框架部研發並開源的一款生產級的配置中心產品，它能夠集中管理應用在不同環境、不同叢集的配置，配置修改後能夠實時推送到應用端，並且具備規範的許可權、流程治理等特性，適用於微服務配置管理場景。

Apollo目前在國內開發者社群比較熱，在Github上有超過5k顆星，在國內眾多網際網路公司有落地案例，可以說Apollo是目前配置中心產品領域Number1的產品，其成熟度和企業級特性要遠遠強於Spring Cloud體系中的Spring Cloud Config產品。

Apollo採用分散式微服務架構，它的架構有一點複雜，Apollo的作者宋順雖然給出了一個架構圖，但是如果沒有一定的分散式微服務架構基礎的話，則普通的開發人員甚至是架構師也很難一下子理解。

二、Apollo架構和模組

四個核心模組及其主要功能

1. ConfigService

• 提供配置獲取介面
• 提供配置推送介面
• 服務於Apollo客戶端

2. AdminService

• 提供配置管理介面
• 提供配置修改釋出介面
• 服務於管理介面Portal

3. Client

• 為應用獲取配置，支援實時更新
• 通過MetaServer獲取ConfigService的服務列表
• 使用客戶端軟負載SLB方式呼叫ConfigService

4. Portal

• 配置管理介面
• 通過MetaServer獲取AdminService的服務列表
• 使用客戶端軟負載SLB方式呼叫AdminService

 

三個輔助服務發現模組

1. Eureka

• 用於服務發現和註冊
• Config/AdminService註冊例項並定期報心跳
• 和ConfigService住在一起部署

2. MetaServer

• Portal通過域名訪問MetaServer獲取AdminService的地址列表
• Client通過域名訪問MetaServer獲取ConfigService的地址列表
• 相當於一個Eureka Proxy
• 邏輯角色，和ConfigService住在一起部署

3. NginxLB

• 和域名系統配合，協助Portal訪問MetaServer獲取AdminService地址列表
• 和域名系統配合，協助Client訪問MetaServer獲取ConfigService地址列表
• 和域名系統配合，協助使用者訪問Portal進行配置管理

 

 

三、架構剖析

Apollo架構V1

如果不考慮分散式微服務架構中的服務發現問題，Apollo的最簡架構如下圖所示：

Apollo V1架構by楊波

要點：

1. ConfigService是一個獨立的微服務，服務於Client進行配置獲取。
2. Client和ConfigService保持長連線，通過一種拖拉結合(push & pull)的模式，實現配置實時更新的同時，保證配置更新不丟失。
3. AdminService是一個獨立的微服務，服務於Portal進行配置管理。Portal通過呼叫AdminService進行配置管理和釋出。
4. ConfigService和AdminService共享ConfigDB，ConfigDB中存放專案在某個環境的配置資訊。ConfigService/AdminService/ConfigDB三者在每個環境(DEV/FAT/UAT/PRO)中都要部署一份。
5. Protal有一個獨立的PortalDB，存放使用者許可權、專案和配置的元資料資訊。Protal只需部署一份，它可以管理多套環境。

Apollo架構V2

為了保證高可用，ConfigService和AdminService都是無狀態以叢集方式部署的，這個時候就存在一個服務發現問題：Client怎麼找到ConfigService？Portal怎麼找到AdminService？為了解決這個問題，Apollo在其架構中引入了Eureka服務註冊中心元件，實現微服務間的服務註冊和發現，更新後的架構如下圖所示：

Apollo V2架構by楊波

要點：

1. Config/AdminService啟動後都會註冊到Eureka服務註冊中心，並定期傳送保活心跳。
2. Eureka採用叢集方式部署，使用分散式一致性協議保證每個例項的狀態最終一致。

Apollo架構V3

我們知道Eureka是自帶服務發現的Java客戶端的，如果Apollo只支援Java客戶端接入，不支援其它語言客戶端接入的話，那麼Client和Portal只需要引入Eureka的Java客戶端，就可以實現服務發現功能。發現目標服務後，通過客戶端軟負載(SLB，例如Ribbon)就可以路由到目標服務例項。這是一個經典的微服務架構，基於Eureka實現服務註冊發現+客戶端Ribbon配合實現軟路由，如下圖所示：

Apollo V3架構by楊波

Apollo架構V4

在攜程，應用場景不僅有Java，還有很多遺留的.Net應用。Apollo的作者也考慮到開源到社群以後，很多客戶應用是非Java的。但是Eureka(包括Ribbon軟負載)原生僅支援Java客戶端，如果要為多語言開發Eureka/Ribbon客戶端，這個工作量很大也不可控。為此，Apollo的作者引入了MetaServer這個角色，它其實是一個Eureka的Proxy，將Eureka的服務發現介面以更簡單明確的HTTP介面的形式暴露出來，方便Client/Protal通過簡單的HTTPClient就可以查詢到Config/AdminService的地址列表。獲取到服務例項地址列表之後，再以簡單的客戶端軟負載(Client SLB)策略路由定位到目標例項，併發起呼叫。

現在還有一個問題，MetaServer本身也是無狀態以叢集方式部署的，那麼Client/Protal該如何發現MetaServer呢？一種傳統的做法是藉助硬體或者軟體負載均衡器，例如在攜程採用的是擴充套件後的NginxLB（也稱Software Load Balancer），由運維為MetaServer叢集配置一個域名，指向NginxLB叢集，NginxLB再對MetaServer進行負載均衡和流量轉發。Client/Portal通過域名+NginxLB間接訪問MetaServer叢集。

引入MetaServer和NginxLB之後的架構如下圖所示：

 

Apollo V4架構by楊波

Apollo架構V5

V4版本已經是比較完成的Apollo架構全貌，現在還剩下最後一個環節：Portal也是無狀態以叢集方式部署的，使用者如何發現和訪問Portal？答案也是簡單的傳統做法，使用者通過域名+NginxLB間接訪問MetaServer叢集。

所以V5版本是包括使用者端的最終的Apollo架構全貌，如下圖所示：

Apollo V5架構by楊波

四、結論

1. 宋順的視角是一個從上往下的俯視視角，而我的是一個側面視角。

2. ConfgService/AdminService/Client/Portal是Apollo的四個核心微服務模組，相互協作完成配置中心業務功能，Eureka/MetaServer/NginxLB是輔助微服務之間進行服務發現的模組。

3. Apollo採用微服務架構設計，架構和部署都有一些複雜，但是每個服務職責單一，易於擴充套件。另外，Apollo只需要一套Portal就可以集中管理多套環境(DEV/FAT/UAT/PRO)中的配置，這個是它的架構的一大亮點。。

4. 服務發現是微服務架構的基礎，在Apollo的微服務架構中，既採用Eureka註冊中心式的服務發現，也採用NginxLB集中Proxy式的服務發現。

 

五、Spring Cloud Config和Apollo對比

這張圖也算是綜合對比了spring cloud config,netflix archaius, ctrip apollo, disconf, hawk 等配置中心的功能點。綜合比較下來攜程Apollo更具有優勢。

 

 

六、Apollo配置中心基本概念、特性

1、配置的幾個屬性

①配置是獨立於程式的只讀變數

           配置首先是獨立於程式的，同一份程式在不同的配置下會有不同的行為。

           其次，配置對於程式是隻讀的，程式通過讀取配置來改變自己的行為，但是程式不應該去改變配置。

           常見的配置有：DB Connection Str、Thread Pool Size、Buffer Size、Request Timeout、Feature Switch、Server Urls等。

②配置伴隨應用的整個生命週期

          配置貫穿於應用的整個生命週期，應用在啟動時通過讀取配置來初始化，在執行時根據配置調整行為。

③配置可以有多種載入方式

           配置也有很多種載入方式，常見的有程式內部hard code，配置檔案，環境變數，啟動引數，基於資料庫等

④配置需要治理

     許可權控制

               由於配置能改變程式的行為，不正確的配置甚至能引起災難，所以對配置的修改必須有比較完善的許可權控制

    不同環境、叢集配置管理

              同一份程式在不同的環境（開發，測試，生產）、不同的叢集（如不同的資料中心）經常需要有不同的配置，所以需要有完善的環境、叢集配置管理

   框架類元件配置管理

              還有一類比較特殊的配置 - 框架類元件配置，比如CAT客戶端的配置。

             雖然這類框架類元件是由其他團隊開發、維護，但是執行時是在業務實際應用內的，所以本質上可以認為框架類元件也是應用的一部分。

              這類元件對應的配置也需要有比較完善的管理方式。

二、Apollo配置中心特性

1、統一管理不同環境、不同叢集的配置

            Apollo提供了一個統一介面集中式管理不同環境（environment）、不同叢集（cluster）、不同名稱空間（namespace）的配置。

            同一份程式碼部署在不同的叢集，可以有不同的配置，比如zk的地址等

           通過名稱空間（namespace）可以很方便的支援多個不同應用共享同一份配置，同時還允許應用對共享的配置進行覆蓋

2、配置修改實時生效（熱釋出）

              使用者在Apollo修改完配置併發布後，客戶端能實時（1秒）接收到最新的配置，並通知到應用程式

3、版本釋出管理

            所有的配置釋出都有版本概念，從而可以方便地支援配置的回滾

4、灰度釋出

            支援配置的灰度釋出，比如點了釋出後，只對部分應用例項生效，等觀察一段時間沒問題後再推給所有應用例項

5、許可權管理、釋出稽核、操作審計

             應用和配置的管理都有完善的許可權管理機制，對配置的管理還分為了編輯和釋出兩個環節，從而減少人為的錯誤。

             所有的操作都有審計日誌，可以方便的追蹤問題

6、客戶端配置資訊監控

             可以在介面上方便地看到配置在被哪些例項使用

7、提供Java和.Net原生客戶端

             提供了Java和.Net的原生客戶端，方便應用整合

             支援Spring Placeholder, Annotation和Spring Boot的ConfigurationProperties，方便應用使用（需要Spring 3.1.1+）

             同時提供了Http介面，非Java和.Net應用也可以方便的使用

8、提供開放平臺API

             Apollo自身提供了比較完善的統一配置管理介面，支援多環境、多資料中心配置管理、許可權、流程治理等特性。

             不過Apollo出於通用性考慮，對配置的修改不會做過多限制，只要符合基本的格式就能夠儲存。

              在我們的調研中發現，對於有些使用方，它們的配置可能會有比較複雜的格式，而且對輸入的值也需要進行校驗後方可儲存，如檢查資料庫、使用者名稱和密碼是否匹配。

對於這類應用，Apollo支援應用方通過開放介面在Apollo進行配置的修改和釋出，並且具備完善的授權和許可權控制

9、部署簡單

            配置中心作為基礎服務，可用性要求非常高，這就要求Apollo對外部依賴儘可能地少

            目前唯一的外部依賴是MySQL，所以部署非常簡單，只要安裝好Java和MySQL就可以讓Apollo跑起來

             Apollo還提供了打包指令碼，一鍵就可以生成所有需要的安裝包，並且支援自定義執行時引數

 

七、Apollo配置中心執行流程

①使用者在配置中心對配置進行修改併發布

②配置中心通知Apollo客戶端有配置更新

③Apollo客戶端從配置中心拉取最新的配置、更新本地配置並通知到應用

 

Apollo後臺管理介面