攜程開源專案——Apollo的設計與實現

Apollo是攜程框架配置部門開源的統一應用配置中心，支援從4個維度管理配置，分別是Appllication（應用）、environment（環境）、Cluster（叢集）、namespace（名稱空間）。

配置是獨立於程式的只讀變數，程式可以通過讀取配置來改變自身的行為，但是不應該去改變配置。配置伴隨著應用的整個生命週期，啟動時讀取配置，執行時根據配置調整行為。配置還可以有多種載入方式，比如程式內部hard code、配置檔案、環境變數，啟動引數、基於資料庫等。

由於配置是可以改變程式的行為的，錯誤的配置就會導致程式的故障，所以對配置的修改和釋出都需要一套完善的許可權管理，另外配置在不同的環境和叢集是存在差別的，這就需要有良好的管理。

Apollo是一個有治理能力的配置管理平臺，它提供了統一管理不同環境、不同叢集的配置，並且配置的修改是實時生效的。每一次配置的修改釋出都會形成新的版本，能夠方便配置出錯時進行回滾。

Apollo支援灰度釋出，對某些重要功能可以事先在多個機器上試執行，沒有問題後再發布。它還提供了許可權管理、釋出稽核、操作審計的功能，並且能夠對客戶端配置資訊進行監控。順帶一提Apollo有著java和.net的原生客戶端，對Spring也有很好的支援。

上圖是Apollo的配置中心介面，左上方是一個環境列表，列出了當前應用的所有環境，下方是一些專案資訊。右側的兩部分可以簡單的認為是兩個檔案，其中Application每個應用都具備，預設的配置管理通過表格形勢展現，可以看到這其中還有更改歷史、修改人之類的資訊以及一些功能按鈕。

Apollo中新增修改配置項可以通過新建或修改配置的按鈕直接操作。需要注意的是修改的配置不會即時生效，而是需要點選發布後才能生效。

可以看到首先我們要獲取config物件，然後呼叫getIntProperty方法並傳入key和預設值，通過這種方式可以獲取到程式的最新值。

而通過上面的程式碼可以讓開發人員實時的獲取到配置的變化，Apollo提供了事件觸發機制，只需要新增一個addChangeListener就行了，每次配置變化的時候會呼叫onChange方法，並且傳入對應配置變化的事件，這個事件包含配置項的改變。

對於Spring整合的簡單用法只需要在AppConfig類上新增EnableApolloConfig。實際的配置中我們還是建議使用下方的方式，它同樣支援配置變化事件。

之前提到過Apollo支援4個維度，在應用維度中，處於執行時狀態下，Apollo可以通過唯一標識的appId來識別應用。環境維度中，我們認為環境資訊與程式碼無關，只跟當前程式碼部署機體有關，所以預設這類資訊存放在機器上。

第三個維度是叢集，它相當於一個應用下不同例項的分組，叢集既可以是物理性的也可以是邏輯性的。對於不同的叢集可以有不一樣的配置，我們預設資料中心作為叢集。

最後的維度namespace（名稱空間）是比較抽象的概念，簡單理解就是一個應用下不同配置的分組，應用預設有自己的配置namespace-application，也可以使用公共元件的配置。

圖中最下方的Config Serivce主要提供配置的讀取、推送等功能，服務物件是客戶端。Admin Service則是提供對配置的修改、釋出、審計這些功能，服務物件是Apollo服務介面。這兩個服務都是多例項無狀態部署。

再往上層的Mate Server主要是用來封裝Eureka服務搭建的介面。在實際的呼叫中，客戶端首先會從Mate Server獲取所關心的服務的地址列表，之後直接通過IP和埠訪問對應介面。

為了實際部署時候的方便，Mate Server、Eureka、Config Service都被部署到一個節點上。

Eureka提供了完整的服務註冊和釋出的實現，並且還能與Spring Cloud無縫整合，通過這樣的整合就可以將本來依賴外部的Eureka變成了內部實現。同時因為Eureka是開源的，所以能夠比較快的去發現問題，瞭解實現原理。

客戶端的執行時和應用是在同一個容器中，應用在啟動時客戶端會做初始化向配置中心拉取配置，獲取到的配置在應用的記憶體和本地檔案分別快取一份。同時客戶端和服務端會保持長連線，以保證能實時的感知到配置的變化。

客戶端發起長連線，服務端預設保持30秒連線，這期間配置發生變化就返回，若一直沒有發生改變服務端就斷開連線，客戶端自動重連。為了保證服務端的長連能力，我們使用了非同步servlet，實現了Spring DeferredResult。

Github地址：https://github.com/ctripcorp/apollo

服務端基於Spring Cloud和Spring Boot開發