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