概述：

• 內(nèi)核模式也被稱為插件架構模式。
• 將附加應用程序功能作為插件添加到核心應用程序，以提供可擴展性以及功能分離和隔離。 這種模式由兩種類型的架構組件組成：一個核心系統(tǒng)和插件模塊。
• 應用程序邏輯分布在獨立的插件模塊和基礎核心系統(tǒng)之間，提供應用程序特性和定制處理邏輯的可擴展性、靈活性和隔離性。
• 從業(yè)務應用的角度看，核心系統(tǒng)通常被定義為沒有特殊情況、特殊規(guī)則或復雜條件處理的定制代碼的通用業(yè)務邏輯。
• 插件模塊是獨立的、獨立的組件，包含專門的處理、額外的特性和定制代碼，這些代碼旨在增強或擴展核心系統(tǒng)以產(chǎn)生額外的業(yè)務能力。保持插件之間的通信最少是非常重要的，以避免依賴性問題。
• 注冊表包含每個插件模塊的信息，包括其名稱、數(shù)據(jù)協(xié)議和遠程訪問協(xié)議詳情（取決于插件如何連接到核心系統(tǒng)）。
• 插件模塊可以通過多種方式連接到核心系統(tǒng)，包括OSGi（開放服務網(wǎng)關倡議）、消息傳遞、網(wǎng)絡服務，甚至直接的點對點綁定（即，對象實例化）。
• 當插件組件由第三方開發(fā)，而你無法控制插件使用的合約時。在這種情況下，通常會創(chuàng)建一個適配器，將插件合約與你的標準合約進行對接，這樣核心系統(tǒng)就不需要為每個插件編寫專門的代碼。

微內(nèi)核架構

微內(nèi)核架構模式（有時被稱為插件架構模式）是實現(xiàn)基于產(chǎn)品的應用程序的自然模式?；诋a(chǎn)品的應用程序是那種打包并以版本形式供下載的典型的第三方產(chǎn)品。然而，許多公司也像軟件產(chǎn)品一樣開發(fā)和發(fā)布他們的內(nèi)部業(yè)務應用程序，配有版本、發(fā)布說明和可插拔特性。這些也是這種模式的自然適合。微內(nèi)核架構模式允許你將額外的應用程序特性作為插件添加到核心應用程序，提供可擴展性以及特性的分離和隔離。

模式描述

微內(nèi)核架構模式由兩種類型的架構組件組成：一個核心系統(tǒng)和插件模塊。應用程序邏輯分布在獨立的插件模塊和基礎核心系統(tǒng)之間，提供應用程序特性和定制處理邏輯的可擴展性、靈活性和隔離性。圖3-1展示了基本的微內(nèi)核架構模式。

微內(nèi)核架構模式的核心系統(tǒng)傳統(tǒng)上只包含使系統(tǒng)運行所需的最小功能。許多操作系統(tǒng)實現(xiàn)了微內(nèi)核架構模式，這也是這個模式名字的由來。從業(yè)務應用的角度來看，核心系統(tǒng)通常被定義為沒有特殊情況、特殊規(guī)則或復雜條件處理的定制代碼的通用業(yè)務邏輯。

插件模塊是獨立的、獨立的組件，包含專門的處理、額外的特性和定制代碼，這些代碼旨在增強或擴展核心系統(tǒng)以產(chǎn)生額外的業(yè)務能力。通常來說，插件模塊應該獨立于其他插件模塊，但你當然可以設計需要其他插件存在的插件。無論如何，保持插件之間的通信最少是非常重要的，以避免依賴性問題。

核心系統(tǒng)需要知道哪些插件模塊是可用的，以及如何訪問它們。實現(xiàn)這一點的一種常見方法是通過某種插件注冊表。這個注冊表包含每個插件模塊的信息，包括其名稱、數(shù)據(jù)協(xié)議和遠程訪問協(xié)議詳情（取決于插件如何連接到核心系統(tǒng)）。例如，一個用于標記高風險稅務審計項目的稅務軟件插件可能有一個注冊表條目，包含服務的名稱（AuditChecker）、數(shù)據(jù)協(xié)議（輸入數(shù)據(jù)和輸出數(shù)據(jù)）和協(xié)議格式（XML）。如果通過SOAP訪問插件，它也可能包含一個WSDL（Web服務定義語言）。

