所有的可擴展性架構設計，背後的基本思想都可以總結為一個字 ： 拆！
拆，就是將原本大一統的系統拆分成多個規模小的部分， 擴展時只修改其中一部分即可， 無須整個系統到處都改， 通過這種方式來減少改動範圍， 降低改動風險 。
常見的拆分思路有如下三種：
• 面向流程拆分：將整個業務流程拆分為幾個階段，每個階段作為一部分。
• 面向服務拆分：將系統提供的服務拆分， 每個服務作為一部分。
• 面向功能拆分：將系統提供的功能拆分， 每個功能作為一部分 。
從範圍上來說， 流程 > 服務 > 功能。以學生管理系統為例，面向流程拆分：展示層→業務層→數據層→存儲層。面向服務拆分：將系統拆分為註冊、登錄、信息管理 、 安全設置等服務。面向功能拆分：登錄服務包括手機號登錄、身份證登錄、郵箱登錄三個功能。
不同的拆分方式，將得到不同的系統架構，典型的可擴展系統架構如下：
面向流程拆分：分層架構。
面向服務拆分：SOA、 微服務。
面向功能拆分：微內核架構。
這幾個系統架構並不是非此即彼的，而是可 以在系統架構設計中進行組合使用的。 例如，以學生管理系統為例，我們最終可以這樣設計架構：
( 1) 整體系統採用面向服務拆分中的“微服務”架構，拆分為“註冊服務”“登錄服務” “信息管理服務”“安全服務”，每個服務是一個獨立運行的子系統 。
(2 ）其中的“註冊服務”子系統本身又是採用面向流程拆分的分層架構。
(3 ）“登錄服務”子系統採用的是面向功能拆分的“微內核”架構 。
微內核架構
也稱為插件化架構，一種面向功能進行拆分的可擴展架構，通常用於實現基於產品的應用。
微內核有兩類組件：核心系統和插件模塊。核心系統負責業務無關的通用功能，插件模塊負責實現具體的業務邏輯。
核心系統功能比較穩定，不會因為業務功能擴展而不斷修改，插件模塊可以根據業務功能的需要不斷地擴展。微內核架構通過隔離變化到插件的方式提供了靈活性、可擴展性。
微內核的核心繫統設計的關鍵技術：
• 插件管理，核心系統需要知道插件的信息，常見的實現方式插件註冊表機制。
• 插件連接，插件如何連接到核心系統。核心系統必須制定插件和核心繫統的連接規範。
• 插件通信，插件通信指插件間的通信，插件間是完全解耦的，但業務中插件是需要進行通信的，這個通信必須通過核心系統，因此核心系統需要提供插件通信機制。
1.OSGi 架構
OSGi 是一個插件化的標準，現在我們談到 OSGi ，如果 沒有特別說明， 一般都是指 OSGi 的規範。
Eclipse 從 3.0 版本開始，拋棄了原來自己實現的插件化框架，改用了 OSGi 框架 。
Eclips巳採用的 OSGi 框架稱為 Equinox ， 類似的實現還有 Apache 的 Felix、 Spring 的 SpringDM 。
OSGi 框架的邏輯架構：
( 1 ）模塊層，模塊層完成插件管理功能 。插件被稱為 Bundle ，每個 Bundle是一個Java的JAR 文件。
(2 ）生命週期層，生命週期層完成插件連接功能，生命週期層精確地定義了 bundle 生命週期的操作（安裝、更新、啟動、停止、卸載〕， Bundle 必須按照規範實現各個操作。
(3 ）服務層，服務層完成插件通信的功能。 OSGi 提供了一個服務註冊的功能，用於各個插件將自己能提 供的服務註冊到 OSGi 核心的服務註冊中心，如果某個服務想用其他服務，則直接在服務註冊中心搜索可用服務就可以了 。
2.規則引擎架構
規則引擎中的規則就是微內核架構的插件，引擎就是微內核架構的內核，規則可以被引擎加載和執行 。執行引擎解析配置好的業務流，執行其中的條件和規則。
• 通過引入規則引擎，業務邏輯實現與業務系統分離，可以在不改動業務系統的情況下擴展新的業務功能 。
• 規則通過自然語言描述，業務人員易於理解和操作。
• 規則引擎系統一般提供可視化的規則定製、審批、查詢及管理，方便業務人員快速配置新的業務。
規則引擎的基本架構：
(1 ）開發人員將業務功能分解提煉為多個規則，將規則保存在規則庫中 。
(2 ）業務人員根據業務需要，通過將規則排列組合，配置成業務流程，保存在業務庫中。
(3 ）規則引 擎執行業務流程，實現業務功能 。
對照微內核架構的設計關鍵點，看規則引擎如何實現：
•插件管理，在規則引擎架構中，規則一般保存在規則庫中，通常使用數據庫來存儲。
•插件連接，規則引 擎的插件連接實現機制其實就是規則語言。業務人員需要基於規則語言來編寫規則文件，然後由規則引 擎加載執行規則文件來 完成業務功能。
•插件通信，規則引擎的規則之間進行通信的方式就是數據流和事件流。規則只需要輸出數據或事件，由引擎將數據或事件傳遞到下一個規則 。
閱讀更多 有一天我會成功 的文章
