一、業(yè)務(wù)背景

在業(yè)務(wù)系統(tǒng)中，支付功能的實(shí)現(xiàn)尤為關(guān)鍵且挑戰(zhàn)重重，尤其是對(duì)經(jīng)驗(yàn)不足的開發(fā)者而言。支付結(jié)算邏輯的細(xì)微差錯(cuò)可能導(dǎo)致對(duì)賬失誤，引發(fā)連鎖反應(yīng)：錯(cuò)誤排查耗時(shí)巨大，數(shù)據(jù)不平需調(diào)整，甚至可能演變成復(fù)雜的賬目混亂，最終不得不依賴人工逐一手動(dòng)修正。

支付場(chǎng)景復(fù)雜，涵蓋多維度業(yè)務(wù)、結(jié)算規(guī)則及長(zhǎng)流程，還需與第三方對(duì)接，技術(shù)上要求嚴(yán)格，涉及事務(wù)管理、異步處理、重試策略、并發(fā)控制等關(guān)鍵細(xì)節(jié)。接下來將深入探討這些技術(shù)要點(diǎn)。

圖片

二、支付業(yè)務(wù)

1、流程拆解

圖片

• 賬面管理：對(duì)于開通支付功能的用戶，必須清晰的管理資金信息；比如可用，凍結(jié)，賬單等；
• 交易流水：整個(gè)資金管理的流水記錄，不局限于交易場(chǎng)景，還有充值，提現(xiàn)，退款等；
• 支付對(duì)接：通常流程中的支付功能都是對(duì)接第三方支付平臺(tái)來實(shí)現(xiàn)的，所以要做好請(qǐng)求和報(bào)文的記錄；
• 訂單結(jié)構(gòu)：比如在電商交易中，訂單模型的管理，拆單策略等，支付的商品規(guī)格等；

常規(guī)交易流程雖可概覽，實(shí)際操作細(xì)節(jié)更為繁復(fù)，各業(yè)務(wù)特異但處理邏輯相似。設(shè)計(jì)時(shí)，細(xì)化各模塊流程圖，確保節(jié)點(diǎn)銜接流暢，協(xié)同工作高效。

2、流程時(shí)序

通過時(shí)序圖的設(shè)計(jì)，來分析各個(gè)節(jié)點(diǎn)在銜接協(xié)作時(shí)應(yīng)該如何處理，在支付業(yè)務(wù)中，通常分為支付前、支付對(duì)接、支付后三個(gè)核心階段：

• 支付前：在商品下單時(shí)，構(gòu)建訂單模型，根據(jù)拆單規(guī)則校驗(yàn)庫(kù)存、商品狀態(tài)等，然后進(jìn)行賬戶資金凍結(jié)，生成交易流水，此時(shí)的狀態(tài)都是待支付；
• 支付對(duì)接：支付前業(yè)務(wù)模型初始化成功之后，構(gòu)建第三方支付對(duì)接請(qǐng)求，發(fā)起付款流程，并記錄相應(yīng)的請(qǐng)求動(dòng)作和參數(shù)，等待支付結(jié)果的通知；
• 支付后：根據(jù)支付結(jié)果的成功與否，執(zhí)行相應(yīng)的業(yè)務(wù)模型狀態(tài)更新，如果支付成功則交易記錄、凍結(jié)的資金、訂單結(jié)構(gòu)與庫(kù)存等都需要做一系列更新；

理解并拆分業(yè)務(wù)后，精心設(shè)計(jì)時(shí)序流程，復(fù)雜場(chǎng)景將變得條理清晰。隨后，重點(diǎn)聚焦于定義各節(jié)點(diǎn)數(shù)據(jù)結(jié)構(gòu)，進(jìn)一步細(xì)化實(shí)現(xiàn)方案。

3、結(jié)構(gòu)設(shè)計(jì)

基于上面的業(yè)務(wù)場(chǎng)景分析和拆解，以及流程時(shí)序圖的呈現(xiàn)，可以很容易輸出一份基礎(chǔ)維度的結(jié)構(gòu)設(shè)計(jì)，下圖可以作為參考：

圖片

• 賬面管理：三個(gè)核心維度，賬戶金額，可用余額，凍結(jié)金額；
• 交易記錄：存儲(chǔ)用戶的交易動(dòng)作，但是可能會(huì)產(chǎn)生多個(gè)交易明細(xì)，典型的場(chǎng)景就是購(gòu)物車下單；
• 交易明細(xì)：通常因?yàn)橛唵尾鸱?，從而?dǎo)致交易被拆分多條明細(xì)，進(jìn)而將資金支付給不同商家；
• 支付對(duì)接：請(qǐng)求第三方支付平臺(tái)時(shí)，需要記錄請(qǐng)求時(shí)參數(shù)，以及第三方回調(diào)通知的報(bào)文；
• 訂單記錄：在一筆訂單中可能存在多個(gè)拆分的子單，拆分策略也很多，比如倉(cāng)庫(kù)，商家，品類等；
• 訂單明細(xì)：管理每筆子訂單的信息，下單的商品、規(guī)格、買賣雙方、單價(jià)、數(shù)量、金額等；

