我們放棄了Nacos作為配置中心，轉而選擇了這款神器~

轉自：網路

目前，我們所有微服務的配置中心都沒有采用Nacos，而是選擇了另一款攜程開源的分散式配置中心Apollo，今天就跟大家詳細介紹一下這款神級配置中心

1. 基本概念

由於 Apollo 概念比較多，剛開始使用比較複雜，最好先過一遍概念再動手實踐嘗試使用。

1.1、背景

隨著程式功能的日益複雜，程式的配置日益增多，各種功能的開關、引數的配置、伺服器的地址……對程式配置的期望值也越來越高，配置修改後即時生效，灰度釋出，分環境、分叢集管理配置，完善的許可權、稽核機制…… 在這樣的大環境下，傳統的透過配置檔案、資料庫等方式已經越來越無法滿足開發人員對配置管理的需求。因此 Apollo 配置中心應運而生！

1.2、簡介

Apollo（阿波羅）是攜程框架部門研發的開源配置管理中心，能夠集中化管理應用不同環境、不同叢集的配置，配置修改後能夠即時推送到應用端，並且具備規範的許可權、流程治理等特性。

1.3、特點

部署簡單
灰度釋出
版本釋出管理
提供開放平臺API
客戶端配置資訊監控
提供Java和.Net原生客戶端
配置修改即時生效（熱釋出）
許可權管理、釋出稽核、操作審計
統一管理不同環境、不同叢集的配置

1.4、基礎模型

如下即是 Apollo 的基礎模型：

(1)、使用者在配置中心對配置進行修改併發布
(2)、配置中心通知Apollo客戶端有配置更新
(3)、Apollo客戶端從配置中心拉取最新的配置、更新本地配置並通知到應用

1.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 的某些配置。

1.6、本地快取

Apollo客戶端會把從服務端獲取到的配置在本地檔案系統快取一份，用於在遇到服務不可用，或網路不通的時候，依然能從本地恢復配置，不影響應用正常執行。

本地快取路徑預設位於以下路徑，所以請確保/opt/data或C:\opt\data\目錄存在，且應用有讀寫許可權。

Mac/Linux： /opt/data/{appId}/config-cache
Windows： C:\opt\data{appId}\config-cache

本地配置檔案會以下面的檔名格式放置於本地快取路徑下：

{appId}+{cluster}+{namespace}.properties

1.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 請求。

1.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 程序中

1.9、可用性考慮

配置中心作為基礎服務，可用性要求非常高，下面的表格描述了不同場景下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 自動切換到其它存活的資料中心

2. Apollo 配置中心建立專案與配置

接下來我們將建立一個 Apollo 的客戶端專案，引用 Apollo 來實現配置動態更新，不過在此之前我們需要提前進入 Apollo Portal 介面，在裡面提前建立一個專案並在其配置一個引數，方便後續客戶端引入該配置引數，測試是否能動態變化。

2.1、登入 Apollo

我這裡是部署到 Kubernetes 中，透過 NodePort 方式暴露出一個埠，開啟這個地址登入 Apollo：

使用者名稱：apollo
密碼：admin

2.2、修改與增加部門資料

在登入後建立專案時，選擇部門預設只能選擇 Apollo 自帶的測試部門1與測試部門2兩個選項。

開始這真讓人迷糊，原來 Apoloo 沒有修改或新增部門資訊的管理節目，只能透過修改資料庫，來新增或者修改資料，這裡開啟 Portal 對月的資料庫中的表 ApolloPortalDB 修改 key 為 organizations 的 value 的 json 資料，改成自己對於的部門資訊。

2.3、建立一個專案

修改完資料庫部門資訊後，重新登入 Apollo Portal，然後建立專案，這時候選擇部門可以看到已經變成我們自己修改後的部門資訊了，選擇我們自定義部門，然後設定應用 ID 為 apollo-test，應用名為 apollo-demo 。

建立完成後進入配置管理介面

2.4、建立一個配置引數

建立一個配置引數，方便後續 Apollo 客戶端專案引入該引數，進行動態配置測試。

設定 key 為 test value 為 123456 然後設定一個備註，儲存。

建立完成後可以看到配置管理節目新增了一條配置。

接下來我們將此配置透過釋出按鈕，進行釋出。

3. 建立 Apollo 客戶端測試專案

這裡建立一個 SpringBoot 專案，引入 Apollo 客戶端來來實現與 Apollo 配置中心服務端互動。

3.1、Mavne 新增 Apollo 依賴

