攜程Apollo配置中心架構深度剖析

轉自：http://www.uml.org.cn/wfw/201808153.asp

---

 

1、介紹

Apollo（阿波羅）[參考附錄]是攜程框架部研發並開源的一款生產級的配置中心產品，它可以集中管理應用在不一樣環境、不一樣集羣的配置，配置修改後可以實時推送到應用端，而且具有規範的權限、流程治理等特性，適用於微服務配置管理場景。

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

Apollo採用分佈式微服務架構，它的架構有一點複雜，Apollo的做者宋順雖然給出了一個架構圖，可是若是沒有必定的分佈式微服務架構基礎的話，則普通的開發人員甚至是架構師也很難一會兒理解。爲了讓你們更好的理解Apollo的架構設計，我花了一點時間把Apollo的架構按個人方式從新剖析一把。只有徹底理解了Apollo的架構，你們才能在生產實踐中更好的部署和使用Apollo。另外，經過學習Apollo的架構，你們能夠深刻理解微服務架構的一些基本原理。

2、架構和模塊

下圖是Apollo的做者給出的架構圖：

若是沒有足夠的分佈式微服務架構的基礎，對攜程的一些框架產品(好比Software Load Balancer(SLB))不瞭解的話，那麼這個架構圖第一眼看是不太好理解的(其實我第一次看到這個架構也沒有看明白)。在這裏咱們先放一下，等我後面把這個架構再從新剖析一把之後，你們再回過頭來看這個架構就容易理解了。

下面是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進行配置管理

3、架構剖析

Apollo架構V1

若是不考慮分佈式微服務架構中的服務發現問題，Apollo的最簡架構以下圖所示：

要點：

ConfigService是一個獨立的微服務，服務於Client進行配置獲取。

Client和ConfigService保持長鏈接，經過一種拖拉結合(push & pull)的模式，實現配置實時更新的同時，保證配置更新不丟失。

AdminService是一個獨立的微服務，服務於Portal進行配置管理。Portal經過調用AdminService進行配置管理和發佈。

ConfigService和AdminService共享ConfigDB，ConfigDB中存放項目在某個環境的配置信息。ConfigService/AdminService/ConfigDB三者在每一個環境(DEV/FAT/UAT/PRO)中都要部署一份。

Protal有一個獨立的PortalDB，存放用戶權限、項目和配置的元數據信息。Protal只需部署一份，它能夠管理多套環境。

Apollo架構V2

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

要點：

Config/AdminService啓動後都會註冊到Eureka服務註冊中心，並按期發送保活心跳。

Eureka採用集羣方式部署，使用分佈式一致性協議保證每一個實例的狀態最終一致。

Apollo架構V3

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

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架構V5

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

因此V5版本是包括用戶端的最終的Apollo架構全貌，以下圖所示：

4、結論

1. 通過我在第三部分的剖析以後，相信你們對Apollo的微服務架構會有更清晰的認識，做爲一個思考題，你們再回頭看一下第二部分宋順給出的架構圖，如今是否可以理解？它和個人架構是如何對應的？提示一下，宋順的視角是一個從上往下的俯視視角，而個人是一個側面視角。

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

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

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