架構設計圖

整個支付鏈路上的功能

支付系統(tǒng)應該有：賬戶管理、渠道管理、支付管理、對賬管理、清算管理、結算管理? ? ? ??

一筆支付訂單，在支付系統(tǒng)側就是要記錄清楚，誰發(fā)起的、對哪個商品進行支付、通過哪個渠道支付、支付時間、支付結果等

消金系統(tǒng)分層架構

? ? ? ? 展示： SS ? ? ? ? ?IQP

? ? ? ? 流程：APS? ? ? ? TDL? ? ? ? TDC

? ? ? ? ? ? ? ? ? ?TC? ? ? ? ?CORE? ? ? FA? ? ? ? MM? ? ? ? RMS/IRISK/RMFP

? ? ? ? 核心：AMS? ? ? ? CIS? ? ? ?

? ? ? ? 基礎：SSP? ? ? ? OPR? ? ? ? ODX? ? ? ? PMS

全局域劃分架構

交互層

業(yè)務串聯(lián)層

核心能力層

公共服務層

數(shù)據存儲層

消金兩大場景：

• 提現(xiàn)
• 消費

需要清楚賬戶系統(tǒng)的額度的變更，也就是通過中間的過程系統(tǒng)TDL/TDC，消金側告知銀行你可以對該筆請求進行放款，此時，銀行才去真正的執(zhí)行給客戶打款

金錢流轉動作額度發(fā)起方，一定是銀行，這個都不用想，一切放款行為都是銀行觸發(fā)的，消金前置流程，是控制用戶有沒有用這筆錢的資格，后置的流程，是為了把銀行的錢，和消金的賬戶做一個綁定。前置流程就是TDL調AMS看額度夠不夠用，后置流程就是銀行本次給用戶打了多少錢，消金的賬戶額度對應的是要加還是減多少額度，核算系統(tǒng)要生成多少錢的賬單

從這個角度來看，AMS和風控系統(tǒng)都一樣，都只是前置流程中的一個校驗，AMS是檢驗額度夠不夠，風控系統(tǒng)是校驗該筆放款是否合規(guī)

信貸三步

• 貸前：主要是用戶授信、實名注冊的一個過程，這個過程順利通過后，用戶看到自己的授信額度，才到后面的動支行為
• 貸中：就是控制用戶當前能不能使用額度，也就是，提現(xiàn)/交易的整個過程
• 貸后：對賬、賬單、還款

業(yè)務流程

定價

授信

對賬

消費

二維碼展示

用戶打開消金app支付二維碼界面，前端系統(tǒng)發(fā)起生成二維碼的請求，請求給到TDC，TDC將二類戶卡號等用戶信息等給到銀行，銀行返回字符串二維碼，TDC側將字符串專為真正的二維碼從而給到前端展示

原來最開始沒進行域劃分之前，功能很混亂，所有當時和前端展示有點沾邊的功能，都丟在SS系統(tǒng)中的，比如支付二維碼的生成

掃碼支付

商戶掃碼槍掃描客戶的消金app二維碼支付頁面，從而發(fā)起對銀行的扣款請求，銀行將扣款請求給到消金的支付網關TC，TC給到TDC，TDC走風控、額度扣減那套邏輯，額度扣減成功后，返回TC，TC將SUCCESS告知銀行，此時，銀行才從消金在上海銀行的公戶中，扣款打給商家的銀行卡

商家掃描客戶的支付二維碼時，就會客戶信息、消費金額信息，商家信息一起給到銀行

疑問，上海銀行，怎么知道每個商戶的銀行卡號？因為，是商家拿著自己在支付寶注冊過的掃碼槍掃描的用戶從上海銀行生成的二維碼，商家肯定是提前在支付寶上注冊填寫過收款卡號的，或者說直接收到支付寶的余額中去

如果銀行接收到了消金側返回的SUCCESS，但是扣款失敗，或者接收消金側響應超時，就會實時發(fā)起沖正

提現(xiàn)

提現(xiàn)一定是銀行管控整個流程，額度扣減都是后置處理，都是銀行先把錢放出去后，銀行才通知消金側扣減額度的

用戶能不能提取到這筆錢、能提取到多少錢，這個是和TDL和消金有關系的，而真金白銀放款的流程其實和TDL關系不大，TDL只是一個結果的記錄，比如銀行把錢放出去了，放了多少錢，TDL調用AMS扣一下額度

提現(xiàn)流程，一定要分清楚放款到底是以文件形式，還是

文件形式，就是說別人放別人的，別人放成功后，再用文件通知你，你這邊是需要有額度調整的。此時，就說明管控方是在別人那邊

如果消金側主動調用銀行的打款接口，則管控方就是消金自己

自有業(yè)務

占用，是放款中的一個過程，是一個中間狀態(tài)，表示該筆額度被占住了，不能用于其他場景了，是AMS為了保證同一時間，這筆額度只能用在同一個地方，防止額度用超

銀行側實際放款成功或失敗，才通知AMS這邊動用額度還是恢復額度

占用

用戶輸入借款金額，發(fā)起請求到銀行，銀行調占用接口到TDL，TDL內調風控通過后，調AMS額度占用（額度中間態(tài)），占用成功后通知銀行允許該筆請求提現(xiàn)，從而銀行給用戶的提現(xiàn)卡號內打錢

動用

銀行調用消金的動用接口，TDL通知AMS扣額度，通知core記賬單，通知大數(shù)據等

說是占用動用兩個接口，實際上在數(shù)據庫中只對應了提現(xiàn)主表里狀態(tài)節(jié)點的9個狀態(tài)扭轉

