共計 3230 個字符，預計需要花費 9 分鐘才能閱讀完成。
今天就跟大家聊聊有關基于 Spring 的應用配置怎么遷移至阿里云應用配置管理 ACM，可能很多人都不太了解，為了讓大家更加了解，丸趣 TV 小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。
最近遇到一些開發者朋友，準備將原有的 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，并把配置內容編輯在對應編輯框中。
第二步，在 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 (http://nacos.io) 為 ACM 的開源實現，ACM 無縫兼容所有 Nacos 的接口。
在代碼示例中，使用了明文注解來寫死 ACM 的 endpoint, namespace, AK, SK, 等等。在實際操作種，相關變量其實不用寫死。
看完上述內容，你們對基于 Spring 的應用配置怎么遷移至阿里云應用配置管理 ACM 有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注丸趣 TV 行業資訊頻道，感謝大家的支持。
