微內核架構（Microkernel Architecture），也被成為插件化架構（Plug-in Architecture）,是一種面向功能進行拆分的可擴展性架構，通常用于實現基于產品（原文為product-based，指存在多個版本，需要下載安裝才能使用，與web-based想對應）的應用。例如Eclipse這類IDE軟件、UNIX這類操作系統、淘寶App這類客戶端軟件等，也有一些企業將自己的業務系統設計成微內核的架構，例如保險公司的保險核算邏輯系統，不同的保險品種可以將邏輯封裝成插件。

基本架構

微內核架構包含兩類組件：核心系統（core system）和插件模塊（plug-in modules）。核心系統負責和具體業務功能無關的通用功能，例如模塊加載、模塊間通信等；插件模塊負責實現具體的業務邏輯

上面這張圖中核心系統Core System功能比較穩定，不會因為業務功能擴展而不斷修改，插件模塊可以根據業務功能的需要不斷擴展。微內核架構的本質就是將變化封裝在插件里面，從而達到快速靈活擴展的目的，而又不影響整體系統的穩定。

設計關鍵點

微內核的核心系統設計的關鍵技術有：插件管理，插件連接和插件通信

1、插件管理

插件系統需要知道當前有哪些插件可用，如何加載這些插件，什么時候加載插件，常見的實現方法是插件注冊表機制。
核心系統提供插件注冊表（可以是配置文件，也可以是代碼，還可以是數據庫），插件注冊表含有每個插件模塊的信息，包括它的名字、位置、加載時機（啟動就加載，還是按需加載等）

2、插件連接

插件連接指插件如何連接到核心系統。通常來說，核心系統必須制定插件和核心系統的連接規范，然后插件按照規范實現，核心系統按照規范加載即可。
常見的連接機制有OSGi（Eclipse使用）、消息模式、依賴注入（Spring使用），甚至使用分布式的協議都是可以的，比如RPC或者HTTP Web的方式。

3、插件通信

通信必須經過核心系統，因此核心系統需要提供插件通信機制。這種情況和計算機類似，計算機的CPU、硬盤、內存、網卡是獨立設計的配件，但計算機運行過程中，CPU和內存，內存和硬盤肯定是有通信的，計算機通過主板的總線提供了這些組件之間的通信功能。微內核的核心系統也必須提供類似的通信機制，各個插件之間才能正常的通信。

OSGi架構簡介

OSGi的全稱是Open Services Gateway intiative,本身其實是指OSGi Alliance。這個聯盟是Sun Microsystems、IBM、愛立信等公司于1999年3月成立的開放的標準化組織，最初名為Connected Alliance。它是一個非盈利的國際組織，旨在建立一個開放的服務規范，為通過網絡向設備提供服務建立開放的標準，這個標準就是OSGi specification。現在我們談到OSGi，如果沒有特別說明，一般是指OSGi的規范。
OSGi聯盟的初始目標是構建一個在廣域網和局域網或設備上展開業務的基礎平臺，所以OSGi的最初設計也是針對嵌入式應用的，諸如機頂盒、服務網關、手機
、汽車等都是其應用的主要環境。然而，無心插柳柳成蔭，由于OSGi具備動態化、熱插拔、高可復用性、高效性、擴展方便等優點，它被應用到了PC上的應用開發。尤其是Eclipse這個流行軟件采用OSGi標準后，OSGi更是成為了首選的插件化標準。現在我們談OSGi已經和嵌入式應用關系不大了，更多是將OSGi當做一個微內核的架構模式。
Eclipse3.0開始，拋棄了自己實現的插件化框架，改用OSGi插件化框架。需要注意的是OSGi是一個插件化的標準，而不是一個可運行的框架，Eclipse采用的OSGi框架為Equinox，類似的實現還有Apache的Felix、Spring的Spring DM。
OSGi框架的邏輯架構圖如下：

1、模塊層（module層）

