插件式可擴展架構設計心得

同時，在解決上面這類問題的時候做到：

並且進一步地可以實現：

這裏提到的不管是提供新能力，還是進行能力定製，都既可以針對系統開發者本身，也可以針對三方開發者。

結合上面的特徵，我們嘗試簡單描述一下插件是什麼吧。插件一般是可獨立完成某個或一系列功能的模塊。一個插件是否引入一定不會影響系統原本的正常運行（除非他和另一個插件存在依賴關係）。插件在運行時被引入系統，由系統控制調度。一個系統可以存在複數個插件，這些插件可通過系統預定的方式進行組合。

怎麼實現插件模式

插件模式本質是一種設計思想，並沒有一個一成不變或者是萬金油的實現。但我們經過長期的代碼實踐，其實已經可以總結出一套方法論來指導插件體系的實現，並且其中的一些實現細節是存在社區認可度比較高的 “最佳實踐” 的。本文在攥寫過程中也參考研讀了社區比較有名的一些項目的插件模式設計，包括但不僅限於 Koa、Webpack、Babel 等。

  1. 解決問題前首先要定義問題

實現一套插件模式的第一步，永遠都是先定義出你需要插件化來幫助你解決的問題是什麼。這往往是具體問題具體分析的，並總是需要你對當前系統的能力做一定程度的抽象。比如 Babel，他的核心功能是將一種語言的代碼轉化爲另一種語言的代碼，他面臨的問題就是，他無法在設計時就窮舉語法類型，也不瞭解應該如何去轉換一種新的語法，因此需要提供相應的擴展方式。爲此，他將自己的整體流程抽象成了 parse、transform、generate 三個步驟，並主要面向 parse 和 transform 提供了插件方式做擴展性支持。在 parse 這層，他核心要解決的問題是怎麼去做分詞，怎麼去做詞義語法的理解。在 transform 這層要做的則是，針對特定的語法樹結構，應該如何轉換成已知的語法樹結構。

很明顯，babel 他很清楚地定義了 parse 和 transform 兩層的插件要完成的事情。當然也有人可能會說，爲什麼我一定要定義清楚問題呢，插件體系本來就是爲未來的不確定性服務的。這樣的說法對，也不對。計算機程序永遠是面向確定性的，我們需要有明確的輸入格式，明確的輸出格式，明確的可以依賴的能力。解決問題一定是在已知的一個框架內的。這就引出了定義問題的一門藝術——如何賦予不確定以確定性，在不確定中尋找確定。說人話，就是 “抽象”，這也是爲什麼最開始我會以過度設計作爲引子。

我在進行問題定義的時候，最常使用的是樣本分析法，這種方法並非捷徑，但總歸是有點效的。樣本分析法，就是先着眼於整理已知待解決的問題，將這些問題作爲樣本嘗試分類和提取共性，從而形成一套抽象模式。然後再通過一些不確定但可能未來待解決的問題來測試，是否存在無法套用的情況。光說無用，下面我們還是以 babel 來舉個栗子，當然 babel 的抽象設計其實本質就是有理論支撐的，在有現有理論已經爲你做好抽象時，還是儘量用現成的就好啦。

Babel 主要解決的問題是把新語法的代碼在不改變邏輯的情況下如何轉換成舊語法的代碼，簡單來說就是 code => code 的一個問題。但是需要轉什麼，怎麼轉，這些是會隨着語法規範不斷更新變化的，因此需要使用插件模式來提升其未來可拓展性。我們當下要解決的問題也許是如何轉換 es6 新語法的內容，以及 JSX 這種框架定製的 DSL。我們當然可以簡單地串聯一系列的正則處理，但是你會發現每一個插件都會有大量重複的識別分析類邏輯，不但加大了運行開銷，同時也很難避免互相影響導致的問題。Babel 選擇了把解析與轉換兩個動作拆開來，分別使用插件來實現。解析的插件要解決的問題是如何解析代碼，把 Code 轉化爲 AST。這個問題對於不同的語言又可以拆解爲相同的兩個事情，如何分詞，以及如何做詞義解析。當然詞義解析還能是如何構築上下文、如何產出 AST 節點等等，就不再細分了。最終形成的就是下圖這樣的模式，插件專注解決這幾個細分問題。轉換這邊的，則可分爲如何查找固定 AST 節點，以及如何轉換，最終形成了 Visitor 模式，這裏就不再詳細說了。那麼我們再思考一下，如果未來 ES7、8、9（相對於設計場景的未來）等新語法出爐時，是不是依然可以使用這樣的模式去解決問題呢？看起來是可行的。

這就是前面所說的在不確定中尋找確定性，儘可能減少系統本身所面臨的不確定，通過拆解問題去限定問題。

