實現可用的插件系統

Jusfr 原創，文章所用代碼已給出，轉載請注明來自博客園。

1. 插件機制與 AppDomain
2. 示例與現實
3. 目標與設計
4. [Serializable] 與 MarshalByRefObject
5. 思路與實現
6. 后記

開始之前還是得說：插件機制老生常談，但一下子到某工廠或 MAF 管線我相信不少園友吃不消。授人以魚不如授人以漁，個人覺得思考過程的引導和干貨一樣重要，不然大家直接看 MSDN 或者 API 文檔好了。

1. 插件機制與 AppDomain

“CLR不提供缷載單獨程序集的能力。如果CLR允許這樣做，那么一旦線程從某個方法返回至已缷載的一個程序集中的代碼，應用程序就會崩潰。健壯性和安全性是CLR最優先考慮的目標，如果允許應用程序以這樣的一種方式崩潰，就和它的設計初衷背道而馳了。缷載應用程序集必須缷載包含它的整個 AppDoamin 。” ———— 出自《CLR via C#》519頁。

想要達到插件化目的，必須手動創建 AppDomain 作為插件容器和邊界，在需要時卸載 AppDomain 以達到卸載插件的目的。這里不得不提及 MEF 和 MAF。MEF 使用 Import 與 Export 進行類型發現和元數據查找，還維護了組件生命周期，但與插件機制並無關聯，多數情況下把它歸納到注入工具比較合適；MAF 極為強大但仍然是上述原理的運用，過於厚重關注有限。

2. 示例與現實

.Net 下插件限制已經在文章開始的時候進行了描述，機制就是自定義 AppDomain 的創建與缷載，實現並不復雜，貼一段 Demo：

    static void Main(string[] args) {
        var pluginDomain = AppDomain.CreateDomain("ad#1");
        var pluginType = typeof(Plugin); // Other ways
        var pluginInstance = (IPlugin)pluginDomain.CreateInstanceAndUnwrap(pluginType.Assembly.FullName, pluginType.FullName);

        // Do stuff with pluginInstance
        AppDomain.Unload(pluginDomain);
    }

我們可以通過反射拿到定義在其他程序集中的 pluginType ，並在 AppDomain.Unload() 調用后刪掉該程序集，它滿足動態缷載的要求。

但是這個 Demo 程序實在是有太多問題：

1）如果 IPlugin 是空的標記接口，那么宿主無法調用實現類的業務邏輯；如果 IPlugin 是非空的業務接口，那么類庫職責與應用職混淆在了一起？
2）接口實現類和關聯類型必須使用 [Serializable] 標記或者從 MarshalByRefObject 派生，由於生產環境存在相當多的數據類型及引用，可能需要把業務上的數據結構改個遍，甚至不能實現；
3）插件的隔離性沒有體現出來，不同插件可能有不同的數據庫連接和獨立的第三方類庫引用，程序發布成為難題；

3. 目標與設想

前文列舉的問題就是我們要解決的問題：

1）可運行時加載/缷載，基本原理在 Demo 中得到了體現，但是實現得非常丑陋，管理 AppDomain 是核心的底層邏輯，不應該出現在啟動過程中；
2）划清類庫開發與應用開發邊界，我期望創建出可重復使用的插件機制而不要混入一大坨業務邏輯;
3）保證隔離性，插件需要擁有獨立配置文件、各自升級的能力；

我們先進入下一節作些准備工作；

4. [Serializable] 與 MarshalByRefObject

.Net 進程總是會創建默認 AppDomain，由於插件化需要額外的 AppDomain，難免出現跨 AppDomain 邊界訪問對象的問題，比如宿主調用插件、為插件傳遞參數、獲取插件的計算結果等等，我們知道有兩種方法可以使用：標記 [Serializable] 以按值封送、從 MarshalByRefObject 派生以按引用封送。

舉例，我們定義某接口包含了推送消息的方法 bool Push(Message message) ，如果期望在自定義 AppDomain 中創建實現類，那么該實現類需要標記 [Serializable] 以按值封送或從 MarshalByRefObject 派生以按引用封送；額外地，按引用封送時，被依賴的 Message 對象也需要滿足跨邊界訪問要求。

