微內核架構(Microkernel Architecture)
微內核架構有時也被成為插件架構模式（plug-in architecture pattern），通常用於實現基於產品的應用，如Eclipse和Firefox。然而許多公司也將內部的業務軟件做成軟件產品，提供版本、發版說明和插件特性。微內核架構模式通過插件向核心應用添加額外的功能，提供了可擴展性和功能的獨立和分離。
模式描述
微內核架構包含兩部分組件：核心系統（core system）和插件模塊（plug-in modules）。應用邏輯被分割為獨立的插件模塊和核心系統，提供了可擴展性、靈活性、功能隔離和自定義處理邏輯的特性。
圖1 微內核架構模式（microkernel architecture pattern）
微內核架構的核心系統通常提供系統運行所需的最小功能集。許多操作系統使用的就是微內核架構，這也是它名字的由來。從商業應用程序的角度來看，核心系統一般是通用業務邏輯，沒有特殊情況、特殊規則或復雜情形下的自定義代碼。
插件模塊是獨立的模塊，包含特定的處理、額外的功能和自定義代碼，來向核心系統增強或擴展額外的業務能力。通常插件模塊之間也是獨立的，也有一些插件是依賴於若干其它插件的。重要的是，盡量減少插件之間的通信以避免依賴的問題。
核心系統需要知道哪些插件是可用的且如何使用。一種實現的方式是使用插件注冊表。注冊表中包含插件的一些信息，如名稱、數據契約（輸入數據和輸出數據）、遠程訪問協議（決定插件如何與核心系統連接，XML或WSDL等）。
插件模塊和核心系統的連接方式有多種，包括OSGi (open service gateway initiative)、messaging、web service、甚至點對點綁定（對象實例化）。選擇哪種連接方式取決於構件的應用類型和是否分布式部署等特殊需求。
插件和核心系統之間的契約也是各種各樣的，既可以是標准的也可以是自定義的。通常在使用第三方插件時需要自定義契約。這種情況下，通常創建一個該插件契約到你的標准契約的適配器，這樣核心系統就不需要針對每個插件的定制編碼了。創建標准契約時（通常為XML），要記得從一開始就設計好版本策略。
案例
微內核架構最好的案例也許就是Eclipse啦。下載基礎版本的Ecilpse或許只比一個功能花哨的編輯器強一點，一旦裝上一些插件，它立刻就變成高度定制化的很有用的產品。瀏覽器也是微內核架構產品的典型案例。
這樣的基於產品的軟件例子數不勝數，但是大型商業應用呢？微內核結構也是適用的。這里再以保險公司的索賠處理為例。（書中的例子都不符合國情，看着挺費勁的。）
索賠處理過程很復雜，每個階段都有很多不同的規則和條例來說明是否應該得到賠償。例如汽車擋風玻璃被岩石擊碎，有的州是允許賠償的，有的是不允許的。標准的索賠過程幾乎有無限的條件。
通常保險索賠應用都會使用一個大型的復雜的規則引擎來處理。但是規則引擎會像滾雪球一樣越來越大，修改一個規則可能會影響其它的規則，或者一個簡單的規則修改需要很多分析人員、開發人員和測試人員。使用微內核架構模式可以避免這樣的問題。
如圖2中所示，核心系統claims processing包含了處理索賠過程的基本業務邏輯。每個插件模塊包含一個州的特殊規則。這個例子中，插件模塊可以通過自定義代碼或分離規則引擎實例來實現。最重要的是，每個州的獨特的規則從核心系統中剝離出來，可以被添加或移除，修改時不影響或會稍微影響核心系統與其它插件。
圖2 微內核架構案例
注意事項
微內核架構模式的一個優秀之處在於它可以嵌入或者作為其它架構模式的一部分。例如事件驅動架構中的事件處理組件就可以使用微內核架構實現。
微內核架構為遞進設計和增量開發提供了方便。可以先實現一個穩固的核心系統，然后在不對核心系統進行大量修改的情況下逐漸地增加功能和特性。
對於基於產品的應用，微內核架構是一開始的首選。尤其是這樣的產品：隨着時間逐漸地發布新功能，而且希望保證所有的用戶都能獲取到新功能。如果以后發現該架構不符合需求了，可以隨時重構成其它架構。
模式分析
下表展示了分層架構模式的通用架構特性的評級和分析。
整體靈活性
評級：高
分析：整體靈活性是對環境變化快速響應的能力。由於插件之間的低耦合，改變通常是隔離的，可以快速實現。通常，核心系統是穩定且快速的，具有一定的健壯性，幾乎不需要修改。
易於部署
評級：高
分析：取決於實現方式，插件可以在運行時動態添加（熱部署），最小化部署的停機時間。
可測試性
評級：高
分析：插件可以獨立測試，也很容易被模擬，不需修改核心系統就可以演示或構建新特性的原型。
性能
評級：高
分析：雖然微內核架構本身不會使應用高性能，但通常使用微內核架構構建的應用性能都還不錯，因為可以自定義或者裁剪掉不需要的功能。JBoss應用服務器就是這樣的。
可伸縮性
評級：低
分析：因為大部分微內核架構的實現都是基於產品的，一般都很小，是一個獨立的單元，因此不具有高可伸縮性。取決於插件的實現方式，有時在插件特性層可以提供伸縮性，但總體上來說該架構還是用於構建高可伸縮性應用的。
開發容易度
評級：低
分析：微內核架構需要深思熟慮的設計和契約的規划管理，因此實現起來比較復雜。契約的版本機制、插件的注冊機制、插件的粒度、插件連接方式的選擇都使得實現起來是復雜的。
參考資料：