基於事件驅動的組件架構

本架構主要目的是改進軟件開發中鬆耦合、增長模塊的重用性、提升開發效率。

在常規的模塊間方法直接調用式開發中，新增的功能對原有模塊代碼的穩定性、重用性破壞大,不利於軟件的後期維護，且開發效率低。

另外，在傳統的軟件開發方法中，若是新增的功能的邏輯在其它模塊須要重複使用，則只能經過copy代碼或方法調用的方式來重用，仍是須要改動原代碼。
經過本技術方案，能夠將一些功能抽像爲組件，這些組件能夠被動態的插入的現有模塊中，不須要改動原有模塊代碼，從而增長了重用性，提升了開發效率。

技術解決方案

A. 相關概念抽像及定義

首先在軟件的業務模塊中抽像出核心業務邏輯(Core Service)及核心業務數據(Core Data Model)，同時抽像出核心業務邏輯相對應的事件接口(Event Interface)。
在覈心業務以外的業務被稱之爲組件(Component)，組件是由一組業務插件（Plugin）組成的，這些插件是一個或多個核心業務的事件的實現體，核心業務和事件的關聯，

是經過插件樁（Plugin Bundle）收集起來的，具體的關聯關係是在一個名爲Component.xml(組件描述文件)中定義的。

 

B. 組件的開發

當須要在覈心業務邏輯中插入新的邏輯時，須要定義出相應的插件，使插件實現相應的業務事件接口，在插件中實現具體業務邏輯代碼，其須要的核心業務數據會經過事件接口作爲參數傳遞過來，這樣插件就能夠無入侵式的操做核心業務數據了。

 

 

C. 組件的加載和啓動

首先組件有如下狀態：安裝狀態和啓動狀態，分別爲已安裝和未安裝，已啓動和未啓動。
當系統啓動時，組件加載模塊查找全部的Component.xml，並解析出插件和核心業務的關聯關係，並將這種關係經過組件視圖（Component View）記錄在內存中。
在加載過程當中，檢測數據中是否有此組件的記錄，若是沒有則在數據中記錄，此時組件的狀態被標記爲未安裝、未啓動。若是數據庫中已經存在則檢測其狀態，若是是已啓動狀態，則將此組件啓動，並標記爲已啓動狀態。
在系統的控制檯中展現組件的列表，並提供操做按鈕，能夠執行如下操做：安裝/卸載、啓動/停用。
綜上所述，組件被啓動可能經過兩種途徑：系統加載時或在控制檯中手動啓動。組件被啓動後，根據組件視圖中記錄的關係將插件和插件樁進行關係綁定，即將插件動態插入到插件樁中，即完成業務邏輯動態地、無侵入式地插入到核心業務邏輯中。

D. 插件調用邏輯說明

在軟件運行中，當核心業務邏輯被調用的同時調用事件接口，同時向接口傳遞核心業務數據，這個過程被稱爲事件激發。
當事件激時，插件樁裏已經收集了相應的插件集合（事件的實現體），進而在插件樁中一個個的調用插件，傳遞核心數據，這樣插件被執行。

 

方案的效果

經過上述組件的技術方案，能夠實現對原系統無侵入式的、鬆耦合式的開發，開發人員無需關係核心代碼細節，只要瞭解事件接口就能夠完成對核心業務的擴展，開發效率高、重用性高。
效果舉例：以電子商務系統爲例，在一個電商業務中建立訂單是核心的業務邏輯，在訂單建立成功後，可能須要發送一條手機短信給顧客， 基於此種組件方案，開發人員須要開發一款基於某個電信網關的短信發送組件。開發人員沒必要了解訂單建立的具體代碼，只需關心如何跟電信網關對接便可，組件機制會將訂單信息、顧客手機號等核心數據經過訂單的建立事件傳遞給插件，插件拿到上述數據， 根據具體接入的電信網關參數，將核心數據（訂單信息、顧客手機號）組織好文字，傳遞給電信網關就完成了經過此短信網關發送訂單短信的功能。
一旦業務發生變動，好比要更換其它短信網關發送短信，此時再根據具體的網關參數開發另外一款短信組件，而後停用以前的短信組件，安裝上新的組件便可。
能夠看出，從功能開發，到後期的變動維護，訂單建立的核心業務代碼從未暴露給組件開發人員，他們也不須要去改動核心代碼，保持了原有系統的穩定性，下降了新功能開發的難度，並且基於一樣規則的系統均可以安裝此短信組件，直接使用，極大的下降了開發成本。

 

 

