建站
咨詢
售后
建站咨詢
新聞中心
概述：
- 內(nèi)核模式也被稱為插件架構(gòu)模式。
- 將附加應(yīng)用程序功能作為插件添加到核心應(yīng)用程序，以提供可擴(kuò)展性以及功能分離和隔離。 這種模式由兩種類型的架構(gòu)組件組成：一個核心系統(tǒng)和插件模塊。
- 應(yīng)用程序邏輯分布在獨(dú)立的插件模塊和基礎(chǔ)核心系統(tǒng)之間，提供應(yīng)用程序特性和定制處理邏輯的可擴(kuò)展性、靈活性和隔離性。
- 從業(yè)務(wù)應(yīng)用的角度看，核心系統(tǒng)通常被定義為沒有特殊情況、特殊規(guī)則或復(fù)雜條件處理的定制代碼的通用業(yè)務(wù)邏輯。
- 插件模塊是獨(dú)立的、獨(dú)立的組件，包含專門的處理、額外的特性和定制代碼，這些代碼旨在增強(qiáng)或擴(kuò)展核心系統(tǒng)以產(chǎn)生額外的業(yè)務(wù)能力。保持插件之間的通信最少是非常重要的，以避免依賴性問題。
- 注冊表包含每個插件模塊的信息，包括其名稱、數(shù)據(jù)協(xié)議和遠(yuǎn)程訪問協(xié)議詳情（取決于插件如何連接到核心系統(tǒng)）。
- 插件模塊可以通過多種方式連接到核心系統(tǒng)，包括OSGi（開放服務(wù)網(wǎng)關(guān)倡議）、消息傳遞、網(wǎng)絡(luò)服務(wù)，甚至直接的點(diǎn)對點(diǎn)綁定（即，對象實(shí)例化）。
- 當(dāng)插件組件由第三方開發(fā)，而你無法控制插件使用的合約時。在這種情況下，通常會創(chuàng)建一個適配器，將插件合約與你的標(biāo)準(zhǔn)合約進(jìn)行對接，這樣核心系統(tǒng)就不需要為每個插件編寫專門的代碼。
微內(nèi)核架構(gòu)
微內(nèi)核架構(gòu)模式（有時被稱為插件架構(gòu)模式）是實(shí)現(xiàn)基于產(chǎn)品的應(yīng)用程序的自然模式?；诋a(chǎn)品的應(yīng)用程序是那種打包并以版本形式供下載的典型的第三方產(chǎn)品。然而，許多公司也像軟件產(chǎn)品一樣開發(fā)和發(fā)布他們的內(nèi)部業(yè)務(wù)應(yīng)用程序，配有版本、發(fā)布說明和可插拔特性。這些也是這種模式的自然適合。微內(nèi)核架構(gòu)模式允許你將額外的應(yīng)用程序特性作為插件添加到核心應(yīng)用程序，提供可擴(kuò)展性以及特性的分離和隔離。
成都創(chuàng)新互聯(lián)主打移動網(wǎng)站、網(wǎng)站建設(shè)、成都網(wǎng)站建設(shè)、網(wǎng)站改版、網(wǎng)絡(luò)推廣、網(wǎng)站維護(hù)、主機(jī)域名、等互聯(lián)網(wǎng)信息服務(wù)，為各行業(yè)提供服務(wù)。在技術(shù)實(shí)力的保障下，我們?yōu)榭蛻舫兄Z穩(wěn)定，放心的服務(wù)，根據(jù)網(wǎng)站的內(nèi)容與功能再決定采用什么樣的設(shè)計(jì)。最后，要實(shí)現(xiàn)符合網(wǎng)站需求的內(nèi)容、功能與設(shè)計(jì)，我們還會規(guī)劃穩(wěn)定安全的技術(shù)方案做保障。
模式描述
微內(nèi)核架構(gòu)模式由兩種類型的架構(gòu)組件組成：一個核心系統(tǒng)和插件模塊。應(yīng)用程序邏輯分布在獨(dú)立的插件模塊和基礎(chǔ)核心系統(tǒng)之間，提供應(yīng)用程序特性和定制處理邏輯的可擴(kuò)展性、靈活性和隔離性。圖3-1展示了基本的微內(nèi)核架構(gòu)模式。
微內(nèi)核架構(gòu)模式的核心系統(tǒng)傳統(tǒng)上只包含使系統(tǒng)運(yùn)行所需的最小功能。許多操作系統(tǒng)實(shí)現(xiàn)了微內(nèi)核架構(gòu)模式，這也是這個模式名字的由來。從業(yè)務(wù)應(yīng)用的角度來看，核心系統(tǒng)通常被定義為沒有特殊情況、特殊規(guī)則或復(fù)雜條件處理的定制代碼的通用業(yè)務(wù)邏輯。
插件模塊是獨(dú)立的、獨(dú)立的組件，包含專門的處理、額外的特性和定制代碼，這些代碼旨在增強(qiáng)或擴(kuò)展核心系統(tǒng)以產(chǎn)生額外的業(yè)務(wù)能力。通常來說，插件模塊應(yīng)該獨(dú)立于其他插件模塊，但你當(dāng)然可以設(shè)計(jì)需要其他插件存在的插件。無論如何，保持插件之間的通信最少是非常重要的，以避免依賴性問題。
核心系統(tǒng)需要知道哪些插件模塊是可用的，以及如何訪問它們。實(shí)現(xiàn)這一點(diǎn)的一種常見方法是通過某種插件注冊表。這個注冊表包含每個插件模塊的信息，包括其名稱、數(shù)據(jù)協(xié)議和遠(yuǎn)程訪問協(xié)議詳情（取決于插件如何連接到核心系統(tǒng)）。例如，一個用于標(biāo)記高風(fēng)險(xiǎn)稅務(wù)審計(jì)項(xiàng)目的稅務(wù)軟件插件可能有一個注冊表?xiàng)l目，包含服務(wù)的名稱（AuditChecker）、數(shù)據(jù)協(xié)議（輸入數(shù)據(jù)和輸出數(shù)據(jù)）和協(xié)議格式（XML）。如果通過SOAP訪問插件，它也可能包含一個WSDL（Web服務(wù)定義語言）。
插件模塊可以通過多種方式連接到核心系統(tǒng)，包括OSGi（開放服務(wù)網(wǎng)關(guān)倡議）、消息傳遞、網(wǎng)絡(luò)服務(wù)，甚至直接的點(diǎn)對點(diǎn)綁定（即，對象實(shí)例化）。你使用的連接類型取決于你正在構(gòu)建的應(yīng)用程序類型（小型產(chǎn)品或大型業(yè)務(wù)應(yīng)用程序）和你的特定需求（例如，單一部署或分布式部署）。這種架構(gòu)模式本身并沒有指定任何這些實(shí)現(xiàn)細(xì)節(jié)，只要求插件模塊必須彼此獨(dú)立。
插件模塊與核心系統(tǒng)之間的合約可以從標(biāo)準(zhǔn)合約到定制合約。定制合約通常出現(xiàn)在插件組件由第三方開發(fā)，而你無法控制插件使用的合約的情況中。在這種情況下，通常會創(chuàng)建一個適配器，將插件合約與你的標(biāo)準(zhǔn)合約進(jìn)行對接，這樣核心系統(tǒng)就不需要為每個插件編寫專門的代碼。在創(chuàng)建標(biāo)準(zhǔn)合約（通常通過XML或Java Map實(shí)現(xiàn)）時，重要的是要記住從一開始就創(chuàng)建一個版本策略。
模式示例
或許微內(nèi)核架構(gòu)最好的例子是Eclipse IDE。下載基本的Eclipse產(chǎn)品只能為你提供一個花哨的編輯器。然而，一旦你開始添加插件，它就會變成一個高度可定制和有用的產(chǎn)品?；ヂ?lián)網(wǎng)瀏覽器是使用微內(nèi)核架構(gòu)的另一個常見產(chǎn)品示例：瀏覽器和其他插件添加了基本瀏覽器（即，核心系統(tǒng)）中找不到的額外功能。
對于基于產(chǎn)品的軟件，例子數(shù)不勝數(shù)，但大型業(yè)務(wù)應(yīng)用程序呢？微內(nèi)核架構(gòu)也適用于這些情況。為了說明這一點(diǎn)，讓我們使用另一個保險(xiǎn)公司的例子，但這次涉及的是保險(xiǎn)索賠處理。
索賠處理是一個非常復(fù)雜的過程。每個州對保險(xiǎn)索賠的允許和不允許都有不同的規(guī)則和規(guī)定。例如，一些州允許如果你的擋風(fēng)玻璃被石頭破壞，免費(fèi)更換擋風(fēng)玻璃，而其他州則不允許。這為標(biāo)準(zhǔn)索賠流程創(chuàng)建了近乎無限的條件集。
不出所料，大多數(shù)保險(xiǎn)索賠應(yīng)用程序利用大型和復(fù)雜的規(guī)則引擎來處理這種復(fù)雜性。然而，這些規(guī)則引擎可以演變成一個復(fù)雜的大泥球，改變一個規(guī)則會影響其他規(guī)則，或者進(jìn)行簡單的規(guī)則更改需要大量的分析師、開發(fā)人員和測試人員。使用微內(nèi)核架構(gòu)模式可以解決這些問題。
你在下圖看到的文件夾堆表示的是索賠處理的核心系統(tǒng)。它包含保險(xiǎn)公司處理索賠所需的基本業(yè)務(wù)邏輯，只是沒有任何定制處理。每個插件模塊包含該州的特定規(guī)則。在這個例子中，插件模塊可以使用定制的源代碼或單獨(dú)的規(guī)則引擎實(shí)例來實(shí)現(xiàn)。無論實(shí)現(xiàn)方式如何，關(guān)鍵點(diǎn)是，特定州的規(guī)則和處理與核心索賠系統(tǒng)是分開的，可以被添加、移除和更改，對核心系統(tǒng)或其他插件模塊的其余部分影響微乎其微。
結(jié)論
以下是微內(nèi)核架構(gòu)模式的優(yōu)點(diǎn)和缺點(diǎn)。
優(yōu)點(diǎn)：
- 它可以在最小化改變核心系統(tǒng)的同時，對插件模塊的改變做出反應(yīng)。
- 不像分層架構(gòu)，有插件模塊意味著部署更容易，從而最小化停機(jī)時間。
- 測試也更容易，因?yàn)榭梢詥为?dú)測試每個模塊。
- 盡管一般來說并不是用于高性能應(yīng)用的理想模式，但是由于只包含所需的功能來定制應(yīng)用，它可以表現(xiàn)得很好。
缺點(diǎn)：
- 應(yīng)用程序傾向于較小的規(guī)模，因此并不具有很高的可擴(kuò)展性。
- 需要在實(shí)現(xiàn)之前進(jìn)行徹底的設(shè)計(jì)分析。需要分析的項(xiàng)目包括合約版本控制、內(nèi)部插件注冊表、插件粒度，以及插件連接的多樣選擇。
標(biāo)題名稱：我們一起聊聊【軟件架構(gòu)模式】—微內(nèi)核架構(gòu)
網(wǎng)頁地址：http://www.dlmjj.cn/article/cdgjceh.html
