這篇文章主要介紹了Nacos配置管理的示例分析，具有一定借鑒價值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。

創(chuàng)新互聯(lián)公司專注于企業(yè)全網(wǎng)整合營銷推廣、網(wǎng)站重做改版、河口網(wǎng)站定制設計、自適應品牌網(wǎng)站建設、H5響應式網(wǎng)站、商城開發(fā)、集團公司官網(wǎng)建設、成都外貿(mào)網(wǎng)站建設、高端網(wǎng)站制作、響應式網(wǎng)頁設計等建站業(yè)務，價格優(yōu)惠性價比高，為河口等各大城市提供網(wǎng)站開發(fā)制作服務。

硬編碼

配置項作為類字段的形式存在，如：

public class AppConfig {    private int connectTimeoutInMills = 5000;    public int getConnectTimeoutInMills() {        return connectTimeoutInMills;
    }    public void setConnectTimeoutInMills(int connectTimeoutInMills) {        this.connectTimeoutInMills = connectTimeoutInMills;
    }
}

這種形式主要有三個問題：

如果配置是需要動態(tài)修改的話，需要當前應用去暴露管理該配置項的接口，至于是 Controller 的 API 接口，還是 JMX ，都是可以做到。

另外，配置變更都是發(fā)生在內(nèi)存中，并沒有持久化。因此，在修改配置之后重啟應用，配置又會變回代碼中的默認值了，這是一個坑啊，筆者就曾經(jīng)掉進去過，爬了好一會才上岸。

最后一個問題，就是當你有多臺機器的時候，要修改一個配置，每一臺都得去操作一遍，運維成本可想而知，極其蛋疼。

配置文件

Spring 中常見的 properties、yml 文件，或其他自定義的，如，“conf”后綴等：

# application.propertiesconnectTimeoutInMills=5000

相比“硬編碼”的形式，它解決了第二個問題，持久化了配置。但是，另外兩個問題并沒有解決，運維成本依舊還是很高的。

配置動態(tài)變更，可以是通過類似“硬編碼”暴露管理接口的方式，這時，代碼中會多一步持久化新配置到文件的邏輯?；蛘?，簡單粗暴點，直接登錄機器上去修改配置文件，再重啟應用，讓配置生效。當然，你也可以在代碼中增加一個定時任務，如每隔 10s 讀取配置文件內(nèi)容，讓最新的配置能夠及時在應用中生效，這樣也就免去了重啟應用這個“較重”的運維操作。

通過增加“持久化邏輯”、“定時任務”讓“配置文件”的形式比“硬編碼”前進了一小步。

DB 配置表

這里的 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 '配置項',  `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);

它相對于前兩者，更進一步，將配置從應用中抽離出來，集中管理，能較大的降低運維成本。

那么，它能怎么解決動態(tài)更新配置的問題呢？據(jù)我所知，有兩種方式。

其一，如同之前一樣，通過暴露管理接口去解決，當然，也一樣得增加持久化的邏輯，只不過，之前是寫文件，現(xiàn)在是將最新配置寫入數(shù)據(jù)庫。不過，程序中還需要有定時從數(shù)據(jù)庫讀取最新配置的任務，這樣，才能做到只需調(diào)用其中一臺機器的管理配置接口，就能把最新的配置下發(fā)到整個應用集群所有的機器上，真正達到降低運維成本的目的。

其二，直接修改數(shù)據(jù)庫，程序中通過定時任務從數(shù)據(jù)庫讀取最新的配置內(nèi)容。

“DB 配置表”的形式解決了主要的問題，但是它不夠優(yōu)雅，帶來了一些“累贅”。

Nacos 配置管理

Nacos 真正將配置從應用中剝離出來，統(tǒng)一管理，優(yōu)雅的解決了配置的動態(tài)變更、持久化、運維成本等問題。

應用自身既不需要去添加管理配置接口，也不需要自己去實現(xiàn)配置的持久化，更不需要引入“定時任務”以便降低運維成本。Nacos 提供的配置管理功能，將配置相關(guān)的所有邏輯都收攏，并且提供簡單易用的 SDK，讓應用的配置可以非常方便被 Nacos 管理起來。

如果是在 Spring 中使用 Nacos，只需三個步驟即可：

• 添加依賴

<dependency>
    <groupId>com.alibaba.nacos</groupId>
    <artifactId>nacos-spring-context</artifactId>
    <version>${latest.version}</version>
</dependency>

• 添加 @EnableNacosConfig 注解啟用 Nacos Spring 的配置管理服務。以下示例中，我們使用 @NacosPropertySource 加載了 dataId 為 example 的配置源，并開啟自動更新：

@Configuration
@EnableNacosConfig(globalProperties = @NacosProperties(serverAddr = "127.0.0.1:8848"))
@NacosPropertySource(dataId = "example", autoRefreshed = true)
public class NacosConfiguration {
}

• 通過 Spring 的 @Value 注解設置屬性值。

注意：需要同時有 Setter方法才能在配置變更的時候自動更新。

public class AppConfig {
    @Value("${connectTimeoutInMills:5000}")
    private int connectTimeoutInMills;
    public int getConnectTimeoutInMills() {
        return connectTimeoutInMills;
    }
    public void setConnectTimeoutInMills(int connectTimeoutInMills) {
        this.connectTimeoutInMills = connectTimeoutInMills;
    }
}

感謝你能夠認真閱讀完這篇文章，希望小編分享的“Nacos配置管理的示例分析”這篇文章對大家有幫助，同時也希望大家多多支持創(chuàng)新互聯(lián)，關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設公司行業(yè)資訊頻道，更多相關(guān)知識等著你來學習!

網(wǎng)頁標題：Nacos配置管理的示例分析-創(chuàng)新互聯(lián)
標題URL：http://jinyejixie.com/article36/ccsosg.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供微信小程序、全網(wǎng)營銷推廣、網(wǎng)站內(nèi)鏈、ChatGPT、網(wǎng)站營銷、網(wǎng)站設計公司

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)