別再用硬編碼寫業務流程了，試試這款輕量級流程編排框架

前言

在每一個公司的系統中，總有一些擁有複雜業務邏輯的系統，這些系統承載着核心業務邏輯，幾乎每一個需求都和這些核心業務有關，這些核心業務業務邏輯冗長，涉及內部邏輯運算，緩存操做，持久化操做，外部資源調取，內部其餘系統RPC調用等等。時間一長，項目幾經易手，維護的成本得就會愈來愈高。各類硬代碼判斷，分支條件愈來愈多。代碼的抽象，複用率也愈來愈低，各個模塊之間的耦合度很高。一小段邏輯的變更，會影響到其餘模塊，須要進行完整迴歸測試來驗證。如要靈活改變業務流程的順序，則要進行代碼大改動進行抽象，從新寫方法。實時熱變動業務流程？幾乎很難實現。

開源解決方案

說到流程引擎，開源界有大名鼎鼎的老牌開源軟件JBPM，也有近幾年很是流行的Activiti和Flowable。他們都是基於BPM協議，能夠作到基於角色任務的流傳，邏輯的流轉。而且不少基於BPM協議的編輯工具都能作可視化的編輯。

但今天我要介紹的，是一款輕量級的流程編排框架——Liteflow。

Liteflow主要致力於邏輯驅動的編排。能夠知足於大部分的生產業務場景。和以上著名的開源流程引擎相比，雖然不如他們那麼全面，可是勝在輕量，高性能和極少的學習成本。並且這些項目都是國外開源項目，集成起來相對比較重，文檔本地化也作的不夠好。Liteflow擁有完善的本地文檔和使用範例。能幫助你的核心繫統變得更加靈活，更加易擴展。是一個解耦你係統的利器。

https://gitee.com/bryan31/lit...

Liteflow框架的做用

Liteflow就是爲解耦複雜邏輯而生，若是你要對複雜業務邏輯進行新寫或者重構，用liteflow最合適不過。它是一個輕量，快速的組件式流程引擎框架，組件編排，幫助解耦業務代碼，讓每個業務片斷都是一個組件。

使用Liteflow，你須要去把複雜的業務邏輯按代碼片斷拆分紅一個個小組件，並定義一個規則流程配置。這樣，全部的組件，就能按照你的規則配置去進行復雜的流轉。同時Liteflow支持規則文件的熱加載，即時完成修改生效。並提供多種持久化規則的方式的擴展。

Liteflow的設計原則

Liteflow是基於工做臺模式進行設計的，何謂工做臺模式？

n個工人按照必定順序圍着一張工做臺，按順序各自生產零件，生產的零件最終能組裝成一個機器，每一個工人只須要完成本身手中零件的生產，而無需知道其餘工人生產的內容。每個工人生產所須要的資源都從工做臺上拿取，若是工做臺上有生產所必須的資源，則就進行生產，如果沒有，就等到有這個資源。每一個工人所作好的零件，也都放在工做臺上。

這個模式有幾個好處：

• 每一個工人無需和其餘工人進行溝通。工人只須要關心本身的工做內容和工做臺上的資源。這樣就作到了每一個工人之間的解耦和無差別性。
• 即使是工人之間調換位置，工人的工做內容和關心的資源沒有任何變化。這樣就保證了每一個工人的穩定性。
• 若是是指派某個工人去其餘的工做臺，工人的工做內容和須要的資源依舊沒有任何變化，這樣就作到了工人的可複用性。
• 由於每一個工人不須要和其餘工人溝通，因此能夠在生產任務進行時進行實時工位更改：替換，插入，撤掉一些工人，這樣生產任務也能實時的被更改。這樣就保證了整個生產任務的靈活性。

這個模式映射到Liteflow框架裏，工人就是組件，工人坐的順序就是流程配置，工做臺就是上下文，資源就是參數，最終組裝的這個機器就是這個業務。正由於有這些特性，因此Liteflow能作到統一解耦的組件和靈活的裝配。

springboot裏快速配置

Liteflow支持了springboot的自動裝配，固然Liteflow也爲非springboot和非spring的項目也提供了支持，這裏僅以springboot項目爲示例進行介紹：

依賴最新的依賴包：

<dependency>
  <groupId>com.yomahub</groupId>
  <artifactId>liteflow-spring-boot-starter</artifactId>
  <version>2.3.3</version>
</dependency>

配置上規則路徑：

liteflow.rule-source=config/flow.xml

定義組件

Liteflow但願用戶把複雜邏輯拆分紅一個個可複用的組件，因此你得定義你的組件，組件的定義很簡單，你須要繼承NodeComponent類，而後實現process 方法就行，如下爲示例：

@Component("test")
public class TestComponent extends NodeComponent {

 @Override
 public void process() {
  Slot slot = this.getSlot();//slot爲這個請求的上下文
  //這裏爲你的業務處理邏輯
 }
}

這裏會有童鞋問，個人業務方法須要入參和出參怎麼辦，如何傳遞呢？