模塊層實現插件管理功能。OSGi中，插件被稱為Bundle，每個Bundle是一個java的jar文件，每個Bundle里面都包含一個元數據文件MANIFEST.MF，這個文件包含了Bundle的基本信息。例如，Bundle的名稱、描述、開發商、classpath，以及需要導入的包和輸出的包等，OSGi核心系統會將這些信息加載到系統中用于后續使用。
一個簡單的MANIFEST.MF樣例如下：

Manifest-Version: 1.0 Archiver-Version: Plexus Archiver Built-By: liuzhe Created-By: Apache Maven 3.5.3 Build-Jdk: 1.8.0_162

2、聲明周期層

聲明周期層實現插件連接功能，提供了執行時模塊管理、模塊對底層OSGi框架的訪問。生命周期層精確的定義了Bundle生命周期的操作（安裝、更新、啟動、停止、卸載），Bundle必須按照規范實現各個操作，例如：

public class NettyBundleActivator implements BundleActivator {private OsgiLoggerFactory loggerFactory;public NettyBundleActivator() {}public void start(BundleContext ctx) throws Exception {this.loggerFactory = new OsgiLoggerFactory(ctx);InternalLoggerFactory.setDefaultFactory(this.loggerFactory);}public void stop(BundleContext ctx) throws Exception {if (this.loggerFactory != null) {InternalLoggerFactory.setDefaultFactory(this.loggerFactory.getFallback());this.loggerFactory.destroy();this.loggerFactory = null;}} }

3、服務層（service層）

服務層實現插件通信的功能。OSGi提供了一個服務注冊的功能，用于各個插件將自己提供的服務注冊到OSGi核心的注冊中心，如果某個服務想用其他服務，則直接在服務注冊中心搜索可用中心即可。

規則引擎架構簡析

規則引擎從結構上來看也屬于微內核架構的一種具體體現，其中執行引擎可以看做是微內核，執行引擎解析配置好的業務流，執行其中的條件和規則，通過這種方式來支持業務的靈活多變。
規則引擎在計費、保險、促銷等領域應用較多。例如電商促銷，常見的促銷規則有：

• 3件8折
• 第三件免費
• 跨店滿200減100
• 新用戶立減50
• …
  以上僅僅列出來常見的幾種，實際上完整列下來可能有幾十上百種，再加上排列組合，促銷方案，可能有幾百上千種，這樣的業務如果靠代碼來實現，開發效率完全跟不上業務的變化速度，而規則引擎卻能很靈活的應對這種需求，主要原因在于：

1、可擴展

通過引入規則引擎，業務邏輯實現與業務系統分離，可以在不改動業務系統的情況下擴展新的業務功能

2、易理解

規則通過自然語言描述，業務人員易于理解和操作，而不像代碼那樣只有程序員才能理解和開發。

3、高效率

規則引擎系統一般提供可視化的規則定制、審批、查詢及管理，方便業務人員快速配置新的業務。
規則引擎基本架構如下：

• 開發人員將業務功能分解提煉為多個規則，將規則保存在規則庫中
• 業務人員根據業務需要，通過將規則排列組合，配置成業務流程，保存在業務庫中
• 規則引擎執行業務流程，實現業務功能
  對照微內核架構的設計關鍵點，看看規則引擎是如何實現的

1、插件管理

規則引擎中的規則就是微內核架構中的插件，引擎就是微內核架構的內核。規則可以被引擎加載和執行。規則引擎架構中，規則一般保存在規則庫中，使用數據庫來存儲。

2、插件連接

業務人員需要基于規則語言來編寫規則文件，然后有規則引擎加載執行規則文件來直線業務功能。因為規則引擎的插件連接實現機制，其實就是規則語言。

3、插件通信

單個規則并不需要依賴其他規則，因此規則之間沒有主動的通信，規則只需要輸出數據或者事件。

總結

以上是生活随笔為你收集整理的微内核架构的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。