1 引言：流程編排的現(xiàn)實需求

1.1 什么是質(zhì)檢系統(tǒng)？

1.2 質(zhì)檢流程日益復雜的挑戰(zhàn)

2 第一階段：基于狀態(tài)機的流程控制實踐

2.1 選用狀態(tài)機的背景

2.2 狀態(tài)機模型設計

2.3 示例狀態(tài)流轉(zhuǎn)（簡化）

2.4 實現(xiàn)方式

2.5 狀態(tài)機的優(yōu)點

2.6 面臨的挑戰(zhàn)

2.7 小結(jié)

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

3.1 主流引擎能力對比

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

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

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

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

4.2 引擎核心模塊設計

5 演進效果與落地實踐

5.1 節(jié)點配置

5.2 線體配置（簡化）

6 未來展望

1、引言：流程編排的現(xiàn)實需求

1.1 什么是質(zhì)檢系統(tǒng)？

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

1.2 質(zhì)檢流程日益復雜的挑戰(zhàn)

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

商品品類不同，要執(zhí)行不同的質(zhì)檢節(jié)點

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

新業(yè)務模式上線，質(zhì)檢鏈路頻繁調(diào)整

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

原有的流程控制方式難以支撐復雜且頻繁變更的業(yè)務場景?！芭渲抿?qū)動、可視化流程、快速響應變更”成為我們架構(gòu)演進的核心訴求，也推動我們從狀態(tài)機邁向流程編排。

2.第一階段：基于狀態(tài)機的流程控制實踐

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

2.1 選用狀態(tài)機的背景

初期的質(zhì)檢業(yè)務流程相對簡單：

錄入 → 質(zhì)檢 →   抽檢 →  上架審核

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

2.2 狀態(tài)機模型設計

我們的狀態(tài)機核心邏輯包括：

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

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

轉(zhuǎn)移（Transition）：由狀態(tài) + 事件決定的流轉(zhuǎn)邏輯；

動作（Action）：狀態(tài)切換時需要執(zhí)行的具體業(yè)務邏輯，如更新數(shù)據(jù)庫、推送消息等。

2.3 示例狀態(tài)流轉(zhuǎn)（簡化）

圖片

我們?yōu)槊糠N質(zhì)檢任務維護一套狀態(tài)定義，通過狀態(tài)圖驅(qū)動業(yè)務流程。

2.4 實現(xiàn)方式

系統(tǒng)內(nèi)部基于cola-component-statemachine封裝了一套輕量狀態(tài)機框架，開發(fā)只需：

配置狀態(tài)枚舉 + 轉(zhuǎn)移規(guī)則；

注冊狀態(tài)流轉(zhuǎn)監(jiān)聽器，綁定處理邏輯；

通過 fireEvent 觸發(fā)流轉(zhuǎn)；

狀態(tài)流轉(zhuǎn)統(tǒng)一落庫，支持流程跟蹤。

例如：

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

2.5 狀態(tài)機的優(yōu)點

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

? 流程清晰：狀態(tài)之間轉(zhuǎn)換規(guī)則明確，易于開發(fā)理解和維護；

? 執(zhí)行穩(wěn)定：邏輯基于事件驅(qū)動，天然適合異步處理和失敗重試；

? 開發(fā)效率高：只需要配置狀態(tài)與事件即可快速上線新流程；

? 狀態(tài)管理方便：支持追蹤流程執(zhí)行軌跡，方便排查問題。

2.6 面臨的挑戰(zhàn)

但隨著業(yè)務復雜度的提升，狀態(tài)機模型逐漸暴露出以下問題：

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

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

為實現(xiàn)分支流轉(zhuǎn)，我們建立了流轉(zhuǎn)單概念，執(zhí)行完成節(jié)點后，調(diào)用單獨的功能去計算下一個要執(zhí)行節(jié)點，建立對應的流轉(zhuǎn)單；

圖片

由于流轉(zhuǎn)單和狀態(tài)機同時存在導致后續(xù)維護人員不清楚使用什么控制對應的功能，導致流程控制混亂

2）并行流程支持能力差

質(zhì)檢業(yè)務中存在多個任務并行處理的場景；

狀態(tài)機模型天然是線性流轉(zhuǎn)模型，缺乏原生的并發(fā)節(jié)點、同步等待、匯聚等能力；

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

3）產(chǎn)品運營無法自主控制流程

所有流程變更都需要開發(fā)參與；

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

2.7 小結(jié)

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

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

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

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

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

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

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

3.1 主流引擎能力對比

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

經(jīng)過深入業(yè)務流程建模驗證后，我們發(fā)現(xiàn)這些引擎的建模能力、并行支持、條件流轉(zhuǎn)處理等都能較好滿足當前質(zhì)檢流程的核心訴求，在功能層面具有較高的可用性。

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

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

