統一配置中心搭建
apollo
4.5.1 Why Eureka
為什麼我們採用Eureka作為服務註冊中心,而不是使用傳統的zk、etcd呢?我大致總結了一下,有以下幾方面的原因:
· 它提供了完整的Service Registry和Service Discovery實現
· 首先是提供了完整的實現,並且也經受住了Netflix自己的生產環境考驗,相對使用起來會比較省心。
·
· 我們的專案本身就使用了Spring Cloud和Spring Boot,同時Spring Cloud還有一套非常完善的開原始碼來整合Eureka,所以使用起來非常方便。
· 另外,Eureka還支援在我們應用自身的容器中啟動,也就是說我們的應用啟動完之後,既充當了Eureka的角色,同時也是服務的提供者。這樣就極大的提高了服務的可用性。
·
· Open Source
· 最後一點是開源,由於程式碼是開源的,所以非常便於我們瞭解它的實現原理和排查問題。
上圖簡要描述了Apollo客戶端的實現原理:
1. 客戶端和服務端保持了一個長連線,從而能第一時間獲得配置更新的推送。
2. 客戶端還會定時從Apollo配置中心服務端拉取應用的最新配置。
1. 這是一個fallback機制,為了防止推送機制失效導致配置不更新
2. 客戶端定時拉取會上報本地版本,所以一般情況下,對於定時拉取的操作,服務端都會返回304 - Not Modified
3. 定時頻率預設為每5分鐘拉取一次,客戶端也可以通過在執行時指定System Property: apollo.refreshInterval來覆蓋,單位為分鐘。
3. 客戶端從Apollo配置中心服務端獲取到應用的最新配置後,會儲存在記憶體中
4. 客戶端會把從服務端獲取到的配置在本地檔案系統快取一份
0. 在遇到服務不可用,或網路不通的時候,依然能從本地恢復配置
5. 應用程式可以從Apollo客戶端獲取最新的配置、訂閱配置更新通知
前面提到了Apollo客戶端和服務端保持了一個長連線,從而能第一時間獲得配置更新的推送。
長連線實際上我們是通過Http Long Polling實現的,具體而言:
· 客戶端發起一個Http請求到服務端
· 服務端會保持住這個連線30秒
· 如果在30秒內有客戶端關心的配置變化,被保持住的客戶端請求會立即返回,並告知客戶端有配置變化的namespace資訊,客戶端會據此拉取對應namespace的最新配置
· 如果在30秒內沒有客戶端關心的配置變化,那麼會返回Http狀態碼304給客戶端
· 客戶端在服務端請求返回後會自動重連
考慮到會有數萬客戶端向服務端發起長連,在服務端我們使用了async servlet(Spring DeferredResult)來服務HttpLong Polling請求。
4.7 可用性考慮
配置中心作為基礎服務,可用性要求非常高,下面的表格描述了不同場景下Apollo的可用性:
場景 |
影響 |
降級 |
原因 |
某臺config service下線 |
無影響 |
|
Config service無狀態,客戶端重連其它config service |
所有config service下線 |
客戶端無法讀取最新配置,Portal無影響 |
客戶端重啟時,可以讀取本地快取配置檔案 |
|
某臺admin service下線 |
無影響 |
|
Admin service無狀態,Portal重連其它admin service |
所有admin service下線 |
客戶端無影響,portal無法更新配置 |
|
|
某臺portal下線 |
無影響 |
|
Portal域名通過slb繫結多臺伺服器,重試後指向可用的伺服器 |
全部portal下線 |
客戶端無影響,portal無法更新配置 |
|
|
某個資料中心下線 |
無影響 |
|
多資料中心部署,資料完全同步,Meta Server/Portal域名通過slb自動切換到其它存活的資料中心 |
1.3.2 Admin Service
- 提供配置管理介面
- 提供配置修改、釋出等介面
- 介面服務物件為Portal
- Portal通過域名訪問Meta Server獲取Admin Service服務列表(IP+Port)
- Client通過域名訪問Meta Server獲取Config Service服務列表(IP+Port)
- Meta Server從Eureka獲取Config Service和Admin Service的服務資訊,相當於是一個Eureka Client
- 增設一個Meta Server的角色主要是為了封裝服務發現的細節,對Portal和Client而言,永遠通過一個Http介面獲取Admin Service和Config Service的服務資訊,而不需要關心背後實際的服務註冊和發現元件
- Meta Server只是一個邏輯角色,在部署時和Config Service是在一個JVM程序中的
1.3.4 Eureka
- 基於Eureka和Spring Cloud Netflix提供服務註冊和發現
- Config Service和Admin Service會向Eureka註冊服務,並保持心跳
- 為了簡單起見,目前Eureka在部署時和Config Service是在一個JVM程序中的(通過Spring Cloud Netflix)
- 提供Web介面供使用者管理配置
- 通過Meta Server獲取Admin Service服務列表(IP+Port),通過IP+Port訪問服務
- 在Portal側做load balance、錯誤重試
- Apollo提供的客戶端程式,為應用提供配置獲取、實時更新等功能
- 通過Meta Server獲取Config Service服務列表(IP+Port),通過IP+Port訪問服務
- 在Client側做load balance、錯誤重試
Apollo目前支援以下環境:
- DEV
- 開發環境
- FAT
- 測試環境,相當於alpha環境(功能測試)
- UAT
- 整合環境,相當於beta環境(迴歸測試)
- PRO
- 生產環境
- Portal部署在生產環境的機房,通過它來直接管理FAT、UAT、PRO等環境的配置
- Meta Server、Config Service和Admin Service在每個環境都單獨部署,使用獨立的資料庫
- Meta Server、Config Service和Admin Service在生產環境部署在兩個機房,實現雙活
- Meta Server和Config Service部署在同一個JVM程序內,Admin Service部署在同一臺伺服器的另一個JVM程序內
10.82.12.136:5601