lua與規則引擎的構思(一)


  1. 規則引擎的應用場景
  2. 規則引擎項目的結構及運行原理
  3. 使用lua作為規則語言的優點與缺點

 

1 規則引擎的應用場景

  我們知道,一切萬物都是在不斷發展,當然也包括我們的任何計算機系統,商業規則在不斷的改變,而我們也要跟着改變,往往是由業務來驅動系統的改變。這就造成我們非常的被動,商業規則可能是一月一變,甚至於可能是一日一變,而我們的業務系統顯然不可能這么跟着如此頻率變化。生活中常見的超市打折扣,是否折上折,是否個別商品不進行折扣;又如,在保險行業里,行業公會或者是保監局有一個新的監管要求;又如國家為了防止通貨緊縮而進行寬松的貨幣政策,而放貸的要求明顯降低等等。這些要求都是多變的,且是易變的,經常不定時的調整,甚至於還有地區性的差異。

  企業越來越依賴於信息技術 (IT) 來管理他們的業務,IT 部門需要開發更復雜的應用程序,同時還要適應其所支持的應用程序的快速變更。通常,在這些應用程序內實施公司的業務策略對於傳統的軟件體系結構而言過於復雜、龐大,變化也過快。

  如果我們還按照以前的思維對核心業務系統進行調整的話,將導致很多問題:

  1. 因此類需求很多,導致,系統經常調整,傷害系統的穩定性,系統的穩定性往往是最重要的
  2. 測試難以進行,因此類業務系統往往維度很多,難以在每次改造都進行覆蓋率很高的測試,難以進行單元測試
  3. 需求難以實現,不管是老的c/c++系統,還是java/c#等新系統,對於業務的描述畢竟與自然語言差異巨大,難以表述,更別指望能對業務進行可視化設計
  4. 此類業務控制可能遍布整個項目,從而難以進行代碼的迭代優化及升級換代

  我們隨便列舉了以上幾點,基本上可以說明規則引擎應用的好處。開發人員和架構設計者可以從應用程序傳統代碼中提取業務邏輯。如果業務策略是硬編碼到企業應用程序中的,則更新系統的過程需要專門的編程人員,並且會使系統穩定性面臨風險,同時需要花費較長的時間。通過用業務規則將業務邏輯提取到業務應用程序外,IT 用戶可以獨立於應用程序來進行業務邏輯的開發和運行。完整的BRMS(即業務規則管理系統)實施甚至可以做得更多,並可使業務用戶能夠在有限依賴於 IT 部門的情況下直接管理業務策略。依賴的程度范圍從通過 IT 實施的策略的業務用戶進行的有限復查到業務用戶完全控制策略的規范、創建、測試和部署。

  IT 周期由開發和維護此基礎結構的時間組成。未使用規則引擎前,IT周期顯示與業務周期是不一致的。在規則引擎解決方案中,我們可以把原來業務系統理解為應用程序、業務規則應用;業務規則管理周期和應用程序開發生命周期可以並行發展。業務策略可以按需發展,不會額外增加應用程序開發的負擔。每次應用程序得以發展,業務策略實施都會與應用程序保持同步。通過這種分離,業務策略和應用程序體系結構可以異步管理。例如,應用程序開發人員可能工作的周期為半年,在此周期內每六個月將開發出一個新的應用程序版本以應對不斷更改的應用程序基礎結構(例如,JDK 和 RDBMS 版本)及其他核心業務需求。同時,策略管理人員可能工作周期為一周,在此周期內交付業務策略的新版本以應對不斷發展的市場、新客戶或不斷更改的規則環境。

  另一方面,業務用戶不關注應用程序開發的細節,而是對定義、測試和管理良好定義的決策(實施表示為應用程序內的業務規則的業務策略)感興趣。因此,他們需要可在總體策略的上下文內簡化組織、搜索和編寫規則的工具。 開發人員按照自己的速度在自己的環境中工作,業務用戶也是如此,這兩方面的工作可以輕松進行同步及合並。 最后,IT 和業務用戶都需要訪問規則執行環境來部署規則。對於開發人員,規則部署是應用程序測試的一部分。對於業務用戶,規則部署是規范、驗證和將新的或更改的策略投入生產的一部分。


 lifecycles

