我們一起聊聊【軟件架構模式】—微內核架構
概述：
- 內核模式也被稱為插件架構模式。
- 將附加應用程序功能作為插件添加到核心應用程序，以提供可擴展性以及功能分離和隔離。 這種模式由兩種類型的架構組件組成：一個核心系統和插件模塊。
- 應用程序邏輯分布在獨立的插件模塊和基礎核心系統之間，提供應用程序特性和定制處理邏輯的可擴展性、靈活性和隔離性。
- 從業務應用的角度看，核心系統通常被定義為沒有特殊情況、特殊規則或復雜條件處理的定制代碼的通用業務邏輯。
- 插件模塊是獨立的、獨立的組件，包含專門的處理、額外的特性和定制代碼，這些代碼旨在增強或擴展核心系統以產生額外的業務能力。保持插件之間的通信最少是非常重要的，以避免依賴性問題。
- 注冊表包含每個插件模塊的信息，包括其名稱、數據協議和遠程訪問協議詳情（取決于插件如何連接到核心系統）。
- 插件模塊可以通過多種方式連接到核心系統，包括OSGi（開放服務網關倡議）、消息傳遞、網絡服務，甚至直接的點對點綁定（即，對象實例化）。
- 當插件組件由第三方開發，而你無法控制插件使用的合約時。在這種情況下，通常會創建一個適配器，將插件合約與你的標準合約進行對接，這樣核心系統就不需要為每個插件編寫專門的代碼。
微內核架構
微內核架構模式（有時被稱為插件架構模式）是實現基于產品的應用程序的自然模式。基于產品的應用程序是那種打包并以版本形式供下載的典型的第三方產品。然而，許多公司也像軟件產品一樣開發和發布他們的內部業務應用程序，配有版本、發布說明和可插拔特性。這些也是這種模式的自然適合。微內核架構模式允許你將額外的應用程序特性作為插件添加到核心應用程序，提供可擴展性以及特性的分離和隔離。
模式描述
微內核架構模式由兩種類型的架構組件組成：一個核心系統和插件模塊。應用程序邏輯分布在獨立的插件模塊和基礎核心系統之間，提供應用程序特性和定制處理邏輯的可擴展性、靈活性和隔離性。圖3-1展示了基本的微內核架構模式。
微內核架構模式的核心系統傳統上只包含使系統運行所需的最小功能。許多操作系統實現了微內核架構模式，這也是這個模式名字的由來。從業務應用的角度來看，核心系統通常被定義為沒有特殊情況、特殊規則或復雜條件處理的定制代碼的通用業務邏輯。
插件模塊是獨立的、獨立的組件，包含專門的處理、額外的特性和定制代碼，這些代碼旨在增強或擴展核心系統以產生額外的業務能力。通常來說，插件模塊應該獨立于其他插件模塊，但你當然可以設計需要其他插件存在的插件。無論如何，保持插件之間的通信最少是非常重要的，以避免依賴性問題。
核心系統需要知道哪些插件模塊是可用的，以及如何訪問它們。實現這一點的一種常見方法是通過某種插件注冊表。這個注冊表包含每個插件模塊的信息，包括其名稱、數據協議和遠程訪問協議詳情（取決于插件如何連接到核心系統）。例如，一個用于標記高風險稅務審計項目的稅務軟件插件可能有一個注冊表條目，包含服務的名稱（AuditChecker）、數據協議（輸入數據和輸出數據）和協議格式（XML）。如果通過SOAP訪問插件，它也可能包含一個WSDL（Web服務定義語言）。
插件模塊可以通過多種方式連接到核心系統，包括OSGi（開放服務網關倡議）、消息傳遞、網絡服務，甚至直接的點對點綁定（即，對象實例化）。你使用的連接類型取決于你正在構建的應用程序類型（小型產品或大型業務應用程序）和你的特定需求（例如，單一部署或分布式部署）。這種架構模式本身并沒有指定任何這些實現細節，只要求插件模塊必須彼此獨立。
插件模塊與核心系統之間的合約可以從標準合約到定制合約。定制合約通常出現在插件組件由第三方開發，而你無法控制插件使用的合約的情況中。在這種情況下，通常會創建一個適配器，將插件合約與你的標準合約進行對接，這樣核心系統就不需要為每個插件編寫專門的代碼。在創建標準合約（通常通過XML或Java Map實現）時，重要的是要記住從一開始就創建一個版本策略。
模式示例
或許微內核架構最好的例子是Eclipse IDE。下載基本的Eclipse產品只能為你提供一個花哨的編輯器。然而，一旦你開始添加插件，它就會變成一個高度可定制和有用的產品。互聯網瀏覽器是使用微內核架構的另一個常見產品示例：瀏覽器和其他插件添加了基本瀏覽器（即，核心系統）中找不到的額外功能。
對于基于產品的軟件，例子數不勝數，但大型業務應用程序呢？微內核架構也適用于這些情況。為了說明這一點，讓我們使用另一個保險公司的例子，但這次涉及的是保險索賠處理。
索賠處理是一個非常復雜的過程。每個州對保險索賠的允許和不允許都有不同的規則和規定。例如，一些州允許如果你的擋風玻璃被石頭破壞，免費更換擋風玻璃，而其他州則不允許。這為標準索賠流程創建了近乎無限的條件集。
不出所料，大多數保險索賠應用程序利用大型和復雜的規則引擎來處理這種復雜性。然而，這些規則引擎可以演變成一個復雜的大泥球，改變一個規則會影響其他規則，或者進行簡單的規則更改需要大量的分析師、開發人員和測試人員。使用微內核架構模式可以解決這些問題。
你在下圖看到的文件夾堆表示的是索賠處理的核心系統。它包含保險公司處理索賠所需的基本業務邏輯，只是沒有任何定制處理。每個插件模塊包含該州的特定規則。在這個例子中，插件模塊可以使用定制的源代碼或單獨的規則引擎實例來實現。無論實現方式如何，關鍵點是，特定州的規則和處理與核心索賠系統是分開的，可以被添加、移除和更改，對核心系統或其他插件模塊的其余部分影響微乎其微。
結論
以下是微內核架構模式的優點和缺點。
優點：
- 它可以在最小化改變核心系統的同時，對插件模塊的改變做出反應。
- 不像分層架構，有插件模塊意味著部署更容易，從而最小化停機時間。
- 測試也更容易，因為可以單獨測試每個模塊。
- 盡管一般來說并不是用于高性能應用的理想模式，但是由于只包含所需的功能來定制應用，它可以表現得很好。
缺點：
- 應用程序傾向于較小的規模，因此并不具有很高的可擴展性。
- 需要在實現之前進行徹底的設計分析。需要分析的項目包括合約版本控制、內部插件注冊表、插件粒度，以及插件連接的多樣選擇。