實際應用

 

 咱們以本架構在javashop電商系統中的應用案例說明：

1、訂單的建立和短信發送

A. 訂單核心業務

 

 

 

 

1.訂單核心業務（OrderService）
負責訂單的建立，這屬於電商業務的核心，經過createOrder()方法建立訂單。

2.訂單插件樁(OrderPluginBundle)
在其pluginList屬性中存儲了全部響應訂單業務事件的插件。

3.訂單建立接口
訂在訂單建立成功後，會激發此事件，而實際調用的是上述pluginList中的插件。
B. 組件的組成

 

 

 

 

如上圖所示，訂單短信組件由如下內容：
1. 訂單短信組件（OrderSmsComponent）
訂單組件類，在組件被安裝時會調用其install方法，完成一些安裝必要的操做。

2. 訂單短信插件
此類實現了訂單建立事件，響應了訂單完成事件（onOrderCreate）方法，當訂單建立完成時，會調用此方法。

3. 組件的描述文件Component.xml
此描述文件定義了訂單插件（OrderSmsPlugin）要注入到訂單插件樁中，即定義了插件要對應的核心業務

C. 組件加載、啓動過程

 

 

組件的加載、啓動過程細節以下：
當系統啓動時，組件加載模塊查找全部的，並解析出插件和核心業務的關聯關係，並將這種關係經過組件視圖記錄在內存中。
在加載過程當中，檢測數據中是否有此組件的記錄，若是沒有則在數據中記錄，此時組件的狀態被標記爲未安裝、未啓動。若是數據庫中已經存在則檢測其狀態，若是是已啓動狀態，則將此組件啓動。
組件啓動首先將插件注入到相應的插件樁中，此時當事件被激發時，經過插件樁就能夠調用到實現了此事件的全部插件了。組織好插件的關係後，將此組件在數據庫中標記爲已啓動。

D. 事件激發及插件調用

 

 

如上圖所示，描述了事件激發和插件調用的過程，具體技術實施細節以下：
在這裏循環全部的訂單建立事件調用之（激發事件接口），這些事件實際是被注入進來的、具體的插件實現體，好比訂單短信插件，此時訂單短信插件被動態調用，在此插件中完成發送短信的邏輯。

經過上述架構的實施，能夠達到以下效果： 

如今短信的廠商衆多，咱們分別爲其實現「短信發送插件」，這對於「訂單核心邏輯」代碼是不須要改動的，

一方面提高了核心代碼的穩定，一方面增長可對「新短信廠商」的擴展性。

 

後記

經過這種組件架構，其實在電商架構領域中還有不少模塊能夠採用組件式的架構，以javashop電商系統中的應用爲例：

支付組件

訂單的支付爲核心邏輯，他來處理狀態改變，記錄日誌等。

經過調用支付插件來完成具體的支付操做，傳遞的是支付金額，訂單號核心標準數據。

而支付插件能夠多種實現：支付寶、微信、銀聯等等。

這樣加強了訂單核心的穩定，提升了支付方式的擴展性

 

物流查詢

查詢動做和展現是核心，傳遞給插件「物流公司」，「物流單號」核心標準數據

物流查詢有多種插件實現：kuaidi100，showapi，菜鳥等等。

一樣加強了訂單核心的穩定，提升了物流查詢廠商的擴展性

 

圖片存儲

圖片都上傳和顯示是核心，傳遞給插件圖片流是核心標準數據

圖片的存儲有多種插件實現：如阿里oss,七牛、又拍等等。

一樣加強了系統核心的穩定，提升了圖片存儲廠商的擴展性

 

其實還有不少邏輯能夠採用這種思路，提升穩定性，提升擴展性，在這裏就不一一列舉

這須要對本身的系統功能進行分析抽象，抽象出核心邏輯、插件接口標準、標準數據。

易族智匯（javashop）原創文章