都什麼年代了，你還在手動配置嗎

轉載本文需註明出處：微信公衆號EAWorld，違者必究。

前言：

隨着程序功能的日益複雜，程序的配置日益增多：各種功能的開關、參數的配置、服務器的地址等等，對程序配置的期望值也越來越高：配置修改後實時生效，灰度發佈，分環境、分集羣管理配置，完善的權限、審覈機制……在這樣的大環境下，傳統的通過配置文件、數據庫等方式已經越來越無法滿足開發人員對配置管理的需求。

1、Apollo介紹

在EOS Platform中，Governor（微服務管理平臺）集成了Apollo作爲配置中心，在介紹之前，我們先來簡單瞭解一下Apollo吧。

Apollo（阿波羅）是攜程框架部門研發的開源配置管理中心，能夠集中化管理應用不同環境、不同集羣的配置，配置修改後能夠實時推送到應用端，並且具備規範的權限、流程治理等特性。服務端基於Spring Boot和Spring Cloud開發，打包後可以直接運行，不需要額外安裝Tomcat等應用容器。Java客戶端不依賴任何框架，能夠運行於所有Java運行時環境，同時對Spring/Spring Boot環境也有較好的支持。

Apollo支持4個維度管理Key-Value格式的配置：

application (應用)：項目的AppId對應Governor系統裏的某個應用，SYS.AppId對應域裏的某個系統
environment (環境)：在Governor中默認填寫DEV，因爲現在的需求只需要用到一個開發環境，不需要設置多環境
cluster (集羣)：在Governor中對應實例組
namespace (命名空間)：在Governor中對應配置組

2、核心概念——Namespace

格式：namespace就相當於Springboot項目中的配置文件，例如namespace中有默認的application，格式爲properties，則對應着application.properties。配置文件有多種格式，例如：properties、xml、yml、yaml、json等。同樣namespace也具有這些格式。
權限：namespace的獲取權限分爲兩種：private和public。
private權限的namespace，只能被所屬的應用獲取到。一個應用嘗試獲取其它應用private的namespace，Apollo會報“404”異常。
public權限的namespace，能被任何應用獲取。
類型：namespace類型有三種：私有類型、公共類型、關聯類型。
私有類型的namespace具有private權限。例如上文提到的“application” Namespace就是私有類型。公共類型的namespace具有public權限。
公共類型的namespace相當於遊離於應用之外的配置，且通過namespace的名稱去標識公共namespace，所以公共的namespace的名稱必須全局唯一。
關聯類型又可稱爲繼承類型，關聯類型具有private權限。關聯類型的namespace繼承於公共類型的namespace，用於覆蓋公共namespace的某些配置。例如公共的namespace有兩個配置項：k1 = v1、k2 = v2，然後應用A有一個關聯類型的namespace關聯了此公共namespace，且覆蓋了配置項k1，新值爲v3。那麼在應用A實際運行時，獲取到的公共namespace的配置爲：k1 = v3、k2 = v2。

3、總體設計

Apollo總體設計

從下往上看：

Config Service 提供配置的讀取、推送等功能，服務端使用Spring DeferredResult實現異步化，從而大大增加長連接數量，服務對象是Apollo客戶端

Admin Service 提供配置的修改、發佈等功能，服務對象是Apollo Portal（管理界面）

Config Service 和 Admin Service 都是多實例、無狀態部署，所以需要將自己註冊到 Eureka 中並保持心跳，也爲了Governor從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進程中

4、Governor如何與Apollo集成

在Governor裏，RuntimeSettings.java是儲存所有域設置的數據庫表的實體類，和其它設置的通用屬性有id、category、type、urls、configJson、name、desc、createdDate、lastModifiedDate、domainId等，這裏我們只關注配置中心，以下屬性是放在configJson這個字段裏的。

除了地址，它們都有固定的值，需要手動填寫，env=DEV，orgId=TEST1，orgName=樣例部門1，username=apollo，password=admin，如下圖：

Apollo的信息存到表裏之後，我們就可以通過拼接url的方式和Apollo進行交互了。所有的url都寫在ApolloService裏，如下圖所示：

接下來以某項目導入配置文件的功能爲例，看看我們應該如何將數據處理併成功導入到Apollo裏進行發佈。

當傳入一份properties文件時，我們通過工具類readProperties()取出裏面的key-value對放在一個map裏(textItems)，再通過配置組id查到一個配置組對象，加上releaseInfo，調用ApplicationConfigService的saveItemKVs方法。這個方法對數據做了最初的處理，爲調用Apollo的接口提供了必要的信息。ApolloIds提供了appId、clusterName、namespaceName等屬性，ApolloConfig提供了env、username、password等屬性，由於ApolloConfig繼承了Config類，所以它還可以獲取到Apollo的地址。getApolloIds和getApolloConfig最終會返回appId、clusterName、namespaceName、url等，因爲我們需要這些信息才能定位到一份具體的配置文件。

在調用createTextItems方法之後，我們傳入的配置文件裏的key-value已經變成了下面的這個Apollo認識的樣子：{"configText":"key-01 = value-01\nkey-02 = value-02\n","namespaceId":73,"format":"properties"}。addId、namespace、cluster等信息也有了，在saveTextItems方法裏將它們拼接在一起，可以向Apollo發請求了。