插件模塊可以通過多種方式連接到核心系統(tǒng)，包括OSGi（開放服務網(wǎng)關倡議）、消息傳遞、網(wǎng)絡服務，甚至直接的點對點綁定（即，對象實例化）。你使用的連接類型取決于你正在構建的應用程序類型（小型產(chǎn)品或大型業(yè)務應用程序）和你的特定需求（例如，單一部署或分布式部署）。這種架構模式本身并沒有指定任何這些實現(xiàn)細節(jié)，只要求插件模塊必須彼此獨立。

插件模塊與核心系統(tǒng)之間的合約可以從標準合約到定制合約。定制合約通常出現(xiàn)在插件組件由第三方開發(fā)，而你無法控制插件使用的合約的情況中。在這種情況下，通常會創(chuàng)建一個適配器，將插件合約與你的標準合約進行對接，這樣核心系統(tǒng)就不需要為每個插件編寫專門的代碼。在創(chuàng)建標準合約（通常通過XML或Java Map實現(xiàn)）時，重要的是要記住從一開始就創(chuàng)建一個版本策略。

模式示例

或許微內(nèi)核架構最好的例子是Eclipse IDE。下載基本的Eclipse產(chǎn)品只能為你提供一個花哨的編輯器。然而，一旦你開始添加插件，它就會變成一個高度可定制和有用的產(chǎn)品?；ヂ?lián)網(wǎng)瀏覽器是使用微內(nèi)核架構的另一個常見產(chǎn)品示例：瀏覽器和其他插件添加了基本瀏覽器（即，核心系統(tǒng)）中找不到的額外功能。

對于基于產(chǎn)品的軟件，例子數(shù)不勝數(shù)，但大型業(yè)務應用程序呢？微內(nèi)核架構也適用于這些情況。為了說明這一點，讓我們使用另一個保險公司的例子，但這次涉及的是保險索賠處理。

索賠處理是一個非常復雜的過程。每個州對保險索賠的允許和不允許都有不同的規(guī)則和規(guī)定。例如，一些州允許如果你的擋風玻璃被石頭破壞，免費更換擋風玻璃，而其他州則不允許。這為標準索賠流程創(chuàng)建了近乎無限的條件集。

不出所料，大多數(shù)保險索賠應用程序利用大型和復雜的規(guī)則引擎來處理這種復雜性。然而，這些規(guī)則引擎可以演變成一個復雜的大泥球，改變一個規(guī)則會影響其他規(guī)則，或者進行簡單的規(guī)則更改需要大量的分析師、開發(fā)人員和測試人員。使用微內(nèi)核架構模式可以解決這些問題。

你在下圖看到的文件夾堆表示的是索賠處理的核心系統(tǒng)。它包含保險公司處理索賠所需的基本業(yè)務邏輯，只是沒有任何定制處理。每個插件模塊包含該州的特定規(guī)則。在這個例子中，插件模塊可以使用定制的源代碼或單獨的規(guī)則引擎實例來實現(xiàn)。無論實現(xiàn)方式如何，關鍵點是，特定州的規(guī)則和處理與核心索賠系統(tǒng)是分開的，可以被添加、移除和更改，對核心系統(tǒng)或其他插件模塊的其余部分影響微乎其微。

結(jié)論

以下是微內(nèi)核架構模式的優(yōu)點和缺點。

優(yōu)點：

1. 它可以在最小化改變核心系統(tǒng)的同時，對插件模塊的改變做出反應。
2. 不像分層架構，有插件模塊意味著部署更容易，從而最小化停機時間。
3. 測試也更容易，因為可以單獨測試每個模塊。
4. 盡管一般來說并不是用于高性能應用的理想模式，但是由于只包含所需的功能來定制應用，它可以表現(xiàn)得很好。

缺點：

1. 應用程序傾向于較小的規(guī)模，因此并不具有很高的可擴展性。
2. 需要在實現(xiàn)之前進行徹底的設計分析。需要分析的項目包括合約版本控制、內(nèi)部插件注冊表、插件粒度，以及插件連接的多樣選擇。