【Apollo】(2)--- Apollo架構設計

Apollo架構設計

上一篇博客有講到：【Apollo】(1)--- Apollo入門介紹篇

這篇來寫Apollo的核心架構設計

1、總體架構

Apollo總體架構圖，已由做者宋順已經給出:

這幅圖所描述的已經很清楚了。下面來具體解釋下上面這張圖。

一、四個主要模塊和核心功能

ConfigService

提供配置的讀取、推送等功能，服務對象是Apollo客戶端(client)(最終目的就是把配置數據給到咱們本身的微服務對象)

Admin Service

提供配置的修改、發佈等功能，服務對象是Apollo Portal（管理界面）（簡單理解成就是就是用來在配置中心管理界面來添加或者修改配置）

Client( 客戶端)

Apollo提供的客戶端程序，爲應用提供配置獲取、實時更新等功能。

域名訪問 Meta Server 獲取 Config Service 服務列表（IP+Port），然後直接經過IP+Port訪問服務，同時在Client側會作負載均衡、錯誤重試

Portal

提供Web界面供用戶管理配置。

Portal經過域名訪問 Meta Server 獲取 Admin Service 服務列表（IP+Port），然後直接經過IP+Port訪問服務，同時在Portal側會作 負載均衡、錯誤重試

我的理解這四個模塊

ConfigService 和 Client 的配合

從這裏面能夠看出咱們本身的微服務不是直接和ConfigService打交道的,而是跟Client打交道，Client纔是真正和ConfigService打交道來獲取最新配置信息。

Admin Service 和 Portal

這裏分類兩個模塊就很好理解了，由於管理界面的實現有本身的一套代碼，並且管理界面操做的一些權限等信息,只會跟它本身有關係，對於微服務來說，我只關心有沒有配置

這條配置數據，而不會去關心在管理界面上什麼用戶可以添加配置信息。因此就有Portal對於了兩個數據庫，一個能夠理解是它本身的，存放一些權限等信息，另外一部分是和

配置有關的，因此經過 Admin Service 存放在 configDB 中。

二、三個輔助服務發現模塊

爲了保證上面四個模塊的高可用，因此這裏須要三個輔助模塊配合。

Eureka

用於服務發現和註冊Config/AdminService註冊實例並按期報心跳。

爲了簡化部署，咱們實際上會把Config Service、Eureka和Meta Server三個邏輯角色部署在同一個JVM進程中

官方也有解釋爲何咱們採用Eureka做爲服務註冊中心，而不是使用傳統的zk、etcd呢？我大體總結了一下，有如下幾方面的緣由：

1）它提供了完整的Service Registry和Service Discovery實現

首先是提供了完整的實現，而且也經受住了Netflix本身的生產環境考驗，相對使用起來會比較省心。

2）和Spring Cloud無縫集成

咱們的項目自己就使用了Spring Cloud和Spring Boot，同時Spring Cloud還有一套很是完善的開源代碼來整合Eureka，因此使用起來很是方便。另外，Eureka還支持在

咱們應用自身的容器中啓動，也就是說咱們的應用啓動完以後，既充當了Eureka的角色，同時也是服務的提供者。這樣就極大的提升了服務的可用性。這一點是咱們選擇

Eureka而不是zk、etcd等的主要緣由，爲了提升配置中心的可用性和下降部署複雜度，咱們須要儘量地減小外部依賴。

3）Open Source

最後一點是開源，因爲代碼是開源的，因此很是便於咱們瞭解它的實現原理和排查問題。

MetaServer

Portal經過域名 訪問 MetaServer 獲取 AdminService 的地址列表。

Client經過域名訪問MetaServer獲取ConfigService的地址列表。

至關於一個Eureka Proxy 邏輯角色，和ConfigService住在一塊兒部署。

NginxLB

和域名系統配合，協助Portal訪問MetaServer獲取AdminService地址列表。

和域名系統配合，協助Client訪問MetaServer獲取ConfigService地址列表。

和域名系統配合，協助用戶訪問Portal進行配置管理。

2、架構剖析

一、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服務註冊中心組件，實現微服務間的服務註冊和發現，更新後的架構以下圖所示：

要點

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

2. 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間接訪問MetaServer集羣。

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

六、結論

1. 通過我在第三部分的剖析以後，相信你們對Apollo的微服務架構會有更清晰的認識，做爲一個思考題，你們再回頭看一下第二部分宋順給出的架構圖，如今是否可以理解？

它和個人架構是如何對應的？提示一下，宋順的視角是一個從上往下的俯視視角，而個人是一個側面視角。

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

發現的模塊。

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

中的配置，這個是它的架構的一大亮點。。

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

3、可用性考慮

上面設計這麼複雜就是爲了知足高可用，若是不考慮可用性，那麼那麼的v1圖片就能夠知足。咱們來下最終的架構圖爲何能知足高可用。

很明顯這些模塊任何一個掛掉，都能知足服務的能夠用性。

參考

一、Apollo配置中心設計

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

別人罵我胖，我會生氣，由於我內心認可了我胖。別人說我矮，我就會以爲可笑，由於我內心知道我不可能矮。這就是咱們爲何會對別人的攻擊生氣。
攻我盾者，乃我心裏之矛(27)