開源配置管理中心apollo使用方法

什么是apollo

Apollo（阿波羅）是一款可靠的分布式配置管理中心，誕生于攜程框架研發部，能夠集中化管理應用不同環境、不同集群的配置，配置修改后能夠實時推送到應用端，并且具備規范的權限、流程治理等特性，適用于微服務配置管理場景。

應用什么場景

項目在不同環境對應的不同的配置，統一管理不同環境、不同集群的配置

Apollo提供了一個統一界面集中式管理不同環境（environment）、不同集群（cluster）、不同命名空間（namespace）的配置。
同一份代碼部署在不同的集群，可以有不同的配置，比如zk的地址等
通過命名空間（namespace）可以很方便的支持多個不同應用共享同一份配置，同時還允許應用對共享的配置進行覆蓋

系統介紹

系統Centos7

java環境	java1.8
數據庫	MariaDB-10.2.9
IP	192.168.1.8

使用文檔

名詞解釋

普通應用
普通應用指的是獨立運行的程序，如Web應用程序、帶有main函數的程序

公共組件
公共組件指的是發布的類庫、客戶端程序，不會自己獨立運行，如Java的jar包、.Net的dll文件

普通應用接入指南

創建項目

要使用Apollo，第一步需要創建項目。

打開apollo-portal主頁

點擊“創建項目”

輸入項目信息

• 部門：選擇應用所在的部門
• 應用AppId：用來標識應用身份的唯一id，格式為string，需要和客戶端app.properties中配置的app.id對應
• 應用名稱：應用名，僅用于界面展示
• 應用負責人：選擇的人默認會成為該項目的管理員，具備項目權限管理、集群創建、Namespace創建等權限

點擊提交

創建成功后，會自動跳轉到項目首頁

項目權限分配

項目管理員權限

項目管理員擁有以下權限：

可以管理項目的權限分配

可以創建集群

可以創建Namespace

創建項目時填寫的應用負責人默認會成為項目的管理員之一，如果還需要其他人也成為項目管理員，可以按照下面步驟操作：

點擊頁面左側的“管理項目”

搜索需要添加的成員并點擊添加

配置編輯、發布權限

配置權限分為編輯和發布：

• 編輯權限允許用戶在Apollo界面上創建、修改、刪除配置
  • 配置修改后只在Apollo界面上變化，不會影響到應用實際使用的配置
• 發布權限允許用戶在Apollo界面上發布、回滾配置
  • 配置只有在發布、回滾動作后才會被應用實際使用到
  • Apollo在用戶操作發布、回滾動作后實時通知到應用，并使最新配置生效

項目創建完，默認沒有分配配置的編輯和發布權限，需要項目管理員進行授權。

點擊application這個namespace的授權按鈕

分配修改權限

分配發布權限

添加配置項

編輯配置需要擁有這個Namespace的編輯權限，如果發現沒有新增配置按鈕，可以找項目管理員授權。

通過表格模式添加配置

點擊新增配置

輸入配置項

點擊提交

通過文本模式編輯

Apollo除了支持表格模式，逐個添加、修改配置外，還提供文本模式批量添加、修改。 這個對于從已有的properties文件遷移尤其有用。

切換到文本編輯模式

點擊右側的修改配置按鈕

輸入配置項，并點擊提交修改

發布配置

配置只有在發布后才會真的被應用使用到，所以在編輯完配置后，需要發布配置。

發布配置需要擁有這個Namespace的發布權限，如果發現沒有發布按鈕，可以找項目管理員授權。

點擊“發布按鈕”

填寫發布相關信息，點擊發布

應用讀取配置

配置發布成功后，應用就可以通過Apollo客戶端讀取到配置了。

Apollo目前提供Java客戶端，具體信息請點擊Java客戶端使用文檔：

如果應用使用了其它語言，也可以通過直接訪問Http接口獲取配置，具體可以參考其它語言客戶端接入指南

應用接入Apollo

首先需要在Apollo中接入你的應用，具體步驟可以參考應用接入文檔。

通過帶緩存的Http接口從Apollo讀取配置

