【Apollo】(2)— Apollo架構設計
- 2020 年 8 月 17 日
- 筆記
- 【分佈式】-- Apollo
Apollo架構設計
上一篇博客有講到：【Apollo】(1)— Apollo入門介紹篇
這篇來寫Apollo的核心架構設計
一、整體架構
Apollo整體架構圖，已由作者宋順已經給出:
這幅圖所描述的已經很清楚了。下面來具體解釋下上面這張圖。
1、四個主要模塊和核心功能
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 中。
2、三個輔助服務發現模塊
為了保證上面四個模塊的高可用，所以這裡需要三個輔助模塊配合。
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進行配置管理。
二、架構剖析
1、Apollo架構V1
如果不考慮分佈式微服務架構中的服務發現問題，Apollo的最簡架構如下圖(來源 楊波)所示：
要點
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只需部署一份，它可以管理多套環境。
2、Apollo架構V2
為了保證高可用，ConfigService和AdminService都是無狀態以集群方式部署的，這個時候就存在一個服務發現問題：Client怎麼找到ConfigService？Portal
怎麼找到AdminService？為了解決這個問題，Apollo在其架構中引入了Eureka服務註冊中心組件，實現微服務間的服務註冊和發現，更新後的架構如下圖所示：
要點
-
Config/AdminService啟動後都會註冊到Eureka服務註冊中心，並定期發送保活心跳。
-
Eureka採用集群方式部署，使用分佈式一致性協議保證每個實例的狀態最終一致。
3、Apollo架構V3
我們知道Eureka是自帶服務發現的Java客戶端的，如果Apollo只支持Java客戶端接入，不支持其它語言客戶端接入的話，那麼Client和Portal只需要引入Eureka的Java
客戶端，就可以實現服務發現功能。發現目標服務後，通過客戶端軟負載(SLB，例如Ribbon)就可以路由到目標服務實例。這是一個經典的微服務架構，基於Eureka實現
服務註冊發現+客戶端Ribbon配合實現軟路由，如下圖所示：
4、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之後的架構如下圖所示：
5、Apollo架構V5
V4版本已經是比較完成的Apollo架構全貌，現在還剩下最後一個環節：Portal也是無狀態以集群方式部署的，用戶如何發現和訪問Portal？答案也是簡單的傳統做法，
用戶通過域名+NginxLB間接訪問MetaServer集群。
所以V5版本是包括用戶端的最終的Apollo架構全貌，如下圖所示：
6、結論
- 經過我在第三部分的剖析之後，相信大家對Apollo的微服務架構會有更清晰的認識，作為一個思考題，大家再回頭看一下第二部分宋順給出的架構圖，現在是否能夠理解？
它和我的架構是如何對應的？提示一下，宋順的視角是一個從上往下的俯視視角，而我的是一個側面視角。
- ConfgService/AdminService/Client/Portal是Apollo的四個核心微服務模塊，相互協作完成配置中心業務功能，Eureka/MetaServer/NginxLB是輔助微服務之間進行服務
發現的模塊。
- Apollo採用微服務架構設計，架構和部署都有一些複雜，但是每個服務職責單一，易於擴展。另外，Apollo只需要一套Portal就可以集中管理多套環境(DEV/FAT/UAT/PRO)
中的配置，這個是它的架構的一大亮點。。
- 服務發現是微服務架構的基礎，在Apollo的微服務架構中，既採用Eureka註冊中心式的服務發現，也採用NginxLB集中Proxy式的服務發現。
三、可用性考慮
上面設計這麼複雜就是為了滿足高可用，如果不考慮可用性，那麼那麼的v1圖片就可以滿足。我們來下最終的架構圖為什麼能滿足高可用。
很明顯這些模塊任何一個掛掉，都能滿足服務的可以用性。
參考
別人罵我胖，我會生氣，因為我心裏承認了我胖。別人說我矮，我就會覺得好笑，因為我心裏知道我不可能矮。這就是我們為什麼會對別人的攻擊生氣。
攻我盾者，乃我內心之矛(27)
