什麼是微內核架構
基本架構
- 微內核架構包含兩類組件:核心系統和插件模塊
核心系統
- 主要負責和具體業務功能無關的通用功能,例如模塊加載、模塊間通信等
插件模塊
- 主要負責實現具體的業務邏輯,例如 “學生信息管理” 系統中的 “手機號碼註冊” 功能
微內核的基本架構圖
-
上圖中核心繫統功能比較穩定,不會因爲業務功能擴展而不斷修改,插件模塊可以根據業務功能的需要不斷地擴展
-
微內核的架構本質就是將變化部分封裝在插件裏面,從而達到快速靈活擴展的目的,而又不影響整體系統的穩定
設計關鍵點
- 微內核的核心繫統設計的關鍵技術有:插件管理、插件連接和插件管理
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 進行封裝,將規則配置做成可視化的操作,例如下面電商反欺詐的一個示例
本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源:https://mp.weixin.qq.com/s/FO9JehhZJ9xt068sufv_qA