引言

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

架構(gòu)

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

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

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

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

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

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

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

獲取配置

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

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

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

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

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

配置項(xiàng)形態(tài)

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

registry:

  enabled: true

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

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

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

registry.refresh: true

registry.interval: 30s

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

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

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

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

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

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

配置運(yùn)行時(shí)熱加載

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

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

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

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

在這樣的機(jī)制下，就可以做到運(yùn)行時(shí)熱加載配置項(xiàng)而無需重啟服務(wù)。

例子

一個(gè)本地文件事件監(jiān)控的例子

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/6844903682362834952

以上就是詳解Go語言微服務(wù)開發(fā)框架之Go chassis的詳細(xì)內(nèi)容，更多關(guān)于Go語言的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！