1 引言：流程編排的現實需求

1.1 什么是質檢系統？

1.2 質檢流程日益復雜的挑戰

2 第一階段：基于狀態機的流程控制實踐

2.1 選用狀態機的背景

2.2 狀態機模型設計

2.3 示例狀態流轉（簡化）

2.4 實現方式

2.5 狀態機的優點

2.6 面臨的挑戰

2.7 小結

3 第二階段：工作流引擎的探索與評估

3.1 主流引擎能力對比

3.2 引擎能力基本滿足，但遷移與性能問題突出

3.3 最終選擇：基于工作流思想，自研流程編排引擎

4 第三階段：結合工作流思想的自研流程編排引擎

4.1 自研流程編排引擎的核心設計目標

4.2 引擎核心模塊設計

5 演進效果與落地實踐

5.1 節點配置

5.2 線體配置（簡化）

6 未來展望

1、引言：流程編排的現實需求

1.1 什么是質檢系統？

質檢系統是針對用戶和平臺交易的手機、3C 數碼等物品，通過專業流程進行全面檢測并輸出質檢報告的系統。它是履約體系中的關鍵一環，核心目標是解決用戶在買賣過程中的信任問題，同時為平臺的質保、售后處理等提供客觀、可依賴的判責依據。

1.2 質檢流程日益復雜的挑戰

質檢流程不是一成不變的，它受到以下因素影響：

商品品類不同，要執行不同的質檢節點

站點不同，流程分支不一致

新業務模式上線，質檢鏈路頻繁調整

比如：一個“C2B”的質檢流程可能是“收貨 →  質檢  → 上架審核”，而一個“B2C”流程則是“錄入 → 質檢 →   拍照 →  上架審核”。

原有的流程控制方式難以支撐復雜且頻繁變更的業務場景。“配置驅動、可視化流程、快速響應變更”成為我們架構演進的核心訴求，也推動我們從狀態機邁向流程編排。

2.第一階段：基于狀態機的流程控制實踐

在質檢系統早期，我們選擇使用狀態機（FSM, Finite State Machine）模型來驅動整個流程的控制。這是當時非常自然的架構選擇，既滿足了流程的基本控制邏輯，也能較好地與業務事件做綁定，且實現成本可控。

2.1 選用狀態機的背景

初期的質檢業務流程相對簡單：

錄入 → 質檢 →   抽檢 →  上架審核

每一步都有明確的起止條件與狀態變化，非常適合用狀態機建模。每個任務都可抽象成一個“流程實例”，而流程實例的每個階段則用“狀態”表示。

2.2 狀態機模型設計

我們的狀態機核心邏輯包括：

狀態（State）：表示流程當前所處階段，例如 已錄入、已質檢、已抽檢、已上架審核 等；

事件（Event）：外部觸發行為，例如 錄入完成、質檢完成、上架審核完成；

轉移（Transition）：由狀態 + 事件決定的流轉邏輯；

動作（Action）：狀態切換時需要執行的具體業務邏輯，如更新數據庫、推送消息等。

2.3 示例狀態流轉（簡化）

圖片

我們為每種質檢任務維護一套狀態定義，通過狀態圖驅動業務流程。

2.4 實現方式

系統內部基于cola-component-statemachine封裝了一套輕量狀態機框架，開發只需：

配置狀態枚舉 + 轉移規則；

注冊狀態流轉監聽器，綁定處理邏輯；

通過 fireEvent 觸發流轉；

狀態流轉統一落庫，支持流程跟蹤。

例如：

stateMachine.fireEvent(context.getProcessState(), context.getEvent(), context);

2.5 狀態機的優點

狀態機模型在早期階段給我們帶來了不少收益：

? 流程清晰：狀態之間轉換規則明確，易于開發理解和維護；

? 執行穩定：邏輯基于事件驅動，天然適合異步處理和失敗重試；

? 開發效率高：只需要配置狀態與事件即可快速上線新流程；

? 狀態管理方便：支持追蹤流程執行軌跡，方便排查問題。

2.6 面臨的挑戰

但隨著業務復雜度的提升，狀態機模型逐漸暴露出以下問題：

1）流程分支能力弱，流程控制混亂

