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客戶端獲取最新的配置、訂閱配置更新通知

4.6.1 配置更新推送實現

前面提到了Apollo客戶端和服務端保持了一個長連線，從而能第一時間獲得配置更新的推送。

長連線實際上我們是通過Http Long Polling實現的，具體而言：

·        客戶端發起一個Http請求到服務端

·        服務端會保持住這個連線30秒

·        如果在30秒內有客戶端關心的配置變化，被保持住的客戶端請求會立即返回，並告知客戶端有配置變化的namespace資訊，客戶端會據此拉取對應namespace的最新配置

·        如果在30秒內沒有客戶端關心的配置變化，那麼會返回Http狀態碼304給客戶端

·        客戶端在服務端請求返回後會自動重連

考慮到會有數萬客戶端向服務端發起長連，在服務端我們使用了async servlet(Spring DeferredResult)來服務HttpLong Polling請求。

4.7 可用性考慮

配置中心作為基礎服務，可用性要求非常高，下面的表格描述了不同場景下Apollo的可用性：

1.3.2 Admin Service

• 提供配置管理介面
• 提供配置修改、釋出等介面
• 介面服務物件為Portal

1.3.3 Meta Server

• 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）

1.3.5 Portal

• 提供Web介面供使用者管理配置
• 通過Meta Server獲取Admin Service服務列表（IP+Port），通過IP+Port訪問服務
• 在Portal側做load balance、錯誤重試

1.3.6 Client

• Apollo提供的客戶端程式，為應用提供配置獲取、實時更新等功能
• 通過Meta Server獲取Config Service服務列表（IP+Port），通過IP+Port訪問服務
• 在Client側做load balance、錯誤重試

https://github.com/ctripcorp/apollo/wiki/%E5%88%86%E5%B8%83%E5%BC%8F%E9%83%A8%E7%BD%B2%E6%8C%87%E5%8D%97

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