該接口會從緩存中獲取配置，適合頻率較高的配置拉取請求，如簡單的每30秒輪詢一次配置。

由于緩存最多會有一秒的延時，所以如果需要配合配置推送通知實現實時更新配置的話，請參考通過不帶緩存的Http接口從Apollo讀取配置

Http接口說明

URL: {config_server_url}/configfiles/json/{appId}/{clusterName}/{namespaceName}?ip={clientIp}

Method: GET

參數說明：

參數名是否必須參數值備注

config_server_url	是	Apollo配置服務的地址
appId	是	應用的appId
clusterName	是	集群名	一般情況下傳入 default 即可。 如果希望配置按集群劃分，可以參考集群獨立配置說明做相關配置，然后在這里填入對應的集群名。
namespaceName	是	Namespace的名字	如果沒有新建過Namespace的話，傳入application即可。 如果創建了Namespace，并且需要使用該Namespace的配置，則傳入對應的Namespace名字。需要注意的是對于properties類型的namespace，只需要傳入namespace的名字即可，如application。對于其它類型的namespace，需要傳入namespace的名字加上后綴名，如datasources.json
ip	否	應用部署的機器ip	這個參數是可選的，用來實現灰度發布。 如果不想傳這個參數，請注意URL中從?號開始的query parameters整個都不要出現。

Http接口返回格式

該Http接口返回的是JSON格式、UTF-8編碼，包含了對應namespace中所有的配置項。

返回內容Sample如下：

{"portal.elastic.document.type":"biz","portal.elastic.cluster.name":"hermes-es-fws" }

通過{config_server_url}/configfiles/{appId}/{clusterName}/{namespaceName}?ip={clientIp}可以獲取到properties形式的配置

測試

由于是Http接口，所以在URL組裝OK之后，直接通過瀏覽器、或者相關的http接口測試工具訪問即可。

本地測試：

# curl http://192.168.1.5:8080/configfiles/json/1001/default/application{"redis_ip":"192.168.1.12","redis_passwd":"123456","redis_port":"6379"}

通過不帶緩存的Http接口從Apollo讀取配置

該接口會直接從數據庫中獲取配置，可以配合配置推送通知實現實時更新配置。

Http接口說明

URL: {config_server_url}/configs/{appId}/{clusterName}/{namespaceName}?releaseKey={releaseKey}&ip={clientIp}

Method: GET

參數說明：

參數名是否必須參數值備注

config_server_url	是	Apollo配置服務的地址
appId	是	應用的appId
clusterName	是	集群名	一般情況下傳入 default 即可。 如果希望配置按集群劃分，可以參考集群獨立配置說明做相關配置，然后在這里填入對應的集群名。
namespaceName	是	Namespace的名字	如果沒有新建過Namespace的話，傳入application即可。 如果創建了Namespace，并且需要使用該Namespace的配置，則傳入對應的Namespace名字。需要注意的是對于properties類型的namespace，只需要傳入namespace的名字即可，如application。對于其它類型的namespace，需要傳入namespace的名字加上后綴名，如datasources.json
releaseKey	否	上一次的releaseKey	將上一次返回對象中的releaseKey傳入即可，用來給服務端比較版本，如果版本比下來沒有變化，則服務端直接返回304以節省流量和運算
ip	否	應用部署的機器ip	這個參數是可選的，用來實現灰度發布。

Http接口返回格式

該Http接口返回的是JSON格式、UTF-8編碼。

如果配置沒有變化（傳入的releaseKey和服務端的相等），則返回HttpStatus 304，response body為空。

如果配置有變化，則會返回HttpStatus 200，response body為對應namespace的meta信息以及其中所有的配置項。

返回內容Sample如下：

{"appId": "100004458","cluster": "default","namespaceName": "application","configurations": {"portal.elastic.document.type":"biz","portal.elastic.cluster.name":"hermes-es-fws"},"releaseKey": "20170430092936-dee2d58e74515ff3" }

測試

由于是Http接口，所以在URL組裝OK之后，直接通過瀏覽器、或者相關的http接口測試工具訪問即可。

本地測試