那么按值封送時類型 Message 不用特殊處理 ？確實如此，簡單解釋下，為封送方式的選擇作出解釋。

使用過 System.Runtime.Serialization.Formatters.Binary.BinaryFormatter 的同學應該和 "SerializationException: Type 'xxoo' in Assembly 'ooxx' is not marked as serializable." 打過交道。按值封送是一個序列化和反序列化的過程，看起來我們在自定義 AppDomain 中進行了類型實例化並拿到引用，實際上發生了更多事情：原始實例被序列化為字節數組傳回調用邏輯所在 AppDomain，然后字節數組反序列化，該類型所在和相關的程序集被視需求加載，最后得到了是對原始對象的精確拷貝及該拷貝的引用，而原始類型實例會在垃圾回收中被銷毀。

按值封送的類型實例化過程中，相關程序集已在調用方 AppDomain 完成加載即我們已經擁有 Message 類型信息，調用 Push() 方法時不會存在跨 AppDomain 邊界訪問對象的問題，故 Message 對象無須處理。

按引用封送拿到的是類型實例的代理，我們通過它與原始對象打交道。基於上述描述和可缷載的插件化要求，我們應該選擇按引用封送。

接着關注下性能問題，以下是基本測試。

    public interface IPlugin {
        Int32 X { get; set; }
    }

    public class Plugin : IPlugin {
        public Int32 X { get; set; }
    }

    [Serializable]
    public class MarshalByRefValuePlugin : IPlugin {
        public Int32 X { get; set; }
    }

    public class MarshalByRefTypePlugin : MarshalByRefObject, IPlugin {
        public Int32 X { get; set; }
    }

    public class MarshalByRefTypePluginProxy : MarshalByRefObject {
        private readonly IPlugin h = new Plugin();

        public void Proceed() {
            h.X++;
        }
    }

MarshalByRefTypePluginProxy 相對其他實現比較特殊，它是一個裝飾器模式；調用測試如下，PerformanceRecorder 是我寫的測試類，它內部包含一個 Stopwatch，接收整型數及一個委托列表，返回每個委托執行聲明次數所需要的時間等結果；

    static void Main(string[] args) {
        var h1 = new Plugin();
        var h2 = new MarshalByRefValuePlugin();
        var h3 = new MarshalByRefTypePlugin();

        AppDomain ad = AppDomain.CreateDomain("ad#2");
        var t1 = typeof(MarshalByRefTypePlugin);
        var h4 = (IPlugin)ad.CreateInstanceAndUnwrap(t1.Assembly.FullName, t1.FullName);
        var t2 = typeof(MarshalByRefValuePlugin);
        var h5 = (IPlugin)ad.CreateInstanceAndUnwrap(t2.Assembly.FullName, t2.FullName);

        var t3 = typeof(MarshalByRefTypePluginProxy);
        var py = (MarshalByRefTypePluginProxy)ad.CreateInstanceAndUnwrap(t3.Assembly.FullName, t3.FullName);

        var records = PerformanceRecorder.Invoke(100000,
            () => h1.X++, () => h3.X++, () => h2.X++, () => h4.X++, () => h5.X++, py.Proceed);
            
        foreach (var r in records) {
            Console.WriteLine("{0} {1,4} {2}",
                r.RunningTime, r.CollectionCount, r.TotalMemory);
        }
    }

可以看到結果：標記 [Serializable] 的 MarshalByRefValuePlugin，由於實例調用並不會發生跨 AppDomain 邊界的對象訪問，無論是直接創建還是使用自定義 AppDomain 創建都沒有顯著的性能差異；而繼承自 MarshalByRefObject 的 MarshalByRefTypePlugin，在默認 AppDomain 中調用時性能十分接近，一旦在自定義 AppDomain 中創建、在默認 AppDomain 中訪問時，性能直跌谷底。

00:00:00.0016055    3 63004
00:00:00.0020829    6 67988
00:00:00.0019477    9 67988
00:00:01.7473949  146 71648
00:00:00.0020485  149 71648
00:00:00.0770707  152 71648
Press any key to continue . . .

采取裝飾器模式的 MarshalByRefTypePluginProxy 很有意思，它依賴 IPlugin 實例工作，因為 IPlugin 調用發生在自定義 AppDomain 內部，這里沒有跨 AppDomain 邊界的對象訪問! 雖然相比直接調用存在不小性能差距，但相比直接引用 IPlugin 在自定義 AppDomain 中的實例還是高效太多，有所啟示嗎？