助貸

接入了平安普惠、支付寶、度小滿、字節(jié)等

占用

比如客戶在度小滿發(fā)起借款請求，通過度小滿的流控，某一次流控走到了消金側，進入TDL開始風控、額度占用成功后，回調度小滿的放款結果通知接收接口，告知度小滿，我消金側認可你這筆請求，你可以開始后續(xù)給客戶打款的流程了。但是，度小滿的動用文件，第二天才到，為了到第二天這期間，不讓用戶額度用超，消金需要控制額度，所以，引入了額度占用的邏輯

如果是平安普惠的優(yōu)質資產助貸，則是TDL先調AMS占用，占用成功后TDL調用支付渠道網關TC，TC又調平安付開始給客戶打錢。TC打錢成功后，回調通知TDL放款成功，然后TDL調AMS動用

如果沒有占用，而是直接動用2w，那么客戶就會看到數(shù)據不一致的中間態(tài)，用戶查看額度少了2w，但是用戶銀行卡2w又還沒有到賬

美團要求10分鐘返回，度小滿要求2個小時返回，借唄要求2秒，所以借唄是單獨一套流程，沒有走MQ

如果是消金側來控制打錢，則消金側產出對賬文件，如果是外部側比如度小滿控制打錢，則度小滿來產出對賬文件，消金側來解析結賬文件對賬

外部調消金的uwg轉發(fā)網關，進行統(tǒng)一加解密、金額單位轉換結束后，調用支付渠道網關TC開始給客戶打錢

動用

• T+1日動用文件通知來扣額度之類的（常用，比較好追溯）
• T日調接口

注意動用文件，與銀行的對賬文件的區(qū)別

消金內部系統(tǒng)

公共服務

綜合查詢平臺 IQP

主要是運營人員使用的

共享支持平臺SSP

單證合成

電子簽名/印章

微服務網關openApi

助貸時，支付寶調用消金的系統(tǒng)時，首先就得通過微服務網關

業(yè)務網關 SS

統(tǒng)一外網的各種各樣的參數(shù)風格，轉換成消金內部統(tǒng)一的參數(shù)，比如消金內部統(tǒng)一的成功響應碼是0000，失敗是9999

這個系統(tǒng)慢慢的被分解，被微服務網關openApi和各個業(yè)務系統(tǒng)瓜分了

產品域

產品管理系統(tǒng)PMS

主要功能：產品配置、定價配置

每個用戶，針對每個產品都有一個唯一的userId，公司內部的不同產品，不同系統(tǒng)之間通用的就是userId

定價查詢接口，返回的是一個很大的json，由于在AMS側需要比較定價是否超話，而直接比較大json不太方便，所以每個大json都會帶一個摘要比如md5值，每次只用比較md5值就知道該定價信息是否變化過

營銷域

營銷管理系統(tǒng)?MM

曾經做過一個宜家消費滿800返80的活動，還有全家消費30返回10塊，不過都有名額限制，需要去搶名額

后來，這個搶名額的邏輯，被我放在了異步流程中了，異步流程中有調MM拿中獎名額，有發(fā)MQ給Core通知放款

電商平臺下的營銷系統(tǒng)

主要是發(fā)優(yōu)惠券，搞促銷活動

千萬級別的全量用戶發(fā)券，如果想爭取在一兩個小時內發(fā)完，就需要用分布式任務調度平臺xxl-job，配合rocketmq來實現(xiàn)分片執(zhí)行，削峰填谷

支付域

簡單理解，就是真正和外界交互，進行打錢的系統(tǒng)

交易渠道網關?TC

定位：報盤，回盤，輔助對賬

接一個渠道就是一個xxx-getway

渠道：建行，工行，平安普惠

和建行等直連成本低，其他的有手續(xù)費。就是從其他的快捷支付啥的有手續(xù)費成本高了，后來就直接和銀行直連了，省錢

就相當于搶了支付寶/微信的一部分生意，可以將建行、工行的銀行卡，綁定在平安消金的app上，然后通過平安消金的app來完成二維碼支付

類似于微信支付的余額界面

財務域

財務系統(tǒng) FA

大數(shù)據域

大數(shù)據系統(tǒng) ODX?

可以理解成為數(shù)據中臺，功能就是負責拉取TDC這邊的支付數(shù)據，然后大屏幕準實時的展示每小時的交易筆數(shù)交易額度的變化情情況

風控域

風控系統(tǒng) IRISK

二類戶交易流程上每筆交易流程都會調用IRISK，來決定是否放行該筆交易

irisk主要是看是不是常用登陸地之類的監(jiān)控

風控管理系統(tǒng) RMS

風控規(guī)則：

客戶評級評分：有客戶的評級信息，一開始是ABCDE五個評級，每個評級的用戶對應享受到的放款額度，放款利率都是不一樣的。后來重構過一次，重構成L1到L10，10個等級了

授信出額：

調額：根據后臺分析，如果準備給用戶提升額度，比如提升2w但是提升額度這2w只能用于消費，那么就去調用AMS的調額接口，AMS就把小橙花二級賬戶的授信額度加2w，并同時把三級消費資金賬戶的可用額度也加2w，但是三級提現(xiàn)資金賬戶的可用額度額度不變

用戶征信、是否逾期等的一些風控規(guī)則

風控系統(tǒng) RMFP

會員域

客戶信息系統(tǒng) CIS?

負責登陸、注冊、注銷、實名認證等的邏輯串聯(lián)

客戶號cust_no

實名服務：比如身份證信息、手機號信息，家庭住址等