# curl http://192.168.1.5:8080/configs/1001/default/application {"appId":"1001","cluster":"default","namespaceName":"application","configurations":{"redis_ip":"192.168.1.12","redis_passwd":"123456","redis_port":"6379"},"releaseKey":"20220330100056-d3ee492df675126d"}# curl http://192.168.1.5:8080/configs/1001/default/application?releaseKey=20220330100056-d3ee492df675126d

應用感知配置更新

Apollo提供了基于Http long polling的配置更新推送通知，第三方客戶端可以看自己實際的需求決定是否需要使用這個功能。

如果對配置更新時間不是那么敏感的話，可以通過定時刷新來感知配置更新，刷新頻率可以視應用自身情況來定，建議在30秒以上。

如果需要做到實時感知配置更新（1秒）的話，可以參考下面的文檔實現配置更新推送的功能。

配置更新推送實現思路

這里建議大家可以參考Apollo的Java實現：RemoteConfigLongPollService.java，代碼量200多行，總體上還是比較簡單的。

初始化

首先需要確定哪些namespace需要配置更新推送，Apollo的實現方式是程序第一次獲取某個namespace的配置時就會來注冊一下，我們就知道有哪些namespace需要配置更新推送了。

初始化后的結果就是得到一個notifications的Map，內容是namespaceName -> notificationId（初始值為-1）。

運行過程中如果發現有新的namespace需要配置更新推送，直接塞到notifications這個Map里面即可。

請求服務

有了notifications這個Map之后，就可以請求服務了。這里先描述一下請求服務的邏輯，具體的URL參數和說明請參見后面的接口說明。

請求遠端服務，帶上自己的應用信息以及notifications信息

服務端針對傳過來的每一個namespace和對應的notificationId，檢查notificationId是否是最新的

如果都是最新的，則保持住請求60秒，如果60秒內沒有配置變化，則返回HttpStatus 304。如果60秒內有配置變化，則返回對應namespace的最新notificationId, HttpStatus 200。

如果傳過來的notifications信息中發現有notificationId比服務端老，則直接返回對應namespace的最新notificationId, HttpStatus 200。

客戶端拿到服務端返回后，判斷返回的HttpStatus

如果返回的HttpStatus是304，說明配置沒有變化，重新執行第1步

如果返回的HttpStauts是200，說明配置有變化，針對變化的namespace重新去服務端拉取配置，參見1.3 通過不帶緩存的Http接口從Apollo讀取配置。同時更新notifications map中的notificationId。重新執行第1步。

Http接口說明

URL: {config_server_url}/notifications/v2?appId={appId}&cluster={clusterName}&notifications={notifications}

Method: GET

參數說明：

參數名是否必須參數值備注

config_server_url	是	Apollo配置服務的地址
appId	是	應用的appId
clusterName	是	集群名	一般情況下傳入 default 即可。 如果希望配置按集群劃分，可以參考集群獨立配置說明做相關配置，然后在這里填入對應的集群名。
notifications	是	notifications信息	傳入本地的notifications信息，注意這里需要以array形式轉為json傳入，如：[{“namespaceName”: “application”, “notificationId”: 100}, {“namespaceName”: “FX.apollo”, “notificationId”: 200}]。需要注意的是對于properties類型的namespace，只需要傳入namespace的名字即可，如application。對于其它類型的namespace，需要傳入namespace的名字加上后綴名，如datasources.json

注1：由于服務端會hold住請求60秒，所以請確保客戶端訪問服務端的超時時間要大于60秒。

注2：別忘了對參數進行url encode

Http接口返回格式

該Http接口返回的是JSON格式、UTF-8編碼，包含了有變化的namespace和最新的notificationId。

返回內容Sample如下：

[{"namespaceName": "application","notificationId": 101} ]

測試

由于是Http接口，所以在URL組裝OK之后，直接通過瀏覽器、或者相關的http接口測試工具訪問即可。

配置訪問密鑰

Apollo從1.6.0版本開始增加訪問密鑰機制，從而只有經過身份驗證的客戶端才能訪問敏感配置。如果應用開啟了訪問密鑰，客戶端發出請求時需要增加簽名，否則無法獲取配置。