X++ 就是業務邏輯，通過調用 MarshalByRefTypePluginProxy.Proceed() 間接調用業務邏輯，我們得到了性能收益，同時因為不再對 IPlugin 的實現有封送要求，我們做到了對業務邏輯沒有入侵。

5. 思路與實現

一方面接口可以有相當多的實現，而去操作每個實例過於細粒度；另一方面實踐中我們常常以項目即 Visual Studio 里的 Project 定義業務，所以我選擇使用項目編譯結果作為插件邊界。使用文件夾分隔能很方便地保證物理隔離，同時配合 AppDomainSetup 初始化 AppDomain 能做到配置文件和第三方類庫引用獨立！

另一方面前文提到的 MarshalByRefTypePluginProxy 相對直接的插件調用有一定的性能優勢，我們可以將其與自定義 AppDomain 關聯、充當宿主與插件的橋梁，達到調用業務邏輯、插件管理的目的。

核心類型為 IPluginCatalog 與 IPluginCatalogProxy。前者並供應用開發人員擴展以操作業務邏輯，后者聚合前者，通過路徑管理自定義 AppDomain 和 IPluginCatalog 實例；IPluginResolver 承擔默認的類型發現職責。

IPluginCatalog 與相關實現：IPluginCatalog 僅定義了插件目錄，泛型 IPluginCatalog<out T> 定義了插件類型查找方法，PluginCatalog<T> 繼承自 MarshalByRefObject 作為默認實現，FindPlugins() 被標記為虛方法，應用開發人員可以很方便地重寫，而 InitializeLifetimeService() 方法返回 null 以避免原始對象被垃圾回收。

IPluginCatalogProxy 與相關實現： IPluginCatalogProxy 定義了泛型的 Construct<T, P>() 方法和約束，T 被要求從 IPluginCatalog<P> 定義。PluginCatalogProxy.Construct() 方法調用前會檢查內部字典以創建或獲取自定義 AppDomain，接着在該 AppDomain 上創建類型為 T 的 IPluginCatalog<P> 實例；Release() 方法執行 AppDomain 的查找和卸載邏輯，用戶擴展的 IPluginCatalog 實例還可以定義資源清理工作，例如停止計數器、釋放數據庫連接。

注意：本例中的IPluginCatalog 實現及類型的實例均調用了的使用了 AppDomain.CreateInstanceAndUnwrap(string assemblyName, string typeName) 重載，該方法將調用目標類型的無參構造函數，其他重載更強大也很復雜，請自行查看。

邏輯不過百來行，就不打包了。