<?xml version="1.0" encoding="UTF-8"?><projectxmlns="http://maven.apache.org/POM/4.0.0"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"><modelVersion>4.0.0</modelVersion><parent><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-parent</artifactId><version>2.1.8.RELEASE</version></parent><groupId>club.mydlq</groupId><artifactId>apollo-demo</artifactId><version>0.0.1</version><name>apollo-demo</name><description>Apollo Demo</description><properties><java.version>1.8</java.version></properties><dependencies><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-web</artifactId></dependency><dependency><groupId>com.ctrip.framework.apollo</groupId><artifactId>apollo-client</artifactId><version>1.4.0</version></dependency></dependencies><build><plugins><plugin><groupId>org.springframework.boot</groupId><artifactId>spring-boot-maven-plugin</artifactId></plugin></plugins></build></project>

3.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 的日誌資訊。

#應用配置server:  port: 8080spring:  application:    name: apollo-demo#Apollo 配置app:  id: apollo-test                            #應用IDapollo:  cacheDir: /opt/data/                       #配置本地配置快取目錄  cluster: default                           #指定使用哪個叢集的配置  meta: http://192.168.2.11:30002            #DEV環境配置中心地址  autoUpdateInjectedSpringProperties: true   #是否開啟 Spring 引數自動更新  bootstrap:                                    enabled: true                            #是否開啟 Apollo    namespaces: application                  #設定 Namespace    eagerLoad:      enabled: false                         #將 Apollo 載入提到初始化日誌系統之前

3.3、建立測試 Controller 類

寫一個 Controller 類來輸出 test 變數的值，使用了 Spring 的 @Value 註解，用於讀取配置檔案中的變數的值，這裡來測試該值，專案啟動後讀取到的變數的值是設定在 application 配置檔案中的預設值，還是遠端 Apollo 中的值，如果是 Apollo 中配置的值，那麼再測試在 Apollo 配置中心中改變該變數的值後，這裡是否會產生變化。

@RestControllerpublicclassTestController{@Value("${test:預設值}")private String test;@GetMapping("/test")public String test(){return"test的值為:" + test;    }}

3.4、建立啟動類

SpringBoot 專案啟動類。

@SpringBootApplicationpublicclassApplication{publicstaticvoidmain(String[] args){        SpringApplication.run(Application.class, args);    }}

3.5、JVM 啟動引數新增啟動引數

由於本人的 Apollo 是部署在 Kubernetes 環境中的，JVM 引數中必須新增兩個變數：

env： 應用使用 Apollo 哪個環境，例如設定為 DEV 就是指定使用開發環境，如果設定為 PRO 就是制定使用生產環境。
apollo.configService： 指定配置中心的地址，跳過 meta 的配置，在測試時指定 meta 地址無效果。如果 Apollo 是部署在 Kubernetes 中，則必須設定該引數為配置中心地址，如果 Apollo 不是在 Kubernetes 環境中，可以不設定此引數，只設置 meta 引數即可。一般情況下，configService 和 meta 值一致。

如果是在 Idea 中啟動，可以配置啟動引數，加上：

-Dapollo.configService=http://192.168.2.11:30002 -Denv=DEV

如果是 java 命令啟動程式，需要 JVM 加上:

$ java -Dapollo.configService=http://192.168.2.11:30002 -Denv=DEV -jar apollo-demo.jar

“

注意：上面 env 指定的環境，要和 apollo.meta 指定 Config 地址的環境一致，例如 -Denv=DEV 即使用開發環境，那麼 apollo.meta=http://xxx.xxx.xxx:8080 這個url 的 Config 也是開發環境下的配置中心服務，而不能是 PRO 或者其它環境下的配置中心。

4. 啟動專案進行測試

4.1、測試是否能夠獲取 Apollo 中設定的值

啟動上面的測試用例，然後輸入地址 http://localhost:8080/test 檢視：

test的值為:123456

可以看到使用的是 Apollo 中配置的 test 引數的值 123456，而不是預設的值。

4.2、測試當 Apollo 中修改引數值後客戶端是否能及時重新整理

修改 Apollo 配置中心引數 test 值為 666666 ，然後再次釋出。

釋出完成後再次輸入地址 http://localhost:8080/test 檢視：

test的值為:666666

可以看到示例應用中的值已經改變為最新的值。

4.3、測試當 Apollo 執行配置回滾操作時客戶端是否能及時改變

回滾完成後狀態將變為未釋出狀態，則時候輸入地址 http://localhost:8080/test 檢視：

test的值為:123456

可以看到已經回滾到之前的 test 配置的值了。

