國產開源工作流引擎，什么情況下，需要使用工作流引擎？

「本文重點介紹關于工作流引擎。」

什么情況下，需要使用工作流引擎？

1、工作流具有的特性  

這篇文章遞進式地介紹工作流除了在業務流程抽象和控制的作用外，還可以實現其他細分領域的賦能。

首先工作流擁有以下幾個特性：

流程的邏輯控制和可編排性

流轉狀態的持久化和可視化

節點功能的自由度

分布式異步執行能力

流程的邏輯控制和可編排性，這個本身就是工作流的初衷，是為了解決復雜的行業流程而抽象出的一套協議，他是工作流的根基，也是目前業界（金融、保險領域等）使用最多的特性。

流轉狀態的持久化是說整個流程圖就是一個巨型且復雜的狀態機，并且他是存在硬盤上的，服務的重啟都會重新恢復它當前的狀態，可視化則是可以直觀的明白當前流轉的進程。

節點功能的自由度，工作流其本質就是節點和其連線的流轉，流轉方向由連線條件控制，流程的阻塞和并行由網關控制。節點的功能可以任意實現，不用拘泥于“人工任務”、“HTTP任務”等。

分布式異步執行能力，這一點非常重要，也是后續賦能細分領域的根基。工作流提供一種節點異步執行的能力，工作流本身的部署是多實例無狀態的，所有實例都會去“搶占”任務列表來執行，所以只要任務丟入隊列中，它將來會在哪個實例上執行是無從知曉且等價的。

以上簡單解釋了一下工作流的4個重要特性，那么從第4點“分布式異步執行能力”出發，我們可以做到具有“分布式特性”、“狀態持久可追溯”、“可編排”的任何事情，下面我就遞進式地說一下幾個可探索的方向。

2. 工作流賦能分布式計算編排上面講到，工作流具有節點邏輯自由+異步分布式執行的特點，利用這兩個特點，我們可以編寫無數個計算類型的節點，把他組合在一起，通過一定的編排，實現計算，下面用流程圖舉一個例子。整

個流程是一個完全的異步服務任務，服務任務帶著計算邏輯，任務被丟入到一個持久化的任務池當中，每個應用實例都會去獲取任務來執行，理論上講，一個完整的流程實例的每個節點的計算和執行會被打散到不同實例上去執行，從而實現了分布式計算。

3. 工作流+無服務函數計算增強分布式計算編排第2個標題中，利用異步服務任務實現了分布式簡單計算，但缺點是：每增加一個邏輯就需要新增加一個節點工作流的本質是推動狀態流轉和狀態持久化，對于計算資源的管理不是專業的所以，在當下Serverless推動的情況下，工作流可以結合函數計算的輕量和彈性容器的特性，實現計算能力的外包。當用戶是內嵌式的工作流，那么實現新的節點相對來說比較簡單，如果說工作流作為云服務，那么要讓用戶自由實現新節點的邏輯腳本是非常麻煩的。如果把計算邏輯外包給Serverless容器，就相對容易得多，用戶側實現邏輯自由度提高了（語言多樣，觸發方式多樣），工作流服務側的壓力也會減小很多，業務執行的結果（或錯誤結果）工作流只需要轉告就行了。使用Serverless擴展工作流，可以使工作流的計算能力近乎無限大。

大數據計算     

如果使用到了函數式計算，小數據量可以通過HTTP或者MQ的方式來傳輸并啟動工作流的推動，但如果是巨量數據（大數據計算），則會帶來一個I\O瓶頸，所以在函數式計算的底部，通常會配置一個數據存儲組件，而流程的啟動往往是從數據的讀取（按分布式模塊Block讀取）開始，而非通過IO傳輸。

4. 工作流賦能微型服務處理鏈工作流通過Serverless得到了強大的計算能力后，可以賦能微型服務，下面舉兩個例子。中小微型門店解決方案

上圖是小商家“菜鳥相館”的服務，對于小商家來說，這些服務自己是不能實現的，就算能實現，加上部署服務器和維護，成本是不劃算的。如果是云上提供一種輕量函數+工作流的編排，可以使用戶低成本、幾乎0門檻的方式展開寸照打印的自動服務，其節約的人力和時間成本是非常可觀的。