卡服務：一個人可能會在消金App上綁定多張銀行卡

后面有綁建行的卡，直接使用消金app掃碼支付，不用通過支付寶微信就可以完成掃碼支付

存用戶身份信息，比如身份證、地址之類的。存消金內部自然人唯一編號?userId，供消金內部所有系統(tǒng)共用，方便問題追溯

存手機號，比如說后面辦什么促銷活動，就可以通過手機號給用戶發(fā)通知短信

從技術的角度而言，所有的核心業(yè)務未必就適合于放在一個系統(tǒng)中處理，如貸款的賬務處理和貸款的授信、審批以及貸后管理就不適合放在一個系統(tǒng)中，因為賬務處理力求穩(wěn)定和高效，而貸款的流程管理力求靈活多變，不同的功能需求更適合在不同的系統(tǒng)中處理。這也說明，核心業(yè)務系統(tǒng)未必就是一個系統(tǒng)，而可能是一個系統(tǒng)群。

銀行核心系統(tǒng)設計目標

以客戶為中心的設計

集中的客戶信息能夠對客戶層次的所有賬目和交易進行匯總。一些銀行目前使用的核心業(yè)務系統(tǒng)正從傳統(tǒng)的以賬戶為中心向以客戶為中心轉變，表現(xiàn)在客戶的基礎信息資料都必須在核心系統(tǒng)做維護(這里說的基礎信息資料指能為多個系統(tǒng)所公用的信息，如名稱、地址、身份證號碼、組織機構代碼等)，某些系統(tǒng)專用的信息可以在專業(yè)的業(yè)務系統(tǒng)存儲。

分散在各個外圍業(yè)務系統(tǒng)的客戶基礎信息資料均需以核心系統(tǒng)客戶資料為準，核心系統(tǒng)統(tǒng)一為客戶分配客戶號，各業(yè)務系統(tǒng)對客戶的引用均以核心系統(tǒng)客戶號為準。盡量避免一戶多號的情況，以客戶號為線索，可以查詢出該客戶在本行的存款、貸款、結算、理財產品購買等業(yè)務情況。

針對不同的客戶提供有針對性的服務

對不同的細分客戶群和層次，在服務檔次和服務定價上有所區(qū)別。好的核心系統(tǒng)應該能幫助用戶對客戶進行細分，根據客戶對本行的綜合貢獻度以及信用等級提供相應的服務，使銀行有能力把更多的資源投入能給本行帶來更多利潤的客戶上

客戶號cust_no全局唯一，user_id是一個產品一個，多個user_id對應同一個cust_no

進件域

進件系統(tǒng) APS

負責貸前鑒權，鑒別是否是本人，流程如下：生成流水、客戶信息，跳轉到第三方頁面，客戶輸入卡號、手機號等，鑒權完成返回信息給我們

負責授信、出額、開戶流程，這整個流程，是以APS作為主導來串流程，二類戶交易是AMS/TDC來串流程

授信業(yè)務分為：

• 公司授信業(yè)務：對公司法人
• 國際貿易授信業(yè)務：
• 個人授信業(yè)務：對個人自然人，房類、汽車類、經營類、消費類、教育類等

授信幾個階段：

調查、審查、審批、放款、貸后工作

把客戶的所有情況了解清楚后，了解了客戶的征信情況，評估好所有的風險，出一份調查報告

放款，是資金出銀行的最后一道關口

信貸審批和審批授權

信貸審批，是指銀行或金融機構對借款人提出的貸款申請進行審查、評估，并決定是否批準貸款的過程。這包括了對借款人的信用狀況、還款能力、貸款用途、擔保措施等多方面的綜合考量。

審批授權，是指銀行或金融機構在辦理信貸業(yè)務時，對各級管理人員和業(yè)務經辦人員授予一定范圍內的信貸業(yè)務審批權限。這種授權是基于職責分工和內部控制的需要，旨在明確各崗位的權限范圍、審批程序和相應責任。

授信審批大致可分為集中管理模式、分級管理模式和垂直管理模式三種模式。

用戶進來注冊授信時，請求通過前端打到SS，再打到APS，然后開始人臉之類的，最后是前面的很多校驗都通過后才到AMS來調開戶接口，調AMS來開戶時，如果是新用戶，那就是3層賬戶表一起開，授信開戶，一定是針對產品開戶的，不同的產品開不同的二級產品賬戶

賬戶域

賬戶管理系統(tǒng) AMS

賬戶系統(tǒng)的5大核心功能：額度，賬戶狀態(tài)，授信開戶，定價，發(fā)票

AMS三大業(yè)務閉環(huán)

• 賬戶開戶、銷戶
• 賬戶狀態(tài)凍結、解凍
• 賬戶額度扣減、恢復

域劃分前

AMS很龐大，AMS的業(yè)務是不清晰的，說白了就是不夠“瘦”，負責交易、賬單、還款，對賬，整個公司內部各系統(tǒng)職責邊界都劃分的不清不楚，造成了很多因邊界問題而起的矛盾

域劃分后

AMS作為賬戶域只作為核心能力層，不負責流程的串聯(lián)，不負責是否應該額度變更（包括額度扣減、額度恢復）的判斷邏輯，所有的額度變更的發(fā)起都由外部系統(tǒng)發(fā)生。比如支付就由TDC向AMS發(fā)起扣減額度請求，還款就由CORE向AMS發(fā)生賬戶還款請求

AMS賬戶額度管控模塊，只提供額度變更接口給別的系統(tǒng)調，至于是什么業(yè)務導致的額度變更，AMS就不去關心了。AMS賬戶狀態(tài)管控模塊也是一樣，因為什么原因導致的賬戶凍結解凍，AMS都不關心，一切都由外部觸發(fā)