Liteflow爲每一個線程都自動分配了惟一的一個slot，能夠理解爲上下文。想想上面說的那個模型，每一個組件不須要和其餘組件進行信息互通，所須要的參數從slot裏取就是了，同時，執行完業務邏輯以後，把結果也放入slot裏。因此每一個組件都是獨立的無參構造，這樣就消除了每一個組件的差別性。

這裏的slot能貫穿全部組件，每個組件均可以訪問到slot裏全部的數據。固然每一個請求之間的slot，Liteflow作了嚴格的隔離，不用擔憂數據會串的問題。

Liteflow提供的默認Slot是一個弱類型的對象，這裏建議使用者本身定義一個值對象，只須要繼承AbsSlot類，即可成爲你本身的Slot。更加貼合業務。

組件除了必需要實現的process 方法，還有幾個可選實現：

isAccess：表示是否進入該節點，能夠用於業務參數的預先判斷

isContinueOnError：表示出錯是否繼續往下執行下一個組件，默認爲false

isEnd：表示是否當即結束整個流程 ，默認爲false，也能夠在業務日誌里根據業務判斷來調用this.setIsEnd(true)來結束整個流程。

@Component("test")
public class TestComponent extends NodeComponent {

 @Override
 public void process() {
  Slot slot = this.getSlot();//slot爲這個請求的上下文
  //這裏爲你的業務處理邏輯
 }
  
  @Override
 public boolean isAccess() {
  Slot slot = this.getSlot();
  //這裏作你的參數檢查，若是沒獲取到必須的業務參數，就不會進入該組件
  boolean checkResult = true;//模擬檢查結果爲true
  return checkResult;
 }
  
  @Override
 public boolean isContinueOnError() {
  return super.isContinueOnError();//默認爲false
 }
  
  @Override
 public boolean isEnd() {
  return super.isEnd();//默認爲false
 }
}

你只需定義你的業務組件，以後，在啓動時，Liteflow會自動掃描到你定義的全部組件，並進行加載。

編輯規則文件

實現完了組件以後，你須要定義規則文件，以前規則文件的路徑配置在了config/flow.xml中，因此咱們要編輯這個文件。

Liteflow的規則文件定義很是簡單好理解。簡單的配置，可是能覆蓋大部分的應用場景。

先來看一個示例：

<chain name="chain1">
    <then value="a,c"/> 
    <when value="b,d"/> 
    <then value="e,f,g"/>
</chain>

在Liteflow中，定義了then和when兩種線程執行方式，then表明串行，上面的示例中，c必需要等a執行完才能執行。when表明並行，上面的示例中，b,d同時執行。而且b,d都執行完了，下面的e，f，g才能挨個順序執行。

再來看個稍微複雜點的：

<chain name="chain1">
   <then value="a,c(b|d)"/> 
   <then value="e,f,g"/>
</chain>

Liteflow提供了條件組件，這種節點的職責就是路由，根據業務邏輯來路由到b節點仍是d節點。

條件組件的定義示例以下，須要去繼承NodeCondComponent這個類，最終返回的b就是最終要路由到的節點

@Component("c")
public class CComponent extends NodeCondComponent {

 @Override
 public String processCond() throws Exception {
    //你的業務邏輯
  return "b";
 }
}

Liteflow容許你編輯嵌套的流程，例子以下：

<chain name="chain1">
  <then value="a,c,strategy1,g"/>
</chain>

<chain name="strategy1">
  <then value="m(m1|m2|strategy2)"/>
</chain>

<chain name="strategy2">
  <then value="q,p(p1|p2)"/>
</chain>

在這個例子中，這3條鏈路是串起來執行的，在xml裏，能夠寫你的組件id，也能夠寫流程id。配合以前的例子，是否是能表達的流程就更加豐富了點呢。

以上3個例子涵蓋了Liteflow最主要的功能，固然Liteflow還提供一些其餘的特性，好比如何進行循環執行，如何打印步驟，而且Liteflow還提供了一個簡易的監控模塊，用於統計你的組件執行狀況。這裏就不一一介紹了。具體你能夠點擊Liteflow的Gitee主頁進行查看：

https://gitee.com/bryan31/lit...

示例工程

爲了方便用戶的使用，Liteflow在項目裏提供了一個測試用例，你能夠直接拿來跑：

同時做者還作了一個帶簡單業務的示例工程，來演示如何具體實踐：

https://gitee.com/bryan31/lit...

這個簡單業務是一個電商場景的價格計算的案例，如何經過拆分組件來組合不一樣的影響價格的業務。而且這個示例工程還提供了一個簡單的頁面供你們進行調試：

最後

在流程編排開源上，國內一直沒有特別著名的開源項目。Liteflow的體量雖然沒法和業界著名的流程引擎相比，可是在某些場景，的確提供了輕量級的解決方案。而且Liteflow通過了公司生產大流量業務的考驗，在穩定性和性能方面有必定保障。但願Liteflow這個開源框架能幫助到有這方面業務須要的同窗們。

關於我

我是一個開源做者，也是一名內容創做者。「元人部落」是一個堅持作原創的技術科技分享號，會一直分享原創的技術文章，陪你一塊兒成長。關注回覆liteflow能加入羣聊，這裏有不少大佬能和你一塊兒探討技術，回答你的問題。