最近遇到一些開發者朋友，準備將原有的Java Spring的應用配置遷移到 阿里云應用配置管理 ACM 中。遷移過程中，遇到不少有趣的問題。本文將通過一個簡單的樣例來還原遷移過程中遇到的問題和相關解決思路，以期達到和讀者交流的目的。

什么樣的配置適合進入配置中心

這是所有準備遷移配置到配置中心的用戶遇到的第一個問題。我們將從時效性和安全這兩個維度進行分析。

時效性：靜態 VS 動態

靜態配置是指程序版本一旦發布，基本上不會修改的配置內容，例如：

• 軟件版本號：顯然版本號一經確定，產品基本上不需要改。
• 日志樣式：日志的layout，如時間戳，文件名，日志級別等排版，基本上也不需要大改。
• 三方軟件LicenseKey：基本上也是一經發布，很少變化。不排除中途三方軟件License升級，但是這種升級一般都可以根據軟件重新發版來解決配置變更。
• PaaS平臺連接串：如數據庫連接串，中間包含數據庫，用戶名和密碼等。除非因為合規原因修改密碼，或者數據發生遷移等，否則也是很少變化。

動態配置是指程序運行時的一些配置變化，通常會影響到程序的一些運行行為，例如：

• 限流降級參數：限流降級參數一般都不太固定。系統一般在運行時最好是需要根據實際workload pattern來動態調節限流參數如閾值RT，峰值TPS，等。
• 監控報警閾值：如交易環比下跌20%產生error報警，下跌50%產生critical報警。 對于監控系統來講，線上業務特征由于變化比較頻繁，因此一般也不將報警的閾值寫死，
• 日志打印級別：線上一旦出現詭異的行為，希望吧日志打印級別從error比如調高到debug，一般都比較希望能動態的去調整，而不需要重啟應用。
• 容災多活：一旦站點反生災難，一定是希望切換是越快越好。因此配置必須動態秒級生效，盡可能降低資損。

從時效性的維度來講，一般建議用戶把靜態配置存放到自己文件中，盡可能保持簡單，但是需要把動態配置放到配置中心里，以加強靈活性和應用動態變更的實效性。

安全：非敏感 VS 敏感

非敏感配置一般指偏向技術類，暴露后不會導致配置上的安全隱患，例如：

• 軟件版本號：跟產品迭代相關，無業務屬性，非敏感配置。
• 日志樣式：一般跟程序事后診斷相關，非敏感配置。
• 日志打印級別：影響日志打印的多或少，非敏感配置。
• 限流降級參數：限流降級主要為維持內部應用穩定，非敏感配置。
• 監控報警閾值：主要是影響業務的報警精度，非敏感配置。
• 容災多活：一般和數據主備配置和業務分片相關，非敏感配置。

敏感配置通常和業務數據相關，一旦泄露將引起安全隱患，例如：

• 三方軟件LicenseKey：一旦泄露容易發生LicenseKey被盜用，為敏感配置。
• PaaS平臺連接串：典型如數據庫連接串，一旦泄露，無論內部或外部用戶，都可以很容易地登到業務數據庫接觸到業務敏感信息，為敏感配置。

從安全的維度來看，我們通常建議用戶把非敏感配置存放到自己的文件中，盡可能保持簡單，但是需要把敏感配置放到配置中心里，并加密且做好鑒權，盡量不要讓無關人員接觸到。

時效性和安全分析總結

基于 Spring 框架的Java應用配置如何遷移

使用Spring框架的Java開發者一般經常用到的一種配置注解姿勢是利用Spring的@value注解。

原始的純靜態文件場景

例如這個配置，包含兩個配置參數，一個是軟件的版本號，一個是數據庫連接串：

通過@PropertySource和@value的注解來自動注入配置。

@Configuration @ComponentScan("com.alibaba") @PropertySource("classpath:myApp.properties")public class AppConfig {@Value(value="${url}")private String URL;@Value(value="${dbuser}")private String USER;@Value(value="${driver}")private String DRIVER;@Value(value="${dbpassword}")private String PASSWORD;@Value(value="${appVersion}")private String version; }

以上代碼省略了相關數據庫連接初始化等操作。

開始配置遷移，進入混合配置場景

目前由于安全合規或配置時效等原因，要開始遷移配置到ACM上。經過分析，我們發現部分數據庫的配置最好遷移到ACM，以紅色字體標注。紅色部分將全部被遷移到ACM中。

接下來主要三個改動，先歸納下。

• 在ACM控制臺種增加相關配置的記錄。
• Java工程包中增加 ACM SDK 相關依賴。
• 少許修改代碼，增加在ACM中取配置的注解代碼。

第一步，直接到ACM中創建配置項，名字為myapp.dbconfig.properties，并把配置內容編輯在對應編輯框中。詳細操作指南請參見 ACM 快速入門文檔，操作截圖如下。

第二步，在maven的pom.xml中增加依賴，如下。

<dependency> <groupId>com.alibaba.nacos</groupId> <artifactId>nacos-spring-context</artifactId> <version>0.2.1- RC1</version> </dependency>

第三步，在對應AppConfig.java代碼中植入API注解，通過ACM去獲取動態配置。代碼增加部分如紅色字體部分。

@Configuration @ComponentScan("com.journaldev") @PropertySource("classpath:myApp.properties") @EnableNacosConfig(globalProperties = @NacosProperties(endpoint = "acm.aliyun.com", namespace = "xxx", accessKey = "xxx", secretKey = "xxx")) @NacosPropertySource(dataId = "myApp.dbconfig.properties", autoRefreshed = true) public class AppConfig { @Value(value="${url}") private String URL; @Value(value="${dbuser}") private String USER; @Value(value="${driver}") private String DRIVER; @Value(value="${dbpassword}") private String PASSWORD; @Value(value="${appVersion}") private String version; public String getVersion() { return version; } }

至此，改動結束。通過ACM SDK支持Spring的@value注解能力，代碼幾乎0改動。

幾點注意事項

在以上代碼實例中，有幾樣事情需要注意：

• 代碼中使用的ACM SDK為Nacos SDK。Nacos 為ACM的開源實現，ACM無縫兼容所有Nacos的接口。

• 在代碼示例中，使用了明文注解來寫死ACM的endpoint, namespace, AK, SK, 等等。在實際操作種，相關變量其實不用寫死。

  • endpoint namespace等可以通過ACM的相關文件配置或系統變量來解決。
  • AK, SK等敏感信息可以通過ECS Ram Role功能來讓系統自行判斷，代碼不用寫死。
• 代碼中未包含動態配置監聽的回調部分。

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的实战：基于 Spring 的应用配置如何迁移至阿里云应用配置管理 ACM的全部內容，希望文章能夠幫你解決所遇到的問題。

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