需要設置的Header信息：

HeaderValue備注

Authorization	Apollo $appId:${signature}	appId: 應用的appId，signature：使用訪問密鑰對當前時間以及所訪問的URL加簽后的值，具體實現可以參考Signature.signature
Timestamp	從1970-1-1 00:00:00 UTC+0到現在所經過的毫秒數	可以參考System.currentTimeMillis

本地測試

# curl http://192.168.1.5:8080/configfiles/json/1001/default/application {"timestamp":"2022-03-30T16:39:11.912+0800","status":401,"error":"Unauthorized","message":"","path":"/configfiles/json/1001/default/application"} 報錯 401密鑰： da01f4aab45d4e3c8b8764d99f9a31f5獲取時間戳： Timestamp=`date +%s`curl http://192.168.1.5:8080/configfiles/json/1001/default/application -X POST -H "Content-type:application/json" -d '{"Authorization":"Apollo 1001:da01f4aab45d4e3c8b8764d99f9a31f5","Timestamp":"1648630422"}'

錯誤碼說明

正常情況下，接口返回的Http狀態碼是200，下面列舉了Apollo會返回的非200錯誤碼說明。

400 - Bad Request

客戶端傳入參數的錯誤，如必選參數沒有傳入等，客戶端需要根據提示信息檢查對應的參數是否正確。

401 - Unauthorized

客戶端未授權，如服務端配置了訪問密鑰，客戶端未配置或配置錯誤。

404 - Not Found

接口要訪問的資源不存在，一般是URL或URL的參數錯誤，或者是對應的namespace還沒有發布過配置。

405 - Method Not Allowed

接口訪問的Method不正確，比如應該使用GET的接口使用了POST訪問等，客戶端需要檢查接口訪問方式是否正確。

500 - Internal Server Error

其它類型的錯誤默認都會返回500，對這類錯誤如果應用無法根據提示信息找到原因的話，可以嘗試查看服務端日志來排查問題。

Apollo使用場景和示例代碼

https://github.com/ctripcorp/apollo-use-cases

Apollo 實踐案例

• Apollo+ES源碼改造，構建民生銀行的ELK日志平臺配置管理中心

• Apollo在有贊的實踐

• 微服務版本切換初始設計思路

• Alibaba Sentinel Push模式 規則推送至Apollo配置中心

Apollo 安全相關最佳實踐

配置查看權限

從1.1.0版本開始，apollo-portal增加了查看權限的支持，可以支持配置某個環境只允許項目成員查看私有Namespace的配置。

這里的項目成員是指：

項目的管理員

具備該私有Namespace在該環境下的修改或發布權限

配置方式很簡單，用超級管理員賬號登錄后，進入管理員工具 - 系統參數頁面新增或修改configView.memberOnly.envs配置項即可。

配置訪問密鑰

Apollo從1.6.0版本開始增加訪問密鑰機制，從而只有經過身份驗證的客戶端才能訪問敏感配置。如果應用開啟了訪問密鑰，客戶端需要配置密鑰，否則無法獲取配置。

項目管理員打開管理密鑰頁面

為項目的每個環境生成訪問密鑰，注意默認是禁用的，建議在客戶端都配置完成后再開啟

客戶端配置訪問密鑰

適用于1.6.0及以上版本

Apollo從1.6.0版本開始增加訪問密鑰機制，從而只有經過身份驗證的客戶端才能訪問敏感配置。如果應用開啟了訪問密鑰，客戶端需要配置密鑰，否則無法獲取配置。

配置方式按照優先級從高到低分別為：

1.通過Java System Property