那麼定義清楚問題，我們大概就完成了 1/3 的工作了，下面就是要正式開始思考如何設計了。

  1. 插件架構設計繞不開的幾大要素

插件模式的設計，可以簡單也可以複雜，我們不能指望一套插件模式適合所有的場景，如果真的可以的話，我也不用寫這篇文章了，給大家甩一個 npm 地址就完事了。這也是爲什麼在設計之前我們一定要先定義清楚問題。具體選擇什麼方式實現，一定是根據具體解決的問題權衡得出的。不過呢，這事終歸還是有跡可循，有法可依的。

當正式開始設計我們的插件架構時，我們所要思考的問題往往離不開以下幾點。整個設計過程其實就是爲每一點選擇合適的方案，最後形成一套插件體系。這幾點分別是：

下面就針對每個點詳細解釋一下

如何注入、配置、初始化插件

注入、配置、初始化其實是幾個分開的事情。但都同屬於 Before 的事情，所以就放在一起講了。

先來講一講注入，其實本質上就是如何讓系統感知到插件的存在。注入的方式一般可以分爲 聲明式 和 編程式。聲明式就是通過配置信息，告訴系統應該去哪裏去取什麼插件，系統運行時會按照約定與配置去加載對應的插件。類似 Babel，可以通過在配置文件中填寫插件名稱，運行時就會去 modules 目錄下去查找對應的插件並加載。編程式的就是系統提供某種註冊 API，開發者通過將插件傳入 API 中來完成註冊。兩種對比的話，聲明式主要適合自己單獨啓動不用接入另一個軟件系統的場景，這種情況一般使用編程式進行定製的話成本會比較高，但是相對的，對於插件命名和發佈渠道都會有一些限制。編程式則適合於需要在開發中被引入一個外部系統的情況。當然也可以兩種方式都進行支持。

然後是插件配置，配置的主要目的是實現插件的可定製，因爲一個插件在不同使用場景下，可能對於其行爲需要做一些微調，這時候如果每個場景都去做一個單獨的插件那就有點小題大作了。配置信息一般在注入時一起傳入，很少會支持注入後再進行重新配置。配置如何生效其實也和插件初始化的有點關聯，初始化這事可以分爲方式和時機兩個細節來講，我們先講講方式。常見的方式我大概列舉兩種。一種是工廠模式，一個插件暴露出來的是一個工廠函數，由調用者或者插件架構來將提供配置信息傳入，生成插件實例。另一種是運行時傳入，插件架構在調度插件時會通過約定的上下文把配置信息給到插件。工廠模式咱們繼續拿 babel 來舉例吧。

function declare<
    O extends Record<string, any>,
    R extends babel.PluginObj = babel.PluginObj
>(
    builder: (api: BabelAPI, options: O, dirname: string) => R,
): (api: object, options: O | null | undefined, dirname: string) => R;

上面代碼中的 builder 呢就是我們說到的工廠函數了，他最終將產出一個 Plugin 實例。builder 通過 options 獲取到配置信息，並且這裏設計上還支持通過 api 設置一些運行環境信息，不過這並不是必須的，所以不細說了。簡化一下就是：

type TPluginFactory<OPTIONS, PLUGIN> = (options: OPTIONS) => PLUGIN;

所以初始化呢，自然也可以是通過調用工廠函數初始化、初始化完成後再注入、不需要初始化三種。一般我們不選擇初始化完成後再注入，因爲解耦的訴求，我們儘量在插件中只做聲明。是否使用工廠模式則看插件是否需要初始化這一步驟。大部分情況下，如果你決定不好，還是推薦優先選擇工廠模式，可以應對後面更多複雜場景。初始化的時機也可以分爲注入即初始化、統一初始化、運行時才初始化。很多情況下 注入即初始化、統一初始化 可以結合使用，具體的區分我嘗試通過一張表格來對應說明：

DnYVSy

另外還有個問題也在這裏提一下，在一些系統中，我們可能依賴許多插件組合來完成一件複雜的事情，爲了屏蔽單獨引入並配置插件的複雜性，我們還會提供一種 Preset 的概念，去打包多個插件及其配置。使用者只需要引入 Preset 即可，不用關心裏面有哪些插件。例如 Babel 在支持 react 語法時，其實要引入 syntax-jsx transform-react-jsx transform-react-display-name transform-react-pure-annotationsd 等多個插件，最終給到的是 preset-react 這樣一個包。

插件如何影響系統

插件對系統的影響我們可以總結爲三方面：行爲、交互、展示。單獨一個插件可能只涉及其中一點。根據具體場景，有些方面也不必去影響，比如一個邏輯引擎類型的系統，就大概率不需要展示這塊的東西啦。

VSCode 插件大致覆蓋了這三個，所以我們可以拿一個簡單的插件來看下。這裏我們選擇了 Clock in status bar 這個插件，這個插件的功能很簡單，就是在狀態欄加一個時鐘，或者你可以在編輯內容內快速插入當前時間。

