最近看到一個(gè)內(nèi)部項(xiàng)目的插件加載機(jī)制，非常贊。當(dāng)然這里說的插件并不是指的golang原生的可以在buildmode中加載指定so文件的那種加載機(jī)制。而是軟件設(shè)計(jì)上的「插件」。如果你的軟件是一個(gè)框架，或者一個(gè)平臺(tái)性產(chǎn)品，想要提升擴(kuò)展性，即可以讓第三方進(jìn)行第三方庫開發(fā)，最終能像搭積木一樣將這些庫組裝起來。那么就可能需要這種庫加載機(jī)制。

我們的目標(biāo)是什么？對(duì)第三方庫進(jìn)行某種庫規(guī)范，只要按照這種庫規(guī)范進(jìn)行開發(fā)，這個(gè)庫就可以被加載到框架中。

我們先定義一個(gè)插件的數(shù)據(jù)結(jié)構(gòu)，這里肯定是需要使用接口來規(guī)范，這個(gè)可以根據(jù)你的項(xiàng)目自由發(fā)揮，比如我希望插件有一個(gè)Setup方法來在啟動(dòng)的時(shí)候加載即可。然后我就定義如下的Plugin結(jié)構(gòu)。

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

而在框架啟動(dòng)的時(shí)候，我啟動(dòng)了一個(gè)如下的全局變量：

var plugins map[string]Plugin

注冊(cè)

有人可能會(huì)問，這里有了加載函數(shù)setup，但是為什么沒有注冊(cè)邏輯呢？

答案是注冊(cè)的邏輯放在庫的init函數(shù)中。

即框架還提供了一個(gè)注冊(cè)函數(shù)。

// package plugin
Register(plugin Plugin)

這個(gè)register就是實(shí)現(xiàn)了將第三方plugin放到plugins全局變量中。

所以第三方的plugin庫大致實(shí)現(xiàn)如下：

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)

這樣注冊(cè)的邏輯就變成了，如果你要加載一個(gè)插件，那么你在main.go中直接以 _ import的形式引入即可。

package main

_ import "github.com/foo/myplugin"
func main() {
}

整體的感覺，這樣子插件的注冊(cè)就被“隱藏”到import中了。

加載

注冊(cè)的邏輯其實(shí)看起來也平平無奇，但是加載的邏輯就考驗(yàn)細(xì)節(jié)了。

首先插件的加載其實(shí)有兩點(diǎn)需要考慮：

• 配置
• 依賴

配置指的是插件一定是有某種配置的，這些配置以配置文件yaml中plugins.myplugin的路徑存在。

plugins:
	myplugin:
		foo: bar

其實(shí)我對(duì)這種實(shí)現(xiàn)持保留意見。配置文件以一個(gè)文件中配置項(xiàng)的形式存在，好像不如以配置文件的形式存在，即以config/plugins/myplugin.yaml 的文件。

這樣不會(huì)出現(xiàn)一個(gè)大配置文件的問題。畢竟每個(gè)配置文件本身就是一門DSL語言。如果你將配置文件的邏輯變復(fù)雜，一定會(huì)有很多附帶的bug是由于配置文件錯(cuò)誤導(dǎo)致的。

第二個(gè)說的是依賴。插件A依賴與插件B，那么這里就有加載函數(shù)Setup的先后順序了。這種先后順序如果純依賴用戶的“經(jīng)驗(yàn)”，將某個(gè)插件的Setup調(diào)用放在某個(gè)插件的Setup調(diào)用之前，是非常痛苦的。（雖然一定是有辦法可以做到）。更好的辦法是依賴于框架自身的加載機(jī)制來進(jìn)行加載。

首先我們?cè)趐lugin包中定義一個(gè)接口：

type Depend interface{
	DependOn() []string
}

如果我的插件依賴一個(gè)名字為 “fooPlugin” 的插件，那么我的插件 MyPlugin就會(huì)實(shí)現(xiàn)這個(gè)接口。

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"}

在最終加載所有插件的時(shí)候，我們并不是簡(jiǎn)單地將所有插件調(diào)用Setup，而是使用一個(gè)channel，將所有插件放在channel中，然后一個(gè)個(gè)調(diào)用Setup，遇到有Depend其他插件的，且依賴插件還未被加載，則將當(dāng)前插件放在隊(duì)列最后（重新塞入channel）。

var setupStatus map[string]bool

// 獲取所有注冊(cè)插件
func loadPlugins() (plugin chan Plugin, setupStatus map[string]bool) {
	// 這里定義一個(gè)長度為10的隊(duì)列
	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
				}
			}
		}
		// 如果這個(gè)插件能被setup
		if canSetup {
			plugin.Setup(xxx)
			setupStatus[p.Name()] = true
		} else {
			// 如果插件不能被setup, 這個(gè)plugin就塞入到最后一個(gè)隊(duì)列
			pluginChan <- plugin
	return nil
} 

上面這段代碼最精妙的就是使用了一個(gè)有buffer的channel作為一個(gè)隊(duì)列，消費(fèi)隊(duì)列一方SetupPlugins，除了消費(fèi)隊(duì)列，也有可能生產(chǎn)數(shù)據(jù)到隊(duì)列，這樣就保證了隊(duì)列中所有plugin都是被按照標(biāo)記的依賴被順序加載的。

總結(jié)

這種插件的注冊(cè)和加載機(jī)制是非常優(yōu)雅的。注冊(cè)方面，巧妙使用隱式import來做插件的注冊(cè)。而加載方面，巧妙使用有buffer的channel作為加載隊(duì)列。

到此這篇關(guān)于Golang庫插件注冊(cè)加載機(jī)制的文章就介紹到這了,更多相關(guān)Golang插件機(jī)制內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！