消費定價更新

定時任務，定時從PMS刷新每個人的定價，因為如果PMS側定價更新以后，AMS側每個人的定價當月不能變化，需要等到下個月才能更新

重構交易的過程

重構前交易流程結構混亂，最關鍵的問題是，串交易流程的核心邏輯，不在一個類中，而是一個類串著下一個類，這樣代碼結構不直觀

三級賬戶表結構

一級賬戶表，主賬戶表，AMS側對應的主賬戶號是account_no，客戶信息系統(tǒng)那邊對應是cust_no

二級賬戶表，授信賬戶表，也叫產品賬戶表，記錄小橙花等不同的產品，AMS側對應的授信賬戶號是pro_credit_no字段，全公司內部通用的則是每個產品對應不同的user_id字段，

三級賬戶表，當前現(xiàn)狀是有兩張：消費額度管理表，提現(xiàn)額度管理表（有一個核心字段，已用額度，消費時是增加已用額度，還款時是降低已用額度）

實際情況，三級資金賬戶表不需要兩張表，只需要一張表，然后弄一個額度類型字段，提現(xiàn)和消費各對應一個額度類型就好

用一張三級資金賬戶表，提供一個amt_type額度類型字段，amt_type是CON消費資金賬戶、另一個amt_type是CASH提現(xiàn)、amt_type是ALL資金總賬戶額度（也就是，產品賬戶額度，這樣二級產品賬戶賬戶中就可以不放產品額度字段了）

三級賬戶表，AMS側每個三級賬戶對應唯一的資金賬戶號loan_acct_no，額度類型amt_type，總額度total_amt，已用額度used_amt，占用額度occupied_amt，賬戶樂觀鎖版本號data_version

二級賬戶表，可能有以下三種典型情況

小橙花，有10w的產品授信額度，其中消費和提現(xiàn)各5w，對應在三級資金賬戶表下，同一個小橙花產品下，有兩個資金賬戶：一個amt_type是CON消費，總額度是5w、另一個amt_type是CASH提現(xiàn)，總額度也是5w （理想情況就是，消費和提現(xiàn)各種獨立出額，互相不耦合）

度小滿，屬于助貸，有5w的產品授信額度，且只能用于提現(xiàn)5w，對應在三級資金賬戶表下，同一個度小滿產品下，就只有一個資金賬戶：amt_type是CASH提現(xiàn)，總額度也是5w

借唄，屬于助貸，有2w的產品授信額度，且只能用于提現(xiàn)2w，對應在三級資金賬戶表下，同一個借唄產品下，就只有一個資金賬戶：amt_type是CASH提現(xiàn)，總額度也是2w

還有一個單筆單批

健康的情況下就是，額度分開管理，也就是數(shù)據分開管理，單一職責，至于業(yè)務怎么用這些數(shù)據，業(yè)務需要用這些數(shù)據時，會加上哪些限制條件，這個是業(yè)務的事情，和數(shù)據存儲的本身，一定要區(qū)分開，不要揉在一起

理想的情況是，消費和提現(xiàn)各種獨立出額，各自都有5w額度，互相不耦合，使用消費時就只動三級表中消費賬戶哪條記錄，使用提現(xiàn)時，就只動三級表中提現(xiàn)賬戶的那條記錄，產品下不同的額度，分開管理，互不影響，這樣我們就只需要給三級表加一個賬戶樂觀鎖版本號data_version字段，來保證某一條三級賬戶表記錄自身的安全性，從而實現(xiàn)同一時刻，針對這同一天三級賬戶表記錄，只能有一筆額度變更流程。額度變更流程，就包括對同一賬戶因為重復請求等原因，而同時發(fā)起了兩次提現(xiàn)/消費，或者對某個三級賬戶進行提現(xiàn)/消費時，另外有一個流程在對這同一個三級賬戶記錄進行還款

而當前消金小橙花，比如如果有10w的產品授信額度，其中消費消費10w，提現(xiàn)5w，對應在三級資金賬戶表下，同一個小橙花產品下，有兩個資金賬戶：一個amt_type是CON消費，總額度是10w、另一個amt_type是CASH提現(xiàn)，總額度也是5w

此時，就已經把業(yè)務和數(shù)據揉在一起了，根據消金自己定的消費和提現(xiàn)占比1比0.5的業(yè)務需求，導致了上面的數(shù)據存儲方式，導致用戶消費6w后，還會影響到提現(xiàn)的額度只有4w了，但用戶一直沒有提現(xiàn)過，而當前還能最多提現(xiàn)卻從5w變成了4w，但是三級提現(xiàn)賬戶表中的授信額度還是5w？

這個時候，就需要額度引擎上場了，額度引擎是公司業(yè)務規(guī)則的一個包裝，

因為現(xiàn)在消金是把業(yè)務和數(shù)據揉在一起的，大量消費可能會影響提現(xiàn)額度，為了避免對小橙花的三級消費賬戶消費的同時，有另一個線程對該用戶的三級提現(xiàn)賬戶進行提現(xiàn)超出該用戶小橙花產品的授信總額度，所以，無論是小橙花提現(xiàn)還是小橙花消費時，都需要先拿一把以二級產品授信賬戶號為key的分布式鎖。這都是因為業(yè)務的原因，導致了需要這些復雜的邏輯，實際上就應該把提現(xiàn)和消費額度分開，兩者之間互不影響，只需要三級表各自的版本號樂觀鎖，來保證各自數(shù)據的安全即可

