快捷導(dǎo)航

詳解Go語言微服務(wù)開發(fā)框架之Go chassis

更新時間：2021年05月19日 10:16:01 作者：華為云開發(fā)者社區(qū)

分布式系統(tǒng)中每個進程的動態(tài)配置管理及運行時熱加載就成為了一個亟待解決的問題。go chassis汲取了netflix的archaius框架經(jīng)驗，并做出來自己的創(chuàng)新特性。

引言

https://github.com/go-chassis/go-chassis是一個微服務(wù)開發(fā)框架，而微服務(wù)開發(fā)框架帶來的其中一個課題就是：當(dāng)單體應(yīng)用向微服務(wù)轉(zhuǎn)型后，有大量的配置需要管理，而你并不希望登錄到遠端機器去更改配置，并重啟應(yīng)用，尤其是現(xiàn)在已經(jīng)是容器的時代了，也不希望因為一個配置的變更，而發(fā)布一個新的軟件包。那么分布式系統(tǒng)中每個進程的動態(tài)配置管理及運行時熱加載就成為了一個亟待解決的問題。https://github.com/go-chassis/go-archaius為gochassis而生，他汲取了netflix的archaius框架經(jīng)驗，并做出來自己的創(chuàng)新特性。

架構(gòu)

Source:配置源是一種標(biāo)準(zhǔn)接口，可以通過實現(xiàn)一個source來接入不同配置源，它定義配置來自哪個資源，配置可以來自配置中心configcenter，來自本地文件，來自環(huán)境變量或是啟動命令行。source負責(zé)將配置項緩存到本地內(nèi)存。用戶可以選擇加載任意的source實現(xiàn)。

Config center source：配置中心源不同于其他source，它包含一個client抽象，可以對接不同的生態(tài)系統(tǒng)，目前對接了攜程開源的配置中心Apollo。

Config manager：負責(zé)整合管理所有source的配置，每個source可以定義優(yōu)先級，當(dāng)通過manager獲取配置時，如果2個不同的source有相同的配置，那么就會取最大優(yōu)先級的配置。

Event Dispatcher：用戶可以通過Archaius API進行配置變化監(jiān)聽，當(dāng)source內(nèi)部的配置項新增，更新，刪除配置時，都會通知到監(jiān)聽器。

Source優(yōu)先級：優(yōu)先級由大到小依次為Config center，CLI，ENV，file，當(dāng)有相同配置項的時候僅優(yōu)先級大的配置生效。在一個分布式系統(tǒng)中，遠程的配置中心理應(yīng)擁有最大優(yōu)先級，而在本地運行一個獨立的進程時，通常的思維是，命令行參數(shù)優(yōu)先級高于環(huán)境變量，高于本地文件內(nèi)容。擁有了這樣一套機制后，用戶就無需再寫代碼處理配置項生效邏輯。

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

Archaius API：封裝底層實現(xiàn)，提供友好的API供開發(fā)者使用

獲取配置

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

1. 調(diào)用archaius API的Get 方法

2. 注冊監(jiān)聽器

事件的觸發(fā)是由soruce的開發(fā)者來決定的，每個source的行為會有不同：

命令行與環(huán)境變量是不會產(chǎn)生任何事件的，當(dāng)archaius運行后配置項就已經(jīng)定下來了，只能使用Get方法獲取。而文件source會在啟動后拉取一遍本地文件內(nèi)容并轉(zhuǎn)換為配置項（可自定義轉(zhuǎn)換算法，決定配置項形態(tài)），之后持續(xù)監(jiān)聽本地文件變化，當(dāng)有變化發(fā)生時會刷新本地配置并通知到監(jiān)聽器。所以2種方法都支持。config center source行為與文件又不同，在啟動后，它就會周期拉取配置中心的配置，并且對比每一次配置項的不同，并觸發(fā)不同類型事件。

配置項形態(tài)

假設(shè)程序有一個配置文件叫a.yaml，內(nèi)容如下

registry:

enabled: true

interval: 30s復(fù)制代碼

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

第一種，將配置項拆分為java properties風(fēng)格的配置：

registry.refresh: true

registry.interval: 30s

go archaius開放了file handler接口，允許你決定如何將文件內(nèi)容處理為配置項

那么在遠程的配置中心中，key value的管理方式就要遵循 file handler的行為，當(dāng)你想變更registry.refresh時，就要在配置中心種更改這個配置項及值。

類似于開關(guān)類的配置項，這種java properties的管理方式還是不錯的，當(dāng)一個配置項改變時觸發(fā)一次事件。

但是有一類配置項并不適合如此管理，這就是第二種方式，比如go chassis中的路由管理配置文件：

通常都需要大范圍的更改配置項，那么如果還使用切分的方式在配置中心中管理將會引起go archaius運行時大量的事件觸發(fā)，并且，用戶在使用體驗上大打折扣，到處去找分散的配置項，逐一更改。正確的行為是，將文件名作為配置中心中的key，文件內(nèi)容作為value。用戶需要更改時，去找對應(yīng)的文件名即可，修改后一次性下發(fā)，只會觸發(fā)一次事件，完成路由的變更。

開發(fā)者應(yīng)根據(jù)實際場景判斷如何處理配置項形態(tài)。也可以自己實現(xiàn)handler來決定配置項形態(tài)

配置運行時熱加載

在運行時可以隨時通過統(tǒng)一的配置中心或者本地文件（不推薦分布式環(huán)境登到機器里改文件，但在本地debug時還是推薦使用文件來測試程序的熱加載邏輯）更改配置了，那么接下來要解決的問題就是配置在運行時生效。

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

go chassis運行時總是會有不斷地大并發(fā)數(shù)據(jù)訪問router config這塊緩存，使用一個讀寫鎖lock中的讀鎖，每次訪問緩存都用讀鎖，使用后，解開讀鎖。

向archaius注冊監(jiān)聽器，需要自己編寫監(jiān)聽器的邏輯，每當(dāng)事件出發(fā)后就會通過archaius中的數(shù)據(jù)構(gòu)建一個結(jié)構(gòu)體數(shù)據(jù)，然后將數(shù)據(jù)存到本地緩存，首先使用lock的寫鎖鎖住router config，更新后，解開寫鎖。

在這樣的機制下，就可以做到運行時熱加載配置項而無需重啟服務(wù)。