想知道為什麼需要配置管理的小夥伴看過來

2022-01-23 17:37:36 字數 3790 閱讀 4539

nacos 是阿里巴巴今年7月份開源的專案,如其名, naming configuration service ,專注於服務發現和配置管理領域。本系列文章,將從 5w1h(what、where、when、who、why、how)全面剖析 nacos,希望對開發者們在服務發現和配置管理開源方案選型的時候,有所幫助。

nacos 是什麼?

他是乙個更易於構建雲原生應用的動態服務發現、配置管理和服務管理平台。

nacos 能幫我們解決什麼問題?

本文將先圍繞其「配置管理」功能來解答。配置,作為**如影隨形的小夥伴,伴隨著應用的整個生命週期,我們當然對它也非常的熟悉,想想配置一般都通過哪幾種形式存在?

配置項作為類字段的形式存在,如:

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

如果配置是需要動態修改的話,需要當前應用去暴露管理該配置項的介面,至於是 controller 的 api 介面,還是 jmx ,都是可以做到。

另外,配置變更都是發生在記憶體中,並沒有持久化。因此,在修改配置之後重啟應用,配置又會變回**中的預設值了,這是乙個坑啊,筆者就曾經掉進去過,爬了好一會才上岸。

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

spring 中常見的 properties、yml 檔案,或其他自定義的,如,「conf」字尾等:

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

配置動態變更,可以是通過類似「硬編碼」暴露管理介面的方式,這時,**中會多一步持久化新配置到檔案的邏輯。或者,簡單粗暴點,直接登入機器上去修改配置檔案,再重啟應用,讓配置生效。當然,你也可以在**中增加乙個定時任務,如每隔 10s 讀取配置檔案內容,讓最新的配置能夠及時在應用中生效,這樣也就免去了重啟應用這個「較重」的運維操作。

通過增加「持久化邏輯」、「定時任務」讓「配置檔案」的形式比「硬編碼」前進了一小步。

這裡的 db 可以是 mysql 等的關係型資料庫,也可以是 redis 等的非關係型資料庫。資料表如:

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 '配置內容',

`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

);

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

那麼,它能怎麼解決動態更新配置的問題呢?據我所知,有兩種方式。

其一,如同之前一樣,通過暴露管理介面去解決,當然,也一樣得增加持久化的邏輯,只不過,之前是寫檔案,現在是將最新配置寫入資料庫。不過,程式中還需要有定時從資料庫讀取最新配置的任務,這樣,才能做到只需呼叫其中一台機器的管理配置介面,就能把最新的配置下發到整個應用集群所有的機器上,真正達到降低運維成本的目的。

其二,直接修改資料庫,程式中通過定時任務從資料庫讀取最新的配置內容。

「db 配置表」的形式解決了主要的問題,但是它不夠優雅,帶來了一些「累贅」。

nacos 真正將配置從應用中剝離出來,統一管理,優雅的解決了配置的動態變更持久化運維成本等問題。

應用自身既不需要去新增管理配置介面,也不需要自己去實現配置的持久化,更不需要引入「定時任務」以便降低運維成本。nacos 提供的配置管理功能,將配置相關的所有邏輯都收攏,並且提供簡單易用的 sdk,讓應用的配置可以非常方便被 nacos 管理起來。

如果是在 spring 中使用 nacos,只需三個步驟即可:

新增依賴

com.alibaba.nacosgroupid>

nacos-spring-contextartifactid>

$version>

dependency>

新增@enablenacosconfig註解啟用 nacos spring 的配置管理服務。以下示例中,我們使用@nacospropertysource載入了dataidexample的配置源,並開啟自動更新:

@configuration

@enablenacosconfig(globalproperties = @nacosproperties(serveraddr = "127.0.0.1:8848"))

@nacospropertysource(dataid = "example", autorefreshed = true)

public class nacosconfiguration

通過 spring 的@value註解設定屬性值。注意:需要同時有setter方法才能在配置變更的時候自動更新。

以上的三個步驟,對應用本身幾乎沒有任何的侵入,1 個依賴2個註解,寥寥數行,就把配置通過 nacos 管理起來了。

關於配置的動態更新,對 nacos spring 的使用者來說,在自身應用中就只是設定 「autorefreshed」 的乙個布林值。然後在需要修改配置的時候,呼叫 nacos 修改配置的介面,或使用 nacos 的控制台去修改,配置發生變更後, nacos 就會把最新的配置推送到該應用的所有機器上,簡單而高效。

想想之前,為了實現此功能,寫了多少冤枉**,做了多少冤枉的運維工作。要是早一點認識 nacos,該有多好呀!

本文作為 nacos 5w1h 系列文章的開篇,從「what」 講述了 nacos 配置管理能幫我們解決的問題:以簡單、優雅、高效的方式管理配置,實現配置的動態變更,大大降低運維成本,讓開發同學早點下班。

當然,nacos 的配置管理,不單單只有上述的那些功能,還有諸如「灰度發布」、「版本管理」、「快速回滾」、「監聽查詢」、「推送軌跡」、「許可權控制」、「敏感配置(如,資料庫連線配置)的加密儲存」等等,這些有的已經在 nacos 中開源實現了,有的在 nacos 配置管理的阿里雲免費產品 acm 中提供了,當然,後續也會慢慢開源到 nacos 中,敬請期待。

你所不知道的配置管理(1) 配置管理概念

配置管理 configuration management 是為了確保軟體開發過程中的產品的一致性 穩定性 可追溯性 回滾性等一系列目的而採取的技術上和管理上的手段的總稱。往往由於軟體開發過程當中重心放在了 開發 本身,配置管理往往被當成了不重要的環節而被忽略了。提起配置管理,很多人都會認為把文件和...

為什麼資料中心該使用配置管理系統?

由於結合了額外的自動化功能,配置管理節約了it團隊的時間。那為什麼有些資料中心對它視若不見呢?配置管理已經從伺服器農場中的 暗黑藝術 解放出來,成為i系統與最佳實踐的it學科。但很多it企業,尤其是smb不明白為什麼需要它。我們給你投資配置管理系統的幾大理由。臉書系統工程師phil dibowitz...

軟體配置管理的作用?軟體配置包括什麼

軟體 配置管理 software configuration management,scm 是一種標識 組織和控制修改的技術。軟體配置 管理應用於整個軟體工程過程 在軟體建立時變更是不可避免的,而變更加劇了專案中軟體開發 者之間的混亂。scm活動的目標就是為了標識變更 控制變更 確保變更正確實現並向...