單筆單批

授信等于動支，

附加額度、臨時額度

所有臨時額度、附加額度、紅包額度，都用單獨的附加額度管理表來保存，區(qū)分不同的額度用途字段，附加額度管理表也有起止有效期字段

這張表，相當于另一張三級資金賬戶表，既然是三級資金賬戶表一定是要依附于某一個產品下的，比如我們當前的實現(xiàn)，是依附于小橙花產品下的

扣額度時，就要在where條件中，既判斷額度用途，又判斷額度有效期等條件都滿足時，才允許扣額度

每個用戶，針對每個產品都有一個唯一的userId，公司內部的不同產品，不同系統(tǒng)之間通用的就是userId。比如如果RMS根據一些風控規(guī)則，需要對某個客戶的小橙花產品額度進行調額，就需要拿著該用戶的小橙花userId來AMS修改該用戶對應的二級賬戶的授信額度（同時，還會去修改三級賬戶表的現(xiàn)金額度字段值嗎？）

按照業(yè)務情況，需要有額度變動的明細表的。我舉的例子搞分布式，也就明細表加個狀態(tài)字段而已

賬戶與額度的關系

賬戶討論狀態(tài)，額度討論有效期，這兩個概念一定要區(qū)分開

賬戶被凍結了，其實額度是沒有被凍結的，這是兩個概念。也可能是額度有效期過了，但是賬戶狀態(tài)是正常的。如果額度過期后，想讓賬戶凍結，也要靠定時任務去刷

正常開的小橙花二級產品賬戶對應的額度，也是有有效期的，如果過了有效期，則需要調用AMS的賬戶激活接口，來更新小橙花產品額度的有效期

賬戶狀態(tài)管控

身份證過期可能會導致賬戶凍結、風控系統(tǒng)檢測到用戶有高危行為也會來AMS調用賬戶凍結接口

賬戶狀態(tài)管控一定是需要的，因為消金，需要控制哪些用戶能用錢，哪些用戶不能用錢

賬戶模型三層表，每層都有一個賬戶狀態(tài)字段，從而精細化的控制每一層的賬戶狀態(tài)

賬戶額度管控

額度討論有效期，一般情況下，循環(huán)額度的有效期，都是控制產品額度的有效期，所以在二級產品表放有效期字段，一般不太會控制到三級資金額度的有效期的粒度，如果只過期提現(xiàn)資金賬戶額度，而不過期消費資金賬戶，那么就需要在三級資金賬戶中加入額度有效期字段。所以，我們要看情況，來看你的業(yè)務兼容到哪一層賬戶

額度變更，一定要有一張額度變更明細表，所有的額度變更，都要在這里留痕，做到快速可追溯，也就是這個入口一定要把控住

額度引擎

就是識別出當前正在使用哪個產品，并適配出當前正在使用該產品下的哪個資金賬戶，根據該資金賬戶的額度使用情況，來判斷當前用戶能不能在當前資金賬戶下使用額度，至于怎么實現(xiàn)的，就是三層賬戶結構

比如，當前用戶開了三個產品，三家機構的額度，是怎么做到互不影響的？

圍繞著三級賬戶來答，三個產品對應三個產品賬戶，每個產品賬戶下又有各自的分開管理的消費和提現(xiàn)資金賬戶，互相獨立，互不影響

如果想針對某個產品，加一個紅包功能，怎么加？

你們是怎么管理消費和提現(xiàn)，消費和提現(xiàn)過程中，如何保證額度不超限？

小橙花產品，對應有兩個三級資金賬戶，一個是消費資金賬戶，另一個是提現(xiàn)資金賬戶，兩個資金賬戶分開管理，然后兩個資金賬戶有一個總的產品額度上限

小橙花產品有5w額度，如果是消費能用3w，提現(xiàn)能用2w，對應消費資金賬戶額度3w，提現(xiàn)資金賬戶2w，兩個額度分開管理，互不影響

小橙花產品有5w額度，如果是消費能用5w，提現(xiàn)能用2w，對應消費資金賬戶額度5w，提現(xiàn)資金賬戶2w，兩個額度耦合在了一起，互相牽制。

針對兩個資金賬戶額度耦合在一起的情況，就需要加鎖，可以加分布式鎖同時鎖住兩個資金賬戶，也就是對提現(xiàn)和消費，統(tǒng)一加一把分布式鎖，保證同一個產品下，提現(xiàn)和消費只有一個在途。也可以使用兩個資金賬戶的版本號一起，整體組成一個樂觀鎖，從而保證小橙花額度使用不超過5w，如果不加鎖控制，最大就可能5w的消費也出去了，2w的提現(xiàn)也出去了，就導致整個小橙花產品一共出去了7w，但該用戶的小橙花產品額度卻只有5w

三級賬戶表目前的現(xiàn)狀

?關鍵是授信額度字段

這里關鍵就是三個賬戶號，加上三個額度字段：現(xiàn)金額度、已用現(xiàn)金額度、占用現(xiàn)金額度

交易域

信貸放款系統(tǒng) TDL

助貸

當時做過對接度小滿、平安普惠，也就是說平安消金作為借貸的資金方，度小滿和平安普惠是作為客戶觸達方

對接度小滿金融時，是度小滿將客戶在度小滿界面發(fā)起的借貸請求，流控到平安消金這端，平安消金這端經過一系列的檢驗，比如額度檢驗，風控檢驗等，檢驗通過后，調用AMS進行額度占用，占用成功后，帶上該筆放款單號回調度小滿的回調接口，通知度小滿該筆通過，然后度小滿自己調用真正的打款接口，給用戶預留的收款銀行卡打款。也就是這里，打款的控制者是度小滿

