Ch12: Microkernel Architecture Style#

Microkernel architecture（微核心架構），也稱為 plug-in architecture（外掛架構），誕生於數十年前但至今仍廣泛使用。它天然適合產品型應用程式（packaged and installed as a single monolithic deployment），但也大量用於非產品型的企業應用中。

Topology（拓撲結構）#

Microkernel architecture 是一種相對簡單的 monolithic 架構，由兩個核心元件組成：

  • Core System（核心系統）
  • Plug-in Components（外掛元件）

Application logic 被拆分為 core system 與 plug-in components 之間，提供可擴展性（extensibility）、可適配性（adaptability），以及對自訂處理邏輯的隔離。

Figure 12.1: Basic components of the microkernel architecture style

Core System#

Core system 的定義：執行系統所需的最小功能。

兩種理解方式：

  • 以 Eclipse IDE 為例：core system 只是一個基本的文字編輯器（開檔、改文字、存檔），加上 plug-in 才成為可用的 IDE
  • 另一種定義：應用程式的 happy path（一般處理流程），不包含自訂或特殊處理

Core system 的實作方式：

  • Layered architecture — 按技術分層（technically partitioned）
  • Modular monolith — 按 domain 分區（domain partitioned）
  • 也可以拆分為獨立部署的 domain services，每個 domain service 擁有各自的 plug-in components

Figure 12.2: Variations of the microkernel architecture core system

Presentation layer 變體：

  • UI 嵌入 core system（single deployment）
  • UI 獨立部署，core system 提供 backend services
  • UI 本身也可以是 microkernel 架構

Figure 12.3: User interface variants

Plug-in Components#

Plug-in components 是獨立的、自包含的元件，用於擴展或增強 core system 的功能。

關鍵原則：

  • Plug-in components 之間應互相獨立，彼此沒有依賴
  • 可用於隔離高度易變的程式碼，提升 maintainability 和 testability

實作方式：

  • Compile-based（編譯期） — 以 shared library 形式實作（JAR、DLL、Gem），整個 monolithic 應用需重新部署

Figure 12.4: Shared library plug-in implementation

  • Runtime-based（執行期） — 透過 OSGi、Penrose、Jigsaw（Java）或 Prism（.NET）等框架管理，可在執行期新增或移除
  • Package/Namespace — 在同一 code base 內以獨立 namespace 實作，例如 app.plugin.<domain>.<context>

Figure 12.5: Package or namespace plug-in implementation

通訊方式：

  • Point-to-point — 方法呼叫或函式呼叫（最常見）
  • Remote access — 透過 REST 或 messaging 呼叫獨立部署的 plug-in service

Remote plug-in access 雖然提供更好的 decoupling 和 scalability，但會將 microkernel 轉變為分散式架構，增加複雜度和成本，也使得第三方 on-prem 產品難以部署。需仔細評估 trade-offs。

資料存取：

  • Plug-in 通常不直接連接共用資料庫，而是由 core system 傳入所需資料
  • Plug-in 可以擁有自己獨立的 data store（外部資料庫或嵌入式資料庫）
  • 這種設計的主要目的是 decoupling：資料庫變更只影響 core system，不影響 plug-in

Figure 12.7: Plug-in components can own their own data store

Registry#

Core system 需要知道哪些 plug-in 可用以及如何存取它們，這透過 plug-in registry 實現。

Registry 包含每個 plug-in 的資訊：

  • 名稱
  • Data contract（輸入與輸出資料格式）
  • Remote access protocol details（依連接方式而定）

Registry 的實作方式：

  • 簡單的 internal map（core system 內部的 key-value 結構）
  • 複雜的 registry / discovery tool（如 Apache ZooKeeper、Consul）

Contracts#

Plug-in 與 core system 之間的 contract（合約）通常在同一 domain 內是標準化的，定義了：

  • 行為（behavior）
  • 輸入資料（input data）
  • 輸出資料（output data）

當 plug-in 由第三方開發、無法控制其合約時，通常使用 adapter pattern 在 plug-in 合約與標準合約之間進行轉換。

Contract 可以用 XML、JSON 或物件（object）實作。

Examples and Use Cases#

產品型軟體：

  • IDE — Eclipse、IntelliJ IDEA 等
  • 瀏覽器 — Chrome、Firefox（viewer、plug-in 擴展基本瀏覽功能）
  • 開發工具 — PMD、Jira、Jenkins

企業應用：

  • 保險理賠系統 — 每個轄區（jurisdiction）的理賠規則作為獨立 plug-in，core system 是標準理賠流程。新增、移除或修改某一轄區的規則不影響其他部分
  • 稅務計算軟體 — 1040 主表作為 core system，各種附表和工作表作為 plug-in。稅法變更時，只需修改或新增對應的 plug-in

Microkernel architecture 不只適合產品型軟體。任何需要依據不同條件（如地區、客戶）做不同配置的業務應用，都非常適合這種架構風格。

Architecture Characteristics Ratings#

Architecture CharacteristicRating
Partitioning typeDomain and technical
Number of quanta1
Deployability3/5
Elasticity1/5
Evolutionary3/5
Fault tolerance1/5
Modularity3/5
Overall cost5/5
Performance3/5
Reliability3/5
Scalability1/5
Simplicity4/5
Testability3/5

主要優勢：Overall cost、Simplicity

  • 與 layered architecture 類似，成本低且簡單
  • Scalability 和 fault tolerance 仍是弱點（受限於 monolithic 部署）

獨特特性：

  • Partitioning type: Domain and technical — 是唯一可以同時支援 domain partitioning 和 technical partitioning 的架構風格
  • Deployability / Testability / Reliability（3/5） — 功能可隔離到獨立 plug-in，縮小測試和部署範圍，降低風險
  • Modularity / Evolutionary（3/5） — 透過獨立的 plug-in components 可輕鬆新增、移除和修改功能
  • Performance（3/5） — 應用通常較小、較精簡，且不受 architecture sinkhole anti-pattern 影響。移除不需要的功能（unplugging）可讓應用執行更快
Backward Pipeline Architecture Style Service-Based Architecture Style Forward