整個項目裏最主要的是下面這些內容：

在 package.json 中，通過擴展的 contributes 字段爲插件註冊了一個命令，和一個配置菜單。

"main": "./extension", // 入口文件地址
"contributes": {
  "commands": [{
    "command": "clock.insertDateTime",
    "title": "Clock: Insert date and time"
  }],
  "configuration": {
    "type": "object",
    "title": "Clock configuration",
    "properties": {
      "clock.dateFormat": {
        "type": "string",
        "default": "hh:MM TT",
        "description": "Clock: Date format according to https://github.com/felixge/node-dateformat"
      }
    }
  }
},

在入口文件 extension.js 中則通過系統暴露的 API 創建了狀態欄的 UI，並註冊了命令的具體行爲。

'use strict';

// The module 'vscode' contains the VS Code extensibility API
// Import the module and reference it with the alias vscode in your code below
const
  clockService = require('./clockservice'),
  ClockStatusBarItem = require('./clockstatusbaritem'),
  vscode = require('vscode');

// this method is called when your extension is activated
// your extension is activated the very first time the command is executed
function activate(context) {
  // Use the console to output diagnostic information (console.log) and errors (console.error)
  // This line of code will only be executed once when your extension is activated

  // The command has been defined in the package.json file
  // Now provide the implementation of the command with  registerCommand
  // The commandId parameter must match the command field in package.json
  context.subscriptions.push(new ClockStatusBarItem());

  context.subscriptions.push(vscode.commands.registerTextEditorCommand('clock.insertDateTime', (textEditor, edit) => {
    textEditor.selections.forEach(selection => {
      const
        start = selection.start,
        end = selection.end;

      if (start.line === end.line && start.character === end.character) {
        edit.insert(start, clockService());
      } else {
        edit.replace(selection, clockService());
      }
    });
  }));
}

exports.activate = activate;

// this method is called when your extension is deactivated
function deactivate() {
}

exports.deactivate = deactivate;

上述這個例子有點大塊兒，有點稍顯粗糙。那麼總結下來我們看一下，在最開始我們提到的三個方面分別是如何體現的。

所以我們在設計一個插件架構時呢，也主要就從這三方面是否會被影響考慮即可。那麼插件又怎麼去影響系統呢，這個過程的前提是插件與系統間建立一份契約，約定好對接的方式。這份契約可以包含文件結構、配置格式、API 簽名。還是結合 VSCode 的例子來看看：

UI 和 交互的定製邏輯，本質上依賴系統本身的實現方式。這裏重點講一下一般通過哪些模式，去調用插件中的邏輯。

直接調用

這個模式很直白，就是在系統的自身邏輯中，根據需要去調用註冊的插件中約定的 API，有時候插件本身就只是一個 API。比如上面例子中的 activate 和 deactivate 兩個接口。這種模式很常見，但調用處可能會關注比較多的插件處理相關邏輯。

鉤子機制（事件機制）

系統定義一系列事件，插件將自己的邏輯掛載在事件監聽上，系統通過觸發事件進行調度。上面例子中的 clock.insertDateTime 命令也可以算是這類，是一個命令觸發事件。在這個機制上，webpack 是一個比較明顯的例子，我們來看一個簡單的 webpack 插件：

// 一個 JavaScript 命名函數。
function MyExampleWebpackPlugin() {

};

// 在插件函數的 prototype 上定義一個 `apply` 方法。
MyExampleWebpackPlugin.prototype.apply = function(compiler) {
  // 指定一個掛載到 webpack 自身的事件鉤子。
  compiler.plugin('webpacksEventHook', function(compilation /* 處理 webpack 內部實例的特定數據。*/, callback) {
    console.log("This is an example plugin!!!");

    // 功能完成後調用 webpack 提供的回調。
    callback();
  });
};

這裏的插件就將 “在 console 打印 This is an example plugin!!!” 這一行爲註冊到了 webpacksEventHook 這個鉤子上，每當這個鉤子被觸發時，會調用一次這個邏輯。這種模式比較常見，webpack 也專門做了一份封裝服務 github.com/webpack/tap… 通過定義了多種不同調度邏輯的鉤子，你可以在任何系統中植入這款模式，並能滿足你不同的調度需求（調度模式我們在下一部分中詳細講述）。

const {
	SyncHook,
	SyncBailHook,
	SyncWaterfallHook,
	SyncLoopHook,
	AsyncParallelHook,
	AsyncParallelBailHook,
	AsyncSeriesHook,
	AsyncSeriesBailHook,
	AsyncSeriesWaterfallHook
} = require("tapable");

鉤子機制適合注入點多，松耦合需求高的插件場景，能夠減少整個系統中插件調度的複雜度。成本就是額外引了一套鉤子機制了，不算高的成本，但也不是必要的。

