微核心架構

_sanjun發表於2019-04-22
架構
  • 注：文章來源：極客時間的專欄《從0開始學架構》
  • 微核心架構（Microkernel Architecture），也被稱為外掛化架構（Plug-in Architecture），是一種面向功能進行拆分的可擴充套件性架構，通常用於實現基於產品的應用
  • 例如Eclipse這類IDE軟體、UNIX這類作業系統、淘寶APP這類客戶端軟體等，也有一些企業將自己的業務系統設計成微核心的架構，例如保險公司的保險核算邏輯系統，不同的保險品種可以將邏輯封裝成外掛

基本架構

  • 微核心架構包含兩類元件：核心系統和外掛模組

核心系統

  • 主要負責和具體業務功能無關的通用功能，例如模組載入、模組間通訊等

外掛模組

  • 主要負責實現具體的業務邏輯，例如“學生資訊管理”系統中的“手機號碼註冊”功能

微核心的基本架構圖

微核心架構

  • 上圖中核心繫統功能比較穩定，不會因為業務功能擴充套件而不斷修改，外掛模組可以根據業務功能的需要不斷地擴充套件
  • 微核心的架構本質就是將變化部分封裝在外掛裡面，從而達到快速靈活擴充套件的目的，而又不影響整體系統的穩定

設計關鍵點

  • 微核心的核心繫統設計的關鍵技術有：外掛管理、外掛連線和外掛管理

1. 外掛管理

  • 核心系統需要知道當前有哪些外掛可用，如何載入這些外掛，什麼時候載入外掛。常見的實現方法是外掛登錄檔機制
  • 核心系統提供外掛登錄檔（可以是配置檔案，也可以是程式碼，還可以是資料庫），外掛登錄檔含有每個外掛模組的資訊，包括它的名字、位置、載入時機（啟動就載入，還是按需載入）等

2. 外掛連線

  • 指外掛如何連線到核心系統。通常來說，核心系統必須指定外掛和核心繫統的連線規範，然後外掛按照規範實現，核心系統按照規範載入即可
  • 常見的連線機制有OSGi（Eclipse使用）、訊息模式、依賴注入（Spring使用），甚至使用分散式的協議都是可以的，比如RPC或者HTTP Web的方式

3. 外掛通訊

  • 指外掛間的通訊。雖然設計的時候外掛間是完全解耦的，但實際業務執行過程中，必然會出現某個業務流程需要多個外掛協作，這就要求兩個外掛間進行通訊
  • 由於外掛之間沒有直接聯絡，通訊必須通過核心系統，因此核心系統需要提供外掛通訊機制
  • 這種情況和計算機類似，計算機的CPU、硬碟、記憶體、網路卡是獨立設計的配置，但計算機執行過程中，CPU和記憶體、記憶體和硬碟肯定是有通訊的，計算機通過主機板上的匯流排提供了這些元件之間的通訊功能
  • 微核心的核心繫統也必須提供類似的通訊機制，各個外掛之間才能進行正常的通訊

OSGi架構簡析

  • OSGi全稱是Open Service Gateway initiative，本身其實是指OSGi Alliance。它是一個非盈利的國際組織，旨在建立一個開放的服務規範，為通過網路向裝置提供服 務建立開放的標準，這個標準就是OSGi specification。如果沒有特別說明，一般都是指OSGi的規範
  • OSGi聯盟的初衷是構建一個在廣域網和區域網或裝置上展開業務的基礎平臺，所以OSGi的最早設計也是針對嵌入式應用的，諸如機頂盒、服務閘道器、手機、汽車等都是其應用的主要環境
  • 由於OSGi具備動態化、熱插拔、高可複用性、高效性、擴充套件方便等優點，它被應用了PC上的應用開發
  • 尤其是Eclipse這個流行軟體採用OSGi標準後，OSGi更是成了首選的外掛化標準
  • 現在OSGi已經和嵌入式應用關聯不大了，更多是將OSGi當做一個微核心的架構模式

OSGi框架的邏輯架構圖

微核心架構

1. 模組層（Module層）
  • 模組層實現外掛管理功能。OSGi中，外掛被稱為Bundle，每個Bundle是一個Java的JAR檔案，每個Bundle裡面都包含一個後設資料檔案MANIFEST.MF，這個檔案包含了Bundle的基本資訊
  • 例如，Bundle的名稱、描述、開發商、classpath，以及需要匯入的包和輸出的包等，OSGi核心系統會將這些資訊載入到系統中用於後續使用

一個簡單的MANIFEST.MF樣例如下

// MANIFEST.MF 
	Bundle-ManifestVersion: 2 
	Bundle-Name:UserRegister
	Bundle-SymbolicName: com.test.userregister 
	Bundle-Version: 1.0 
	Bundle-Activator: com.test.UserRegisterActivator
	 
	Import-Package: org.log4j;version="2.0", 
	..... 
	Export-Package: com.test.userregister;version="1.0", 

複製程式碼
2. 生命週期層（Lifecycle層）
  • 生命週期層實現外掛連線功能，提供了執行時模組管理、模組對底層OSGi框架的訪問
  • 生命週期層精確地定義了Bundle生命週期的操作（安裝、更新、啟動、停止、解除安裝），Bundle必須按照規範實現各個操作。例如：