通過Java System Propertyapollo.access-key.secret(1.9.0+) 或者 apollo.accesskey.secret(1.9.0之前) 可以通過Java的System Property apollo.access-key.secret(1.9.0+) 或者 apollo.accesskey.secret(1.9.0之前)來指定 在Java程序啟動腳本中，可以指定-Dapollo.access-key.secret=1cf998c4e2ad4704b45a98a509d15719(1.9.0+) 或者 -Dapollo.accesskey.secret=1cf998c4e2ad4704b45a98a509d15719(1.9.0之前) 如果是運行jar文件，需要注意格式是java -Dapollo.access-key.secret=1cf998c4e2ad4704b45a98a509d15719 -jar xxx.jar(1.9.0+) 或者 java -Dapollo.accesskey.secret=1cf998c4e2ad4704b45a98a509d15719 -jar xxx.jar(1.9.0之前)也可以通過程序指定，如System.setProperty("apollo.access-key.secret", "1cf998c4e2ad4704b45a98a509d15719");(1.9.0+) 或者 System.setProperty("apollo.accesskey.secret", "1cf998c4e2ad4704b45a98a509d15719");(1.9.0之前)

2.通過Spring Boot的配置文件

可以在Spring Boot的application.properties或bootstrap.properties中指定apollo.access-key.secret=1cf998c4e2ad4704b45a98a509d15719(1.9.0+) 或者 apollo.accesskey.secret=1cf998c4e2ad4704b45a98a509d15719(1.9.0之前)

3.通過操作系統的System Environment

還可以通過操作系統的System Environment APOLLO_ACCESS_KEY_SECRET(1.9.0+) 或者 APOLLO_ACCESSKEY_SECRET(1.9.0之前)來指定 注意key為全大寫

4.通過app.properties配置文件

可以在classpath:/META-INF/app.properties指定apollo.access-key.secret=1cf998c4e2ad4704b45a98a509d15719(1.9.0+) 或者 apollo.accesskey.secret=1cf998c4e2ad4704b45a98a509d15719(1.9.0之前)

自定義server.properties路徑

適用于1.8.0及以上版本

1.8.0版本開始支持以下方式自定義server.properties路徑，按照優先級從高到低分別為：

一.通過Java System Property apollo.path.server.properties

1.可以通過Java的System Property apollo.path.server.properties來指定2.在Java程序啟動腳本中，可以指定-Dapollo.path.server.properties=/some-dir/some-file.properties 如果是運行jar文件，需要注意格式是java -Dapollo.path.server.properties=/some-dir/some-file.properties -jar xxx.jar3.也可以通過程序指定，如System.setProperty("apollo.path.server.properties", "/some-dir/some-file.properties");

二、通過操作系統的System EnvironmentAPOLLO_PATH_SERVER_PROPERTIES

可以通過操作系統的System Environment APOLLO_PATH_SERVER_PROPERTIES來指定 注意key為全大寫，且中間是_分隔

客戶端用法

Apollo支持API方式和Spring整合方式，該怎么選擇用哪一種方式？

• API方式靈活，功能完備，配置值實時更新（熱發布），支持所有Java環境。

• Spring方式接入簡單，結合Spring有N種酷炫的玩法，如

  • Placeholder方式：
    • 代碼中直接使用，如：@Value("${someKeyFromApollo:someDefaultValue}")
    • 配置文件中使用替換placeholder，如：spring.datasource.url: ${someKeyFromApollo:someDefaultValue}
    • 直接托管spring的配置，如在apollo中直接配置spring.datasource.url=jdbc:mysql://localhost:3306/somedb?characterEncoding=utf8
  • Spring boot的@ConfigurationProperties方式
  • 從v0.10.0開始的版本支持placeholder在運行時自動更新，具體參見PR #972。（v0.10.0之前的版本在配置變化后不會重新注入，需要重啟才會更新，如果需要配置值實時更新，可以參考后續3.2.2 Spring Placeholder的使用的說明）

• Spring方式也可以結合API方式使用，如注入Apollo的Config對象，就可以照常通過API方式獲取配置了：

  @ApolloConfig private Config config; //inject config for namespace application點擊復制錯誤復制成功

API使用方式

API方式是最簡單、高效使用Apollo配置的方式，不依賴Spring框架即可使用。

獲取默認namespace的配置（application）

Config config = ConfigService.getAppConfig(); //config instance is singleton for each namespace and is never null String someKey = "someKeyFromDefaultNamespace"; String someDefaultValue = "someDefaultValueForTheKey"; String value = config.getProperty(someKey, someDefaultValue);

通過上述的config.getProperty可以獲取到someKey對應的實時最新的配置值。

