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