go第三方庫 github.com/spf13/viper 實(shí)現(xiàn)了對(duì)配置文件的讀取并注入到結(jié)構(gòu)中，好用方便。
其中以
viperInstance := viper.New() // viper實(shí)例
viperInstance.WatchConfig()
viperInstance.OnConfigChange(func(e fsnotify.Event) {
log.Print("Config file updated.")
viperLoadConf(viperInstance) // 加載配置的方法
})
可實(shí)現(xiàn)配置的熱更新，不用重啟項(xiàng)目新配置即可生效（實(shí)現(xiàn)熱加載的方法也不止這一種，比如以文件的上次修改時(shí)間來判斷等）。
為什么這么寫？這樣寫為什么就能立即生效？基于這兩個(gè)問題一起來看看viper是怎樣實(shí)現(xiàn)熱更新的。
上面代碼的核心一共兩處：WatchConfig()方法、OnConfigChange()方法。WatchConfig()方法用來開啟事件監(jiān)聽，確定用戶操作文件后該文件是否可正常讀取，并將內(nèi)容注入到viper實(shí)例的config字段，先來看看WatchConfig()方法：
func (v *Viper) WatchConfig() {
go func() {
// 建立新的監(jiān)視處理程序，開啟一個(gè)協(xié)程開始等待事件
// 從I/O完成端口讀取，將事件注入到Event對(duì)象中：Watcher.Events
watcher, err := fsnotify.NewWatcher()
if err != nil {
log.Fatal(err)
}
defer watcher.Close()
// we have to watch the entire directory to pick up renames/atomic saves in a cross-platform way
filename, err := v.getConfigFile()
if err != nil {
log.Println("error:", err)
return
}
configFile := filepath.Clean(filename) //配置文件E:\etc\bizsvc\config.yml
configDir, _ := filepath.Split(configFile) // E:\etc\bizsvc\
done := make(chan bool)
go func() {
for {
select {
// 讀取的event對(duì)象有兩個(gè)屬性，Name為E:\etc\bizsvc\config.yml，Op為write（對(duì)文件的操作）
case event := -watcher.Events:
// 清除內(nèi)部的..和他前面的元素，清除當(dāng)前路徑.，用來判斷操作的文件是否是configFile
if filepath.Clean(event.Name) == configFile {
// 如果對(duì)該文件進(jìn)行了創(chuàng)建操作或?qū)懖僮?
if event.Opfsnotify.Write == fsnotify.Write || event.Opfsnotify.Create == fsnotify.Create {
err := v.ReadInConfig()
if err != nil {
log.Println("error:", err)
}
v.onConfigChange(event)
}
}
case err := -watcher.Errors:
// 有錯(cuò)誤將打印
log.Println("error:", err)
}
}
}()
watcher.Add(configDir)
-done
}()
}
其中，fsnotify是用來監(jiān)控目錄及文件的第三方庫； watcher, err := fsnotify.NewWatcher() 用來建立新的監(jiān)視處理程序，它會(huì)開啟一個(gè)協(xié)程開始等待讀取事件，完成 從I / O完成端口讀取任務(wù)，將事件注入到Event對(duì)象中，即Watcher.Events；
執(zhí)行v.ReadInConfig()后配置文件的內(nèi)容將重新讀取到viper實(shí)例中，如下圖：
執(zhí)行完v.ReadInConfig()后,config字段的內(nèi)容已經(jīng)是用戶修改的最新內(nèi)容了；
其中這行v.onConfigChange(event)的onConfigChange是核心結(jié)構(gòu)體Viper的一個(gè)屬性，類型是func：
type Viper struct {
// Delimiter that separates a list of keys
// used to access a nested value in one go
keyDelim string
// A set of paths to look for the config file in
configPaths []string
// The filesystem to read config from.
fs afero.Fs
// A set of remote providers to search for the configuration
remoteProviders []*defaultRemoteProvider
// Name of file to look for inside the path
configName string
configFile string
configType string
envPrefix string
automaticEnvApplied bool
envKeyReplacer *strings.Replacer
config map[string]interface{}
override map[string]interface{}
defaults map[string]interface{}
kvstore map[string]interface{}
pflags map[string]FlagValue
env map[string]string
aliases map[string]string
typeByDefValue bool
// Store read properties on the object so that we can write back in order with comments.
// This will only be used if the configuration read is a properties file.
properties *properties.Properties
onConfigChange func(fsnotify.Event)
}
它用來傳入本次event來執(zhí)行你寫的函數(shù)。為什么修改會(huì)立即生效？相信第二個(gè)疑問已經(jīng)得到解決了。
接下來看看OnConfigChange(func(e fsnotify.Event) {...... })的運(yùn)行情況：
func (v *Viper) OnConfigChange(run func(in fsnotify.Event)) {
v.onConfigChange = run
}
方法參數(shù)為一個(gè)函數(shù)，類型為func(in fsnotify.Event)) {}，這就意味著開發(fā)者需要把你自己的執(zhí)行邏輯放到這個(gè)func里面，在監(jiān)聽到event時(shí)就會(huì)執(zhí)行你寫的函數(shù)，所以就可以這樣寫：
viperInstance.OnConfigChange(func(e fsnotify.Event) {
log.Print("Config file updated.")
viperLoadConf(viperInstance) // viperLoadConf函數(shù)就是將最新配置注入到自定義結(jié)構(gòu)體對(duì)象的邏輯
})
而OnConfigChange方法的參數(shù)會(huì)賦值給形參run并傳到viper實(shí)例的onConfigChange屬性，以WatchConfig()方法中的v.onConfigChange(event)來執(zhí)行這個(gè)函數(shù)。
到此，第一個(gè)疑問也就解決了。
到此這篇關(guān)于詳解go基于viper實(shí)現(xiàn)配置文件熱更新及其源碼分析的文章就介紹到這了,更多相關(guān)go viper文件熱更新內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！
您可能感興趣的文章:- golang使用信號(hào)量熱更新的實(shí)現(xiàn)示例
- 解讀golang plugin熱更新嘗試