另外，配置值從內存中獲取，所以不需要應用自己做緩存。

Go、Python、Nodejs、PHP等客戶端使用

對應開發語言支持：https://www.apolloconfig.com/#/zh/usage/third-party-sdks-user-guide

Apollo PHP 客戶端 1

項目地址：apollo-php-client

Apollo PHP 客戶端 2

項目地址：apollo-sdk-config

項目地址：apollo-sdk-clientd

什么是Namespace

Namespace是配置項的集合，類似于一個配置文件的概念。

個人覺得也是Apollo的比較重要和核心的知識點！

什么是“application”的Namespace

Apollo在創建項目的時候，都會默認創建一個“application”的Namespace。顧名思義，“application”是給應用自身使用的，熟悉Spring Boot的同學都知道，Spring Boot項目都有一個默認配置文件application.yml。在這里application.yml就等同于“application”的Namespace。對于90%的應用來說，“application”的Namespace已經滿足日常配置使用場景了。

客戶端獲取“application” Namespace的代碼如下：

Config config = ConfigService.getAppConfig();

客戶端獲取非“application” Namespace的代碼如下：

Config config = ConfigService.getConfig(namespaceName);

Namespace的格式有哪些？

配置文件有多種格式，例如：properties、xml、yml、yaml、json等。同樣Namespace也具有這些格式。在Portal UI中可以看到“application”的Namespace上有一個“properties”標簽，表明“application”是properties格式的。

注1：非properties格式的namespace，在客戶端使用時需要調用ConfigService.getConfigFile(String namespace, ConfigFileFormat configFileFormat)來獲取，如果使用Http接口直接調用時，對應的namespace參數需要傳入namespace的名字加上后綴名，如datasources.json。

注2：apollo-client 1.3.0版本開始對yaml/yml做了更好的支持，使用起來和properties格式一致：Config config = ConfigService.getConfig("application.yml");，Spring的注入方式也和properties一致。

Namespace的獲取權限分類

private （私有的）

public （公共的）

這里的獲取權限是相對于Apollo客戶端來說的。

private權限的Namespace：只能被所屬的應用獲取到。一個應用嘗試獲取其它應用private的Namespace，Apollo會報“404”異常。

public權限的Namespace： 能被任何應用獲取。

Namespace的類型

Namespace類型有三種：

私有類型

具有private權限。例如上文提到的“application” 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

關聯類型使用場景：

舉一個實際使用的場景。假設RPC框架的配置（如：timeout）有以下要求：

• 提供一份全公司默認的配置且可動態調整
• RPC客戶端項目可以自定義某些配置項且可動態調整

如果把以上兩點要求去掉“動態調整”，那么做法很簡單。在rpc-client.jar包里有一份配置文件，每次修改配置文件然后重新發一個版本的jar包即可。同理，客戶端項目修改配置也是如此。

如果只支持客戶端項目可動態調整配置。客戶端項目可以在Apollo “application” Namespace上配置一些配置項。在初始化service的時候，從Apollo上讀取配置即可。這樣做的壞處就是，每個項目都要自定義一些key，不統一。

那么如何完美支持以上需求呢？答案就是結合使用Apollo的公共類型的Namespace和關聯類型的Namespace。RPC團隊在Apollo上維護一個叫“rpc-client”的公共Namespace，在“rpc-client” Namespace上配置默認的參數值。rpc-client.jar里的代碼讀取“rpc-client”Namespace的配置即可。如果需要調整默認的配置，只需要修改公共類型“rpc-client” Namespace的配置。如果客戶端項目想要自定義或動態修改某些配置項，只需要在Apollo 自己項目下關聯“rpc-client”，就能創建關聯類型“rpc-client”的Namespace。然后在關聯類型“rpc-client”的Namespace下修改配置項即可。這里有一點需要指出的，那就是rpc-client.jar是在應用容器里運行的，所以rpc-client獲取到的“rpc-client” Namespace的配置是應用的關聯類型的Namespace加上公共類型的Namespace。

例子

如下圖所示，有三個應用：應用A、應用B、應用C。