某些流程節點根據不同條件需要進入不同分支（如：是否抽檢），但狀態機天生不擅長處理條件流；

為實現分支流轉，我們建立了流轉單概念，執行完成節點后，調用單獨的功能去計算下一個要執行節點，建立對應的流轉單；

圖片

由于流轉單和狀態機同時存在導致后續維護人員不清楚使用什么控制對應的功能，導致流程控制混亂

2）并行流程支持能力差

質檢業務中存在多個任務并行處理的場景；

狀態機模型天然是線性流轉模型，缺乏原生的并發節點、同步等待、匯聚等能力；

要實現并發處理，需要額外引入中間狀態和異步控制邏輯，極易導致代碼復雜化、狀態混亂。

3）產品運營無法自主控制流程

所有流程變更都需要開發參與；

產品無法“可視化配置流程”，流程靈活性嚴重受限。

2.7 小結

狀態機作為質檢流程的第一個技術實現形態，幫助我們度過了流程初期“可控但固定”的階段，為質檢系統的穩定運行打下了良好基礎。但在面對 復雜性提升、業務高頻調整 的現實挑戰時，它逐漸難以勝任。

這一階段的經驗與教訓，推動我們開始思考：

有沒有一種更靈活、可配置、對業務友好的流程控制方式？

這也引出了我們探索工作流引擎的下一階段。

3.第二階段：工作流引擎的探索與評估

隨著質檢業務復雜度不斷提升，原本基于狀態機的流程控制架構逐漸難以滿足需求，暴露出流程分支弱、并行處理能力差、流程配置依賴開發等問題。在這種背景下，我們開始考慮是否引入成熟的工作流引擎來承接未來的流程管理能力。

工作流引擎相比狀態機具有更強的流程建模能力，天生支持條件判斷、并發處理、任務分派、流程追蹤等能力。為了選出最適合我們業務場景的引擎，我們調研并評估了以下幾款主流工作流引擎，包括 Flowable、Camunda、Activiti、Zeebe、Netflix Conductor 等。

3.1 主流引擎能力對比

3.2 引擎能力基本滿足，但遷移與性能問題突出

經過深入業務流程建模驗證后，我們發現這些引擎的建模能力、并行支持、條件流轉處理等都能較好滿足當前質檢流程的核心訴求，在功能層面具有較高的可用性。

但是在設計過程中，我們也遇到了一些關鍵挑戰：

遷移成本高：將現有流程與質檢系統完全遷移至工作流引擎意味著流程表達需要重新建模、任務系統需要全面適配，風險與人力成本高；

性能表現不佳：引擎對高并發下的任務執行、事件響應等性能瓶頸難以規避；

黑盒感強：調試和排查難度大，且不易擴展復雜的業務規則。

3.3 最終選擇：基于工作流思想，自研流程編排引擎

在充分評估上述優劣后，我們意識到：雖然現有開源工作流引擎“功能夠用”，但并不適合我們。

因此，團隊最終決定：借鑒成熟工作流引擎的核心思想（BPMN建模、執行流控制），結合我們質檢業務對流程顆粒度控制、節點靈活配置、自定義擴展能力的訴求，自研一套輕量級流程編排引擎，更好地支撐復雜質檢流程的靈活演進與運營驅動。

4 第三階段：結合工作流思想的自研流程編排引擎

4.1 自研流程編排引擎的核心設計目標

我們自研流程編排引擎的目標不是重造一個 BPMN 引擎，而是結合自身業務需求，設計一套“既能建模流程邏輯，又能快速適配現有系統，簡單易用”的引擎：

4.2 引擎核心模塊設計

我們將整個流程編排引擎拆分為以下核心模塊

4.2.1 流程建模模塊

核心概念

節點模板流程中一個具體的作業環節原型，例如“質檢”“抽檢”“拍照”等。模板描述的是環節的業務語義和通用執行邏輯，可被不同流程復用。

節點基于節點模板實例化的流程環節。雖然同為“質檢”節點，不同業務線可有差異化的配置，例如執行規則、質檢標準、圖片要求等。

節點配置綁定在節點上的具體規則，包括執行條件、輸入輸出參數、校驗規則等。在節點執行時，這些配置會直接影響任務的處理方式。

