筆者在工作中遇到如下問題，隨着程序功能越多，配置文件不斷增加，一些功能的開關、服務器地址、接口地址、不同環境的一些配置文件不同，這些在每次發佈不同環境、更新項目時都比較繁瑣，後來學習微服務時接觸到了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
一、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楊波
要點：
- 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間接訪問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後臺管理界面
