Flowable這個(gè)開源工作流引擎在我們系統(tǒng)里躺了大半年之后我終于決定在它上面再蓋一層統(tǒng)一流程平臺(tái)。說實(shí)話這一步不是一開始就想好的而是被現(xiàn)實(shí)逼出來的最初只是想找一個(gè)能畫BPMN流程圖、能跑審批的引擎結(jié)果半年后十幾個(gè)業(yè)務(wù)系統(tǒng)都在各自調(diào)Flowable的API每個(gè)項(xiàng)目組自己部署一套流程模型散落各處待辦任務(wù)互相看不見。寫這篇文章是想把我們從“裸用Flowable”到“建設(shè)統(tǒng)一流程平臺(tái)”的完整過程、關(guān)鍵設(shè)計(jì)和踩過的坑整理出來給正在用工作流引擎、或者正準(zhǔn)備做流程中臺(tái)的團(tuán)隊(duì)一個(gè)參考。這篇文章適合三類人一是已經(jīng)用上Flowable、但覺得有點(diǎn)失控的開發(fā)者二是正在做流程平臺(tái)選型或架構(gòu)設(shè)計(jì)的技術(shù)負(fù)責(zé)人三是對(duì)BPM、工作流領(lǐng)域感興趣、想了解這套東西落地長什么樣的同學(xué)。我會(huì)從為什么選Flowable開始講然后說清楚Flowable直接使用會(huì)遇到的典型問題再重點(diǎn)展開統(tǒng)一流程平臺(tái)的整體設(shè)計(jì)、核心實(shí)操細(xì)節(jié)、以及我在真實(shí)業(yè)務(wù)里踩過的坑和排查思路。內(nèi)容會(huì)以實(shí)際可落地的方案為主不是泛泛的架構(gòu)概念。1. 為什么拿Flowable當(dāng)起點(diǎn)先說一個(gè)很多人會(huì)問的問題既然最終要做統(tǒng)一流程平臺(tái)為什么不一開始就自己寫一套流程引擎說實(shí)話工作流引擎這件事看起來不難無非就是“節(jié)點(diǎn)流轉(zhuǎn)、條件判斷、任務(wù)分配”但真要把BPMN 2.0的網(wǎng)關(guān)、子流程、事件、多實(shí)例、定時(shí)器都做穩(wěn)定沒有一兩年持續(xù)投入是做不出來的。所以當(dāng)時(shí)我們很務(wù)實(shí)地選擇了先站在Flowable的肩膀上。1.1 Flowable到底是什么Flowable是基于BPMN 2.0標(biāo)準(zhǔn)的開源工作流引擎它起源于更早的Activiti 5/6分支后來獨(dú)立發(fā)展目前社區(qū)版和企業(yè)版并行。核心能力包括解析和執(zhí)行BPMN 2.0流程定義、維護(hù)流程實(shí)例和任務(wù)、記錄歷史數(shù)據(jù)、支持定時(shí)器、消息事件、信號(hào)事件以及比較完整的表單集成方案。Java生態(tài)里用得非常廣這也是我們當(dāng)時(shí)選它的一個(gè)重要原因——團(tuán)隊(duì)都是Java背景排查問題、二次開發(fā)都比較順手。在Flowable里幾個(gè)核心對(duì)象要心里有數(shù)流程定義ProcessDefinition相當(dāng)于“圖紙”部署好之后不可變流程實(shí)例ProcessInstance是按圖紙創(chuàng)建的一次具體流轉(zhuǎn)相當(dāng)于“一棟按圖建出來的樓”任務(wù)Task是流轉(zhuǎn)過程中待辦的一個(gè)節(jié)點(diǎn)執(zhí)行實(shí)例Execution則更細(xì)代表當(dāng)前運(yùn)行到哪條分支。理解這幾個(gè)概念的層級(jí)關(guān)系后面做平臺(tái)封裝才會(huì)心里有底。1.2 選Flowable而不是自己造輪子的三個(gè)理由第一BPMN 2.0的覆蓋面很全。會(huì)簽、或簽、并行網(wǎng)關(guān)、排他網(wǎng)關(guān)、子流程、邊界事件、補(bǔ)償事件這些都是業(yè)務(wù)上非常高頻的需求自己從零寫一個(gè)能讓模型穩(wěn)定跑在生產(chǎn)環(huán)境的引擎工作量遠(yuǎn)超想象。第二Flowable的表結(jié)構(gòu)公開、數(shù)據(jù)模型清晰運(yùn)行實(shí)例、任務(wù)、歷史都分開存放對(duì)于做監(jiān)控和二次開發(fā)非常友好。第三它的API設(shè)計(jì)相對(duì)穩(wěn)定RuntimeService、TaskService、HistoryService、RepositoryService這些核心服務(wù)接口多年沒有大變動(dòng)意味著平臺(tái)層可以相對(duì)穩(wěn)定地建立在它之上。當(dāng)時(shí)我們是拿一個(gè)請(qǐng)假審批的Demo做了驗(yàn)證部署流程圖、發(fā)起流程、查待辦、審批通過、查詢歷史半天時(shí)間全部跑通。這個(gè)速度讓我們很確定流程引擎本身不需要自己寫精力應(yīng)該放在業(yè)務(wù)能力的抽象上。但也是從這個(gè)時(shí)候開始隱患已經(jīng)埋下了。2. Flowable直接裸用用著用著就疼了流程引擎跑起來之后業(yè)務(wù)團(tuán)隊(duì)很快發(fā)現(xiàn)這東西好用于是“請(qǐng)假審批”剛上線緊接著就有報(bào)銷、合同、采購、出入庫等各種流程需求找過來。每個(gè)系統(tǒng)各接各的Flowable看著熱鬧實(shí)際是問題的集中爆發(fā)期。2.1 最直接的問題業(yè)務(wù)代碼和流程代碼糾纏不清在裸用階段每個(gè)業(yè)務(wù)系統(tǒng)都要自己維護(hù)一套啟動(dòng)流程、處理任務(wù)的代碼。比如一個(gè)業(yè)務(wù)系統(tǒng)要發(fā)起審批它要做的事包括往自己的業(yè)務(wù)表里插一條單據(jù)數(shù)據(jù)再調(diào)flowable的RuntimeService.startProcessInstanceByKey發(fā)起流程還要準(zhǔn)備一個(gè)業(yè)務(wù)表主鍵和流程實(shí)例ID的映射關(guān)系審批回調(diào)時(shí)再根據(jù)流程實(shí)例ID去反查業(yè)務(wù)數(shù)據(jù)。這套代碼寫一次兩次沒問題寫了十幾個(gè)系統(tǒng)之后問題就來了每個(gè)系統(tǒng)的映射方式不一樣有的用businessKey有的用流程變量有的自己在擴(kuò)展表里存關(guān)聯(lián)后續(xù)做統(tǒng)一查詢、統(tǒng)一待辦的時(shí)候數(shù)據(jù)根本對(duì)不齊。更麻煩的是沒經(jīng)過平臺(tái)約束的流程模型寫起來很隨意。有的流程把所有審批邏輯塞進(jìn)一個(gè)ServiceTask里有的把業(yè)務(wù)規(guī)則寫在網(wǎng)關(guān)條件表達(dá)式里有的干脆用排他網(wǎng)關(guān)模擬一切。流程圖最后淪為了擺設(shè)真真正正的邏輯都藏在Java delegate里流程定義換代時(shí)根本不敢動(dòng)。2.2 重復(fù)建設(shè)與權(quán)限割裂審批意見、加簽、轉(zhuǎn)辦、撤回、催辦、待辦提醒這些跟流程強(qiáng)相關(guān)但又非常通用的功能我們當(dāng)時(shí)在每個(gè)系統(tǒng)里都重復(fù)實(shí)現(xiàn)了一遍。A系統(tǒng)寫了一套加簽邏輯B系統(tǒng)又寫了一套實(shí)現(xiàn)方式還不一樣——有的用Flowable的ADD_AND_APPROVE變更任務(wù)辦理人有的直接在任務(wù)變量里存了一個(gè)加簽人列表由應(yīng)用層自己判斷處理。這套東西的時(shí)間成本和維護(hù)成本都很高。還有一個(gè)讓人頭疼的問題是權(quán)限割裂。崗位A的管理者在系統(tǒng)1里能看到待辦在系統(tǒng)2里又得重新配置一遍權(quán)限才能看到那套流程的待辦同一個(gè)人的待辦任務(wù)散落在多個(gè)系統(tǒng)里沒有一個(gè)匯總視圖。用戶每天都得去各個(gè)系統(tǒng)里翻一遍有沒有需要自己審批的單子。這種體驗(yàn)很差而這其實(shí)是流程平臺(tái)治理缺失的典型表現(xiàn)——流程引擎只是提供了“流轉(zhuǎn)”的技術(shù)能力并沒有把“人的視角”統(tǒng)一起來。2.3 運(yùn)維與治理基本是空白Flowable裸用階段運(yùn)維基本是靠“流程沒跑掛就沒人管”。某次有一個(gè)定時(shí)器任務(wù)因?yàn)閳?zhí)行節(jié)點(diǎn)所在服務(wù)重啟一批定時(shí)器全部錯(cuò)過觸發(fā)時(shí)間要不是業(yè)務(wù)人員反饋“單子卡住了”我們根本發(fā)現(xiàn)不了。再比如流程模型更新當(dāng)時(shí)直接覆蓋部署結(jié)果因?yàn)樾掳姹镜牧鞒虉D里刪了一個(gè)節(jié)點(diǎn)導(dǎo)致還在途的舊流程實(shí)例在查詢?nèi)蝿?wù)時(shí)出現(xiàn)空指針最后只能手工改數(shù)據(jù)庫才把流程救回來。還有一個(gè)隱藏問題歷史數(shù)據(jù)無限膨脹。Flowable默認(rèn)會(huì)往歷史表里寫大量數(shù)據(jù)ACT_HI_ACTINST這張表幾乎記錄了流程實(shí)例的每一個(gè)執(zhí)行節(jié)點(diǎn)動(dòng)作高并發(fā)流程跑上幾個(gè)月這張表就是千萬級(jí)起步。我們沒有做歸檔策略數(shù)據(jù)庫越來越慢最后拖累了正常的流程任務(wù)查詢。到這一步我們基本意識(shí)到Flowable解決的是“單個(gè)流程怎么跑”的問題而公司需要的其實(shí)是“所有流程怎么被管起來、被統(tǒng)一使用”的問題。這二者之間有巨大的工程缺口。3. 統(tǒng)一流程平臺(tái)設(shè)計(jì)的關(guān)鍵決策統(tǒng)一流程平臺(tái)這個(gè)東西說起來容易做起來需要非常清醒地想清楚一個(gè)問題我們做的到底是一個(gè)給開發(fā)者調(diào)用的SDK還是一個(gè)給全公司業(yè)務(wù)系統(tǒng)使用的平臺(tái)。這兩者的設(shè)計(jì)思路完全不同。我們最后明確平臺(tái)必須成為一個(gè)獨(dú)立的、可獨(dú)立部署的中間層Flowable只是這個(gè)平臺(tái)內(nèi)部的一個(gè)引擎組件對(duì)外完全屏蔽。3.1 平臺(tái)定位流程資產(chǎn)的統(tǒng)一管理入口統(tǒng)一流程平臺(tái)的本質(zhì)是把自己定位成所有流程資產(chǎn)的統(tǒng)一管理入口。所有流程模型都必須在平臺(tái)上注冊(cè)所有流程的發(fā)起、審批、查詢、歸檔都通過平臺(tái)進(jìn)行業(yè)務(wù)系統(tǒng)不允許繞過平臺(tái)直接操作引擎底層API。聽起來像是一刀切的規(guī)定但實(shí)際上這是避免失控最有效的手段。平臺(tái)化之后各個(gè)業(yè)務(wù)系統(tǒng)的角色從“自己管流程”變成了“向平臺(tái)申請(qǐng)流程能力”。比如業(yè)務(wù)系統(tǒng)需要一個(gè)新的審批流程開發(fā)同學(xué)只需要在平臺(tái)上設(shè)計(jì)BPMN模型、配置好表單地址和權(quán)限策略、申請(qǐng)一個(gè)唯一的流程Key然后通過統(tǒng)一的API發(fā)起流程、接收回調(diào)即可。流程模型、運(yùn)行數(shù)據(jù)、歷史數(shù)據(jù)、待辦權(quán)限全部沉淀在平臺(tái)側(cè)方便統(tǒng)一治理。3.2 兩個(gè)決定性架構(gòu)決策第一個(gè)決策統(tǒng)一入口。所有流程發(fā)起統(tǒng)一走平臺(tái)的“發(fā)起流程”開放接口而不是允許業(yè)務(wù)系統(tǒng)直接new一個(gè)ProcessEngine然后調(diào)用startProcessInstanceByKey。這樣做的好處非常實(shí)際平臺(tái)可以在發(fā)起的必經(jīng)之路上做權(quán)限校驗(yàn)、參數(shù)規(guī)整、冪等控制、數(shù)據(jù)埋點(diǎn)。第二個(gè)決策統(tǒng)一運(yùn)行時(shí)。Platform模式即平臺(tái)內(nèi)部只維護(hù)一個(gè)Flowable引擎實(shí)例所有流程跑在同一個(gè)引擎上。而不是每個(gè)業(yè)務(wù)域獨(dú)立部署引擎實(shí)例來跑自己的流程。統(tǒng)一運(yùn)行時(shí)的好處是待辦任務(wù)天然就匯合在一起查詢所有系統(tǒng)流程的待辦只需要對(duì)ACT_RU_TASK表做一次查詢不需要跨庫聯(lián)表。這兩個(gè)決策做下來后面很多模塊就順理成章了。3.3 整體架構(gòu)分層我們的平臺(tái)架構(gòu)大致是四層最上層是接入層也叫Open API層面向業(yè)務(wù)系統(tǒng)提供發(fā)起流程、審批、查詢、撤回等統(tǒng)一接口。接入層負(fù)責(zé)身份鑒權(quán)、參數(shù)校驗(yàn)、數(shù)據(jù)權(quán)限過濾業(yè)務(wù)系統(tǒng)通過這些接口與平臺(tái)交互不感知底層引擎。往下一層是流程編排層負(fù)責(zé)流程模型的注冊(cè)、流程分類管理、表單配置、權(quán)限策略配置、流程擴(kuò)展點(diǎn)配置。這一層做的是“建模與業(yè)務(wù)策略的綁定”比如某個(gè)流程發(fā)起前要校驗(yàn)什么、審批通過后要回調(diào)哪個(gè)系統(tǒng)都在這一層配置。第三層是引擎適配層這是對(duì)Flowable的二次封裝。把RuntimeService、TaskService、HistoryService等原生API包裝成平臺(tái)內(nèi)部的服務(wù)并補(bǔ)充了流程實(shí)例與業(yè)務(wù)單據(jù)的關(guān)聯(lián)映射、統(tǒng)一任務(wù)模型、事件監(jiān)聽分發(fā)等能力。最底層是數(shù)據(jù)層包括Flowable自身的ACT_*表以及我們自己補(bǔ)充的業(yè)務(wù)關(guān)聯(lián)表、平臺(tái)配置表、擴(kuò)展字段表。數(shù)據(jù)層做的事情很簡(jiǎn)單讓平臺(tái)的數(shù)據(jù)模型能自洽地支撐上層業(yè)務(wù)。3.4 平臺(tái)的核心模塊統(tǒng)一流程平臺(tái)從功能上可以拆成幾個(gè)核心模塊。流程模型管理模塊負(fù)責(zé)BPMN文件的上傳、校驗(yàn)、部署、版本管理、下線處理。這個(gè)模塊把“流程模型”從開發(fā)者的本地文件變成平臺(tái)的可管理資產(chǎn)。流程運(yùn)行模塊負(fù)責(zé)發(fā)起流程、驅(qū)動(dòng)任務(wù)流轉(zhuǎn)、處理各類事件。這個(gè)模塊封裝了Flowable最核心的運(yùn)行時(shí)操作是業(yè)務(wù)系統(tǒng)調(diào)用最頻繁的地方。任務(wù)中心模塊負(fù)責(zé)統(tǒng)一展示所有待辦、已辦、抄送、我發(fā)起的任務(wù)。它不只從Flowable取任務(wù)數(shù)據(jù)還要聚合業(yè)務(wù)摘要、表單地址、優(yōu)先級(jí)、超時(shí)信息等讓用戶在一個(gè)頁面處理所有系統(tǒng)的審批。權(quán)限與策略模塊負(fù)責(zé)流程發(fā)起權(quán)限、任務(wù)操作權(quán)限、數(shù)據(jù)權(quán)限的集中控制。這塊是平臺(tái)能否落地的關(guān)鍵后面實(shí)操章節(jié)我會(huì)細(xì)說。監(jiān)控運(yùn)維模塊負(fù)責(zé)流程積壓、超時(shí)、異常實(shí)例、歷史數(shù)據(jù)歸檔等運(yùn)維能力。沒有這個(gè)模塊平臺(tái)就只是個(gè)能跑的引擎而不是一個(gè)能長期穩(wěn)定服務(wù)的平臺(tái)。4. 核心實(shí)操從裸用Flowable到平臺(tái)化改造平臺(tái)化的改造不是重新寫一套系統(tǒng)而是一個(gè)個(gè)把能力收攏到平臺(tái)側(cè)的過程。下面按實(shí)操順序講每一步都是我們能直接復(fù)用的經(jīng)驗(yàn)。4.1 流程定義統(tǒng)一注冊(cè)與管理第一步把所有存量流程模型收攏到平臺(tái)統(tǒng)一管理。我們建了一張流程模型注冊(cè)表我們叫PROC_MODEL_REG字段包括流程Key、流程名稱、所屬分類、版本號(hào)、部署ID、狀態(tài)草稿/已發(fā)布/已下線、負(fù)責(zé)人、表單標(biāo)識(shí)、回調(diào)地址。這張表是流程資產(chǎn)的“戶口本”所有模型在平臺(tái)里都有一個(gè)正式檔案。一個(gè)容易出錯(cuò)的地方是Flowable自身的流程定義版本機(jī)制。同一個(gè)流程Key每次部署會(huì)生成一個(gè)新的流程定義ID帶有版本號(hào)。如果業(yè)務(wù)系統(tǒng)用老的部署方式直接按Key發(fā)起流程Flowable默認(rèn)會(huì)使用最新版本。這在流程在途的情況下容易出問題明明A流程實(shí)例是上個(gè)月發(fā)起的中間的邏輯應(yīng)該按舊版本來但新發(fā)起的流程已經(jīng)使用了新版本。我們的做法是在注冊(cè)表里維護(hù)每個(gè)流程當(dāng)前允許發(fā)起的最小版本和默認(rèn)版本發(fā)起流程前明確指定要使用的部署版本避免模糊匹配。BPMN文件的來源也要管好。我們從一開始就確定了“模型入庫 Git備份”雙保險(xiǎn)BPMN文件上傳到平臺(tái)后既存一份到數(shù)據(jù)庫用來部署和展示也同步提交一份到Git倉庫用來追溯和Diff。上線一段時(shí)間后回頭看這個(gè)習(xí)慣救了我們好幾次——某次模型誤覆蓋我們就是靠Git歷史版本還原的。4.2 發(fā)起流程的統(tǒng)一入口發(fā)起流程是業(yè)務(wù)系統(tǒng)使用頻率最高、也最容易出問題的一個(gè)動(dòng)作。平臺(tái)提供的“發(fā)起流程”接口我們定義為platform.startProcess(procKey, businessId, operatorId, variables)。其中businessId是業(yè)務(wù)系統(tǒng)里的單據(jù)主鍵operatorId是發(fā)起人variables是這次流程攜帶的業(yè)務(wù)變量。這里重點(diǎn)說businessId的用法。我們要求業(yè)務(wù)系統(tǒng)必須以業(yè)務(wù)單據(jù)主鍵作為業(yè)務(wù)關(guān)聯(lián)標(biāo)識(shí)平臺(tái)內(nèi)部會(huì)維護(hù)一張流程實(shí)例與業(yè)務(wù)單號(hào)的關(guān)聯(lián)表PROC_BIZ_REL。這個(gè)設(shè)計(jì)解決了之前在途流程單和流程實(shí)例映射混亂的問題。后續(xù)所有“根據(jù)單據(jù)查流程狀態(tài)”“根據(jù)流程實(shí)例查業(yè)務(wù)單號(hào)”的操作都只查這一張表性能非常好邏輯也干凈。發(fā)起流程前平臺(tái)要做三件事一是校驗(yàn)這個(gè)業(yè)務(wù)系統(tǒng)是否有權(quán)發(fā)起該流程Key二是校驗(yàn)該流程Key當(dāng)前是否在可發(fā)起狀態(tài)而不是已下線三是做冪等控制。冪等控制這點(diǎn)特別容易被忽略但實(shí)際很重要。比如前端按鈕被雙擊或者消息隊(duì)列重復(fù)投遞如果同一個(gè)businessId重復(fù)發(fā)起流程就會(huì)產(chǎn)生多條重復(fù)的流程實(shí)例業(yè)務(wù)上很難處理。我們的方案是在PROC_BIZ_REL里給businessId和procKey建唯一索引重復(fù)發(fā)起時(shí)直接攔截并返回原流程實(shí)例ID而不是新建。4.3 統(tǒng)一任務(wù)中心與任務(wù)操作統(tǒng)一任務(wù)中心是平臺(tái)讓用戶“有感”的關(guān)鍵模塊。它要做的事情是把Flowable的待辦任務(wù)加上業(yè)務(wù)摘要、表單地址、優(yōu)先級(jí)、截止時(shí)間等維度后統(tǒng)一展示給用戶。TaskService.createTaskQuery()直接用起來很快會(huì)發(fā)現(xiàn)幾個(gè)問題。第一待辦任務(wù)查詢條件復(fù)雜后SQL不好優(yōu)化第二Flowable返回的任務(wù)對(duì)象上沒法直接關(guān)聯(lián)業(yè)務(wù)摘要比如“采購申請(qǐng)單號(hào)PO20250801”這種信息需要二次回業(yè)務(wù)表查詢第三權(quán)限過濾如果靠Flowable的taskCandidateUser表達(dá)式配置起來非常繁瑣且不靈活。所以我們沒有直接讓前端查詢Flowable而是做了一層任務(wù)視圖平臺(tái)定時(shí)任務(wù)把待辦數(shù)據(jù)從Flowable同步到自己的任務(wù)寬表里寬表冗余了Flowable任務(wù)ID、任務(wù)Key、流程實(shí)例ID、業(yè)務(wù)單號(hào)、表單標(biāo)識(shí)、業(yè)務(wù)摘要、當(dāng)前節(jié)點(diǎn)名、接收人、創(chuàng)建時(shí)間、優(yōu)先級(jí)等字段。業(yè)務(wù)系統(tǒng)統(tǒng)一查這個(gè)寬表體驗(yàn)和性能都遠(yuǎn)超直查Flowable。任務(wù)操作方面除了基礎(chǔ)的審批同意、駁回我們重點(diǎn)實(shí)現(xiàn)了加簽、轉(zhuǎn)辦、委派、撤回。這四個(gè)操作本質(zhì)都是修改Flowable任務(wù)辦理人但細(xì)節(jié)差異很大。加簽ADD_AND_APPROVE是當(dāng)前任務(wù)繼續(xù)保留、同時(shí)新增一個(gè)會(huì)簽任務(wù)轉(zhuǎn)辦是把任務(wù)直接交給另一個(gè)人處理當(dāng)前人不再是辦理人委派是當(dāng)前人把任務(wù)委派給另一個(gè)人被委派人處理后任務(wù)還會(huì)回到當(dāng)前人撤回一般是發(fā)起人在流程還在第一個(gè)節(jié)點(diǎn)時(shí)主動(dòng)把整個(gè)流程結(jié)束起來。這些操作我們都封裝成平臺(tái)接口業(yè)務(wù)系統(tǒng)不需要再自己調(diào)用TaskService去改辦理人也就不容易出現(xiàn)辦完任務(wù)后歷史里看不到是誰處理的這種問題。4.4 權(quán)限模型從流程級(jí)到任務(wù)級(jí)權(quán)限設(shè)計(jì)直接決定平臺(tái)能否被業(yè)務(wù)方接受。我們經(jīng)過幾輪調(diào)整最后沉淀了一套比較務(wù)實(shí)的權(quán)限模型分兩層流程發(fā)起權(quán)限和任務(wù)處理權(quán)限。流程發(fā)起權(quán)限比較簡(jiǎn)單就是“誰能發(fā)起某類流程”的策略配置可以按部門、崗位、角色、用戶甚至可以按業(yè)務(wù)數(shù)據(jù)規(guī)則來限制。我們把這部分做成了頁面配置而不是寫死在代碼里。這樣業(yè)務(wù)調(diào)整發(fā)起范圍時(shí)不需要發(fā)版。任務(wù)處理權(quán)限復(fù)雜一些核心是解決“誰能看到這個(gè)待辦、誰能處理這個(gè)待辦”。之前裸用Flowable時(shí)有人通過候選組的方式配置待辦候選人的判斷邏輯分散在各處。平臺(tái)的做法是統(tǒng)一在任務(wù)分配策略里管理任務(wù)創(chuàng)建時(shí)根據(jù)流程模型里預(yù)先配置的分單規(guī)則把任務(wù)分配給具體用戶或候選組并在任務(wù)數(shù)據(jù)里寫入允許操作的用戶列表。后面做待辦查詢時(shí)直接按“處理人當(dāng)前用戶”或“當(dāng)前用戶在候選組列表里”過濾簡(jiǎn)單直接也方便做數(shù)據(jù)權(quán)限控制。4.5 事件擴(kuò)展點(diǎn)讓流程和業(yè)務(wù)系統(tǒng)解耦一個(gè)審批流程“審批通過后自動(dòng)更新單據(jù)狀態(tài)”這件事如果寫在Flowable的監(jiān)聽器里那Flowable就和你業(yè)務(wù)系統(tǒng)強(qiáng)耦合了。平臺(tái)的處理方式是提供標(biāo)準(zhǔn)的事件回調(diào)機(jī)制。我們?cè)贔lowable的監(jiān)聽器里只做一件事把事件拋到平臺(tái)的消息管道里。比如任務(wù)創(chuàng)建、任務(wù)完成、流程結(jié)束、流程取消這些事件統(tǒng)一封裝成標(biāo)準(zhǔn)消息體包含事件類型、流程實(shí)例ID、流程Key、任務(wù)ID、業(yè)務(wù)單號(hào)、操作人等字段然后推送給在平臺(tái)上訂閱了這個(gè)流程事件的回調(diào)地址。業(yè)務(wù)系統(tǒng)側(cè)只需要提供一個(gè)接收回調(diào)的HTTP接口在配置中心里登記一下即可。這個(gè)設(shè)計(jì)把流程引擎和業(yè)務(wù)系統(tǒng)徹底解耦了。后面新的業(yè)務(wù)系統(tǒng)接入時(shí)不需要去改平臺(tái)代碼不需要再往Flowable里塞業(yè)務(wù)邏輯只需要注冊(cè)回調(diào)就行。哪怕是改業(yè)務(wù)邏輯也不會(huì)造成流程實(shí)例運(yùn)行中途找不到監(jiān)聽類的問題。4.6 監(jiān)控與歷史歸檔平臺(tái)上線后的第一件事是把積壓任務(wù)監(jiān)控做起來。我們寫了一個(gè)定時(shí)任務(wù)每隔5分鐘統(tǒng)計(jì)ACT_RU_TASK里各流程節(jié)點(diǎn)的任務(wù)數(shù)量、停留時(shí)長超過閾值的就推送告警。這個(gè)告警此前救過一次緊急事故某個(gè)系統(tǒng)調(diào)用回調(diào)接口一直失敗任務(wù)在“已辦結(jié)但回調(diào)失敗”的狀態(tài)下堆積了幾百條正是停留時(shí)長告警幫我們第一時(shí)間發(fā)現(xiàn)的。歷史數(shù)據(jù)歸檔策略也得盡早訂。我們按月份分區(qū)管理ACT_HI_ACTINST和ACT_HI_TASKINST這兩張大表每個(gè)月定時(shí)把三個(gè)月前的明細(xì)數(shù)據(jù)遷移到歷史庫。同時(shí)借助Flowable自帶的歷史數(shù)據(jù)自動(dòng)清理機(jī)制把不需要保留的流程定義級(jí)數(shù)據(jù)、已有歸檔副本的流程實(shí)例數(shù)據(jù)做異步清理。這塊做好了數(shù)據(jù)庫規(guī)模才能穩(wěn)定住不會(huì)跑著跑著突然因?yàn)榇疟P和慢查詢出事。5. 關(guān)鍵設(shè)計(jì)細(xì)節(jié)與踩坑實(shí)錄平臺(tái)建設(shè)過程中有大量看似不起眼、但影響巨大的細(xì)節(jié)。這一節(jié)我把印象最深的幾個(gè)單獨(dú)拿出來講都是實(shí)際踩過的坑希望能幫大家繞開。5.1 流程定義ID還是KEY一定要分清Flowable里有兩個(gè)標(biāo)識(shí)容易搞混流程定義Key和流程定義ID。Key是BPMN文件里process元素的id屬性比如leaveProcess部署之后Flowable會(huì)生成一個(gè)帶版本號(hào)的流程定義ID形如leaveProcess:1:25031004。很多調(diào)用場(chǎng)景要傳流程定義ID比如按版本發(fā)布、按版本查詢模型如果混用輕則查不到數(shù)據(jù)重則把流程部署到了錯(cuò)誤版本。我們的統(tǒng)一策略是平臺(tái)內(nèi)部所有操作都以“流程Key 版本號(hào)”作為邏輯標(biāo)識(shí)部署ID只在需要調(diào)用Flowable原生API時(shí)臨時(shí)獲取不落庫、不傳遞。這樣業(yè)務(wù)系統(tǒng)只跟平臺(tái)的Key體系打交道版本歧義在平臺(tái)層就消化掉了。5.2 業(yè)務(wù)單號(hào)與流程實(shí)例綁定必須用獨(dú)立關(guān)聯(lián)表很多教程里推薦用Flowable的businessKey來關(guān)聯(lián)業(yè)務(wù)單號(hào)我們?cè)谠缙谝策@么干過后來發(fā)現(xiàn)不行。原因是businessKey只能在發(fā)起時(shí)設(shè)置一次后續(xù)如果業(yè)務(wù)單號(hào)因?yàn)槟撤N原因需要改變或者一個(gè)流程實(shí)例要關(guān)聯(lián)多個(gè)業(yè)務(wù)單據(jù)businessKey就不夠用了。我們最終采用了獨(dú)立關(guān)聯(lián)表方案。PROC_BIZ_REL表記錄了流程實(shí)例ID、流程Key、業(yè)務(wù)主單據(jù)ID、業(yè)務(wù)擴(kuò)展單據(jù)ID列表、創(chuàng)建時(shí)間。查詢流程狀態(tài)時(shí)先根據(jù)業(yè)務(wù)單號(hào)反查流程實(shí)例ID再查流程狀態(tài)反過來的需求也同理。這張表是我們整個(gè)平臺(tái)數(shù)據(jù)模型里承擔(dān)壓力最大的一張表一定要做好索引和分表規(guī)劃。5.3 歷史表膨脹不是等到慢了才處理Flowable的歷史數(shù)據(jù)寫入非常積極尤其ACT_HI_ACTINST幾乎每個(gè)活動(dòng)進(jìn)出都記一條。高并發(fā)場(chǎng)景下這張表的增長速度超出很多人預(yù)期。我們?cè)?jīng)在生產(chǎn)上出現(xiàn)過ACT_HI_ACTINST達(dá)幾千萬行的情況導(dǎo)致所有帶歷史表查詢的接口響應(yīng)時(shí)間從幾十毫秒變成幾秒。兩條處置經(jīng)驗(yàn)分享一是從平臺(tái)上線第一天就把歸檔任務(wù)寫好不要等出了問題再補(bǔ)二是歷史數(shù)據(jù)查詢接口不要總是直查Flowable歷史表可以定期把需要長期保留的流程快照數(shù)據(jù)冗余到自己的歷史寬表里查詢走寬表Flowable歷史表只作為原始數(shù)據(jù)留存。這樣既保留了數(shù)據(jù)完整性又保證了查詢性能。5.4 上傳BPMN文件的校驗(yàn)不能省我們對(duì)外開放模型上傳功能后業(yè)務(wù)方經(jīng)常從各種建模工具里導(dǎo)BPMN文件上來。有些文件的命名空間不規(guī)范有些引用了一些Flowable不支持的擴(kuò)展屬性甚至還有的XML在其他工具里能打開、Flowable解析就報(bào)錯(cuò)。平臺(tái)做的校驗(yàn)包括三層一是XML格式的解析校驗(yàn)確保文件能被正常解析成文檔對(duì)象二是BPMN語義校驗(yàn)檢查是否存在孤立節(jié)點(diǎn)、未閉合網(wǎng)關(guān)等基礎(chǔ)問題三是Flowable部署前的集成校驗(yàn)直接調(diào)用引擎的部署接口試部署一下部署成功才允許發(fā)布。雖然這個(gè)校驗(yàn)會(huì)多花幾秒鐘但省掉了大量上線后才發(fā)現(xiàn)模型錯(cuò)誤的尷尬。5.5 任務(wù)查詢的索引與緩存設(shè)計(jì)Flowable的ACT_RU_TASK在生產(chǎn)環(huán)境數(shù)據(jù)量不小待辦查詢?nèi)绻蛔咚饕頀呙璺浅Ｖ旅?。我們觀察下來以下三個(gè)查詢場(chǎng)景必須建好索引按任務(wù)辦理人查詢、按流程實(shí)例ID查詢、按任務(wù)Key和流程定義Key組合查詢。Flowable的ACT_RU_TASK表默認(rèn)有一些索引但不同數(shù)據(jù)庫版本上的索引覆蓋并不完全一致所以建好表之后最好由DBA結(jié)合真實(shí)慢查詢?nèi)罩景阉饕a(bǔ)一輪。另外流程定義本身是只讀資產(chǎn)非常適合做JVM級(jí)緩存。我們把流程Key對(duì)應(yīng)的最新部署ID、模型元數(shù)據(jù)都要緩存在平臺(tái)進(jìn)程內(nèi)熱流程發(fā)起時(shí)不再反復(fù)查詢數(shù)據(jù)庫。這個(gè)緩存命中率高、失效時(shí)機(jī)清晰只在流程部署新版本時(shí)刷新效果非常好。6. 常見問題排查速查表平臺(tái)在線上跑了這段時(shí)間有幾類問題反復(fù)出現(xiàn)。我整理了一個(gè)排查速查表按“現(xiàn)象、可能原因、排查思路、預(yù)防建議”的格式列出來方便團(tuán)隊(duì)各位直接參照?，F(xiàn)象可能原因排查思路預(yù)防建議發(fā)起流程后待辦里看不到任務(wù)任務(wù)創(chuàng)建后又被代碼主動(dòng)刪掉或者任務(wù)分配給了候選組而當(dāng)前用戶不是候選成員查ACT_RU_TASK確認(rèn)該流程實(shí)例是否有任務(wù)查平臺(tái)事件流里任務(wù)創(chuàng)建事件是否正常發(fā)出任務(wù)分配統(tǒng)一走平臺(tái)策略不裸調(diào)Flowable流程實(shí)例執(zhí)行到某節(jié)點(diǎn)后不再往下走網(wǎng)關(guān)條件表達(dá)式?jīng)]有分支命中或JavaServiceTask執(zhí)行拋異常被吞掉查ACT_RU_EXECUTION當(dāng)前停留的節(jié)點(diǎn)看平臺(tái)異常日志是否有引擎執(zhí)行錯(cuò)誤網(wǎng)關(guān)條件要寫兜底分支ServiceTask異常要拋出來并告警會(huì)簽任務(wù)只產(chǎn)生了一個(gè)人的任務(wù)多實(shí)例的collection表達(dá)式寫錯(cuò)或者輸入變量沒傳對(duì)查流程發(fā)起時(shí)variables集合是否正確檢查節(jié)點(diǎn)多實(shí)例配置多實(shí)例輸入集合統(tǒng)一由平臺(tái)注入不靠業(yè)務(wù)系統(tǒng)傳菜名定時(shí)器事件不觸發(fā)引擎時(shí)鐘沒有開啟或執(zhí)行節(jié)點(diǎn)上的服務(wù)實(shí)例沒有運(yùn)行查Flowable時(shí)鐘配置查看定時(shí)節(jié)點(diǎn)所在服務(wù)是否存活定時(shí)任務(wù)單獨(dú)跑在獨(dú)立服務(wù)并配置進(jìn)程守護(hù)流程審批完結(jié)但業(yè)務(wù)系統(tǒng)沒有收到回調(diào)監(jiān)聽器拋異常被忽略或回調(diào)接口網(wǎng)絡(luò)超時(shí)查平臺(tái)事件表和回調(diào)重試記錄確認(rèn)回調(diào)地址可達(dá)回調(diào)必須配置重試機(jī)制和失敗告警歷史數(shù)據(jù)查詢特別慢ACT_HI_ACTINST表過大索引缺失看慢SQL是否都命中歷史表確認(rèn)歸檔任務(wù)是否正常運(yùn)行從上線第一天就啟動(dòng)歸檔查詢走自定義歷史寬表同一個(gè)單據(jù)被重復(fù)發(fā)起了流程前端重復(fù)點(diǎn)擊或MQ重復(fù)投遞查PROC_BIZ_REL是否同一businessId對(duì)應(yīng)多個(gè)流程實(shí)例發(fā)起接口做冪等校驗(yàn)businessIdprocKey建唯一索引新發(fā)布流程模型后老流程實(shí)例跑掛老實(shí)例走到已刪除的節(jié)點(diǎn)或引用了不存在的bean查老流程實(shí)例當(dāng)前停在哪一步和分析新老模型差異發(fā)布新模型前做兼容性檢查不允許刪除仍有在途實(shí)例的節(jié)點(diǎn)這個(gè)表基本覆蓋了我們?nèi)粘＿\(yùn)維中需要處理的80%問題。排查時(shí)記得先看現(xiàn)象發(fā)生在運(yùn)行期還是流程定義期能少走很多彎路。7. 結(jié)合實(shí)際運(yùn)維再說幾點(diǎn)真心話寫到最后我想分享一些個(gè)人在推進(jìn)這件事時(shí)形成的體會(huì)。第一做統(tǒng)一流程平臺(tái)最難的往往不是技術(shù)而是推動(dòng)業(yè)務(wù)系統(tǒng)按規(guī)范接入。我們給業(yè)務(wù)方定的規(guī)矩是“平臺(tái)提供能力但禁止繞過平臺(tái)動(dòng)引擎”。聽起來像是對(duì)業(yè)務(wù)方的限制實(shí)際上反而幫他們省了很多事——不用自己維護(hù)流程代碼、不用自己處理流程歷史和權(quán)限只需對(duì)接平臺(tái)的標(biāo)準(zhǔn)API。但前期的溝通量確實(shí)很大建議從簡(jiǎn)單增量的流程開始試點(diǎn)做出示范案例之后再推全量。第二流程平臺(tái)的價(jià)值要在“運(yùn)行三個(gè)月后”才能真正體現(xiàn)。初期業(yè)務(wù)系統(tǒng)會(huì)感覺平臺(tái)多了一層聯(lián)調(diào)多了一些成本看不到明顯收益。真正跑起來之后統(tǒng)一待辦、統(tǒng)一監(jiān)控、權(quán)限集中、模型管理這些能力才逐步顯現(xiàn)出價(jià)值。所以如果你們也在推進(jìn)類似的事情給自己和團(tuán)隊(duì)多一點(diǎn)耐心關(guān)鍵節(jié)點(diǎn)放在上線后第一次大促或月度結(jié)算峰值時(shí)那時(shí)候平臺(tái)的承壓能力一目了然。第三擴(kuò)展性要給后面留好口子。我們平臺(tái)建設(shè)時(shí)最擔(dān)心的是“Flowable有一天不能滿足需求怎么辦”。為此我們?cè)谝孢m配層做了模塊化封裝核心接口都定義在平臺(tái)自己的服務(wù)里底層是Flowable還是其他引擎只影響適配層實(shí)現(xiàn)不影響上層業(yè)務(wù)。目前還沒發(fā)生引擎替換但這個(gè)設(shè)計(jì)給了團(tuán)隊(duì)很大的安全感。第四平臺(tái)化之后那些“清理歷史數(shù)據(jù)”“監(jiān)控積壓任務(wù)”“巡檢流程執(zhí)行異?！敝惖氖虑榫筒辉偈悄硞€(gè)業(yè)務(wù)系統(tǒng)自己的事了而是平臺(tái)團(tuán)隊(duì)的日常職責(zé)。這其實(shí)是一件好事當(dāng)你從“把流程跑通”上升到“管理流程資產(chǎn)”時(shí)才能發(fā)現(xiàn)哪些流程長期沒人用、哪些流程頻繁超時(shí)、哪些流程的模型寫得亂七八糟。流程本身也變成了需要治理的數(shù)字資產(chǎn)。這套方案做到現(xiàn)在平臺(tái)已經(jīng)穩(wěn)定支撐了公司內(nèi)部多個(gè)業(yè)務(wù)域的上百個(gè)流程每天承載數(shù)萬次任務(wù)操作統(tǒng)一待辦入口成為了大家日常工作必不可少的部分。如果你也正在從單點(diǎn)使用Flowable走向流程平臺(tái)化的路上希望這篇總結(jié)能幫你對(duì)整體規(guī)劃和細(xì)節(jié)設(shè)計(jì)有一個(gè)清晰的參考。別想著一步到位先圈定邊界、統(tǒng)一入口、做好模型和權(quán)限的治理再從運(yùn)行中逐步補(bǔ)齊監(jiān)控、歸檔和擴(kuò)展能力這條路走下來是踏實(shí)的。