度小滿，給客戶打款成功后，就可以通過調TDL接口或者以文件的形式，通知TDL去AMS進行額度動用

對接平安普惠時，打款的控制者就是平安消金自身，而不是平安普惠。依然是客戶的觸達方，將客戶發(fā)起的放款請求給到平安消金，比如額度檢驗，風控檢驗等，檢驗通過后，有三個重要的步驟：步驟一，直接調用AMS進行額度動用、步驟二是帶上該筆放款單號回平安普惠的回調接口，告知該筆放款成功；步驟二是調用TC的接口，TC再調用平安付的渠道，進行給客戶真正的打款動作（步驟二和三調用失敗，TDL側會發(fā)起重試）

注：

說到這里，就要提一個生產問題，當時一個外包同事負責步驟三，結果調用平安付超時了沒有拿到響應（實際該筆平安付那邊已經執(zhí)行成功放款5w的動作了），然后外包同事就進行了重試，重試時，他竟然換了一個放款單號，沒有用原來的單號，結果就給客戶又打了5w的錢，造成了二次放款的嚴重生產問題

整個TDL就是一個大異步流程，異步里面又用MQ進行了二次異步，又因為一條MQ有消費超時時間，整個放款流程網絡請求過多，可能會讓單條MQ消費超時，所以采用的自己發(fā)送自己消費的模式，每發(fā)送接收一次MQ只處理一個放款流程七八個業(yè)務節(jié)點中的一個

放款主表trade_loan_mgr，有一個流程狀態(tài)扭轉與回退的狀態(tài)字段，每執(zhí)行成功一個節(jié)點，流程狀態(tài)就更新一步

外部支付調用異步化

在外部支付中，經常需要服務方與第三方支付交互，獲取預支付憑證，如上圖所示。

這種同步調用的情況下，由于需要跨外部網絡，響應的 RT 會非常長，可能會出現(xiàn)跨秒的情況。由于是同步調用，會阻塞整個支付鏈路。一旦 RT 很長且 QPS 比較大的情況下，服務會整體 hold 住，甚至會出現(xiàn)拒絕服務的情況

因此，可以拆分獲取憑證的操作，通過獨立網關渠道前置服務，將獲取的方式異步化，從前置網關獲取內部憑證，然后由前置網關去異步調用第三方

如上，

2：三方支付收單，可以采用異步回調的方式，讓三方支付系統(tǒng)返回一個受理憑證，三方支付系統(tǒng)完成真正的支付動作后，異步回調渠道網關的回調接口，當前TDL就是采用的這種回調的方式

實時交易系統(tǒng) TDC?

四大功能：交易、退款、沖正、對賬

主要有

• 二類戶交易
• 好醫(yī)生商城交易

二類戶交易內部又有兩個分支

• 普通二類戶交易〔非分期〕、
• 商戶分期交易

普通二類戶交易CON，走普通的定價邏輯。商戶分期，因為每家商戶給定的利率都不一樣，所以走商戶分期時，需要每次交易都實時去查PMS定價系統(tǒng)，商戶分期一般是3 6 12三期，三種選擇

支付路由

商戶分期POS，是針對和消金合作的商戶而言的。是有一個預申請的概念，客戶在勾選比如宜家的某個商品后，決定購買前如果決定使用商戶分期，客戶需要自己選擇是3 6 12期，三種選擇，選擇好分多少期后，就可以生成對應的二維碼，此時，就會在APS預先生成交易信息，合作商家掃描二維碼后，開始真正的交易邏輯，交易請求到達TDC

交易流程，每次需要先去APS查詢是否有預申請信息，如果有則走商戶分期流程，否則走普通非分商戶分期交易

普通交易流程，用戶展示付款碼或者用戶掃描商家機器展示的二維碼，注意，這個二維碼都是銀行生成的

交易信息落表、留痕

支付路由，確定是商戶分期交易還是普通交易，來決定怎么查定價，普通交易的定價查本地，商戶分期的因為每個商戶的定價不一樣，所以要傳商戶給PMS，來查詢當前交易的定價

查CIS，查詢是否為公司員工，從而采用固定定價

檢驗：賬戶狀態(tài)檢驗、冪等檢驗、交易是否存在檢驗、各種限額檢驗、irisk反欺詐檢驗、rms用途管控檢驗、黑白名單檢驗、額度檢驗

檢驗都通過后，調AMS扣額度

扣額度成功后，更改交易狀態(tài)

然后開始異步流程

調core核算系統(tǒng)計利息、調MM營銷系統(tǒng)撞滿800返80的活動、調大數(shù)據同步交易數(shù)據

支付流程圖

技術點

當時用過分布式鎖，用過冪等，用過延時消息，用過最終一致性，用過樂觀鎖版本號

延時消息

最開始的版本二類戶交易，上行的交易請求發(fā)來后，如果在600ms內沒有收到消金的響應，就會立馬發(fā)沖正過來

但是，AMS的交易流程走完至少要兩三秒，所以就把很多步驟放在異步流程里了，這其中就包括AMS扣減額度成功后，通知core開始進行針對該筆交易的記息（還有后續(xù)賬單的展示）

有一次上行的沖正請求過來后，core給返回了一個沒有該筆交易記錄，但是core團隊又在他們的數(shù)據庫中，發(fā)現(xiàn)了這筆交易

總結起來就是，上行的沖正請求達到core的時間，比交易異步流程中通知到core的時間要快