4.4、測試當不能訪問 Apollo 時客戶端的變化

這裡我們將 JVM 引數中 Apollo 配置中心地址故意改錯：

-Dapollo.configService=http://192.168.2.100:30002 -Denv=DEV

然後輸入地址 http://localhost:8080/test 可以看到值為：

test的值為:123456

可以看到顯示的值並不是我們定義的預設值，而還是 Apollo 配置中心配置的 test 引數的值。考慮到由於 Apollo 會在本地將配置快取一份，出現上面原因，估計是快取生效。當客戶端不能連線到 Apollo 配置中心時候，預設使用本地快取檔案中的配置。

上面我們配置了本地快取配置檔案存放地址為 "/opt/data/" ，接下來進入快取目錄，找到對應的快取配置檔案，刪除快取配置檔案後，重啟應用，再次輸入地址檢視：

test的值為:預設值

刪除快取配置檔案後，可以看到輸出的值為自己定義的預設值。

4.5、測試當 Apollo 中將引數刪除後客戶端的變化

這裡我們進入 Apollo 配置中心，刪除之前建立的 test 引數，然後釋出。

然後再次開啟地址 http://localhost:8080/test 檢視：

test的值為:預設值

可以看到顯示的是應用程式中設定的預設值。

5. 對 Apollo 的 Cluster、Namespace 進行探究

在 Apollo 中，配置可以根據不同的環境劃分為 Dev（開發）、Prod（生產）等環境，又能根據區域劃分為不同的 Cluster（叢集），還能根據配置引數作用功能的不同劃分為不同的 Namespace（名稱空間），這裡探究下，如何使用上述能力。

5.1、不同環境下的配置

（1）、Apollo 配置中心 PRO 環境新增引數

開啟 Apollo 配置中心，環境列表點選 PRO 環境，然後新增一條配置，和之前例子中引數保持一致，都為 test 引數，建立完成後釋出。

然後修改上面的示例專案，將配置引數指定為 PRO 環境:

（2）、示例專案修改 application.yml 配置檔案

把 apollo.meta 引數改成 RPO 的配置中心地址

......apollo: meta: http://192.168.2.11:30005 #RPO環境配置中心地址......

（3）、示例專案修改 JVM 引數

把 apollo.configService 引數改成 PRO 配置中心地址，env 引數的值改為 PRO。

-Dapollo.configService=http://192.168.2.11:30005 -Denv=PRO

（4）、啟動示例專案觀察結果

啟動示例專案，然後接著輸入地址 http://localhost:8080/test 檢視資訊：

test的值為:abcdefg

可以看到已經改成生成環境配置，所以在實際專案中，如果要更換環境，需要修改 JVM 引數 env（如果 Apollo 部署在 Kubernetes 環境中，還需要修改 apollo.configService 引數），和修改 application.yml 配置檔案的引數 apollo.meta 值。

5.2、不同叢集下的配置

（1）、建立兩個叢集

例如在開發過程中，經常要將應用部署到不同的機房，這裡分別建立 beijing、shanghai 兩個叢集。

（2）、兩個叢集都配置同樣的引數不同的值

在兩個叢集 beijing 與 shanghai 中，都統一配置引數 test，並且設定不同的值。

（3）、示例專案 application.yml 修改叢集配置引數,並啟動專案觀察結果

指定叢集為 beijing:

......apollo: cluster: beijing #指定使用 beijing 叢集......

啟動示例專案，然後接著輸入地址 http://localhost:8080/test 檢視資訊：

test的值為:Cluster-BeiJing

可以看到用的是 beijing 叢集的配置

指定叢集為 shanghai:

......apollo: cluster: shanghai #指定使用 shanghai 叢集......

啟動示例專案，然後接著輸入地址 http://localhost:8080/test 檢視資訊：

test的值為:Cluster-ShangHai

可以看到用的是 shanghai 叢集的配置

5.3、不同名稱空間下的配置

（1）、建立兩個名稱空間

名稱空間有兩種，一種是 public（公開），一種是 private 私有，公開名稱空間所有專案都能讀取配置資訊，而私有的只能 app.id 值屬於該應用的才能讀取配置。

這裡建立 dev-1 與 dev-2 兩個私有的名稱空間，用於測試。

（2）、兩個叢集都配置同樣的引數不同的值

在兩個名稱空間中，都統一配置引數 test，並且設定不同的值，設定完後釋出。

（3）、示例專案 application.yml 修改名稱空間配置引數,並啟動專案觀察結果

指定名稱空間為 dev-1:

......apollo: bootstrap: namespaces: dev-1 #設定 dev-1 名稱空間......