示意圖(摘自JRule6.6 quickstart)

2 規則引擎項目的結構及運行原理

2.1 規則引擎關鍵名詞

  任何程序都是算法與數據結構,而規則引擎也不例外。這些商業規則實際上也是程序,那他自然也要關心這些數據結構。規則引擎中關注的數據結構,我們稱之為BOM(Business Object Modal),即:商業對象模型;規則引擎中關注的算法就是規則了。

  現在關注一下規則引擎中關鍵的幾個名詞:

  • DTO(Data Translate Object,即數據傳輸對象)
  • BOM(Business Object Modal,即商業對象模型)
  • Ruleset(規則集)
  • Ruleset Execute Flow(規則集執行流)
  • Rule Runtime Context 運行時上下文環境
  • 決策表
  • 決策樹

  

  image

 

2.2 規則引擎的模塊

  我們主要把規則引擎分為接口層、適配層、核心、數據層、規則管理層,下圖顯示各層次之間的關系

image

  當一次請求進入規則引擎時,即DTO,DTO具體的樣式,可能是一份xml文檔,或者是一段內存,序列化的對象等等;當然,這具體與規則引擎與應用程序的調用方式相關,比如使用http post請求:web service,或者是簡單的xml對象模型的,當然也可以將之嵌入應用程序等,此是后話。當DTO經過適配層時,由適配層負責去訪問其他的接口,或者是數據庫,進行填充數據。為什么需要這個步驟呢?在這里舉一個例子,這是一個計算購物折扣率的應用,應用程序過來的DTO中,肯定包含了購物車中的具體信息,包括所購商量的數量及價格,以及會員信息,但是,肯定不包含該會員的歷史購買記錄,如果這個時候,有這么一條規則,注冊至今購買金額超過1W給予9折的優惠,那就得訪問DB,統計該會員的注冊至今的購買金額,並組成在規則中需要的BOM。

  規則引擎核心得到BOM之后,將該對象(LUA中的Table)傳入運行的上下文環境,然后對規則進行逐條運算,最終得到運算結果的輸出BOM,中間可能也得經過適配層並訪問DB填充數據成為DTO並返回給應用程序。

3.使用Lua作為規則描述語言的優缺點

  首先,lua有非常成熟的實現,而且在游戲行業中作為嵌入的腳本的應用也有非常成熟的應用。lua是使用純C實現的開源項目(當然,如果是java/c#等,也可以用相應的語言實現),可以移植到任何平台,可以與任何項目相結合,並且免費易用。

  其次,從lua這個語言本身出發,語言簡單易懂,甚至可以對業務人員進行簡單的培訓之后迅速的介入開發,讓業務人員自己來寫規則腳本。lua的腳本執行效率高,可以保證適應復雜的規則而不影響效率。lua是非面向對象的語言,在適合編寫邏輯的同時,保持最簡單的語法。如果想實現可視化設計邏輯規則的話,相對於其他腳本語言(如,python、ruby)等,可有一個更簡單的實現。與成熟的規則引擎(如JRule)的規則語言相比較,lua更適合程序員使用,工作效率更高,且是文本,易維護。

  lua作為普通的腳本語言並非為了規則而生,因為如果要實現類似Jrule的中文描述規則將會有難度,並且如果要實現可視化設計邏輯,像設計流程圖等等,在實現上要給lua腳本設計一個代碼格式,代碼標准,以使我們的編輯器實現可視化設計。因此,就我目前的理解而言,lua作為規則描述語言最大的缺點就在於可視化實現,當然也並非不可實現,但真的要費很大的勁。


注意!

本站转载的文章为个人学习借鉴使用,本站对版权不负任何法律责任。如果侵犯了您的隐私权益,请联系我们删除。



 
粤ICP备14056181号  © 2014-2021 ITdaan.com