1. 程式人生 > >Apollo架構體系、Apollo執行原理、Apollo配置中心簡單介紹(一)

Apollo架構體系、Apollo執行原理、Apollo配置中心簡單介紹(一)

筆者在工作中遇到如下問題,隨著程式功能越多,配置檔案不斷增加,一些功能的開關、伺服器地址、介面地址、不同環境的一些配置檔案不同,這些在每次釋出不同環境、更新專案時都比較繁瑣,後來學習微服務時接觸到了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後臺管理介面