public class UserRegisterActivator implements BundleActivator { 
	 
	 public void start(BundleContext context) { 
	     UserRegister.instance = new UserRegister (); 
	 } 
	 
	 public void stop(BundleContext context) { 
	     UserRegister.instance = null; 
	 } 
} 
複製程式碼
3. 服務層（Service層）
  • 服務層實現外掛通訊的功能。OSGi提供了一個服務註冊的功能，用於各個外掛將自己能提供的服務註冊到OSGi核心的註冊中心，如果某個服務想用其他服務，則直接在服務註冊中心搜尋可用服務中心就可以了
  • 例如：
// 註冊服務
public class UserRegisterActivator implements BundleActivator {
// 在 start() 中用 BundleContext.registerService() 註冊服務
public void start(BundleContext context) {
context.registerService(UserRegister.class.getName(), new UserRegisterImpl(), null);
}
// 無須在 stop() 中登出服務，因為 Bundle 停止時會自動登出該 Bundle 中已註冊的服務
public void stop(BundleContext context) {}
}
// 檢索服務
public class Client implements BundleActivator {
public void start(BundleContext context) {
// 1. 從服務登錄檔中檢索間接的“服務引用”
ServiceReference ref = context.getServiceReference(UserRegister.class.getName());
// 2. 使用“服務引用”去訪問服務物件的例項
((UserRegister) context.getService(ref)).register();
}
public void stop(BundleContext context) {}
}
複製程式碼
  • 注意：這裡的服務註冊不是外掛管理功能中的外掛註冊，實際上是外掛間通訊的機制

規則引擎架構簡析

規則引擎從結構上來看也屬於微核心架構的一種具體實現，其中執行引擎可以看作是微核心，執行引擎解析配置好的業務流，執行其中的條件和規則，通過各種方式來支援業務的靈活多變

規則引擎在計費、保險、促銷等業務領域應用較多。例如電商促銷，常見的促銷規則有：

  • 滿100送50
  • 3件立減50
  • 3件8折
  • 第3件免費
  • 跨店滿200減100
  • 新使用者立減50

以上僅僅列出來常見的幾種，實際上完整列下來可能有幾十上百種，再加上排列組合，促銷方案可能有幾百上千種，這樣的業務如果完全靠程式碼來實現，開發效率遠遠跟不上業務的變化速度，而規則引擎卻能夠很靈活的應對這種需求，主要原因在於：

1. 可擴充套件

  • 通過引用規則引擎，業務邏輯實現與業務系統分離，可以在不改變業務系統的情況下擴充套件新的業務功能

2. 易理解

  • 規則通過自然語言描述，業務人員易於理解和操作，而不像程式碼那樣只有程式設計師才能理解和開發

3. 高效率

  • 規則引擎系統一般提供視覺化的規則定製、審批、查詢及管理，方便業務人員快速配置新的業務。

規則引擎的基本架構

微核心架構

  • 開發人員將業務功能分解提煉為多個規則，將規則儲存在規則庫中
  • 業務人員根據業務需要，通過將規則排列組合，配置成業務流程，儲存在業務庫中
  • 規則引擎執行業務流程實現業務功能

對照微核心架構的設計關鍵點，規則引擎具體是如何實現的：

1. 外掛管理
  • 規則引擎中的規則就是微核心架構的外掛，引擎就是微核心架構的核心。規則可以被引擎載入和執行。規則引擎架構中，規則一般儲存在規則庫中，通常使用資料庫來儲存。
2. 外掛連線
  • 類似於程式設計師開發的時候需要採用C++、Java等語言，規則引擎也規定了規則的開發語言，業務人員需要基於規則語言來編寫規則檔案，然後由規則引擎載入執行規則檔案來完成業務功能，因此，規則引擎的外掛連線實現機制其實就是規則語言
3. 外掛通訊
  • 規則引擎的規則之間進行通訊的方式就是資料流和事件流，由於單個規則並不需要依賴其他規則，因此規則之間沒有主動的通訊，規則只需要輸出資料或者事件，由引擎將資料或者事件傳遞到下一個規則

目前最常用的規則引擎是開源的JBoss Drools，採用Java語言編寫，基於Rete演算法

Drools具有下面的優點：

  • 非常活躍的社群支援，以及廣泛的應用
  • 快速的執行速度
  • 與Java Rule Engine API（JSR-94）相容
  • 提供了基於Web的BRMS——Guvnor，Guvnor提供了規則管理的知識庫，通過它可以實現規則的版本控制，以及規則的線上修改與編譯，使得開發人員和系統管理人員可以線上管理業務規則

雖然Drools號稱簡單易用，但實際上其規則語言還是和程式語言比較類似，在實際應用的時候普通業務人員面對這樣的規則語言，學習成本和理解成本還是比較高的，例如下面這個樣例

微核心架構

因此，通常情況下需要基於Drools進行封裝，將規則配置做成視覺化的操作，例如下面電商反欺詐的一個示例

微核心架構

注：有興趣瞭解極客時間專欄的同學，可以檢視極客時間專欄—可提供返現服務

相關文章