啟動示例專案，然後接著輸入地址 http://localhost:8080/test 檢視資訊：

test的值為:dev-1 Namespace

可以看到用的是 dev-1 名稱空間的配置

指定名稱空間為 dev-2:

......apollo: bootstrap: namespaces: dev-2 #設定 dev-1 名稱空間......

YAML

啟動示例專案，然後接著輸入地址 http://localhost:8080/test 檢視資訊：

test的值為:dev-2 Namespace

HTML

可以看到用的是 dev-2 名稱空間的配置

6. Kubernetes 的 SpringBoot 應用使用 Apollo 配置中心

本人的 Apollo 和 SpringBoot 應用一般都是基於 Kubernetes 部署的，所以這裡簡單介紹下，如何在 Kubernetes 環境下部署 SpringBoot 應用且使用 Apollo 作為配置中心。

這裡專案依舊使用上面的示例，不過首先要將其編譯成 Docker 映象，方便後續部署到 Kubernetes 環境下。

6.1、構建 Docker 映象

（1）、執行 Maven 編譯

首先執行 Maven 命令，將專案編譯成一個可執行 JAR。

$ mvn clean install

BASH

（2）、準備 Dockerfile

建立構建 Docker 映象需要的 Dockerfile 檔案，將 Maven 編譯的 JAR 複製到映象內部，然後設定兩個變數，分別是：

JAVA_OPTS： Java JVM 啟動引數變數，這裡需要在這裡加一個時區引數。
APP_OPTS： Spring 容器啟動引數變數，方便後續操作時能透過此變數配置 Spring 引數。

Dockerfile：

FROM openjdk:8u222-jre-slimVOLUME /tmpADD target/*.jar app.jarRUN sh -c 'touch /app.jar'ENV JAVA_OPTS="-XX:MaxRAMPercentage=80.0 -Duser.timezone=Asia/Shanghai"ENV APP_OPTS=""ENTRYPOINT [ "sh", "-c", "java $JAVA_OPTS -Djava.security.egd=file:/dev/./urandom -jar /app.jar $APP_OPTS" ]

（3）、構建 Docker 映象

執行 Docker Build 命令構建 Docker 映象。

$ docker build -t mydlqclub/springboot-apollo:0.0.1 .

BASH

6.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

apiVersion: v1kind: Servicemetadata:  name: springboot-apollospec:  type: NodePort  ports:    - name: server      nodePort: 31080      port: 8080      targetPort: 8080    - name: management      nodePort: 31081      port: 8081      targetPort: 8081  selector:    app: springboot-apollo---apiVersion: apps/v1kind: Deploymentmetadata:  name: springboot-apollo  labels:    app: springboot-apollospec:  replicas: 1  selector:    matchLabels:      app: springboot-apollo  template:    metadata:      name: springboot-apollo      labels:        app: springboot-apollo    spec:      restartPolicy: Always      containers:        - name: springboot-apollo          image: mydlqclub/springboot-apollo:0.0.1          imagePullPolicy: Always          ports:            - containerPort: 8080              name: server          env:            - name: JAVA_OPTS              value: "-Denv=DEV"              ##注意修改此處的 mydlqcloud 為你自己的 Namespace 名稱            - name: APP_OPTS              value: "                     --app.id=apollo-demo                     --apollo.bootstrap.enabled=true                     --apollo.bootstrap.eagerLoad.enabled=false                     --apollo.cacheDir=/opt/data/                     --apollo.cluster=default                     --apollo.bootstrap.namespaces=application                     --apollo.autoUpdateInjectedSpringProperties=true                     --apollo.meta=http://service-apollo-config-server-dev.mydlqcloud:8080                         "          resources:            limits:              memory: 1000Mi              cpu: 1000m            requests:              memory: 500Mi              cpu: 500m

（2）、部署 SpringBoot 應用到 Kubernetes

-n：建立應用到指定的 Namespace 中。

$ kubectl apply -f springboot-apollo.yaml -n mydlqcloud

BASH

6.3、測試部署的應用介面

上面的應用配置了 NodePort 埠，可以透過此埠訪問 Kubernetes 叢集內的應用介面，本人 Kubernetes 叢集地址為 192.168.2.11 且 NodePort 埠為 31081，所以瀏覽器訪問地址 http://192.168.2.11:31081/test 來測試介面，顯示：

test的值為:123456

可以看到能透過 Apollo 獲取引數值，此文章到此結束。

END

官方站點：www.linuxprobe.com

Linux命令大全：www.linuxcool.com