這篇文章主要介紹了Nacos配置管理的示例分析，具有一定借鑒價值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。
創(chuàng)新互聯(lián)建站-專業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設(shè)、高性價比集賢網(wǎng)站開發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫,直接使用。一站式集賢網(wǎng)站制作公司更省心,省錢,快速模板網(wǎng)站建設(shè)找我們，業(yè)務(wù)覆蓋集賢地區(qū)。費(fèi)用合理售后完善，10多年實(shí)體公司更值得信賴。
配置項(xiàng)作為類字段的形式存在，如：
重慶分公司
重慶分公司
public class AppConfig { private int connectTimeoutInMills = 5000; public int getConnectTimeoutInMills() { return connectTimeoutInMills;
} public void setConnectTimeoutInMills(int connectTimeoutInMills) { this.connectTimeoutInMills = connectTimeoutInMills;
}
}這種形式主要有三個問題：
如果配置是需要動態(tài)修改的話，需要當(dāng)前應(yīng)用去暴露管理該配置項(xiàng)的接口，至于是 Controller 的 API 接口，還是 JMX ，都是可以做到。
另外，配置變更都是發(fā)生在內(nèi)存中，并沒有持久化。因此，在修改配置之后重啟應(yīng)用，配置又會變回代碼中的默認(rèn)值了，這是一個坑啊，筆者就曾經(jīng)掉進(jìn)去過，爬了好一會才上岸。
最后一個問題，就是當(dāng)你有多臺機(jī)器的時候，要修改一個配置，每一臺都得去操作一遍，運(yùn)維成本可想而知，極其蛋疼。
Spring 中常見的 properties、yml 文件，或其他自定義的，如，“conf”后綴等：
# application.propertiesconnectTimeoutInMills=5000
相比“硬編碼”的形式，它解決了第二個問題，持久化了配置。但是，另外兩個問題并沒有解決，運(yùn)維成本依舊還是很高的。
配置動態(tài)變更，可以是通過類似“硬編碼”暴露管理接口的方式，這時，代碼中會多一步持久化新配置到文件的邏輯?；蛘撸唵未直c(diǎn)，直接登錄機(jī)器上去修改配置文件，再重啟應(yīng)用，讓配置生效。當(dāng)然，你也可以在代碼中增加一個定時任務(wù)，如每隔 10s 讀取配置文件內(nèi)容，讓最新的配置能夠及時在應(yīng)用中生效，這樣也就免去了重啟應(yīng)用這個“較重”的運(yùn)維操作。
通過增加“持久化邏輯”、“定時任務(wù)”讓“配置文件”的形式比“硬編碼”前進(jìn)了一小步。
這里的 DB 可以是 MySQL 等的關(guān)系型數(shù)據(jù)庫，也可以是 redis 等的非關(guān)系型數(shù)據(jù)庫。數(shù)據(jù)表如：
CREATE TABLE `config` ( `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT, `key` varchar(50) NOT NULL DEFAULT '' COMMENT '配置項(xiàng)', `value` varchar(50) NOT NULL DEFAULT '' COMMENT '配置內(nèi)容', `updated_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, `created_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (`id`), UNIQUE KEY `idx_key` (`key`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='配置信息';INSERT INTO `config` (`key`, `value`, `updated_time`, `created_time`) VALUES ('connectTimeoutInMills', '5000', CURRENT_TIMESTAMP, CURRENT_TIMESTAMP);它相對于前兩者，更進(jìn)一步，將配置從應(yīng)用中抽離出來，集中管理，能較大的降低運(yùn)維成本。
那么，它能怎么解決動態(tài)更新配置的問題呢？據(jù)我所知，有兩種方式。
其一，如同之前一樣，通過暴露管理接口去解決，當(dāng)然，也一樣得增加持久化的邏輯，只不過，之前是寫文件，現(xiàn)在是將最新配置寫入數(shù)據(jù)庫。不過，程序中還需要有定時從數(shù)據(jù)庫讀取最新配置的任務(wù)，這樣，才能做到只需調(diào)用其中一臺機(jī)器的管理配置接口，就能把最新的配置下發(fā)到整個應(yīng)用集群所有的機(jī)器上，真正達(dá)到降低運(yùn)維成本的目的。
其二，直接修改數(shù)據(jù)庫，程序中通過定時任務(wù)從數(shù)據(jù)庫讀取最新的配置內(nèi)容。
“DB 配置表”的形式解決了主要的問題，但是它不夠優(yōu)雅，帶來了一些“累贅”。
Nacos 真正將配置從應(yīng)用中剝離出來，統(tǒng)一管理，優(yōu)雅的解決了配置的動態(tài)變更、持久化、運(yùn)維成本等問題。
應(yīng)用自身既不需要去添加管理配置接口，也不需要自己去實(shí)現(xiàn)配置的持久化，更不需要引入“定時任務(wù)”以便降低運(yùn)維成本。Nacos 提供的配置管理功能，將配置相關(guān)的所有邏輯都收攏，并且提供簡單易用的 SDK，讓應(yīng)用的配置可以非常方便被 Nacos 管理起來。
如果是在 Spring 中使用 Nacos，只需三個步驟即可：
添加依賴
com.alibaba.nacos nacos-spring-context ${latest.version}
添加 @EnableNacosConfig 注解啟用 Nacos Spring 的配置管理服務(wù)。以下示例中，我們使用 @NacosPropertySource 加載了 dataId 為 example 的配置源，并開啟自動更新：
@Configuration
@EnableNacosConfig(globalProperties = @NacosProperties(serverAddr = "127.0.0.1:8848"))
@NacosPropertySource(dataId = "example", autoRefreshed = true)
public class NacosConfiguration {
}通過 Spring 的 @Value 注解設(shè)置屬性值。
注意：需要同時有 Setter方法才能在配置變更的時候自動更新。
public class AppConfig {
@Value("${connectTimeoutInMills:5000}")
private int connectTimeoutInMills;
public int getConnectTimeoutInMills() {
return connectTimeoutInMills;
}
public void setConnectTimeoutInMills(int connectTimeoutInMills) {
this.connectTimeoutInMills = connectTimeoutInMills;
}
}感謝你能夠認(rèn)真閱讀完這篇文章，希望小編分享的“Nacos配置管理的示例分析”這篇文章對大家有幫助，同時也希望大家多多支持創(chuàng)新互聯(lián)，關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，更多相關(guān)知識等著你來學(xué)習(xí)!