連接線描述節點間可達的流轉關系及條件。例如，從“質檢”節點到“抽檢”節點的路徑可能要求質檢結果為“待復檢”。

流出規則決定流程是否進入下一個節點的條件判斷，類似 BPMN 中的Sequence Flow 條件表達式。

網關用于處理流程中的分支、匯聚、并行等復雜邏輯。為降低配置復雜度，我們將網關能力直接集成到節點配置中，由節點自身決定流轉策略。

線體流程的完整載體，由多個節點與連接線構成。一個線體即代表一個完整的質檢作業流程模型。

作業單用于記錄質檢相關的基礎信息（設備信息、檢測類型、進度等），并標識該作業在流程線體中的當前位置。同時為質檢人員提供可查詢、可追溯的運營能力。

作業任務單節點執行的核心控制單元。當流程進入某節點時，會生成對應的作業任務單，用于驅動節點執行、記錄執行結果、觸發后續流轉。

概念關系圖

圖片

在流程模型設計完成后，我們進入了落地實現階段。前端采用 AntV X6 框架，實現可視化流程編排與節點配置能力；所有配置數據均以 JSON 格式進行結構化存儲，既方便前端渲染和交互，又便于后端解析與版本管理，為流程的靈活調整和快速迭代提供了堅實基礎。

4.2.2 流程引擎調度器

在完成流程建模之后，進入流程調度階段。流程調度是流程編排引擎的核心執行環節，我們將其拆分為四個步驟：

圖片

查詢作業單從存儲中獲取當前作業單，包含質檢對象的基礎信息與當前流程執行位置。

加載流程節點與連接信息根據作業單關聯的線體，獲取當前節點及其相關的連接線定義。

規則計算下一執行節點調用規則引擎，結合節點配置與業務上下文，計算流程的下一步目標節點（支持分支、并行等邏輯）。

創建作業任務單為目標節點生成對應的作業任務單，作為后續執行調度與狀態追蹤的核心控制單元。

4.2.3 節點執行器機制

在生成具體的作業任務單后，系統即可進入節點執行階段。節點執行過程可拆分為以下五個步驟：

圖片

進入節點執行啟動當前作業任務單對應的節點作業流程。

加載節點配置根據作業任務單關聯的節點 ID，獲取該節點的詳細配置與執行規則。

規則驅動節點作業按照節點配置的規則與業務邏輯，執行質檢、拍照、判責等具體作業操作。

標記任務完成作業完成后，將對應的作業任務單狀態更新為“已完成”，并記錄執行結果。

異步觸發流程調度通過事件驅動或消息隊列，異步通知流程引擎調度器，計算并執行下一步流程節點。

5.演進效果與落地實踐

5.1 節點配置

圖片

這張圖展示了單個流程節點的可視化配置界面，是運營和產品調整流程的核心入口。

作用：定義節點的執行邏輯、質檢規則等。

意義：

過去這些規則需要開發寫死在代碼中，現在只需在頁面上修改參數即可生效。

支持業務線差異化，比如不同站點的“質檢”節點可以配置不同的質檢標準或圖片要求。

讓流程細節可視化，運營可直接理解和調整，無需依賴研發。

5.2 線體配置（簡化）

圖片

這張圖展示了完整質檢流程的編排視圖，類似于一個可拖拽的流程圖。

作用：將多個節點按照業務邏輯連接成“線體”（完整作業流程），并定義節點間的流轉條件、分支、并行關系等。

意義：

過去需要在狀態機和流轉單中分散實現，現在可以一圖呈現整個鏈路，清晰直觀。

可直接在圖中調整節點順序、修改條件分支，實現“所見即所得”的流程配置。

支持復雜場景（如條件分支、并行節點、網關匯聚）而不增加開發成本。

6.未來展望

當前，自研流程編排引擎已穩定承載質檢新業務的全流程運行。下一階段，我們將推動存量舊流程的平滑遷移，實現新舊業務的統一調度與集中管理。同時，計劃升級引擎架構，引入低代碼能力，開放更豐富的可視化配置與擴展接口，以更高的靈活性與敏捷性響應業務變化。

關于作者 李冠，轉轉履約中臺研發工程師，主要負責質檢業務