一種優雅的Golang的庫外掛註冊載入機制

軒脈刃發表於2022-03-28
Golang

一種優雅的Golang的庫外掛註冊載入機制

你好，我是軒脈刃。

最近看到一個內部專案的外掛載入機制，非常贊。當然這裡說的外掛並不是指的golang原生的可以在buildmode中載入指定so檔案的那種載入機制。而是軟體設計上的「外掛」。如果你的軟體是一個框架，或者一個平臺性產品，想要提升擴充套件性，即可以讓第三方進行第三方庫開發，最終能像搭積木一樣將這些庫組裝起來。那麼就可能需要這種庫載入機制。

我們的目標是什麼？對第三方庫進行某種庫規範，只要按照這種庫規範進行開發，這個庫就可以被載入到框架中。

我們先定義一個外掛的資料結構，這裡肯定是需要使用介面來規範，這個可以根據你的專案自由發揮，比如我希望外掛有一個Setup方法來在啟動的時候載入即可。然後我就定義如下的Plugin結構。

type Plugin interface{
  Name() string
  Setup(config map[string]string) error
}

而在框架啟動的時候，我啟動了一個如下的全域性變數：

var plugins map[string]Plugin

註冊

有人可能會問，這裡有了載入函式setup，但是為什麼沒有註冊邏輯呢？

答案是註冊的邏輯放在庫的init函式中。

即框架還提供了一個註冊函式。

// package plugin

Register(plugin Plugin)

這個register就是實現了將第三方plugin放到plugins全域性變數中。

所以第三方的plugin庫大致實現如下：

package MyPlugin

type MyPlugin struct{
}

func (m *MyPlugin) Setup(config map[string]string) error {
	// TODO
}

func (m *MyPlugin) Name() string {
	return "myPlugin"
}

func init() {
	plugin.Register(&MyPlugin)
}

這樣註冊的邏輯就變成了，如果你要載入一個外掛，那麼你在main.go中直接以 _ import的形式引入即可。

package main

_ import "github.com/foo/myplugin"

func main() {

}

整體的感覺，這樣子外掛的註冊就被“隱藏”到import中了。

載入

註冊的邏輯其實看起來也平平無奇，但是載入的邏輯就考驗細節了。

首先外掛的載入其實有兩點需要考慮：

  • 配置
  • 依賴

配置指的是外掛一定是有某種配置的，這些配置以配置檔案yaml中plugins.myplugin的路徑存在。

plugins:
	myplugin:
		foo: bar

其實我對這種實現持保留意見。配置檔案以一個檔案中配置項的形式存在，好像不如以配置檔案的形式存在，即以config/plugins/myplugin.yaml 的檔案。

這樣不會出現一個大配置檔案的問題。畢竟每個配置檔案本身就是一門DSL語言。如果你將配置檔案的邏輯變複雜，一定會有很多附帶的bug是由於配置檔案錯誤導致的。

第二個說的是依賴。外掛A依賴與外掛B，那麼這裡就有載入函式Setup的先後順序了。這種先後順序如果純依賴使用者的“經驗”，將某個外掛的Setup呼叫放在某個外掛的Setup呼叫之前，是非常痛苦的。（雖然一定是有辦法可以做到）。更好的辦法是依賴於框架自身的載入機制來進行載入。

首先我們在plugin包中定義一個介面：

type Depend interface{
	DependOn() []string
}

如果我的外掛依賴一個名字為 “fooPlugin” 的外掛，那麼我的外掛 MyPlugin就會實現這個介面。

package MyPlugin

type MyPlugin struct{
}

func (m *MyPlugin) Setup(config map[string]string) error {
	// TODO
}

func (m *MyPlugin) Name() string {
	return "myPlugin"
}

func init() {
	plugin.Register(&MyPlugin)
}

func (m *MyPlugin) DependOn() []string {
	return []string{"fooPlugin"}
}

在最終載入所有外掛的時候，我們並不是簡單地將所有外掛呼叫Setup，而是使用一個channel，將所有外掛放在channel中，然後一個個呼叫Setup，遇到有Depend其他外掛的，且依賴外掛還未被載入，則將當前外掛放在佇列最後（重新塞入channel）。

var setupStatus map[string]bool

// 獲取所有註冊外掛
func loadPlugins() (plugin chan Plugin, setupStatus map[string]bool) {
	// 這裡定義一個長度為10的佇列
	var sortPlugin = make(chan Plugin, 10)
	var setupStatus = make[string]bool
	
	// 所有的外掛
	for name, plugin := range plugins {
		sortPlugin <- plugin
		setupStatus[name] = false
	}
	
	return sortPlugin, setupStatus
}

// 載入所有外掛
func SetupPlugins(pluginChan chan Plugin, setupStatus map[string]bool) error {
	num := len(pluginChan)
	for num > 0 {
		plugin <- pluginChan
		
		canSetup := true
		if deps, ok := p.(Depend); ok {
			depends := deps.DependOn()
			for _, dependName := range depends{
				if _, setuped := setupStatus[dependName]; !setup {
						// 有未載入的外掛
						canSetup = false
						break
				}
			}
		}
		
		// 如果這個外掛能被setup
		if canSetup {
			plugin.Setup(xxx)
			setupStatus[p.Name()] = true
		} else {
			// 如果外掛不能被setup, 這個plugin就塞入到最後一個佇列
			pluginChan <- plugin
		}
	}
	return nil
}

上面這段程式碼最精妙的就是使用了一個有buffer的channel作為一個佇列，消費佇列一方SetupPlugins，除了消費佇列，也有可能生產資料到佇列，這樣就保證了佇列中所有plugin都是被按照標記的依賴被順序載入的。

總結

這種外掛的註冊和載入機制是非常優雅的。註冊方面，巧妙使用隱式import來做外掛的註冊。而載入方面，巧妙使用有buffer的channel作為載入佇列。

歡迎關注公眾號: 軒脈刃的刀光劍影

相關文章