直觀的解決方案就是，讓沖正請求來得慢一點，然后我就在AMS里，把上行的沖正請求，一進來就丟進MQ了，延時1min，然后自己搞了個消費者消費它，才繼續(xù)走后面的沖正流程

交易流程全部同步的跑完可能需要兩三秒中，所以把一大堆操作，挪到異步流程中了，同步流程中就只有必要的數(shù)據獲取、風控校驗、每月/每日的限額校驗，額度扣減等核心步驟了

分布式鎖

每月/每日的消費額度限制

當時做過一個需求，限制客戶每日在某個門店的消費額度，限制客戶每個月的消費總額度

以主賬戶號 + 商戶號為key，當日消費金額為value

因為沒有使用lua腳本，通過賬戶號 + 商戶號為key查詢到當日消費金額value，判斷額度還沒有超過當日5000的限額，就以主賬戶號 + 商戶號為key，當日消費金額+ 當前該筆交易金額amt為新的value寫入redis，這兩個步驟無法保證原子性，所以就給這兩個步驟，一起加了個redis分布式鎖

版本號樂觀鎖

賬戶表加了一個版本號字段，TDC先查出賬戶額度 和當前的版本號m，然后做后續(xù)的校驗邏輯，這段邏輯可能耗費幾百毫秒，然后真正調用AMS扣減額度時，把版本號m傳遞給AMS，讓AMS自己去比對庫中目前的版本號是否與版本號m是否一致

核心交易邏輯

二類戶交易的流程

當時的交易流程，是接口一進來，立馬把所有的請求參數(shù)存一遍，交易主表trade_disburse_contract_mgr和交易事務表trade_transaction_detail

交易主表trade_manager，每比交易進來，都立馬先記錄一條記錄，交易主表有個狀態(tài)字段trade_status：初始化，支付成功，支付失敗

最開始，搞了個大字段，把整個交易請求報文一股腦全丟進去，用來追溯問題的，后來被DBA勸退下架了，后來提出申請幾臺MongoDB專門存這種大json的非結構化數(shù)據，很合適，不過又被部門長拍死了

交易事務表trade_transaction_detail，交易/退款/撤銷/沖正，等都要在這個表中添加一條記錄，這個表有個關鍵字段 transaction_type，用來表示是TRADE REFUND REVERSED REVOKED?

交易的錯誤碼

錯誤碼一定要明細，0000是成功，其余的都是失敗，但是失敗的原因各異，可能是額度不夠失敗，可能是風控校驗不通過失敗，可能是每日限額失敗，等等，不同的失敗都要有各自不同的碼值，這樣才能實現(xiàn)精細化管理，問題的定位也會更清晰

二類戶交易流程，黑白名單檢驗，是不是可以使用余弦向量比較法？

好醫(yī)生商城交易

背景：平安好醫(yī)生有自己的商城，在平安好醫(yī)生商城購物，可以使用平安消金的消費額度

實現(xiàn)：整個實現(xiàn)采用流行的異步化的實現(xiàn)

好醫(yī)生商城下訂單的信息，是給到了APS保存，所以APS維護了訂單的狀態(tài)信息。

下單成功后，好醫(yī)生商城側，發(fā)生支付請求，支付請求經TC轉入AMS/TDC。AMS/TDC接收到支付交易請求時，立馬先完整的保存一遍交易信息，并在交易主表中記錄支付狀態(tài)為初始化狀態(tài)

然后AMS/TDC用異步線程開啟內部的后續(xù)支付處理邏輯，同時同步流程直接給好醫(yī)生返回了

3秒后，消金自己的前端會發(fā)生輪訓，通過支付單號來AMS/TDC查詢該筆交易的支付情況

支付回調的邏輯，除了等第三方回調，還會提供主動查詢結果的功能，這種是經典的分布式最終一致性解決方案

整個支付操作流程是，客戶在好醫(yī)生商城側成功下訂單后，點擊開始支付，會首先彈出內嵌于好醫(yī)生商城app執(zhí)行的消金支付流程界面，客戶在消金前端頁面上發(fā)起真正的支付請求，此時的支付請求，才會打到AMS/TDC來。也就是說，此時的消金前端是能拿到好醫(yī)生商城傳過來的外部交易單號的

22年3月，交易遷移到TDC

23年2月，賬戶再次重構，重構邏輯未知

關于交易流程的最終一致性解決方案

蘑菇街交易創(chuàng)建過程中的分布式一致性方案

交易創(chuàng)建的一般性流程

我們把交易創(chuàng)建流程抽象出一系列可擴展的功能點，每個功能點都可以有多個實現(xiàn)（具體的實現(xiàn)之間有組合/互斥關系）。把各個功能點按照一定流程串起來，就完成了交易創(chuàng)建的過程。

面臨的問題

每個功能點的實現(xiàn)都可能會依賴外部服務。那么如何保證各個服務之間的數(shù)據是一致的呢？比如鎖定優(yōu)惠券服務調用超時了，不能確定到底有沒有鎖券成功，該如何處理？再比如鎖券成功了，但是扣減庫存失敗了，該如何處理？

方案選型

服務依賴過多，會帶來管理復雜性增加和穩(wěn)定性風險增大的問題。試想如果我們強依賴 10 個服務，9 個都執(zhí)行成功了，最后一個執(zhí)行失敗了，那么是不是前面 9 個都要回滾掉？這個成本還是非常高的。

所以在拆分大的流程為多個小的本地事務的前提下，對于非實時、非強一致性的關聯(lián)業(yè)務寫入，在本地事務執(zhí)行成功后，我們選擇發(fā)消息通知、關聯(lián)事務異步化執(zhí)行的方案

