目錄 . 一、基本概念 . 1、背景 . 2、簡介 . 3、特點 . 4、基礎模型 . 5、Apollo 的四個維度 . 6、本地緩存 . 7、客戶端設計 . 8、總體設計 . 9、可用性考慮 . 二、Apollo 配置中心創建項目與配置 . 1、登錄 Apollo . 2、修改與增加部門數據 . ...
目錄
. 一、基本概念
. 1、背景
. 2、簡介
. 3、特點
. 4、基礎模型
. 5、Apollo 的四個維度
. 6、本地緩存
. 7、客戶端設計
. 8、總體設計
. 9、可用性考慮
. 二、Apollo 配置中心創建項目與配置
. 1、登錄 Apollo
. 2、修改與增加部門數據
. 3、創建一個項目
. 4、創建一個配置參數
. 三、創建 Apollo 客戶端測試項目
. 1、Mavne 添加 Apollo 依賴
. 2、配置文件添加參數
. 3、創建測試 Controller 類
. 4、創建啟動類
. 5、JVM 啟動參數添加啟動參數
. 四、啟動項目進行測試
. 1、測試是否能夠獲取 Apollo 中設置的值
. 2、測試當 Apollo 中修改參數值後客戶端是否能及時刷新
. 3、測試當 Apollo 執行配置回滾操作時客戶端是否能及時改變
. 4、測試當不能訪問 Apollo 時客戶端的變化
. 5、測試當 Apollo 中將參數刪除後客戶端的變化
. 五、對 Apollo 的 Cluster、Namespace 進行探究
. 1、不同環境下的配置
. 2、不同集群下的配置
. 3、不同命名空間下的配置
. 六、Kubernetes 的 SpringBoot 應用使用 Apollo 配置中心
. 1、構建 Docker 鏡像
. 2、Kubernetes 部署示例應用
. 3、測試部署的應用介面
目錄
-
一、Kubernetes 部署配置中心 Apollo
-
二、SpringBoot 集成 Apollo 配置中心
系統環境
-
SpringBoot 版本:2.1.8.RELEASE
-
Apollo 版本:1.4.0
參考地址
-
Apollo 文檔知識
-
Apollo Github 地址
-
SpringBoto 集成 Apollo 示例項目 Github 地址:https://github.com/my-dlq/blog-example/tree/master/springboot/springboot-apollo-demo
一、基本概念
由於 Apollo 概念比較多,剛開始使用比較複雜,最好先過一遍概念再動手實踐嘗試使用。
1、背景
隨著程式功能的日益複雜,程式的配置日益增多,各種功能的開關、參數的配置、伺服器的地址……對程式配置的期望值也越來越高,配置修改後實時生效,灰度發佈,分環境、分集群管理配置,完善的許可權、審核機制…… 在這樣的大環境下,傳統的通過配置文件、資料庫等方式已經越來越無法滿足開發人員對配置管理的需求。因此 Apollo 配置中心應運而生!
2、簡介
Apollo(阿波羅)是攜程框架部門研發的開源配置管理中心,能夠集中化管理應用不同環境、不同集群的配置,配置修改後能夠實時推送到應用端,並且具備規範的許可權、流程治理等特性。
特點
-
部署簡單
-
灰度發佈
-
版本發佈管理
-
提供開放平臺API
-
客戶端配置信息監控
-
提供Java和.Net原生客戶端
-
配置修改實時生效(熱發佈)
-
許可權管理、發佈審核、操作審計
-
統一管理不同環境、不同集群的配置
基礎模型
如下即是 Apollo 的基礎模型:
(1)、用戶在配置中心對配置進行修改併發布
(2)、配置中心通知Apollo客戶端有配置更新
(3)、Apollo客戶端從配置中心拉取最新的配置、更新本地配置並通知到應用
5、Apollo 的四個維度
Apollo支持4個維度管理Key-Value格式的配置:
-
application (應用)
-
environment (環境)
-
cluster (集群)
-
namespace (命名空間)
(1)、application
-
Apollo 客戶端在運行時需要知道當前應用是誰,從而可以根據不同的應用來獲取對應應用的配置。
-
每個應用都需要有唯一的身份標識,可以在代碼中配置
app.id
參數來標識當前應用,Apollo 會根據此指來辨別當前應用。
(2)、environment
在實際開發中,我們的應用經常要部署在不同的環境中,一般情況下分為開發、測試、生產等等不同環境,不同環境中的配置也是不同的,在 Apollo 中預設提供了四種環境:
-
FAT(Feature Acceptance Test):功能測試環境
-
UAT(User Acceptance Test):集成測試環境
-
DEV(Develop):開發環境
-
PRO(Produce):生產環境
在程式中如果想指定使用哪個環境,可以配置變數 env
的值為對應環境名稱即可。
(3)、cluster
-
一個應用下不同實例的分組,比如典型的可以按照數據中心分,把上海機房的應用實例分為一個集群,把北京機房的應用實例分為另一個集群。
-
對不同的集群,同一個配置可以有不一樣的值,比如說上面所指的兩個北京、上海兩個機房設置兩個集群,兩個集群中都有 mysql 配置參數,其中參數中配置的地址是不一樣的。
(4)、namespace
一個應用中不同配置的分組,可以簡單地把 namespace 類比為不同的配置文件,不同類型的配置存放在不同的文件中,如資料庫配置文件,RPC 配置文件,應用自身的配置文件等。
熟悉 SpringBoot 的都知道,SpringBoot 項目都有一個預設配置文件 application.yml
,如果還想用多個配置,可以創建多個配置文件來存放不同的配置信息,通過指定 spring.profiles.active
參數指定應用不同的配置文件。這裡的 namespace
概念與其類似,將不同的配置放到不同的配置 namespace
中。
Namespace 分為兩種許可權,分別為:
-
public(公共的): public許可權的 Namespace,能被任何應用獲取。
-
private(私有的): 只能被所屬的應用獲取到。一個應用嘗試獲取其它應用 private 的 Namespace,Apollo 會報 “404” 異常。
Namespace 分為三種類型,分別為:
-
私有類型: 私有類型的 Namespace 具有 private 許可權。例如 application Namespace 為私有類型。
-
公共類型: 公共類型的 Namespace 具有 public 許可權。公共類型的N amespace 相當於游離於應用之外的配置,且通過 Namespace 的名稱去標識公共 Namespace,所以公共的 Namespace 的名稱必須全局唯一。
-
關聯類型(繼承類型): 關聯類型又可稱為繼承類型,關聯類型具有 private 許可權。關聯類型的 Namespace 繼承於公共類型的 Namespace,將裡面的配置全部繼承,並且可以用於覆蓋公共 Namespace 的某些配置。
-
繼承,並且可以用於覆蓋公共 Namespace 的某些配置。
6、本地緩存
Apollo客戶端會把從服務端獲取到的配置在本地文件系統緩存一份,用於在遇到服務不可用,或網路不通的時候,依然能從本地恢復配置,不影響應用正常運行。
本地緩存路徑預設位於以下路徑,所以請確保/opt/data或C:\opt\data\目錄存在,且應用有讀寫許可權。
-
Mac/Linux: /opt/data/{appId}/config-cache
-
Windows: C:\opt\data{appId}\config-cache
本地配置文件會以下麵的文件名格式放置於本地緩存路徑下:
1 {appId}+{cluster}+{namespace}.properties
7、客戶端設計
上圖簡要描述了Apollo客戶端的實現原理
-
客戶端和服務端保持了一個長連接,從而能第一時間獲得配置更新的推送。
-
客戶端還會定時從 Apollo 配置中心服務端拉取應用的最新配置。
-
這是一個 fallback 機制,為了防止推送機制失效導致配置不更新
-
客戶端定時拉取會上報本地版本,所以一般情況下,對於定時拉取的操作,服務端都會返回 304 - Not Modified
-
定時頻率預設為每 5 分鐘拉取一次,客戶端也可以通過在運行時指定
apollo.refreshInterval
來覆蓋,單位為分鐘。 -
客戶端從 Apollo 配置中心服務端獲取到應用的最新配置後,會保存在記憶體中。
-
客戶端會把從服務端獲取到的配置在本地文件系統緩存一份 在遇到服務不可用,或網路不通的時候,依然能從本地恢復配置。
-
應用程式從 Apollo 客戶端獲取最新的配置、訂閱配置更新通知。
配置更新推送實現
前面提到了 Apollo 客戶端和服務端保持了一個長連接,從而能第一時間獲得配置更新的推送。長連接實際上我們是通過 Http Long Polling 實現的,具體而言:
-
客戶端發起一個 Http 請求到服務端
-
服務端會保持住這個連接 60 秒
-
如果在 60 秒內有客戶端關心的配置變化,被保持住的客戶端請求會立即返回,並告知客戶端有配置變化的 namespace 信息,客戶端會據此拉取對應 namespace 的最新配置
-
如果在 60 秒內沒有客戶端關心的配置變化,那麼會返回 Http 狀態碼 304 給客戶端
-
客戶端在收到服務端請求後會立即重新發起連接,回到第一步
-
考慮到會有數萬客戶端向服務端發起長連,在服務端我們使用了 async servlet(Spring DeferredResult) 來服務 Http Long Polling 請求。
8、總體設計
上圖簡要描述了Apollo的總體設計,我們可以從下往上看:
-
Config Service 提供配置的讀取、推送等功能,服務對象是 Apollo 客戶端
-
Admin Service 提供配置的修改、發佈等功能,服務對象是 Apollo Portal(管理界面)
-
Config Service 和 Admin Service 都是多實例、無狀態部署,所以需要將自己註冊到 Eureka 中並保持心跳
-
在 Eureka 之上我們架了一層 Meta Server 用於封裝Eureka的服務發現介面
-
Client 通過功能變數名稱訪問 Meta Server 獲取Config Service服務列表(IP+Port),而後直接通過 IP+Port 訪問服務,同時在 Client 側會做 load balance 錯誤重試
-
Portal 通過功能變數名稱訪問 Meta Server 獲取 Admin Service 服務列表(IP+Port),而後直接通過 IP+Port 訪問服務,同時在 Portal 側會做 load balance、錯誤重試
-
為了簡化部署,我們實際上會把 Config Service、Eureka 和 Meta Server 三個邏輯角色部署在同一個 JVM 進程中