Go語言分散式系統配置管理實踐--go archaius

二手雄獅發表於2018-10-23

引言

https://github.com/go-chassis/go-chassis是一個微服務開發框架,而微服務開發框架帶來的其中一個課題就是:當單體應用向微服務轉型後,有大量的配置需要管理,而你並不希望登入到遠端機器去更改配置,並重啟應用,尤其是現在已經是容器的時代了,也不希望因為一個配置的變更,而釋出一個新的軟體包。那麼分散式系統中每個程式的動態配置管理及執行時熱載入就成為了一個亟待解決的問題。https://github.com/go-chassis/go-archaius為go chassis而生,他汲取了netflix的archaius框架經驗,並做出來自己的創新特性。


架構

Go語言分散式系統配置管理實踐--go archaiusGo語言分散式系統配置管理實踐--go archaius

Source: 配置源是一種標準介面,可以通過實現一個source來接入不同配置源,它定義配置來自哪個資源,配置可以來自配置中心configcenter,來自本地檔案,來自環境變數或是啟動命令列。source負責將配置項快取到本地記憶體。使用者可以選擇載入任意的source實現。

Config center source: 配置中心源不同於其他source,它包含一個client抽象,可以對接不同的生態系統,目前對接了攜程開源的配置中心Apollo。

Config manager:負責整合管理所有source的配置,每個source可以定義優先順序,當通過manager獲取配置時,如果2個不同的source有相同的配置,那麼就會取最大優先順序的配置。

Event Dispatcher:使用者可以通過Archaius API進行配置變化監聽,當source內部的配置項新增,更新,刪除配置時,都會通知到監聽器。

Source優先順序:優先順序由大到小依次為Config center,CLI,ENV,file,當有相同配置項的時候僅優先順序大的配置生效。在一個分散式系統中,遠端的配置中心理應擁有最大優先順序,而在本地執行一個獨立的程式時,通常的思維是,命令列引數優先順序高於環境變數,高於本地檔案內容。擁有了這樣一套機制後,使用者就無需再寫程式碼處理配置項生效邏輯。

Config Factory: 封裝了event 和 config manager的API

Archaius API: 封裝底層實現,提供友好的API供開發者使用

獲取配置

獲取配置有2種不同的手段:

1. 呼叫archaius API的Get 方法

2. 註冊監聽器

事件的觸發是由soruce的開發者來決定的,每個source的行為會有不同:

命令列與環境變數是不會產生任何事件的,當archaius執行後配置項就已經定下來了,只能使用Get方法獲取。而檔案source會在啟動後拉取一遍本地檔案內容並轉換為配置項(可自定義轉換演算法,決定配置項形態),之後持續監聽本地檔案變化,當有變化發生時會重新整理本地配置並通知到監聽器。所以2種方法都支援。config center source行為與檔案又不同,在啟動後,它就會週期拉取配置中心的配置,並且對比每一次配置項的不同,並觸發不同型別事件。

配置項形態

假設程式有一個配置檔案叫a.yaml,內容如下

registry:
  enabled: true
  interval: 30s複製程式碼

要考慮該如何去對待這raw data,目前有2種方式

第一種,將配置項拆分為java properties風格的配置:

registry.refresh: true

registry.interval: 30s

go archaius開放了file handler介面,允許你決定如何將檔案內容處理為配置項

Go語言分散式系統配置管理實踐--go archaius

那麼在遠端的配置中心中,key value的管理方式就要遵循 file handler的行為,當你想變更registry.refresh時,就要在配置中心種更改這個配置項及值。

類似於開關類的配置項,這種java properties的管理方式還是不錯的,當一個配置項改變時觸發一次事件。

但是有一類配置項並不適合如此管理,這就是第二種方式,比如go chassis中的路由管理配置檔案:

Go語言分散式系統配置管理實踐--go archaius

通常都需要大範圍的更改配置項,那麼如果還使用切分的方式在配置中心中管理將會引起go archaius執行時大量的事件觸發,並且,使用者在使用體驗上大打折扣,到處去找分散的配置項,逐一更改。正確的行為是,將檔名作為配置中心中的key,檔案內容作為value。使用者需要更改時,去找對應的檔名即可,修改後一次性下發,只會觸發一次事件,完成路由的變更。

開發者應根據實際場景判斷如何處理配置項形態。也可以自己實現handler來決定配置項形態

配置執行時熱載入

在執行時可以隨時通過統一的配置中心或者本地檔案(不推薦分散式環境登到機器裡改檔案,但在本地debug時還是推薦使用檔案來測試程式的熱載入邏輯)更改配置了,那麼接下來要解決的問題就是配置在執行時生效。

這裡的技巧是使用go語言中的讀寫鎖。我以go chassis中路由配置來說明

Go語言分散式系統配置管理實踐--go archaius

go chassis執行時總是會有不斷地大併發資料訪問router config這塊快取,使用一個讀寫鎖lock中的讀鎖,每次訪問快取都用讀鎖,使用後,解開讀鎖。

向archaius註冊監聽器,需要自己編寫監聽器的邏輯,每當事件出發後就會通過archaius中的資料構建一個結構體資料,然後將資料存到本地快取,首先使用lock的寫鎖鎖住router config,更新後,解開寫鎖。

在這樣的機制下,就可以做到執行時熱載入配置項而無需重啟服務。

例子

一個本地檔案事件監控的例子

https://github.com/go-chassis/go-archaius/tree/master/examples/event

管理本地多檔案的例子

https://github.com/go-chassis/go-archaius/tree/master/examples/file



Go chassis介紹

https://juejin.im/post/5ba34495e51d450e9e440d1f


相關文章