由於 Apollo 概念比較多，剛開始使用比較複雜，最好先過一遍概念再動手實踐嘗試使用。
1、背景
隨著程序功能的日益複雜，程序的配置日益增多，各種功能的開關、參數的配置、服務器的地址……對程序配置的期望值也越來越高，配置修改後實時生效，灰度發佈，分環境、分集群管理配置，完善的權限、審核機制…… 在這樣的大環境下，傳統的通過配置文件、數據庫等方式已經越來越無法滿足開發人員對配置管理的需求。因此 Apollo 配置中心應運而生！
2、簡介
Apollo（阿波羅）是攜程框架部門研發的開源配置管理中心，能夠集中化管理應用不同環境、不同集群的配置，配置修改後能夠實時推送到應用端，並且具備規範的權限、流程治理等特性。
3、特點
- 部署簡單
- 灰度發佈
- 版本發佈管理
- 提供開放平臺API
- 客戶端配置信息監控
- 提供Java和.Net原生客戶端
- 配置修改實時生效（熱發佈）
- 權限管理、發佈審核、操作審計
- 統一管理不同環境、不同集群的配置
4、基礎模型
如下即是 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 的某些配置。
6、本地緩存
Apollo客戶端會把從服務端獲取到的配置在本地文件系統緩存一份，用於在遇到服務不可用，或網絡不通的時候，依然能從本地恢復配置，不影響應用正常運行。
本地緩存路徑默認位於以下路徑，所以請確保/opt/data或C:\\opt\\data\\目錄存在，且應用有讀寫權限。
- Mac/Linux： /opt/data/{appId}/config-cache
- Windows： C:\\opt\\data{appId}\\config-cache
本地配置文件會以下面的文件名格式放置於本地緩存路徑下：
<code>1{appId}+{cluster}+{namespace}.properties/<code>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 進程中
9、可用性考慮
配置中心作為基礎服務，可用性要求非常高，下面的表格描述了不同場景下Apollo的可用性：
Apollo 配置中心創建項目與配置
接下來我們將創建一個 Apollo 的客戶端項目，引用 Apollo 來實現配置動態更新，不過在此之前我們需要提前進入 Apollo Portal 界面，在裡面提前創建一個項目並在其配置一個參數，方便後續客戶端引入該配置參數，測試是否能動態變化。
1、登錄 Apollo
我這裡是部署到 Kubernetes 中，通過 NodePort 方式暴露出一個端口，打開這個地址登錄 Apollo：
- 用戶名：apollo
- 密 碼：admin
2、修改與增加部門數據
在登錄後創建項目時，選擇部門默認只能選擇 Apollo 自帶的 測試部門1與測試部門2兩個選項。
開始這真讓人迷糊，原來 Apoloo 沒有修改或新增部門信息的管理節目，只能通過修改數據庫，來新增或者修改數據，這裡打開 Portal 對月的數據庫中的表 ApolloPortalDB 修改 key 為 organizations 的 value 的 json 數據，改成自己對於的部門信息。
3、創建一個項目
修改完數據庫部門信息後，重新登錄 Apollo Portal，然後創建項目，這時候選擇部門可以看到已經變成我們自己修改後的部門信息了，選擇我們自定義部門，然後設置應用 ID 為 apollo-test，應用名為 apollo-demo 。
創建完成後進入配置管理界面
4、創建一個配置參數
創建一個配置參數，方便後續 Apollo 客戶端項目引入該參數，進行動態配置測試。
設置 key 為 test value 為 123456 然後設置一個備註，保存。
創建完成後可以看到配置管理節目新增了一條配置。
接下來我們將此配置通過發佈按鈕，進行發佈。
創建 Apollo 客戶端測試項目
這裡創建一個 SpringBoot 項目，引入 Apollo 客戶端來來實現與 Apollo 配置中心服務端交互。
1、Maven 添加 Apollo 依賴
2、配置文件添加參數
在 application.yml 配置文件中添加下面參數，這裡簡單介紹下 Apollo 參數作用：
- apollo.meta： Apollo 配置中心地址。
- apollo.cluster： 指定使用某個集群下的配置。
- apollo.bootstrap.enabled： 是否開啟 Apollo。
- apollo.bootstrap.namespaces ： 指定使用哪個 Namespace 的配置，默認 application。
- apollo.cacheDir=/opt/data/some-cache-dir： 為了防止配置中心無法連接等問題，Apollo 會自動將配置本地緩存一份。
- apollo.autoUpdateInjectedSpringProperties： Spring應用通常會使用 Placeholder 來注入配置，如${someKey:someDefaultValue}，冒號前面的是 key，冒號後面的是默認值。如果想關閉 placeholder 在運行時自動更新功能，可以設置為 false。
- apollo.bootstrap.eagerLoad.enabled ： 將 Apollo 加載提到初始化日誌系統之前，如果設置為 false，那麼將打印出 Apollo 的日誌信息，但是由於打印 Apollo 日誌信息需要日誌先啟動，啟動後無法對日誌配置進行修改，所以 Apollo 不能管理應用的日誌配置，如果設置為 true，那麼 Apollo 可以管理日誌的配置，但是不能打印出 Apollo 的日誌信息。
3、創建測試 Controller 類
寫一個 Controller 類來輸出 test 變量的值，使用了 Spring 的 @Value 註解，用於讀取配置文件中的變量的值，這裡來測試該值，項目啟動後讀取到的變量的值是設置在 application 配置文件中的默認值，還是遠程 Apollo 中的值，如果是 Apollo 中配置的值，那麼再測試在 Apollo 配置中心中改變該變量的值後，這裡是否會產生變化。
4、創建啟動類
SpringBoot 項目啟動類。
5、JVM 啟動參數添加啟動參數
由於本人的 Apollo 是部署在 Kubernetes 環境中的，JVM 參數中必須添加兩個變量：
- env： 應用使用 Apollo 哪個環境，例如設置為 DEV 就是指定使用開發環境，如果設置為 PRO 就是制定使用生產環境。
- apollo.configService： 指定配置中心的地址，跳過 meta 的配置，在測試時指定 meta 地址無效果。如果 Apollo 是部署在 Kubernetes 中，則必須設置該參數為配置中心地址，如果 Apollo 不是在 Kubernetes 環境中，可以不設置此參數，只設置 meta 參數即可。一般情況下，configService 和 meta 值一致。
如果是在 Idea 中啟動，可以配置啟動參數，加上：
<code>1-Dapollo.configService=http://192.168.2.11:30002 -Denv=DEV/<code>
如果是 java 命令啟動程序，需要 JVM 加上:
<code>1$ java -Dapollo.configService=http://192.168.2.11:30002 -Denv=DEV -jar apollo-demo.jar/<code>
注意：上面 env 指定的環境，要和 apollo.meta 指定 Config 地址的環境一致，例如 -Denv=DEV 即使用開發環境，那麼 apollo.meta=http://xxx.xxx.xxx:8080 這個url 的 Config 也是開發環境下的配置中心服務，而不能是 PRO 或者其它環境下的配置中心。
啟動項目進行測試
1、測試是否能夠獲取 Apollo 中設置的值
啟動上面的測試用例，然後輸入地址 http://localhost:8080/test 查看：
<code>1test的值為:123456/<code>
可以看到使用的是 Apollo 中配置的 test 參數的值 123456，而不是默認的值。
2、測試當 Apollo 中修改參數值後客戶端是否能及時刷新
修改 Apollo 配置中心參數 test 值為 666666 ，然後再次發佈。
發佈完成後再次輸入地址 http://localhost:8080/test 查看：
<code>1test的值為:666666/<code>
可以看到示例應用中的值已經改變為最新的值。
3、測試當 Apollo 執行配置回滾操作時客戶端是否能及時改變
回滾完成後狀態將變為未發佈狀態，則時候輸入地址 http://localhost:8080/test 查看：
<code>1test的值為:123456/<code>
可以看到已經回滾到之前的 test 配置的值了。
4、測試當不能訪問 Apollo 時客戶端的變化
這裡我們將 JVM 參數中 Apollo 配置中心地址故意改錯：
<code>1-Dapollo.configService=http://192.168.2.100:30002 -Denv=DEV/<code>
然後輸入地址 http://localhost:8080/test 可以看到值為：
<code>1test的值為:123456/<code>
可以看到顯示的值並不是我們定義的默認值，而還是 Apollo 配置中心配置的 test 參數的值。考慮到由於 Apollo 會在本地將配置緩存一份，出現上面原因，估計是緩存生效。當客戶端不能連接到 Apollo 配置中心時候，默認使用本地緩存文件中的配置。
上面我們配置了本地緩存配置文件存放地址為 “/opt/data/” ，接下來進入緩存目錄，找到對應的緩存配置文件，刪除緩存配置文件後，重啟應用，再次輸入地址查看：
<code>1test的值為:默認值/<code>
刪除緩存配置文件後，可以看到輸出的值為自己定義的默認值。
5、測試當 Apollo 中將參數刪除後客戶端的變化
這裡我們進入 Apollo 配置中心，刪除之前創建的 test 參數，然後發佈。
然後再次打開地址 http://localhost:8080/test 查看：
<code>1test的值為:默認值/<code>
可以看到顯示的是應用程序中設置的默認值。
對 Apollo 的 Cluster、Namespace 進行探究
在 Apollo 中，配置可以根據不同的環境劃分為 Dev（開發）、Prod（生產） 等環境，又能根據區域劃分為不同的 Cluster（集群），還能根據配置參數作用功能的不同劃分為不同的 Namespace（命名空間），這裡探究下，如何使用上述能力。
1、不同環境下的配置
（1）、Apollo 配置中心 PRO 環境添加參數
打開 Apollo 配置中心，環境列表點擊 PRO 環境，然後新增一條配置，和之前例子中參數保持一致，都為 test 參數，創建完成後發佈。
然後修改上面的示例項目，將配置參數指定為 PRO 環境:
（2）、示例項目修改 application.yml 配置文件
把 apollo.meta 參數改成 RPO 的配置中心地址
<code>1......
2
3apollo:
4 meta: http://192.168.2.11:30005 #RPO環境配置中心地址
5
6....../<code>
（3）、示例項目修改 JVM 參數
把 apollo.configService 參數改成 PRO 配置中心地址，env 參數的值改為 PRO。
<code>1-Dapollo.configService=http://192.168.2.11:30005 -Denv=PRO/<code>
（4）、啟動示例項目觀察結果
啟動示例項目，然後接著輸入地址 http://localhost:8080/test 查看信息：
<code>1test的值為:abcdefg/<code>
可以看到已經改成生成環境配置，所以在實際項目中，如果要更換環境，需要修改 JVM 參數 env（如果 Apollo 部署在 Kubernetes 環境中，還需要修改 apollo.configService 參數），和修改 application.yml 配置文件的參數 apollo.meta 值。
2、不同集群下的配置
（1）、創建兩個集群
例如在開發過程中，經常要將應用部署到不同的機房，這裡分別創建 beijing、shanghai 兩個集群。
（2）、兩個集群都配置同樣的參數不同的值
在兩個集群 beijing 與 shanghai 中，都統一配置參數 test，並且設置不同的值。
（3）、示例項目 application.yml 修改集群配置參數,並啟動項目觀察結果
指定集群為 beijing:
<code>1......
2
3apollo:
4 cluster: beijing #指定使用 beijing 集群
5
6....../<code>
啟動示例項目，然後接著輸入地址 http://localhost:8080/test 查看信息：
<code>1test的值為:Cluster-BeiJing/<code>
可以看到用的是 beijing 集群的配置
指定集群為 shanghai:
<code>1......
2
3apollo:
4 cluster: shanghai #指定使用 shanghai 集群
5
6....../<code>
啟動示例項目，然後接著輸入地址 http://localhost:8080/test 查看信息：
<code>1test的值為:Cluster-ShangHai/<code>
可以看到用的是 shanghai 集群的配置
3、不同命名空間下的配置
（1）、創建兩個命名空間
命名空間有兩種，一種是 public（公開），一種是 private 私有，公開命名空間所有項目都能讀取配置信息，而私有的只能 app.id 值屬於該應用的才能讀取配置。
這裡創建 dev-1 與 dev-2 兩個私有的命名空間，用於測試。
（2）、兩個集群都配置同樣的參數不同的值
在兩個命名空間中，都統一配置參數 test，並且設置不同的值，設置完後發佈。
（3）、示例項目 application.yml 修改命名空間配置參數,並啟動項目觀察結果
指定命名空間為 dev-1:
<code>1......
2
3apollo:
4 bootstrap:
5 namespaces: dev-1 #設置 dev-1 命名空間
6
7....../<code>
啟動示例項目，然後接著輸入地址 http://localhost:8080/test 查看信息：
<code>1test的值為:dev-1 Namespace/<code>
可以看到用的是 dev-1 命名空間的配置
指定命名空間為 dev-2:
<code>1......
2
3apollo:
4 bootstrap:
5 namespaces: dev-2 #設置 dev-1 命名空間
6
7....../<code>
啟動示例項目，然後接著輸入地址 http://localhost:8080/test 查看信息：
<code>1test的值為:dev-2 Namespace/<code>
可以看到用的是 dev-2 命名空間的配置
Kubernetes 的 SpringBoot 應用使用 Apollo 配置中心
本人的 Apollo 和 SpringBoot 應用一般都是基於 Kubernetes 部署的，所以這裡簡單介紹下，如何在 Kubernetes 環境下部署 SpringBoot 應用且使用 Apollo 作為配置中心。
這裡項目依舊使用上面的示例，不過首先要將其編譯成 Docker 鏡像，方便後續部署到 Kubernetes 環境下。
1、構建 Docker 鏡像
（1）、執行 Maven 編譯
首先執行 Maven 命令，將項目編譯成一個可執行 JAR。
<code>1$ mvn clean install/<code>
（2）、準備 Dockerfile
創建構建 Docker 鏡像需要的 Dockerfile 文件，將 Maven 編譯的 JAR 複製到鏡像內部，然後設置兩個變量，分別是：
- JAVA_OPTS： Java JVM 啟動參數變量，這裡需要在這裡加一個時區參數。
- APP_OPTS： Spring 容器啟動參數變量，方便後續操作時能通過此變量配置 Spring 參數。
Dockerfile：
<code>1FROM openjdk:8u222-jre-slim
2VOLUME /tmp
3ADD target/*.jar app.jar
4RUN sh -c 'touch /app.jar'
5ENV JAVA_OPTS="-Duser.timezone=Asia/Shanghai"
6ENV APP_OPTS=""
7ENTRYPOINT [ "sh", "-c", "java $JAVA_OPTS -Djava.security.egd=file:/dev/./urandom -jar /app.jar $APP_OPTS" ]/<code>
（3）、構建 Docker 鏡像
執行 Docker Build 命令構建 Docker 鏡像。
<code>1$ docker build -t mydlqclub/springboot-apollo:0.0.1 ./<code>
2、Kubernetes 部署示例應用
（1）、創建 SpringBoot 且使用 Apollo 配置中心的 Kubernetes 部署文件
這裡創建 Kubernetes 下的 SpringBoot 部署文件 apollo-demo-example.yaml。在之前 Dockerfile 中設置了兩個環境變量，JAVA_OPTS 與 APP_OPTS。其中 JAVA_OPTS 變量的值將會作為 JVM 啟動參數，APP_OPTS 變量的值將會作為應用的配置參數。所以，這裡我們將 Apollo 配置參數放置到變量中，這樣一來就可以方便修改與維護 Apollo 的配置信息。
在下面配置的環境變量參數中，設置的配置中心地址為 http://service-apollo-config-server-dev.mydlqclub:8080，這是因為 Apollo 部署在 K8S 環境中，且可以使用域名方式訪問，service-apollo-config-server-dev 是應用的 Service 名稱，mydlqcloud 是 K8S 下的 Namespace 名稱。
springboot-apollo.yaml
<code> 1apiVersion: v1
2kind: Service
3metadata:
4 name: springboot-apollo
5spec:
6 type: NodePort
7 ports:
8 - name: server
9 nodePort: 31080
10 port: 8080
11 targetPort: 8080
12 - name: management
13 nodePort: 31081
14 port: 8081
15 targetPort: 8081
16 selector:
17 app: springboot-apollo
18---
19apiVersion: apps/v1
20kind: Deployment
21metadata:
22 name: springboot-apollo
23 labels:
24 app: springboot-apollo
25spec:
26 replicas: 1
27 selector:
28 matchLabels:
29 app: springboot-apollo
30 template:
31 metadata:
32 name: springboot-apollo
33 labels:
34 app: springboot-apollo
35 spec:
36 restartPolicy: Always
37 containers:
38 - name: springboot-apollo
39 image: mydlqclub/springboot-apollo:0.0.1
40 imagePullPolicy: Always
41 ports:
42 - containerPort: 8080
43 name: server
44 env:
45 - name: JAVA_OPTS
46 value: "-Denv=DEV"
47 ##注意修改此處的 mydlqcloud 為你自己的 Namespace 名稱
48 - name: APP_OPTS
49 value: "
50 --app.id=apollo-demo
51 --apollo.bootstrap.enabled=true
52 --apollo.bootstrap.eagerLoad.enabled=false
53 --apollo.cacheDir=/opt/data/
54 --apollo.cluster=default
55 --apollo.bootstrap.namespaces=application
56 --apollo.autoUpdateInjectedSpringProperties=true
57 --apollo.meta=http://service-apollo-config-server-dev.mydlqcloud:8080
58 "
59 resources:
60 limits:
61 memory: 1000Mi
62 cpu: 1000m
63 requests:
64 memory: 500Mi
65 cpu: 500m/<code>
（2）、部署 SpringBoot 應用到 Kubernetes
-n：創建應用到指定的 Namespace 中。
<code>1$ kubectl apply -f springboot-apollo.yaml -n mydlqcloud/<code>
3、測試部署的應用接口
上面的應用配置了 NodePort 端口，可以通過此端口訪問 Kubernetes 集群內的應用接口，本人 Kubernetes 集群地址為 192.168.2.11 且 NodePort 端口為 31081，所以瀏覽器訪問地址 http://192.168.2.11:31081/test 來測試接口，顯示：
<code>1test的值為:123456/<code>
可以看到能通過 Apollo 獲取參數值，此文章到此結束。
閱讀更多 java互聯網架構 的文章