即使單看上面的簡(jiǎn)單設(shè)計(jì)，都能感覺到支付業(yè)務(wù)的復(fù)雜性，更何況還會(huì)疊加紅包或滿減等優(yōu)惠規(guī)則之后，其復(fù)雜程度可想而知；

當(dāng)然如果有明確的開發(fā)規(guī)范，在復(fù)雜版本中，所有開發(fā)必須輸出業(yè)務(wù)的分解拆分思路，時(shí)序和結(jié)構(gòu)設(shè)計(jì)，在統(tǒng)一評(píng)審之后再落地編碼，這樣即便是復(fù)雜的業(yè)務(wù)也會(huì)有極大的質(zhì)量保證。

三、關(guān)聯(lián)業(yè)務(wù)

上面單從支付的主邏輯去分析流程，實(shí)際上涉及到的業(yè)務(wù)遠(yuǎn)不止流程中提到的這些，以常見的電商場(chǎng)景為例，交易中還存在商品管理、庫(kù)存管理、物流管理，支付對(duì)接還會(huì)涉及優(yōu)惠規(guī)則嵌入等等；

商品管理

圖片

• 商品主體：維護(hù)商品各個(gè)維度的信息，并提供各種規(guī)格選項(xiàng)，以及基礎(chǔ)的定價(jià)階梯，構(gòu)建商品詳情描述；
• 倉(cāng)儲(chǔ)管理：訂單拆單之后，需要根據(jù)商品編號(hào)去校驗(yàn)倉(cāng)儲(chǔ)信息，進(jìn)行相應(yīng)的庫(kù)存凍結(jié)以及支付后的倉(cāng)庫(kù)發(fā)貨；

優(yōu)惠券規(guī)則

圖片

• 優(yōu)惠券主體：為了適配更多的業(yè)務(wù)場(chǎng)景，需要對(duì)優(yōu)惠規(guī)則有諸多的設(shè)計(jì)，比如滿減或折扣比例、按價(jià)格階梯優(yōu)惠、有效期限制等；
• 發(fā)放規(guī)則：支撐日常的運(yùn)營(yíng)活動(dòng)，用戶生命周期的維護(hù)，以及渠道流量的轉(zhuǎn)化，提供用戶群營(yíng)銷的基礎(chǔ)能力；

這里簡(jiǎn)述的商品和優(yōu)惠券業(yè)務(wù)，都是與支付流程有緊密的聯(lián)系，比如拆單后庫(kù)存不足，需要移除該商品；優(yōu)惠券在支付中的使用策略，以及退款時(shí)的處理方式等；

四、實(shí)踐總結(jié)

最后從技術(shù)實(shí)現(xiàn)的角度，總結(jié)一下支付流程中的一些關(guān)鍵問題：

• 業(yè)務(wù)模型：對(duì)業(yè)務(wù)有清晰的理解，并能拆分出核心的節(jié)點(diǎn)，設(shè)計(jì)出相應(yīng)的流程時(shí)序和數(shù)據(jù)結(jié)構(gòu)；
• 事務(wù)管理：交易流程中常用TCC事務(wù)機(jī)制，即Try(預(yù)處理)、Confirm(確認(rèn))、Cancel(取消)模式；
• 加鎖與重試：支付完成后發(fā)出支付成功的消息，而后進(jìn)行業(yè)務(wù)更新，通常需要對(duì)處理的訂單號(hào)加鎖，避免消息重試機(jī)制引發(fā)數(shù)據(jù)問題；
• 資金結(jié)算：涉及金額的計(jì)算，自然要求不能出現(xiàn)精度損失的問題，在一次交易中必須保證每筆資金可以通過對(duì)賬核驗(yàn)；
• 流程維護(hù)：流程本身是很難保證不出現(xiàn)錯(cuò)誤的，需要在開發(fā)的時(shí)候，提供流程的可視化界面，并且支持手動(dòng)維護(hù)的機(jī)制；

很多復(fù)雜的業(yè)務(wù)場(chǎng)景管理，都需要一個(gè)長(zhǎng)期的迭代過程，但是前提需要牢牢把握住核心的邏輯；對(duì)業(yè)務(wù)的認(rèn)知是一個(gè)由繁入簡(jiǎn)的過程，而業(yè)務(wù)的實(shí)現(xiàn)是一個(gè)由淺到深的過程，即分析與理解，到落地實(shí)現(xiàn)，再到探索與創(chuàng)新。