• 應用A有兩個私有類型的Namespace：application和NS-Private，以及一個關聯類型的Namespace：NS-Public。

• 應用B有一個私有類型的Namespace：application，以及一個公共類型的Namespace：NS-Public。

• 應用C只有一個私有類型的Namespace：application

應用A獲取Apollo配置

//application Config appConfig = ConfigService.getAppConfig();appConfig.getProperty("k1", null); // k1 = v11appConfig.getProperty("k2", null); // k2 = v21//NS-PrivateConfig privateConfig = ConfigService.getConfig("NS-Private");privateConfig.getProperty("k1", null); // k1 = v3privateConfig.getProperty("k3", null); // k3 = v4//NS-Public，覆蓋公共類型配置的情況，k4被覆蓋Config publicConfig = ConfigService.getConfig("NS-Public");publicConfig.getProperty("k4", null); // k4 = v6 coverpublicConfig.getProperty("k6", null); // k6 = v6publicConfig.getProperty("k7", null); // k7 = v7點擊復制錯誤復制成功

應用B獲取Apollo配置

//applicationConfig appConfig = ConfigService.getAppConfig();appConfig.getProperty("k1", null); // k1 = v12appConfig.getProperty("k2", null); // k2 = nullappConfig.getProperty("k3", null); // k3 = v32//NS-Private，由于沒有NS-Private Namespace 所以獲取到default valueConfig privateConfig = ConfigService.getConfig("NS-Private");privateConfig.getProperty("k1", "default value"); //NS-PublicConfig publicConfig = ConfigService.getConfig("NS-Public");publicConfig.getProperty("k4", null); // k4 = v5publicConfig.getProperty("k6", null); // k6 = v6publicConfig.getProperty("k7", null); // k7 = v7點擊復制錯誤復制成功

應用C獲取Apollo配置

//applicationConfig appConfig = ConfigService.getAppConfig();appConfig.getProperty("k1", null); // k1 = v12appConfig.getProperty("k2", null); // k2 = nullappConfig.getProperty("k3", null); // k3 = v33//NS-Private，由于沒有NS-Private Namespace 所以獲取到default valueConfig privateConfig = ConfigService.getConfig("NS-Private");privateConfig.getProperty("k1", "default value"); //NS-Public，公共類型的Namespace，任何項目都可以獲取到Config publicConfig = ConfigService.getConfig("NS-Public");publicConfig.getProperty("k4", null); // k4 = v5publicConfig.getProperty("k6", null); // k6 = v6publicConfig.getProperty("k7", null); // k7 = v7點擊復制錯誤復制成功

ChangeListener

以上代碼例子中可以看到，在客戶端Namespace映射成一個Config對象。Namespace配置變更的監聽器是注冊在Config對象上。

所以在應用A中監聽application的Namespace代碼如下：