低代碼

工作流在微型應用領域同樣可以賦能另一個巨無霸-“低代碼平臺”。低代碼平臺號稱幾乎無代碼完成業務邏輯。其無非就是囊括了表單引擎即支持數據的變動和傳遞，再一個就是配合門戶引擎的展示控件拖拽+報表引擎的統計能力，可以快速搭建一個大屏式的門戶網站。但業務終究是會由流程來體現的，它作為核心來推動工作或者功能的繼續，配合上常用的功能插件和鏈接中心的數據收發，幾乎可以講一個很大的故事。

5. 工作流+DevOps

最近突然聽到很多DevOps的詞，我大概看了看定義，心想難道不就是CI（持續繼承）么，為什么又冒出來這么一個詞。DevOps是老故事換新詞，并不新鮮，就是Development和Operations的合并，直白點就是把開發和運維利用自動化的方式結合了，當初說的CI持續集成其實只是一個核心部分（優化了提交->編譯->部署的過程），而DevOps又把不是講得更大了，在各個階段實現自動化，持續繼承->運維反饋->持續繼承....無限循環，其最終目的還是敏捷開發。下面我拿圖舉個簡單的例子，說明工作流配合DevOps的理念。

上圖就大概表現了一下工作流是如何自動化地串聯起來所有角色，實現DevOps，從而達到敏捷開發的（有些細節不要糾結，大概就是這個意思）。從需求產生的開端，到開發人員的完成，一直到線上的代碼更新都全部交由工作流人工審批功能和服務任務來實現，極大地減少了溝通成本和角色立場不同所帶來的矛盾。

6. 工作流實現微服務編排微服務的概念已經提出很多年了，說白了他就是把各種模塊拆分開來單獨部署成服務，一是利于功能的專注和維護人員的專一性、易替換性，第二個是微服務更容易把控性能和成本的粒度，重要的甚至可以做成集群或給予更加重要和昂貴的資源，其他的就不多贅述。但是微服務隨之也帶來很多惡心的東西：消息如何傳遞，同步調用還是異步調用？調用鏈的監控和問題的定位事務性把握困難長流程業務需要狀態持久化針對以上問題，工作流天然解決這些問題，工作流的同步天然支持事務，異步支持重推。工作流支持流程流轉狀態的查看，對于流程流轉節點的統計和問題的定位非常簡單。工作流本身作為狀態管理，他的狀態肯定是持久化的，所以這一點也支持。除此之外，工作流還支持異常狀態捕獲、邊界時間補償、超時時間處理等，下面就拿電商這個經典的例子大概講一下。

上圖是使用事件總線來聯系微服務的方式和工作流編排微服務的方式來對比，雖然說事件總線的方式并不確切，但我想表達的意思是，微服務雖然解耦了很多東西，也很靈活，但付出的代碼是交流起來非常復雜。而用工作流來編排的微服務，看起來就清爽得多（當然，服務任務需要額外的處理和加持，才能實現微服務的功能）。

7. 工作流+Serverless+大數據賦能機器學習的模型訓練機器訓練模型是一個數據量頻率高，數據雜亂且持續性強的強計算應用，利用上面講到的工作流+Serverless的模型可以極大的利用計算資源來幫助訓練模型。這個大家可以去看看Netflix弄的meson，以下是我扒的圖。

可以看出，工作流控制著數據接收、數據清洗、訓練模型、輸出模型的流程流轉。

8. 工作流賦能細分領域可能需要準備的新特性流程邏輯控制的增強，循環，打斷，邊界事件的增強流程實例的重復利用（流程實例池），即一開始初始化流程實例池，不能手動啟動流程實例，只能從池里拿出可用的。流程流轉歷史的取舍，避免無效資源占用流程啟動和流程結束功能的增強（接收數據和下發數據）以上的特性只是臨時想到的一些，如果要實現本文章所說的領域賦能，需要擴展和增強的東西還有很多。

「上述就是小編為大家整理的工作流引擎」

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。