using System;
using System.Collections.Generic;
using System.ComponentModel.Composition.Hosting;
using System.IO;
using System.Reflection;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace ChuyeEventBus.Plugin {
    #region 類型發現相關
    public interface IPluginResolver {
        IEnumerable<T> FindAll<T>(String pluginFolder);
    }

    public class MefPluginResolver : IPluginResolver {
        public IEnumerable<T> FindAll<T>(String pluginFolder) {
            var catalog = new AggregateCatalog();
            catalog.Catalogs.Add(new DirectoryCatalog(pluginFolder));
            var container = new CompositionContainer(catalog);
            return container.GetExportedValues<T>();
        }
    }
    
    public class ReflectionPluginResolver : IPluginResolver {
        public IEnumerable<T> FindAll<T>(String pluginFolder) {
            var basePluginType = typeof(T);
            var pluginTypes = Directory.EnumerateFiles(pluginFolder, "*.dll", SearchOption.TopDirectoryOnly)
                .Concat(Directory.EnumerateFiles(pluginFolder, "*.exe", SearchOption.TopDirectoryOnly))
                .SelectMany(f => Assembly.LoadFrom(f).ExportedTypes)
                .Where(t => basePluginType.IsAssignableFrom(t) && t != basePluginType 
                    && !t.IsInterface && !t.IsAbstract);
            foreach (var pluginType in pluginTypes) {
                yield return (T)Activator.CreateInstance(pluginType);
            }
        }
    }
    
    #endregion
    
    public interface IPluginCatalog {
        String PluginFolder { get; set; }
    }
    
    public interface IPluginCatalog<out T> : IPluginCatalog {
        // 這里其實並不希望被跨 AppDoamin 訪問，文末有補救
        IEnumerable<T> FindPlugins();
    }
    
    public class PluginCatalog<T> : MarshalByRefObject, IPluginCatalog<T> {
        public String PluginFolder { get; set; }

        // 避免原始對象被釋放
        public override object InitializeLifetimeService() {
            return null;
        }

        public virtual IEnumerable<T> FindPlugins() {
            var resolver = new ReflectionPluginResolver();
            return resolver.FindAll<T>(PluginFolder);
        }
    }
    
    public interface IPluginCatalogProxy {
        // T 類型需要有無參構造函數
        T Construct<T, P>(String pluginFolder) where T : IPluginCatalog<P>, new();
        void Release(String pluginFolder);
        void ReleaseAll();
    }
    
    public class PluginCatalogProxy : IPluginCatalogProxy, IDisposable {
        private readonly Dictionary<String, AppDomain> _pluginDomains
            = new Dictionary<String, AppDomain>();

        public T Construct<T, P>(String pluginFolder) where T : IPluginCatalog<P>, new() {
            var pluginCatalogType = typeof(T);
            //todo: 如果期望區分同一目錄獲取不同的 IPluginCatalog<P> 實例，則需要做更多工作
            var pluginDomain = CreatePluginDomain(pluginFolder);
            var pluginCatalog = (IPluginCatalog)pluginDomain.CreateInstanceAndUnwrap(
                  pluginCatalogType.Assembly.FullName,
                  pluginCatalogType.FullName);
            pluginCatalog.PluginFolder = pluginFolder;
            return (T)pluginCatalog;
        }

        protected virtual AppDomain CreatePluginDomain(String pluginFolder) {
            var cfg = GetPluginConfiguration(pluginFolder);
            var bins = new[] { pluginFolder.Substring(AppDomain.CurrentDomain.BaseDirectory.Length) };
            var setup = new AppDomainSetup();
            if (File.Exists(cfg)) {
                setup.ConfigurationFile = cfg;
            }
            setup.ApplicationBase = AppDomain.CurrentDomain.BaseDirectory;
            setup.PrivateBinPath = String.Join(";", bins);

            AppDomain pluginDoamin;
            if (!_pluginDomains.TryGetValue(pluginFolder, out pluginDoamin)) {
                pluginDoamin = AppDomain.CreateDomain(pluginFolder, null, setup);
                _pluginDomains.Add(pluginFolder, pluginDoamin);
            }
            return pluginDoamin;
        }

        // 可以定義自己的規則
        protected virtual String GetPluginConfiguration(String pluginFolder) {
            var config = Path.Combine(pluginFolder, "main.config");
            if (!File.Exists(config)) {
                config = Path.Combine(pluginFolder, Path.GetFileName(pluginFolder) + ".dll.config");
            }
            if (!File.Exists(config)) {
                var configs = Directory.GetFiles(pluginFolder, "*.dll.config", SearchOption.TopDirectoryOnly);

                if (config.Length > 1) {
                    Debug.WriteLine(String.Format("Unknown configuration as too many .dll.config files in \"{0}\""
                        , Path.GetFileName(pluginFolder)));
                }
                else if (config.Length == 1) {
                    config = configs[0];
                }
            }
            return config;
        }

        public void Release(String pluginFolder) {
            AppDomain pluginDoamin;
            if (_pluginDomains.TryGetValue(pluginFolder, out pluginDoamin)) {
                AppDomain.Unload(pluginDoamin);
                _pluginDomains.Remove(pluginFolder);
            }
        }

        public void ReleaseAll() {
            var unloadTasks = _pluginDomains.Select(async p =>
                await Task.Run(action: () => AppDomain.Unload(p.Value))).ToArray();
            Task.WaitAll(unloadTasks);
            _pluginDomains.Clear();
        }

        public void Dispose() {
            ReleaseAll();
        }
    }

業務邏輯的入口在哪里？我們來看一個場景和實例。計數應用需要從特定隊列出隊，然后操作數據庫。我們定義接口 IFeature 及其實現；擴展 PluginCatalog<IFeature> 添加 StartAll() 作為業務入口；

    public interface IFeature {
        void Start();
    }

    public class MyFeature : IFeature {

        public void Start() {
            Console.WriteLine("MyFeature.Start()");
            // Grab message from message queue, calculate & persistence 
        }
    }

    public class MyPluginCatalog : PluginCatalog {

        public void StartAll() {
            Console.WriteLine("MyPluginCatalog.StartAll()");
            foreach (var feature in FindPlugins()) {
                feature.Start();
            }
        }
    }

PluginCatalogProxy.Construct() 方法獲取到了用戶定義的 PluginCatalog<T> 子類對象，而 FindPlugins() 在 MyPluginCatalog 內部使用，使得任何 IFeature 都不需要跨 AppDomain 邊界訪問；這里忽略掉了不是重點的 Timer 相關代碼。

    static void Main(string[] args) {
        var pluginCatalogProxy = new PluginCatalogProxy();
        var pluginFolder = AppDomain.CurrentDomain.BaseDirectory; // Define your own plugin folder
        var pluginCatalog = pluginCatalogProxy.Construct(pluginFolder);

        pluginCatalog.StartAll();
        pluginCatalogProxy.Release(pluginFolder);
    }

IPluginCatalog 是前文 MarshalByRefTypePluginProxy 邏輯的體現，配合 PluginCatalogProxy.Construct() 方法，應用開發人員可以獲取到自定義 IPluginCatalog 實現類的實例而不僅僅是 IPluginCatalog 接口，這為應用開發人員提供業務入口，並將業務邏輯隔離在自定義 AppDomain 中處理，規避了實現類的跨 AppDomain 邊界問題; PluginCatalogProxy 管理維護着自定義 AppDomain 的生命周期，控制了其可見性。

應用開發人員通過引用 PluginCatalogProxy 和自定義 IPluginCatalog 實例可以完成業務調用、資源清理；也可以重寫相關實現定制 AppDomain；在上層應用中通過文件監視，動態的插件加載、卸載不在話下；原理並不復雜，園友完全可以自行實現，處理好 AppDomain 邊界問題即可。

在技術上，可以對 PluginCatalogProxy 使用單例模式，只是喪失了對其內部實現的修改能力; IPluginCatalog<out T>.FindPlugins() 也只是希望在子類調用而不是任何地方，可以在其實現中顯式實現該接口來達到目的，大概是這樣子：

public class PluginCatalog : MarshalByRefObject, IPluginCatalog {
        //...
        protected virtual IEnumerable FindPlugins() {
            var resolver = new ReflectionPluginResolver();
            return resolver.FindAll(PluginFolder);
        }

        IEnumerable IPluginCatalog.FindPlugins() {
            return FindPlugins();
        }
    }

6. 后記

泛型與逆變使用可能有些晦澀，看多兩次也不是太難理解，思路最重要。

關於插件的部署方式，我的實踐如前文所提，宿主程序的根目錄下創建文件夾，各業務實現再分別創建子文件夾；為了達到不停止插件宿主更新插件的目標，我們並不能直接在上述文件夾中進行類型發現和加載，而是需要使用一個拷貝目錄，監視插件目錄並原樣復制，當發現插件目標更新時，優雅地停止相關業務邏輯、卸載對應 AppDomain、更新對應的文件拷貝、重新啟動業務邏輯。

不得說說 Asp.Net，實踐中我們知道無論是修改 Web.config 還是覆蓋新的 dll，下次訪問時站點會再次 JIT 編譯，原理和剛才描述的大致相同，站點被復制到了特定臨時文件夾，w3wp 通過額外的 AppDomain 寄宿了我們的站點。從這個意義 MVC 應用的插件化重點並不在於如何管理 AppDomain，路由注冊、虛擬目錄和視圖查找才是重點，盜圖一張幫助理解。

插件系統中的異常處理是不小的話題，自定義 AppDomain 里的異步線程下未處理異常是進程 Crash 的罪魁禍首——— w3wp 進程常常這么沒了，而MAF 具有防止宿主崩潰的特性；而資源監控和分配需要更深入的實踐。

以上代碼已在項目中使用，稍后整理了丟上來。

Jusfr 原創，轉載請注明來自博客園。