干了這么多年我為什么還在強(qiáng)調(diào)先把流程想清楚再做系統(tǒng)處理流程設(shè)計(jì)與系統(tǒng)設(shè)計(jì)這兩個(gè)詞程序員天天掛在嘴邊但真正能說(shuō)明白的沒(méi)幾個(gè)。尤其是流程設(shè)計(jì)很多人覺(jué)得畫(huà)個(gè)流程圖、箭頭連一連、節(jié)點(diǎn)擺一擺就算完事。實(shí)際工作里流程設(shè)計(jì)決定的是系統(tǒng)的骨架系統(tǒng)設(shè)計(jì)決定的是血肉。骨架錯(cuò)了后面填充多少功能模塊都是白搭。這篇文章我不會(huì)講教科書(shū)式的理論也不會(huì)空談方法論。我拿一個(gè)真實(shí)的訂單處理場(chǎng)景來(lái)做完整的拆解演示把流程設(shè)計(jì)、狀態(tài)機(jī)落地、異常處理、監(jiān)控埋點(diǎn)這幾個(gè)環(huán)節(jié)全部走一遍。適合正在做后端系統(tǒng)、微服務(wù)架構(gòu)或者需要從零搭一套業(yè)務(wù)系統(tǒng)的開(kāi)發(fā)者參考。也適合產(chǎn)品經(jīng)理和技術(shù)負(fù)責(zé)人看因?yàn)楹芏鄾_突的根源恰恰是流程沒(méi)定義清楚就進(jìn)入編碼了。1. 先把處理流程和系統(tǒng)設(shè)計(jì)的邊界劃清楚1.1 處理流程到底在解決什么問(wèn)題處理流程解決的是業(yè)務(wù)層面的問(wèn)題一件事從一個(gè)狀態(tài)到下一個(gè)狀態(tài)經(jīng)過(guò)哪些環(huán)節(jié)每個(gè)環(huán)節(jié)做什么決策異常情況下往哪走。它不關(guān)心代碼怎么寫(xiě)不關(guān)心你用MySQL還是Redis不關(guān)心接口是同步還是異步。它只回答一個(gè)問(wèn)題數(shù)據(jù)在系統(tǒng)中是怎么流動(dòng)的。舉個(gè)最簡(jiǎn)單的例子電商下單用戶(hù)提交訂單系統(tǒng)校驗(yàn)庫(kù)存鎖定庫(kù)存生成支付單用戶(hù)支付回調(diào)通知異步發(fā)貨這就是一條主線流程。但真實(shí)場(chǎng)景沒(méi)這么簡(jiǎn)單。庫(kù)存不足怎么辦、超時(shí)未支付怎么辦、支付回調(diào)失敗怎么辦、發(fā)貨失敗怎么辦這些分支都屬于流程設(shè)計(jì)的范疇。系統(tǒng)設(shè)計(jì)解決的是技術(shù)層面的問(wèn)題流程確定之后每個(gè)環(huán)節(jié)用什么組件實(shí)現(xiàn)、數(shù)據(jù)怎么存儲(chǔ)、接口怎么定義、并發(fā)怎么控制、異常怎么兜底。系統(tǒng)設(shè)計(jì)必須服從流程設(shè)計(jì)而不是反過(guò)來(lái)。如果流程沒(méi)定清楚就上來(lái)設(shè)計(jì)表結(jié)構(gòu)大概率會(huì)返工。很多項(xiàng)目組犯的典型錯(cuò)誤是產(chǎn)品畫(huà)了兩頁(yè)流程圖開(kāi)發(fā)就直接開(kāi)搞。結(jié)果流程里支付成功后的狀態(tài)扭轉(zhuǎn)和退款后的狀態(tài)扭轉(zhuǎn)語(yǔ)義重疊后面排錯(cuò)排到懷疑人生。根本原因不是開(kāi)發(fā)能力不行是流程設(shè)計(jì)階段壓根沒(méi)把狀態(tài)定義清楚。1.2 為什么系統(tǒng)設(shè)計(jì)經(jīng)常被流程設(shè)計(jì)拖后腿我接觸過(guò)很多項(xiàng)目系統(tǒng)架構(gòu)看著挺合理服務(wù)拆分也干凈但聯(lián)調(diào)的時(shí)候就暴露出各種別扭。仔細(xì)一拆八成是流程設(shè)計(jì)階段埋的雷。一個(gè)典型場(chǎng)景運(yùn)營(yíng)后臺(tái)要支持訂單改價(jià)。產(chǎn)品定義的流程是訂單詳情頁(yè)-點(diǎn)擊改價(jià)-輸入新價(jià)格-確認(rèn)提交。開(kāi)發(fā)拿到需求后開(kāi)始設(shè)計(jì)訂單表加個(gè)改價(jià)記錄字段接口加個(gè)updatePrice方法完事。但是改了價(jià)之后支付單金額變了沒(méi)如果支付通道已經(jīng)生成了支付二維碼二維碼里的金額是按照原價(jià)生成的用戶(hù)掃了碼會(huì)提示金額不一致這個(gè)流程分支誰(shuí)來(lái)處理此時(shí)開(kāi)發(fā)才發(fā)現(xiàn)流程圖上訂單改價(jià)這個(gè)節(jié)點(diǎn)根本沒(méi)有向下游延伸。為了補(bǔ)救只能在代碼里if-else一堆判斷屬于典型的流程沒(méi)想明白就動(dòng)手。系統(tǒng)設(shè)計(jì)本身是有章法的——分層、模塊化、抽象接口、控制反轉(zhuǎn)這些技術(shù)手段都有成熟套路。但流程設(shè)計(jì)沒(méi)有標(biāo)準(zhǔn)答案每個(gè)業(yè)務(wù)都不一樣依賴(lài)的是思考的完整性。這兩個(gè)東西放到一起做真正難的不是技術(shù)實(shí)現(xiàn)而是怎么把流程中的每個(gè)分支、每個(gè)異常情況都識(shí)別出來(lái)再落到系統(tǒng)設(shè)計(jì)里。1.3 流程設(shè)計(jì)的基本步驟我不說(shuō)廢話直接列第一步明確主流程。從觸發(fā)點(diǎn)開(kāi)始到終態(tài)結(jié)束先把主干畫(huà)出來(lái)。不要管異常不要管擴(kuò)展純粹一條主線。第二步識(shí)別分支。每個(gè)節(jié)點(diǎn)問(wèn)三個(gè)問(wèn)題成功之后去哪、失敗之后去哪、超時(shí)之后去哪。第三步定義狀態(tài)。給流程中的每個(gè)關(guān)鍵環(huán)節(jié)定義狀態(tài)名注意區(qū)分業(yè)務(wù)狀態(tài)和流程狀態(tài)。第四步確定流轉(zhuǎn)條件。什么情況下允許從A狀態(tài)到B狀態(tài)什么情況下禁止流轉(zhuǎn)要有明確規(guī)則。第五步補(bǔ)異常兜底。異常分支、補(bǔ)償邏輯、人工介入點(diǎn)必須在流程圖上體現(xiàn)出來(lái)。這五步走完流程設(shè)計(jì)才算初步完成。這時(shí)候再進(jìn)入系統(tǒng)設(shè)計(jì)你會(huì)發(fā)現(xiàn)自己設(shè)計(jì)表結(jié)構(gòu)、定義接口、劃分模塊的時(shí)候思路清晰得多。2. 一個(gè)案例拆到底訂單履約流程的完整設(shè)計(jì)思路2.1 案例背景與需求分析為了演示方便我虛構(gòu)一個(gè)項(xiàng)目某跨平臺(tái)訂單系統(tǒng)的訂單履約模塊。背景是用戶(hù)在平臺(tái)下單之后訂單要經(jīng)歷支付、審核、揀貨、出庫(kù)、配送、簽收等環(huán)節(jié)其中還穿插著退款、改地址、攔截等操作。這個(gè)項(xiàng)目最開(kāi)始的版本只做了最簡(jiǎn)單的正向流程——下單、支付、發(fā)貨、完成。加上退款之后就亂套了用戶(hù)在配送中申請(qǐng)退款倉(cāng)庫(kù)已經(jīng)出庫(kù)了退款該不該退貨要不要追回后續(xù)狀態(tài)怎么流轉(zhuǎn)順著這個(gè)案例我把處理流程設(shè)計(jì)的每一步都走一遍重點(diǎn)展示怎么預(yù)判和拆解復(fù)雜分支。在設(shè)計(jì)之前我先把業(yè)務(wù)規(guī)則問(wèn)清楚用戶(hù)申請(qǐng)退款在什么節(jié)點(diǎn)之前可以直接退款在什么節(jié)點(diǎn)之后必須攔截物流訂單已出庫(kù)但未簽收用戶(hù)申請(qǐng)退款是走攔截還是等簽收后再退攔截成功和攔截失敗退款流程分別怎么走訂單改地址和退款同時(shí)發(fā)生先處理哪個(gè)這些問(wèn)題全部都問(wèn)到業(yè)務(wù)方確認(rèn)清楚之后再來(lái)畫(huà)流程。2.2 一級(jí)流程的拆解主鏈路與支鏈路主鏈路是這樣的用戶(hù)下單支付系統(tǒng)審核風(fēng)控校驗(yàn)推送倉(cāng)庫(kù)揀貨出庫(kù)配送簽收完成支鏈路至少有這幾條支付超時(shí)自動(dòng)取消用戶(hù)在待發(fā)貨時(shí)申請(qǐng)退款用戶(hù)在已發(fā)貨時(shí)申請(qǐng)退款物流配送異常拒收、超時(shí)、丟失訂單攔截這些支鏈路不能獨(dú)立設(shè)計(jì)因?yàn)橹ф溌泛椭麈溌饭蚕硗粋€(gè)訂單狀態(tài)它們之間會(huì)發(fā)生狀態(tài)競(jìng)爭(zhēng)。這里我強(qiáng)烈建議先定義狀態(tài)清單再畫(huà)流程圖。很多人習(xí)慣上來(lái)就畫(huà)箭頭畫(huà)到一半就發(fā)現(xiàn)圖太亂。實(shí)際正確做法是先把所有可能的狀態(tài)窮舉出來(lái)再定狀態(tài)間的遷移規(guī)則。2.3 節(jié)點(diǎn)級(jí)細(xì)化每個(gè)環(huán)節(jié)的輸入、處理、輸出流程不能只畫(huà)到模塊級(jí)別關(guān)鍵節(jié)點(diǎn)必須細(xì)化到輸入-處理-輸出這個(gè)粒度。拿支付回調(diào)節(jié)點(diǎn)舉例輸入支付通道的回調(diào)通知包含訂單號(hào)、支付金額、支付時(shí)間、渠道流水號(hào)處理校驗(yàn)簽名、校驗(yàn)訂單狀態(tài)、校驗(yàn)金額一致性輸出支付成功狀態(tài)、支付單流水記錄、觸發(fā)后續(xù)流程事件細(xì)化到這個(gè)程度系統(tǒng)設(shè)計(jì)才能跟上。因?yàn)槟忝鞔_知道了這個(gè)節(jié)點(diǎn)要接什么外部系統(tǒng)、要做什么校驗(yàn)、要產(chǎn)出什么結(jié)果后面定義接口和數(shù)據(jù)結(jié)構(gòu)的時(shí)候完全是按圖索驥。在真實(shí)項(xiàng)目中這個(gè)環(huán)節(jié)最花時(shí)間但最值得花。我把整個(gè)訂單履約流程按節(jié)點(diǎn)拆完之后發(fā)現(xiàn)原本以為要建20個(gè)接口的模塊其實(shí)有12個(gè)是多余的通過(guò)狀態(tài)機(jī)內(nèi)部流轉(zhuǎn)就能解決。這就是流程細(xì)化的直接收益。3. 從流程到系統(tǒng)狀態(tài)機(jī)設(shè)計(jì)與核心邏輯實(shí)現(xiàn)3.1 狀態(tài)清單定義方法與注意事項(xiàng)狀態(tài)清單在流程設(shè)計(jì)中是重中之重。我通常把狀態(tài)分為三級(jí)來(lái)管理一級(jí)狀態(tài)訂單的粗略生命周期待支付、已支付、履約中、已完成、已關(guān)閉。 二級(jí)狀態(tài)一級(jí)狀態(tài)下的細(xì)分比如履約中可以細(xì)分為待發(fā)貨、已發(fā)貨、配送中。 三級(jí)狀態(tài)具體動(dòng)作位比如已發(fā)貨可以細(xì)分為待攬收、運(yùn)輸中、待派送。為什么要分三級(jí)因?yàn)椴煌巧P(guān)注的狀態(tài)粒度不一樣。用戶(hù)在App上看到的是已發(fā)貨客服看到的是運(yùn)輸中運(yùn)營(yíng)看到的是待攬收。如果只建一個(gè)狀態(tài)字段就得不停給不同角色做狀態(tài)翻譯費(fèi)勁且容易出錯(cuò)。狀態(tài)命名我建議用英文字母加數(shù)字的組合做系統(tǒng)內(nèi)部編碼顯示層再做映射。用中文狀態(tài)名直接存數(shù)據(jù)庫(kù)編碼風(fēng)格會(huì)亂而且后面加狀態(tài)需要改一堆代碼。注意狀態(tài)字段和業(yè)務(wù)流程字段必須分開(kāi)。比如已發(fā)貨是一個(gè)狀態(tài)物流單號(hào)是一個(gè)業(yè)務(wù)字段不能把物流單號(hào)的有無(wú)作為判斷狀態(tài)的條件。狀態(tài)機(jī)只依據(jù)狀態(tài)字段流轉(zhuǎn)業(yè)務(wù)字段只做信息補(bǔ)充。這個(gè)原則能避免很多隱性耦合。最后是狀態(tài)流轉(zhuǎn)表。我整理了一個(gè)表格把核心狀態(tài)遷移規(guī)則全部列出來(lái)。這個(gè)表在評(píng)審會(huì)議上比任何流程圖都好用一目了然能看到有沒(méi)有漏掉轉(zhuǎn)移。當(dāng)前狀態(tài)觸發(fā)動(dòng)作目標(biāo)狀態(tài)前置條件后續(xù)動(dòng)作待支付用戶(hù)支付成功已支付金額校驗(yàn)一致創(chuàng)建履約單已支付系統(tǒng)風(fēng)控審核通過(guò)待發(fā)貨風(fēng)控標(biāo)記通過(guò)通知倉(cāng)庫(kù)待發(fā)貨用戶(hù)申請(qǐng)退款退款中無(wú)出庫(kù)記錄自動(dòng)退款流程待發(fā)貨倉(cāng)庫(kù)確認(rèn)揀貨揀貨中庫(kù)存鎖定成功通知物流已發(fā)貨用戶(hù)申請(qǐng)退款退款攔截中存在物流單號(hào)發(fā)起物流攔截退款攔截中攔截成功退款中物流商確認(rèn)可攔截創(chuàng)建退貨單退款攔截中攔截失敗待簽收物流商確認(rèn)無(wú)法攔截提示用戶(hù)等簽收后退有了這張表系統(tǒng)設(shè)計(jì)里的狀態(tài)機(jī)代碼基本就能照抄了。3.2 狀態(tài)機(jī)的控制邏輯與代碼落地狀態(tài)機(jī)的代碼落地方式有很多種簡(jiǎn)單的用if-else嵌套講究點(diǎn)的用狀態(tài)模式再講究點(diǎn)用現(xiàn)成的狀態(tài)機(jī)框架。我個(gè)人的經(jīng)驗(yàn)是業(yè)務(wù)流量不大、狀態(tài)數(shù)量在十來(lái)個(gè)以?xún)?nèi)老老實(shí)實(shí)用表驅(qū)動(dòng)的方式就夠了不要為了設(shè)計(jì)模式而設(shè)計(jì)模式。表驅(qū)動(dòng)的本質(zhì)就是把狀態(tài)遷移規(guī)則配置化。偽代碼大致是這樣的# 遷移規(guī)則配置 TRANSITIONS { (待支付, 用戶(hù)支付成功): 已支付, (已支付, 風(fēng)控審核通過(guò)): 待發(fā)貨, (待發(fā)貨, 用戶(hù)申請(qǐng)退款): 退款中, (待發(fā)貨, 倉(cāng)庫(kù)確認(rèn)揀貨): 揀貨中, (已發(fā)貨, 用戶(hù)申請(qǐng)退款): 退款攔截中, (退款攔截中, 攔截成功): 退款中, (退款攔截中, 攔截失敗): 待簽收, } def trans(current_state, action): key (current_state, action) if key not in TRANSITIONS: raise IllegalStateTransition(current_state, action) return TRANSITIONS[key]代碼不復(fù)雜但關(guān)鍵在于遷移動(dòng)作和狀態(tài)更新必須在同一個(gè)事務(wù)里完成。比如已支付到待發(fā)貨這個(gè)遷移除了修改狀態(tài)字段可能還要插入一條風(fēng)控審核記錄、觸發(fā)一個(gè)MQ消息通知倉(cāng)庫(kù)。如果先改狀態(tài)再發(fā)消息消息發(fā)送失敗狀態(tài)就漂移了如果先發(fā)消息再改狀態(tài)下游消費(fèi)者看到的狀態(tài)可能還是舊的。我實(shí)際項(xiàng)目中踩過(guò)這個(gè)坑當(dāng)時(shí)的解法是把狀態(tài)變更和業(yè)務(wù)動(dòng)作放進(jìn)同一個(gè)本地事務(wù)表通過(guò)事務(wù)消息保證最終一致。代碼結(jié)構(gòu)上狀態(tài)機(jī)只是控制中樞真正的業(yè)務(wù)邏輯在監(jiān)聽(tīng)器側(cè)實(shí)現(xiàn)。3.3 并發(fā)場(chǎng)景下的狀態(tài)流轉(zhuǎn)安全流程設(shè)計(jì)階段不考慮到并發(fā)系統(tǒng)設(shè)計(jì)階段就會(huì)很難補(bǔ)。訂單系統(tǒng)里最典型的并發(fā)問(wèn)題用戶(hù)點(diǎn)擊退款的同時(shí)倉(cāng)庫(kù)完成了出庫(kù)。兩個(gè)操作同時(shí)進(jìn)行狀態(tài)到底是變成退款中還是已發(fā)貨解決辦法是在狀態(tài)機(jī)執(zhí)行層加鎖。實(shí)現(xiàn)方式有三種第一種數(shù)據(jù)庫(kù)行鎖。在訂單表上執(zhí)行SELECT ... FOR UPDATE拿到鎖之后再判斷當(dāng)前狀態(tài)是否允許流轉(zhuǎn)。簡(jiǎn)單粗暴流量不大的時(shí)候完全夠用。 第二種分布式鎖。用Redis實(shí)現(xiàn)鎖定訂單ID作為key。適合訂單服務(wù)拆分成多個(gè)實(shí)例的架構(gòu)。 第三種CAS更新。更新時(shí)帶上當(dāng)前狀態(tài)作為條件UPDATE order SET status 新?tīng)顟B(tài) WHERE id ? AND status 舊狀態(tài)受影響行數(shù)為0說(shuō)明有并發(fā)沖突。我傾向推薦第三種加第一種的組合。CAS輕量且無(wú)鎖競(jìng)爭(zhēng)開(kāi)銷(xiāo)但受限于只能比較一個(gè)舊狀態(tài)如果狀態(tài)機(jī)遷移條件復(fù)雜比如只有已支付且審核通過(guò)才能流轉(zhuǎn)到待發(fā)貨CAS就沒(méi)法直接表達(dá)這時(shí)候行鎖更可靠。不管選哪種有一個(gè)共識(shí)必須堅(jiān)持狀態(tài)流轉(zhuǎn)必須是有條件的不是無(wú)腦賦值。所有入口的狀態(tài)校驗(yàn)都要做服務(wù)內(nèi)部之間調(diào)用也一樣不要信任上游已經(jīng)校驗(yàn)過(guò)。3.4 異步流程與重試機(jī)制的取舍流程設(shè)計(jì)還有一個(gè)常見(jiàn)問(wèn)題哪些環(huán)節(jié)同步執(zhí)行、哪些異步執(zhí)行原則很簡(jiǎn)單用戶(hù)在請(qǐng)求鏈路上必須等待的結(jié)果同步不在關(guān)鍵路徑上的動(dòng)作異步。比如支付回調(diào)之后必須同步更新訂單狀態(tài)并返回成功給支付渠道否則渠道會(huì)持續(xù)重試。而通知倉(cāng)庫(kù)這個(gè)動(dòng)作就不該在回調(diào)線程里同步做因?yàn)閭}(cāng)庫(kù)系統(tǒng)的響應(yīng)時(shí)間不可控如果在回調(diào)線程里同步調(diào)用回調(diào)響應(yīng)超時(shí)會(huì)引發(fā)連鎖問(wèn)題。異步化的實(shí)現(xiàn)方式業(yè)界通常使用消息隊(duì)列。在這個(gè)案例中訂單狀態(tài)更新后發(fā)送一個(gè)已支付事件倉(cāng)庫(kù)服務(wù)監(jiān)聽(tīng)事件后開(kāi)始揀貨。這里有一個(gè)細(xì)節(jié)消息發(fā)送必須是先更新?tīng)顟B(tài)事務(wù)提交成功后再發(fā)消息。如果事務(wù)沒(méi)提交就發(fā)了消息下游立馬查到舊狀態(tài)就產(chǎn)生了消息亂序問(wèn)題。我常用的方案是把消息發(fā)送放進(jìn)TransactionSynchronization的回調(diào)中事務(wù)提交成功后統(tǒng)一發(fā)送。如果發(fā)送失敗本地記錄一條事件發(fā)送日志有定時(shí)任務(wù)兜底補(bǔ)償。4. 異常處理、監(jiān)控埋點(diǎn)與人工介入設(shè)計(jì)4.1 流程設(shè)計(jì)里最容易漏掉的異常分支我問(wèn)過(guò)不少開(kāi)發(fā)者你們的流程圖畫(huà)了異常分支嗎多數(shù)人會(huì)說(shuō)畫(huà)了但仔細(xì)看就會(huì)發(fā)現(xiàn)異常分支只是畫(huà)了個(gè)失敗箭頭指向一個(gè)處理失敗的節(jié)點(diǎn)就完了。這是完全不合格的。異常分支必須要能回答四個(gè)問(wèn)題失敗后能不能重試重試有次數(shù)上限嗎重試失敗之后人工怎么介入人工介入的操作入口落在哪個(gè)系統(tǒng)我們用配送超時(shí)這個(gè)場(chǎng)景舉例。物流接口返回配送超時(shí)這是一個(gè)異常。簡(jiǎn)單的處理是把這個(gè)訂單標(biāo)記為配送異常然后人工介入。但合理的處理應(yīng)該多一步先判斷訂單類(lèi)型如果是普通訂單進(jìn)入自動(dòng)重試流程重新分配配送資源如果是加急訂單直接轉(zhuǎn)人工處理。這一步為什么不簡(jiǎn)單因?yàn)楫惓Ｌ幚肀旧硪惨吡鞒趟皇且粋€(gè)孤立動(dòng)作。如果是退款申請(qǐng)中支付渠道退款失敗可能需要自動(dòng)重試 告警 人工介入三層組合每層都有自己的狀態(tài)流轉(zhuǎn)規(guī)則。4.2 超時(shí)、補(bǔ)償與狀態(tài)回滾的實(shí)操設(shè)計(jì)超時(shí)在流程設(shè)計(jì)中的定義要具體到數(shù)值和動(dòng)作。拿待支付超時(shí)取消舉例訂單創(chuàng)建時(shí)間超過(guò)30分鐘未支付系統(tǒng)掃描任務(wù)發(fā)現(xiàn)后主動(dòng)取消訂單取消動(dòng)作執(zhí)行前再校驗(yàn)一次支付狀態(tài)這里有一個(gè)細(xì)節(jié)很多人忽略站在某個(gè)時(shí)間點(diǎn)掃描超時(shí)訂單和訂單實(shí)際超時(shí)之間有時(shí)間差。假設(shè)掃描任務(wù)是每10分鐘執(zhí)行一次某訂單在第31分鐘被掃描到實(shí)際它的狀態(tài)是已超時(shí)1分鐘。沒(méi)問(wèn)題。但如果用戶(hù)在第29分鐘完成了支付第30分鐘掃描任務(wù)執(zhí)行它理所當(dāng)然不應(yīng)該取消這個(gè)訂單。所以掃描任務(wù)必須再校驗(yàn)一次當(dāng)前狀態(tài)仍是待支付而不是只看是否超過(guò)30分鐘。補(bǔ)償邏輯方面訂單取消后如果發(fā)現(xiàn)庫(kù)存已經(jīng)預(yù)占需要釋放庫(kù)存。如果發(fā)現(xiàn)優(yōu)惠券已鎖定需要回滾優(yōu)惠券。這些補(bǔ)償操作不是主流程的一部分但缺了就會(huì)出嚴(yán)重資損問(wèn)題。我在項(xiàng)目里專(zhuān)門(mén)建了一張compensation_task表記錄所有需要補(bǔ)償?shù)娜蝿?wù)以及補(bǔ)償執(zhí)行狀態(tài)由獨(dú)立的任務(wù)調(diào)度器驅(qū)動(dòng)確保主流程和補(bǔ)償流程解耦。4.3 監(jiān)控指標(biāo)與告警閾值怎么定流程設(shè)計(jì)收尾階段必須把監(jiān)控指標(biāo)定義出來(lái)。很多項(xiàng)目運(yùn)行半年之后才補(bǔ)監(jiān)控屬于亡羊補(bǔ)牢。每個(gè)狀態(tài)節(jié)點(diǎn)至少要有三件事的監(jiān)控第一件流轉(zhuǎn)量。每個(gè)狀態(tài)入口流入的訂單量、出口流出的訂單量要能畫(huà)出流量趨勢(shì)圖。哪天突然某狀態(tài)入口流量下跌說(shuō)明上游出了問(wèn)題。 第二件滯留量。某個(gè)狀態(tài)的訂單數(shù)量在時(shí)間維度上的堆積情況。待發(fā)貨狀態(tài)堆積超過(guò)2小時(shí)可能倉(cāng)庫(kù)同步出了問(wèn)題。 第三件失敗量。每個(gè)流轉(zhuǎn)動(dòng)作的失敗次數(shù)以及失敗原因分布。告警閾值不要拍腦袋定。先找一段歷史數(shù)據(jù)看基線基線基礎(chǔ)上再定告警閾值。比如正常情況流轉(zhuǎn)失敗率在0.1%以下那告警閾值可以定在0.5%連續(xù)觸發(fā)5分鐘就報(bào)警。閾值太低容易頻繁誤報(bào)導(dǎo)致告警疲勞閾值太高會(huì)漏掉真正的故障。5. 踩坑實(shí)錄那些流程設(shè)計(jì)不完善引發(fā)的生產(chǎn)事故5.1 案例一狀態(tài)機(jī)缺少冪等導(dǎo)致重復(fù)退款某個(gè)項(xiàng)目上線了退款功能第一天就出問(wèn)題用戶(hù)發(fā)起一次退款申請(qǐng)結(jié)果微信支付側(cè)打了兩筆退款。查日志一看原因是支付回調(diào)接口被渠道重試了三次每次重試都走了發(fā)起退款的邏輯沒(méi)有做冪等校驗(yàn)。排查結(jié)果很清晰流程設(shè)計(jì)階段支付回調(diào)節(jié)點(diǎn)只畫(huà)了驗(yàn)簽、改狀態(tài)、發(fā)事件沒(méi)有畫(huà)重復(fù)回調(diào)這個(gè)分支。系統(tǒng)設(shè)計(jì)階段也沒(méi)有在退款入口處設(shè)計(jì)冪等表。教訓(xùn)凡是涉及資金的流程節(jié)點(diǎn)必須默認(rèn)它是會(huì)被重試的。外部系統(tǒng)回調(diào)、內(nèi)部消息重發(fā)、定時(shí)任務(wù)掃描任何一個(gè)環(huán)節(jié)觸發(fā)兩次都不該產(chǎn)生副作用。冪等設(shè)計(jì)不是狀態(tài)機(jī)的一部分但必須在狀態(tài)機(jī)旁邊同步考慮。5.2 案例二分支條件過(guò)于粗略導(dǎo)致訂單卡死另一個(gè)項(xiàng)目退款攔截中狀態(tài)下物流商回調(diào)結(jié)果是攔截失敗。開(kāi)發(fā)人員設(shè)計(jì)的時(shí)候只處理了攔截成功和攔截失敗兩個(gè)分支但真實(shí)物流商的回調(diào)既不是成功也不是失敗而是處理中。這個(gè)處理中狀態(tài)沒(méi)有對(duì)應(yīng)分支訂單就卡在退款攔截中一直不動(dòng)。后來(lái)排查定位到是分支遺漏補(bǔ)了一個(gè)處理中轉(zhuǎn)超時(shí)監(jiān)控的邏輯。但補(bǔ)這個(gè)邏輯的過(guò)程很痛苦因?yàn)樯婕皵?shù)據(jù)庫(kù)字段變更和存量數(shù)據(jù)的回填。這個(gè)案例告訴我們的道理是外部系統(tǒng)的返回值不要想當(dāng)然認(rèn)為只有成功和失敗兩種。第三方系統(tǒng)往往有受理中已下發(fā)待確認(rèn)等各種中間態(tài)流程設(shè)計(jì)階段必須要能完整識(shí)別這些狀態(tài)。5.3 案例三狀態(tài)定義不統(tǒng)一導(dǎo)致跨系統(tǒng)數(shù)據(jù)對(duì)不上訂單系統(tǒng)和財(cái)務(wù)系統(tǒng)對(duì)賬出現(xiàn)大量差異。原因是訂單系統(tǒng)的已完成和財(cái)務(wù)系統(tǒng)的已完成定義不同。訂單系統(tǒng)的已完成指的是用戶(hù)簽收財(cái)務(wù)系統(tǒng)的已完成指的是資金清算完畢。兩個(gè)系統(tǒng)之間的狀態(tài)映射關(guān)系沒(méi)有在流程設(shè)計(jì)階段對(duì)齊對(duì)賬全是差異。后來(lái)專(zhuān)門(mén)梳理了兩個(gè)系統(tǒng)的狀態(tài)映射表定義了維度統(tǒng)一的對(duì)賬口徑差異才慢慢清零。這個(gè)坑的教訓(xùn)是流程設(shè)計(jì)不只是在單個(gè)系統(tǒng)內(nèi)部設(shè)計(jì)跨系統(tǒng)協(xié)作時(shí)狀態(tài)口徑必須先拉齊。哪里是上游系統(tǒng)的終態(tài)、哪里是下游系統(tǒng)的起始態(tài)邊界必須清楚。6. 實(shí)操檢查清單開(kāi)始編碼前我必過(guò)一遍的20條這些檢查項(xiàng)都是實(shí)際項(xiàng)目總結(jié)出來(lái)的分享出來(lái)供參考主流程是否覆蓋了從觸發(fā)到終態(tài)的全路徑每個(gè)節(jié)點(diǎn)的成功-失敗-超時(shí)三個(gè)出口是否完整定義狀態(tài)之間是否存在跳轉(zhuǎn)遺漏是否存在多個(gè)動(dòng)作競(jìng)爭(zhēng)同一狀態(tài)的并發(fā)場(chǎng)景是否定好了處理策略所有外部系統(tǒng)調(diào)用是否都考慮了冪等所有異步流程是否都有補(bǔ)償機(jī)制超時(shí)時(shí)間是否設(shè)定具體數(shù)值并確認(rèn)業(yè)務(wù)可接受每個(gè)入口是否做了前置狀態(tài)校驗(yàn)狀態(tài)變更和數(shù)據(jù)寫(xiě)入是否在同一事務(wù)中消息發(fā)送是否在事務(wù)提交之后是否有存量數(shù)據(jù)的狀態(tài)遷移方案跨系統(tǒng)的狀態(tài)映射是否明確人工介入節(jié)點(diǎn)有哪些操作入口是否已定義每個(gè)異常分支是否定義可重試次數(shù)和重試間隔是否保留狀態(tài)變更歷史表便于排查和回溯各節(jié)點(diǎn)是否有對(duì)應(yīng)的監(jiān)控看板告警閾值是否基于歷史基線設(shè)定狀態(tài)機(jī)執(zhí)行失敗時(shí)是否記錄上下文信息日常運(yùn)維操作是否也需要走狀態(tài)機(jī)不允許繞過(guò)規(guī)則改庫(kù)新老流程的灰度切換方案是否提前設(shè)計(jì)這20條全過(guò)完了流程設(shè)計(jì)才算真正落地。沒(méi)有過(guò)完就動(dòng)手寫(xiě)代碼后面大概率要回頭補(bǔ)課。7. 流程設(shè)計(jì)工具與文檔沉淀的個(gè)人經(jīng)驗(yàn)流程設(shè)計(jì)用什么工具不核心但值得說(shuō)一句。Visio、draw.io、ProcessOn都可以用關(guān)鍵是看團(tuán)隊(duì)協(xié)作效率。我習(xí)慣用draw.io免費(fèi)的支持在線協(xié)作存到倉(cāng)庫(kù)里還能做版本管理。但比工具更重要的是文檔規(guī)范化。我每個(gè)項(xiàng)目的流程設(shè)計(jì)文檔固定包含五張圖業(yè)務(wù)流程圖、狀態(tài)流轉(zhuǎn)圖、時(shí)序圖、異常分支圖、系統(tǒng)部署交互圖。外加一張狀態(tài)遷移表、一張冪等方案表、一張監(jiān)控指標(biāo)表。這個(gè)結(jié)構(gòu)用熟了之后新同事上手也快。文檔不要一次性寫(xiě)完流程設(shè)計(jì)文檔應(yīng)該是活文檔。每次流程調(diào)整先更新文檔再改代碼。如果代碼改了文檔沒(méi)改這個(gè)文檔很快就廢掉了。我可以分享一個(gè)實(shí)際心得畫(huà)流程圖的動(dòng)作本身并不產(chǎn)生價(jià)值真正產(chǎn)生價(jià)值的是你在畫(huà)的過(guò)程里被迫把每個(gè)分支都想清楚。所以哪怕你手繪在白板上只要問(wèn)題想透了也一樣有效。我曾經(jīng)帶著團(tuán)隊(duì)不開(kāi)電腦直接在白板上推演流程用了一下午把一套訂單系統(tǒng)的所有狀態(tài)和分支全部過(guò)了一遍后面編碼順暢到不可思議。畫(huà)得丑沒(méi)關(guān)系邏輯閉環(huán)才是重點(diǎn)。8. 關(guān)于流程復(fù)用與設(shè)計(jì)規(guī)范的延伸思考處理流程設(shè)計(jì)積累到一定程度會(huì)沉淀出一批可復(fù)用的流程模式。比如訂單創(chuàng)建-支付-履約是一個(gè)模式審批流轉(zhuǎn)-執(zhí)行-結(jié)果回傳是另一個(gè)模式。如果公司內(nèi)部有多個(gè)業(yè)務(wù)線把這些通用流程抽象成公共模塊或配置化引擎能節(jié)省大量重復(fù)設(shè)計(jì)成本。但做抽象要克制。抽象程度越高學(xué)習(xí)成本越高。技術(shù)團(tuán)隊(duì)在早期階段我更建議先服務(wù)好具體業(yè)務(wù)把一兩個(gè)流程做扎實(shí)沉淀出項(xiàng)目自己的最佳實(shí)踐再考慮橫向擴(kuò)展。我所在的項(xiàng)目組后來(lái)做了一個(gè)輕量級(jí)的流程配置引擎把狀態(tài)機(jī)規(guī)則、節(jié)點(diǎn)處理邏輯、事件分發(fā)機(jī)制統(tǒng)一管理起來(lái)。新業(yè)務(wù)接入時(shí)只需要配置狀態(tài)和轉(zhuǎn)移規(guī)則再實(shí)現(xiàn)少量節(jié)點(diǎn)處理器整個(gè)流程就跑起來(lái)了。這是流程設(shè)計(jì)能力沉淀后的自然結(jié)果同時(shí)也印證了流程設(shè)計(jì)做到位之后系統(tǒng)設(shè)計(jì)可以變得非常輕。