使用者調度機制

這種模式本質就是將插件提供的能力，統一作爲系統的額外能力對外透出，最後又系統的開發使用者決定什麼時候調用。例如 JQuery 的插件會註冊 fn 中的額外行爲，或者是 Egg 的插件可以向上下文中註冊額外的接口能力等。這種模式我個人認爲比較適合又需要定製更多對外能力，又需要對能力的出口做收口的場景。如果你希望用戶通過統一的模式調用你的能力，那大可嘗試一下。你可以嘗試使用新的 Proxy 特性來實現這種模式。

不管是系統對插件的調用還是插件調用系統的能力，我們都是需要一個確定的輸入輸出信息的，這也是我們上面 API 簽名所覆蓋到的信息。我們會在下一部分專門講一講。

插件輸入輸出的含義與可以使用的能力

插件與系統間最重要的契約就是 API 簽名，這涉及了可以使用哪些 API，以及這些 API 的輸入輸出是什麼。

可以使用的能力

是指插件的邏輯可以使用的公共工具，或者可以通過一些方式獲取或影響系統本身的狀態。能力的注入我們常使用的方式是參數、上下文對象或者工廠函數閉包。

提供的能力類型主要有下面四種：

對於需要提供哪些能力，一般的建議是根據插件需要完成的工作，提供最小夠用範圍內的能力，儘量減少插件破壞系統的可能性。在部分場景下，如果不能通過 API 有效控制影響範圍，可以考慮爲插件創造沙箱環境，比如插件內可能會調用 global 的接口等。

輸入輸出

當我們的插件是處在我們系統一個特定的處理邏輯流程中的（常見於直接調用機制或鉤子機制），我們的插件重點關注的就是輸入與輸出。此時的輸入與輸出一定是由邏輯流程本身所處的邏輯來決定的。輸入輸出的結構需要與插件的職責強關聯，儘量保證可序列化能力（爲了防止過度膨脹以及本身的易讀性），並根據調度模式有額外的限制條件（下面會講）。如果你的插件輸入輸出過於複雜，可能要反思一下抽象是否過於粗粒度了。

另外還需要對插件邏輯保證異常捕捉，防止對系統本身的破壞。

還是 Babel Parser 那個例子。

{
  parseExprAtom(refExpressionErrors: ?ExpressionErrors): N.Expression;
  getTokenFromCode(code: number): void; // 內部再調用 finishToken 來影響邏輯
  updateContext(prevType: TokenType): void; // 內部通過修改 this.state 來改變上下文信息
}

意料之中的輸入，堅信不疑的輸出

複數個插件之間的關係是怎麼樣的

Each plugin should only do a small amount of work, so you can connect them like building blocks. You may need to combine a bunch of them to get the desired result.

這裏我們討論的是，在同一個擴展點上注入的插件，應該以什麼形式做組合。常見的形式如下：

覆蓋式

只執行最新註冊的邏輯，跳過原始邏輯

管道式

輸入輸出相互銜接，一般輸入輸出是同一個數據類型。

洋蔥圈式

在管道式的基礎上，如果系統核心邏輯處於中間，插件同時關注進與出的邏輯，則可以使用洋蔥圈模型。

這裏也可以參考 koa 中的中間件調度模式 github.com/koajs/compo…

const middleware = async (...params, next) => {
  // before
  await next();
  // after
};

集散式

集散式就是每一個插件都會執行，如果有輸出則最終將結果進行合併。這裏的前提是存在方案，可以對執行結果進行 merge。

另外調度還可以分爲 同步 和 異步 兩個方式，主要看插件邏輯是否包含異步行爲。同步的實現會簡單一點，不過如果你不能確定，那也可以考慮先把異步的一起考慮進來。類似 www.npmjs.com/package/neo… 這樣的工具可以很好地幫助你。如果你使用了 tapble，那裏面已經有相應的定義。

另外還需要注意的細節是：

總結

當你跟着這篇文章的思路，把這些問題都思考清楚之後，想必你的腦海中一定已經有了一個插件架構的雛形了。剩下的可能是結合具體問題，再通過一些設計模式去優化開發者的體驗了。個人認爲設計一個插件架構，是一定逃不開針對這些問題的思考的，而且只有去真正關注這些問題，才能避開炫技、過度設計等面向未來開發時時常會犯的錯誤。當然可能還差一些東西，一些推薦的實現方式也可能會過時，這些就歡迎大家幫忙指正啦。

作者：ES2049 / armslave00

文章可隨意轉載，但請保留此原文鏈接。

非常歡迎有激情的你加入 ES2049 Studio，簡歷請發送至 caijun.hcj@alibaba-inc.com 。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://juejin.cn/post/6962102171923906596

猜你喜歡