想知道為什麽需要配置管理的小夥伴看過來
本文作為 Nacos 系列文章的開篇,從 “What” 開始。我們開始關註一個開源項目的時候,通常最先冒出的 2 個問題是:
-
他是什麽?
-
他幫我們解決什麽問題?
Nacos 是什麽?
他是一個更易於構建雲原生應用的動態服務發現、配置管理和服務管理平臺。
Nacos 能幫我們解決什麽問題?
本文將先圍繞其“配置管理”功能來解答。配置,作為代碼如影隨形的小夥伴,伴隨著應用的整個生命周期,我們當然對它也非常的熟悉,想想配置一般都通過哪幾種形式存在?
-
硬編碼
-
配置文件
-
DB 配置表
| 硬編碼
配置項作為類字段的形式存在,如:
public class AppConfig {
?
private int connectTimeoutInMills = 5000;
?
public int getConnectTimeoutInMills() {
return connectTimeoutInMills;
}
?
public void setConnectTimeoutInMills(int connectTimeoutInMills) {
this.connectTimeoutInMills = connectTimeoutInMills;
}
}
這種形式主要有三個問題:
-
如果配置是需要動態修改的話,需要當前應用去暴露管理該配置項的接口,至於是 Controller 的 API 接口,還是 JMX ,都是可以做到。
-
另外,配置變更都是發生在內存中,並沒有持久化。因此,在修改配置之後重啟應用,配置又會變回代碼中的默認值了,這是一個坑啊,筆者就曾經掉進去過,爬了好一會才上岸。
-
最後一個問題,就是當你有多臺機器的時候,要修改一個配置,每一臺都得去操作一遍,運維成本可想而知,極其蛋疼。
| 配置文件
Spring 中常見的 properties、yml 文件,或其他自定義的,如,“conf”後綴等:
# application.properties
connectTimeoutInMills=5000
相比“硬編碼”的形式,它解決了第二個問題,持久化了配置。但是,另外兩個問題並沒有解決,運維成本依舊還是很高的。
配置動態變更,可以是通過類似“硬編碼”暴露管理接口的方式,這時,代碼中會多一步持久化新配置到文件的邏輯。或者,簡單粗暴點,直接登錄機器上去修改配置文件,再重啟應用,讓配置生效。當然,你也可以在代碼中增加一個定時任務,如每隔 10s 讀取配置文件內容,讓最新的配置能夠及時在應用中生效,這樣也就免去了重啟應用這個“較重”的運維操作。
通過增加“持久化邏輯”、“定時任務”讓“配置文件”的形式比“硬編碼”前進了一小步。
| DB 配置表
這裏的 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 真正將配置從應用中剝離出來,統一管理,優雅的解決了配置的動態變更、持久化、運維成本等問題。
應用自身既不需要去添加管理配置接口,也不需要自己去實現配置的持久化,更不需要引入“定時任務”以便降低運維成本。Nacos 提供的配置管理功能,將配置相關的所有邏輯都收攏,並且提供簡單易用的 SDK,讓應用的配置可以非常方便被 Nacos 管理起來。
如果是在 Spring 中使用 Nacos,只需三個步驟即可:
-
添加依賴
<dependency>
<groupId>com.alibaba.nacos</groupId>
<artifactId>nacos-spring-context</artifactId>
<version>${latest.version}</version>
</dependency>
-
添加
-
通過 Spring 的
@Value
註解設置屬性值。 註意:需要同時有Setter
方法才能在配置變更的時候自動更新。
public class AppConfig {
?
以上的三個步驟,對應用本身幾乎沒有任何的侵入,1 個依賴2個註解,寥寥數行,就把配置通過 Nacos 管理起來了。
關於配置的動態更新,對 Nacos Spring 的用戶來說,在自身應用中就只是設置 “autoRefreshed” 的一個布爾值。然後在需要修改配置的時候,調用 Nacos 修改配置的接口,或使用 Nacos 的控制臺去修改,配置發生變更後, Nacos 就會把最新的配置推送到該應用的所有機器上,簡單而高效。
想想之前,為了實現此功能,寫了多少冤枉代碼,做了多少冤枉的運維工作。要是早一點認識 Nacos,該有多好呀!
| 總結
本文作為 Nacos 5W1H 系列文章的開篇,從“What” 講述了 Nacos 配置管理能幫我們解決的問題:以簡單、優雅、高效的方式管理配置,實現配置的動態變更,大大降低運維成本,讓開發同學早點下班。
https://mp.weixin.qq.com/s/IqSDx_7ithQ75dDd57vECQ
想知道為什麽需要配置管理的小夥伴看過來