Nacos 是阿里巴巴今年7月份開源的項(xiàng)目，如其名， Naming Configuration Service ，專注于服務(wù)發(fā)現(xiàn)和配置管理領(lǐng)域。本系列文章，將從 5W1H（What、Where、When、Who、Why、How）全面剖析 Nacos，給大家安利一下 Nacos。本文作為 Nacos 系列文章的開篇，也就從 “What” 開始。我們開始關(guān)注一個(gè)開源項(xiàng)目的時(shí)候，通常最先冒出的 2 個(gè)問題是：

它是什么？

它幫我們解決什么問題？

Nacos 是什么？上面已經(jīng)大概介紹了，更多詳細(xì)內(nèi)容可以從 官網(wǎng) 或 Github 了解。

Nacos 能幫我們解決什么問題？本文圍繞其“配置管理”功能來解答。

配置，作為代碼如影隨形的小伙伴，伴隨著應(yīng)用的整個(gè)生命周期，我們當(dāng)然對(duì)它也非常的熟悉，想想配置一般都通過哪幾種形式存在？

硬編碼

配置文件

DB 配置表

硬編碼

配置項(xiàng)作為類字段的形式存在，如：

這種形式主要有三個(gè)問題：

如果配置是需要?jiǎng)討B(tài)修改的話，需要當(dāng)前應(yīng)用去暴露管理該配置項(xiàng)的接口，至于是 Controller 的 API 接口，還是 JMX ，都是可以做到。

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

最后一個(gè)問題，就是當(dāng)你有多臺(tái)機(jī)器的時(shí)候，要修改一個(gè)配置，每一臺(tái)都得去操作一遍，運(yùn)維成本可想而知，極其蛋疼。

配置文件

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

# application.properties

connectTimeoutInMills=5000

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

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

通過增加“持久化邏輯”、“定時(shí)任務(wù)”讓“配置文件”的形式比“硬編碼”前進(jìn)了一小步。

DB 配置表

這里的 DB 可以是 MySQL 等的關(guān)系型數(shù)據(jù)庫，也可以是 Redis 等的非關(guān)系型數(shù)據(jù)庫。數(shù)據(jù)表如：

它相對(duì)于前兩者，更進(jìn)一步，將配置從應(yīng)用中抽離出來，集中管理，能較大的降低運(yùn)維成本。

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

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

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

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

Nacos 配置管理

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

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

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

添加依賴

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

通過 Spring 的 @Value 注解設(shè)置屬性值。

注意：需要同時(shí)有 Setter方法才能在配置變更的時(shí)候自動(dòng)更新。

以上的三個(gè)步驟，對(duì)應(yīng)用本身幾乎沒有任何的侵入，1 個(gè)依賴 2 注解，寥寥數(shù)行，就把配置通過 Nacos 管理起來了。

關(guān)于配置的動(dòng)態(tài)更新，對(duì) Nacos Spring 的用戶來說，在自身應(yīng)用中就只是設(shè)置 “autoRefreshed” 的一個(gè)布爾值。然后在需要修改配置的時(shí)候，調(diào)用 Nacos 修改配置的接口，或使用 Nacos 的控制臺(tái)去修改，配置發(fā)生變更后， Nacos 就會(huì)把最新的配置推送到該應(yīng)用的所有機(jī)器上，簡(jiǎn)單而高效。

想想之前，為了實(shí)現(xiàn)此功能，寫了多少冤枉代碼，做了多少冤枉的運(yùn)維工作。要是早一點(diǎn)認(rèn)識(shí) Nacos，該有多好呀！

總結(jié)

本文作為 Nacos 5W1H 系列文章的開篇，從“What” 講述了 Nacos 配置管理能幫我們解決的問題：以簡(jiǎn)單、優(yōu)雅、高效的方式管理配置，實(shí)現(xiàn)配置的動(dòng)態(tài)變更，大大降低運(yùn)維成本，讓開發(fā)同學(xué)早點(diǎn)下班。

當(dāng)然，Nacos 的配置管理，不單單只有上述的那些功能，還有諸如“灰度發(fā)布”、“版本管理”、“快速回滾”、“監(jiān)聽查詢”、“推送軌跡”、“權(quán)限控制”、“敏感配置（如，數(shù)據(jù)庫連接配置）的加密存儲(chǔ)”等等，這些有的已經(jīng)在 Nacos 中開源實(shí)現(xiàn)了，有的在 Nacos 配置管理的阿里云免費(fèi)產(chǎn)品 ACM 中提供了，當(dāng)然，后續(xù)也會(huì)慢慢開源到 Nacos 中，敬請(qǐng)期待。

作者：云棲社區(qū) 中間件小哥