一、介紹
Apollo（阿波羅）[參考附錄] 是攜程框架部研發並開源的一款生產級的配置中心產品，它能夠集中管理應用在不同環境、不同集群的配置，配置修改後能夠實時推送到應用端，並且具備規範的權限、流程治理等特性，適用於微服務配置管理場景。
Apollo 目前在國內開發者社區比較熱，在 Github 上有超過 5k 顆星，在國內眾多互聯網公司有落地案例，可以說 Apollo 是目前配置中心產品領域 Number1 的產品，其成熟度和企業級特性要遠遠強於 Spring Cloud 體系中的 Spring Cloud Config 產品。
Apollo 採用分佈式微服務架構，它的架構有一點複雜，Apollo 的作者宋順雖然給出了一個架構圖，但是如果沒有一定的分佈式微服務架構基礎的話，則普通的開發人員甚至是架構師也很難一下子理解。為了讓大家更好的理解 Apollo 的架構設計，我花了一點時間把 Apollo 的架構按我的方式重新剖析一把。只有完全理解了 Apollo 的架構，大家才能在生產實踐中更好的部署和使用 Apollo。另外，通過學習 Apollo 的架構，大家可以深入理解微服務架構的一些基本原理。
二、架構和模塊
下圖是 Apollo 的作者宋順給出的架構圖：
Apollo 架構圖 by 宋順
如果沒有足夠的分佈式微服務架構的基礎，對攜程的一些框架產品 (比如 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 進行配置管理
三、架構剖析
Apollo 架構 V1
如果不考慮分佈式微服務架構中的服務發現問題，Apollo 的最簡架構如下圖所示：
Apollo V1 架構 by 楊波
要點：
- 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 服務註冊中心組件，實現微服務間的服務註冊和發現，更新後的架構如下圖所示：
Apollo V2 架構 by 楊波
要點：
- Config/AdminService 啟動後都會註冊到 Eureka 服務註冊中心，並定期發送保活心跳。
- 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 間接訪問 Portal 集群。
所以 V5 版本是包括用戶端的最終的 Apollo 架構全貌，如下圖所示：
Apollo V5 架構 by 楊波
四、結論
1. 經過我在第三部分的剖析之後，相信大家對 Apollo 的微服務架構會有更清晰的認識，作為一個思考題，大家再回頭看一下第二部分宋順給出的架構圖，現在是否能夠理解？它和我的架構是如何對應的？提示一下，宋順的視角是一個從上往下的俯視視角，而我的是一個側面視角。
2. ConfgService/AdminService/Client/Portal 是 Apollo 的四個核心微服務模塊，相互協作完成配置中心業務功能，Eureka/MetaServer/NginxLB 是輔助微服務之間進行服務發現的模塊。
3. Apollo 採用微服務架構設計，架構和部署都有一些複雜，但是每個服務職責單一，易於擴展。另外，Apollo 只需要一套 Portal 就可以集中管理多套環境 (DEV/FAT/UAT/PRO) 中的配置，這個是它的架構的一大亮點。。
4. 服務發現是微服務架構的基礎，在 Apollo 的微服務架構中，既採用 Eureka 註冊中心式的服務發現，也採用 NginxLB 集中 Proxy 式的服務發現。
原文地址：https://www.infoq.cn/article/ctrip-apollo-configuration-center-architecture/
閱讀更多 架構師筆記 的文章