性能表現(xiàn)不佳：引擎對高并發(fā)下的任務執(zhí)行、事件響應等性能瓶頸難以規(guī)避；

黑盒感強：調(diào)試和排查難度大，且不易擴展復雜的業(yè)務規(guī)則。

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

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

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

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

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

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

4.2 引擎核心模塊設計

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

4.2.1 流程建模模塊

核心概念

節(jié)點模板流程中一個具體的作業(yè)環(huán)節(jié)原型，例如“質(zhì)檢”“抽檢”“拍照”等。模板描述的是環(huán)節(jié)的業(yè)務語義和通用執(zhí)行邏輯，可被不同流程復用。

節(jié)點基于節(jié)點模板實例化的流程環(huán)節(jié)。雖然同為“質(zhì)檢”節(jié)點，不同業(yè)務線可有差異化的配置，例如執(zhí)行規(guī)則、質(zhì)檢標準、圖片要求等。

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

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

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

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

線體流程的完整載體，由多個節(jié)點與連接線構(gòu)成。一個線體即代表一個完整的質(zhì)檢作業(yè)流程模型。

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

作業(yè)任務單節(jié)點執(zhí)行的核心控制單元。當流程進入某節(jié)點時，會生成對應的作業(yè)任務單，用于驅(qū)動節(jié)點執(zhí)行、記錄執(zhí)行結(jié)果、觸發(fā)后續(xù)流轉(zhuǎn)。

概念關系圖

圖片

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

4.2.2 流程引擎調(diào)度器

在完成流程建模之后，進入流程調(diào)度階段。流程調(diào)度是流程編排引擎的核心執(zhí)行環(huán)節(jié)，我們將其拆分為四個步驟：

圖片

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

加載流程節(jié)點與連接信息根據(jù)作業(yè)單關聯(lián)的線體，獲取當前節(jié)點及其相關的連接線定義。

規(guī)則計算下一執(zhí)行節(jié)點調(diào)用規(guī)則引擎，結(jié)合節(jié)點配置與業(yè)務上下文，計算流程的下一步目標節(jié)點（支持分支、并行等邏輯）。

創(chuàng)建作業(yè)任務單為目標節(jié)點生成對應的作業(yè)任務單，作為后續(xù)執(zhí)行調(diào)度與狀態(tài)追蹤的核心控制單元。

4.2.3 節(jié)點執(zhí)行器機制

在生成具體的作業(yè)任務單后，系統(tǒng)即可進入節(jié)點執(zhí)行階段。節(jié)點執(zhí)行過程可拆分為以下五個步驟：

圖片

進入節(jié)點執(zhí)行啟動當前作業(yè)任務單對應的節(jié)點作業(yè)流程。

加載節(jié)點配置根據(jù)作業(yè)任務單關聯(lián)的節(jié)點 ID，獲取該節(jié)點的詳細配置與執(zhí)行規(guī)則。

規(guī)則驅(qū)動節(jié)點作業(yè)按照節(jié)點配置的規(guī)則與業(yè)務邏輯，執(zhí)行質(zhì)檢、拍照、判責等具體作業(yè)操作。

標記任務完成作業(yè)完成后，將對應的作業(yè)任務單狀態(tài)更新為“已完成”，并記錄執(zhí)行結(jié)果。

異步觸發(fā)流程調(diào)度通過事件驅(qū)動或消息隊列，異步通知流程引擎調(diào)度器，計算并執(zhí)行下一步流程節(jié)點。

5.演進效果與落地實踐

5.1 節(jié)點配置

圖片

這張圖展示了單個流程節(jié)點的可視化配置界面，是運營和產(chǎn)品調(diào)整流程的核心入口。

作用：定義節(jié)點的執(zhí)行邏輯、質(zhì)檢規(guī)則等。

意義：

過去這些規(guī)則需要開發(fā)寫死在代碼中，現(xiàn)在只需在頁面上修改參數(shù)即可生效。

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

讓流程細節(jié)可視化，運營可直接理解和調(diào)整，無需依賴研發(fā)。

5.2 線體配置（簡化）

圖片

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

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

意義：

過去需要在狀態(tài)機和流轉(zhuǎn)單中分散實現(xiàn)，現(xiàn)在可以一圖呈現(xiàn)整個鏈路，清晰直觀。

可直接在圖中調(diào)整節(jié)點順序、修改條件分支，實現(xiàn)“所見即所得”的流程配置。

支持復雜場景（如條件分支、并行節(jié)點、網(wǎng)關匯聚）而不增加開發(fā)成本。

6.未來展望

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

關于作者 李冠，轉(zhuǎn)轉(zhuǎn)履約中臺研發(fā)工程師，主要負責質(zhì)檢業(yè)務