Config appConfig = ConfigService.getAppConfig(); appConfig.addChangeListener(new ConfigChangeListener() {public void onChange(ConfigChangeEvent changeEvent) {//do something} })

在應用A中監聽NS-Private的Namespace代碼如下：

Config privateConfig = ConfigService.getConfig("NS-Private"); privateConfig.addChangeListener(new ConfigChangeListener() {public void onChange(ConfigChangeEvent changeEvent) {//do something} })

在應用A、應用B、應用C中監聽NS-Public的Namespace代碼如下：

Config publicConfig = ConfigService.getConfig("NS-Public"); publicConfig.addChangeListener(new ConfigChangeListener() {public void onChange(ConfigChangeEvent changeEvent) {//do something} })

調整ApolloConfigDB配置

配置項統一存儲在ApolloConfigDB.ServerConfig表中，需要注意每個環境的ApolloConfigDB.ServerConfig都需要單獨配置，修改完一分鐘實時生效。

namespace.lock.switch - 一次發布只能有一個人修改開關，用于發布審核

這是一個功能開關，如果配置為true的話，那么一次配置發布只能是一個人修改，另一個發布。

生產環境建議開啟此選項

服務端配置說明

以下配置除了支持在數據庫中配置以外，也支持通過-D參數、application.properties等配置，且-D參數、application.properties等優先級高于數據庫中的配置

調整ApolloPortalDB配置

配置項統一存儲在ApolloPortalDB.ServerConfig表中，也可以通過管理員工具 - 系統參數頁面進行配置，無特殊說明則修改完一分鐘實時生效。

apollo.portal.envs - 可支持的環境列表

默認值是dev，如果portal需要管理多個環境的話，以逗號分隔即可（大小寫不敏感），如：

DEV,FAT,UAT,PRO

名詞解釋：

DEV(Development environment) 開發環境，用于開發者調試使用FAT(Feature Acceptance Test environment) 功能驗收測試環境，用于軟件測試者測試使用UAT(User Acceptance Test environment) 用戶驗收測試環境，用于用戶測試驗收使用PRO(Production environment) 生產環境

修改完需要重啟生效。

注1：一套Portal可以管理多個環境，但是每個環境都需要獨立部署一套Config Service、Admin Service和ApolloConfigDB，具體請參考：2.1.2 創建ApolloConfigDB，3.2 調整ApolloConfigDB配置，2.2.1.1.2 配置數據庫連接信息，另外如果是為已經運行了一段時間的Apollo配置中心增加環境，別忘了參考2.1.2.4 從別的環境導入ApolloConfigDB的項目數據對新的環境做初始化。

注2：只在數據庫添加環境是不起作用的，還需要為apollo-portal添加新增環境對應的meta server地址，具體參考：2.2.1.1.2.4 配置apollo-portal的meta service信息。apollo-client在新的環境下使用時也需要做好相應的配置，具體參考：1.2.2 Apollo Meta Server。

注3：如果希望添加自定義的環境名稱，具體步驟可以參考Portal如何增加環境。

注4：1.1.0版本增加了系統信息頁面（管理員工具 -> 系統信息），可以通過該頁面檢查配置是否正確

多環境部署

配置apollo-portal的meta service信息

Apollo Portal需要在不同的環境訪問不同的meta service(apollo-configservice)地址，所以我們需要在配置中提供這些信息。默認情況下，meta service和config service是部署在同一個JVM進程，所以meta service的地址就是config service的地址。

對于1.6.0及以上版本，可以通過ApolloPortalDB.ServerConfig中的配置項來配置Meta Service地址，詳見apollo.portal.meta.servers - 各環境Meta Service列表

使用程序員專用編輯器（如vim，notepad++，sublime等）打開apollo-portal-x.x.x-github.zip中config目錄下的apollo-env.properties文件。

假設DEV的apollo-configservice未綁定域名，地址是192.168.1.5:8080，PRO的apollo-configservice綁定了域名apollo.chuanqu.ltd，那么可以如下修改各環境meta service服務地址，格式為${env}.meta=http://${config-service-url:port}，如果某個環境不需要，也可以直接刪除對應的配置項（如lpt.meta）：

dev.meta=http://1.1.1.1:8080 fat.meta=http://apollo.fat.xxx.com uat.meta=http://apollo.uat.xxx.com pro.meta=http://apollo.xxx.com

除了通過apollo-env.properties方式配置meta service以外，apollo也支持在運行時指定meta service（優先級比apollo-env.properties高）：

通過Java System Property

${env}_meta

• 可以通過Java的System Property ${env}_meta來指定
• 如java -Ddev_meta=http://config-service-url -jar xxx.jar
• 也可以通過程序指定，如System.setProperty("dev_meta", "http://config-service-url");

通過操作系統的System Environment

${ENV}_META

• 如DEV_META=http://config-service-url
• 注意key為全大寫，且中間是_分隔

注1: 為了實現meta service的高可用，推薦通過SLB（Software Load Balancer）做動態負載均衡

注2: meta service地址也可以填入IP，0.11.0版本之前只支持填入一個IP。從0.11.0版本開始支持填入以逗號分隔的多個地址（PR #1214），如http://1.1.1.1:8080,http://2.2.2.2:8080，不過生產環境還是建議使用域名（走slb），因為機器擴容、縮容等都可能導致IP列表的變化。

總結

以上是生活随笔為你收集整理的开源配置管理中心apollo使用方法的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。