一、業務背景
通常在業務體系中，都會或多或少的涉及到支付相關的功能；對於一些經驗欠缺同學來說，最緊張的就是面對這類支付結算的邏輯，因為流程中的任何細節問題，都可能引發對賬異常的情況；
錯誤發生之後，再想去修復流程，花費的時間成本又是高昂的，還牽扯錯誤數據的調平問題，最終很可能引發亂賬算不清的結果，然後需要人工介入手動處理；
在支付場景中，不但涉及諸多的復雜業務，結算規則，超長的流程，第三方對接，其中更是涉及到諸多技術細節，比如：事務管理、異步處理、重試機制、加鎖等；下面來分析具體的細節邏輯。
二、支付業務
1、流程拆解
面對復雜業務的時候，最基本的能力就是要懂得把流程拆成模組，做好各個模組管理，再考慮如何銜接起整個流程，從而形成解決問題的思路和經驗；
如圖是對交易場景常見的分解，大致可以分為四個模組：
賬面管理：對於開通支付功能的使用者，必須清晰的管理資金資訊；比如可用，凍結，賬單等；
交易流水：整個資金管理的流水記錄，不局限於交易場景，還有充值，提現，退款等；
支付對接：通常流程中的支付功能都是對接第三方支付平台來實作的，所以要做好請求和報文的記錄；
訂單結構：比如在電商交易中，訂單模型的管理，拆單策略等，支付的商品規格等；
這裏只是從一個常規的交易流程中去分析，實際的細節描述會遠比圖例復雜，雖然業務細節各不相同，但是處理思路是大體相通的；再根據各個模組設計流程時序圖，規劃好節點之間的銜接和協作；
2、流程時序
透過時序圖的設計，來分析各個節點在銜接協作時應該如何處理，在支付業務中，通常分為支付前、支付對接、支付後三個核心階段：
支付前：在商品下單時，構建訂單模型，根據拆單規則校驗庫存、商品狀態等，然後進行帳戶資金凍結，生成交易流水，此時的狀態都是待支付；
支付對接：支付前業務模型初始化成功之後，構建第三方支付對接請求，發起付款流程，並記錄相應的請求動作和參數，等待支付結果的通知；
支付後：根據支付結果的成功與否，執行相應的業務模型狀態更新，如果支付成功則交易記錄、凍結的資金、訂單結構與庫存等都需要做一系列更新；
實際上對業務有清晰的理解和拆分之後，再做好時序流程的設計，這樣就已經讓一個復雜的場景看起來簡單許多了，之後就是設計各個節點的數據結構；
3、結構設計
基於上面的業務場景分析和拆解，以及流程時序圖的呈現，可以很容易輸出一份基礎維度的結構設計，下圖可以作為參考：
賬面管理：三個核心維度，帳戶金額，可用余額，凍結金額；
交易記錄：儲存使用者的交易動作，但是可能會產生多個交易明細，典型的場景就是購物車下單；
交易明細：通常因為訂單拆分，從而導致交易被拆分多條明細，進而將資金支付給不同商家；
支付對接：請求第三方支付平台時，需要記錄請求時參數，以及第三方回呼通知的報文；
訂單記錄：在一筆訂單中可能存在多個拆分的子單，拆分策略也很多，比如倉庫，商家，品類等；
訂單明細：管理每筆子訂單的資訊，下單的商品、規格、買賣雙方、單價、數量、金額等；
即使單看上面的簡單設計，都能感覺到支付業務的復雜性，更何況還會疊加紅包或滿減等優惠規則之後，其復雜程度可想而知；
當然如果有明確的開發規範，在復雜版本中，所有開發必須輸出業務的分解拆分思路，時序和結構設計，在統一評審之後再落地編碼，這樣即便是復雜的業務也會有極大的品質保證。
三、關聯業務
上面單從支付的主邏輯去分析流程，實際上涉及到的業務遠不止流程中提到的這些，以常見的電商場景為例，交易中還存在商品管理、庫存管理、物流管理，支付對接還會涉及優惠規則嵌入等等；
商品管理
商品主體：維護商品各個維度的資訊，並提供各種規格選項，以及基礎的定價階梯，構建商品詳情描述；
倉儲管理：訂單拆單之後，需要根據商品編號去校驗倉儲資訊，進行相應的庫存凍結以及支付後的倉庫發貨；
優惠券規則
優惠券主體：為了適配更多的業務場景，需要對優惠規則有諸多的設計，比如滿減或折扣比例、按價格階梯優惠、有效期限制等；
發放規則：支撐日常的營運活動，使用者生命周期的維護，以及渠道流量的轉化，提供使用者群行銷的基礎能力；
這裏簡述的商品和優惠券業務，都是與支付流程有緊密的聯系，比如拆單後庫存不足，需要移除該商品；優惠券在支付中的使用策略，以及退款時的處理方式等；
四、實踐總結
最後從技術實作的角度，總結一下支付流程中的一些關鍵問題：
業務模型：對業務有清晰的理解，並能拆分出核心的節點，設計出相應的流程時序和數據結構；
事務管理：交易流程中常用TCC事務機制，即Try(預處理)、Confirm(確認)、Cancel(取消)模式；
加鎖與重試：支付完成後發出支付成功的訊息，而後進行業務更新，通常需要對處理的訂單號加鎖，避免訊息重試機制引發數據問題；
資金結算：涉及金額的計算，自然要求不能出現精度損失的問題，在一次交易中必須保證每筆資金可以透過對賬核驗；
流程維護：流程本身是很難保證不出現錯誤的，需要在開發的時候，提供流程的視覺化界面，並且支持手動維護的機制；
很多復雜的業務場景管理，都需要一個長期的叠代過程，但是前提需要牢牢把握住核心的邏輯；對業務的認知是一個由繁入簡的過程，而業務的實作是一個由淺到深的過程，即分析與理解，到落地實作，再到探索與創新。
如喜歡本文，請點選右上角，把文章分享到朋友圈
如有想了解學習的技術點，請留言給若飛安排分享
因公眾號更改推播規則，請點「在看」並加「星標」 第一時間獲取精彩技術分享
·END·
相關閱讀：
作者：cicada_smile
來源：https://blog.csdn.net/cicada_smile/article/details/125586542
版權聲明：本文為博主原創文章，遵循 CC 4.0 BY-SA 版權協定，轉載請附上原文出處連結和本聲明。
架構師
我們都是架構師！
關註 架構師(JiaGouX)，添加「星標」
獲取每天技術幹貨，一起成為牛逼架構師
技術群請 加若飛： 1321113940 進架構師群
投稿、合作、版權等信箱： [email protected]