消息通知往往不能保證 100% 成功；且消息通知后，接收方業(yè)務是否能執(zhí)行成功還是未知數(shù)。前者問題可以通過重試解決；后者可以選用事務消息來保證。

但是事務消息框架本身會給業(yè)務代碼帶來侵入性和復雜性，所以我們選擇基于 DB 事件變化通知到 MQ 的方式做系統(tǒng)間解耦，通過訂閱方消費 MQ 消息時的 ACK 機制，保證消息一定消費成功，達到最終一致性。由于消息可能會被重發(fā)，消息訂閱方業(yè)務邏輯處理要做好冪等保證。

所以目前只剩下需要實時同步做、有強一致性要求的業(yè)務場景了。在交易創(chuàng)建過程中，鎖券和扣減庫存是這樣的兩個典型場景。

要保證多個系統(tǒng)間數(shù)據一致，乍一看，必須要引入分布式事務框架才能解決。但引入非常重的類似二階段提交分布式事務框架會帶來復雜性的急劇上升；

解決方案為：

在電商領域，絕對的強一致是過于理想化的，我們可以選擇準實時的最終一致性。

1. 我們在交易創(chuàng)建流程中，首先創(chuàng)建一個不可見訂單，然后在同步調用鎖券和扣減庫存時，針對調用異常（失敗或者超時），發(fā)出廢單消息到MQ
2. 如果廢單消息發(fā)送失敗，本地會做時間階梯式的異步重試；優(yōu)惠券系統(tǒng)和庫存系統(tǒng)收到消息后，會進行判斷是否需要做業(yè)務回滾，這樣就準實時地保證了多個本地事務的最終一致性

總結

• 這里就是MQ的一個應用場景：天然的重試機制，當然都需要配合冪等消費措施
• 蘑菇街的這個最終一致性解決方案，消金自己的交易流程，可以作為參考
• 總結起來，很多最終一致性解決方案的根本原理是類似的，也就是將分布式事務轉換為多個本地事務，然后依靠重試等方式達到最終一致性

參考鏈接：https://www.cnblogs.com/Vincent-yuan/p/16074577.html

轉賬案例的最終一致性

拿a轉賬b舉起例子。a操作生成一個賬戶金額變更記錄，這個記錄添加一個state，標記記錄未完成，事務提交，然后發(fā)送消息到b那邊系統(tǒng)

a這邊系統(tǒng)支持冪等，等待下一步b回調通知轉賬結果完成。而a在操作其他業(yè)務，其能操作的金額是過濾掉這個未完成記錄后的金額部分。這種就是我說的語義鎖，好像有一部分金額被鎖住了，也就是凍結一個中間狀態(tài)

賬單域

核算系統(tǒng) CORE

#貸款核心核算#?規(guī)劃和實現(xiàn)貸款整個生命周期的現(xiàn)金流動。包括貸款發(fā)放、利息計算、利率調整、還款計劃生成、貸款償還或處置等，覆蓋貸款的整個生命周期，核算根本要求:準！算得準并且記得準，每一筆錢不允許出現(xiàn)精度要求范圍內的差額，一分錢不能多，一分錢不能少，每一筆帳不允許出現(xiàn)漏記、錯記的現(xiàn)象

核算系統(tǒng)，負責貸后的相關邏輯：借據管理是基礎能力。核心系統(tǒng)的主要職責是借據信息的存儲和管理、分期計劃和息費計算及交易流水管理。

比如每日跑批算利息、比如還款（還款試算）、比如賬單管理，包括賬單查詢，賬單分期

①借據。借據是用來標識客戶的一次借款，每個借據都有全局唯一的借據號。借據包含各項息費金額、借款日、借據狀態(tài)等基礎信息。

②分期計劃。借據會根據產品規(guī)則包含多個分期計劃，如 3 期、6 期、

12 期、24 期、36 期等。每個分期計劃都有各自息費對應的應還、已還以及分期狀態(tài)等信息。

③交易流水。交易流水用來唯一標識客戶的一次交易行為，如放款、還款、退款等。每一種交易行為對應一個交易碼。同時交易行為對應的息費金額等信息的變化過程都會被系統(tǒng)記錄和保留

????????????????????????

借據

借款申請對應借款單（借據），借款審批對應審批單據，額度扣減對應額度扣減記錄，簽署合同對應簽約記錄，生成還款計劃對應賬單，放款對應支付單

上述內容參考：DDD在有贊信貸核心系統(tǒng)中的實踐 (qq.com)

分發(fā)路由系統(tǒng)

信貸放款需要資金支持，目前的信貸業(yè)務，除了使用自營資金承接外， 更多的資金來源需要依靠合作金融機構的資金池。每家平臺都會接入幾家甚至幾十家的合作金融機構。

分發(fā)路由系統(tǒng)在設計時，需要.......

有的公司支付系統(tǒng)每天千萬級交易需要盡快的收集到大數(shù)據平臺參與計算，就需要用到kafka，來把每筆交易數(shù)據給到風控系統(tǒng)

大數(shù)據風控系統(tǒng)，每天都會計算產生一些結果，比如白名單、黑名單等，如果計算得出張三進入了黑名單，那就要在支付系統(tǒng)APP內給張三發(fā)一條站內信，這種黑名單的通知的量是比較小的，但是對可靠性要求比較高，這時就不需要用kafka，就可以選擇RabbitMQ或者RocketMQ

RocketMQ天生就克服了kafka、RabbitMQ的缺點，又綜合了他倆的優(yōu)點，RocketMQ的一個小的缺點是RocketMQ的客戶端只支持Java