接手這個代號為 financial-services 的項目時團隊只有四個人。老板給的需求就一句話把對公客戶的開戶、收單、代發(fā)、資金歸集放到一個平臺上。聽起來像普通的業(yè)務系統(tǒng)改造但做過金融類項目的同學都清楚這類系統(tǒng)的重點根本不在功能多不多而在賬平不平、錢安不安全、出了問題能不能說清來龍去脈。這篇文章把我從立項到落地的完整決策過程整理了一遍包括為什么這樣選型、哪些環(huán)節(jié)最容易被坑、以及后來踩過的幾個真坑希望對正在做或準備做類似金融服務的團隊有點參考價值。1. 先劃清楚金融服務的項目邊界哪些必須做哪些堅決不做金融服務的項目一上來最怕的不是技術難而是業(yè)務邊界模糊。需求方經(jīng)常說以后我們還要做貸款、理財、供應鏈融資然后希望架構上一步到位。這種想法本身沒問題但如果第一次迭代就把所有可能性都塞進系統(tǒng)成本會失控風險也會失控。1.1 業(yè)務邊界先回答你的服務覆蓋到哪一層我們當時花了整整一周做業(yè)務梳理最后把范圍收斂成三個核心閉環(huán)賬戶管理、收單支付、資金歸集。其他像信貸審批、理財代銷全部劃到二期物理隔離在獨立服務里只預留接口位。這個取舍背后是有邏輯的。賬戶、收單、歸集都屬于交易型鏈路對賬口徑和資金流可以統(tǒng)一設計而信貸、理財涉及不同的期限、利率、風控模型屬于完全不同的業(yè)務語義硬湊進一期只會讓賬務模型四不像。如果你也在做類似項目建議立項時先回答三個問題你的服務是自營還是代銷資金是客戶托管還是銀行存管業(yè)務是實時結算還是TN結算這三個答案基本決定了系統(tǒng)邊界和數(shù)據(jù)模型的方向。1.2 合規(guī)邊界資質(zhì)是一切的技術前提技術方案做得再漂亮沒有對應資質(zhì)也上不了線。我們在技術啟動之前先做了一輪合規(guī)確認是否涉及資金池、是否需要持牌支付通道、是否需要銀行存管、用戶協(xié)議與隱私政策是否覆蓋業(yè)務全鏈路。這些不是法務部門單獨搞定就完事開發(fā)和產(chǎn)品必須知道邊界在哪里。比如資金歸集業(yè)務如果平臺先收錢再分發(fā)給商戶存在合規(guī)風險如果采用銀行存管模式資金不經(jīng)過平臺賬戶技術對接方式就完全不一樣。我們最終選擇通過已有支付持牌機構走代收付通道并在銀行側開立備付金賬戶系統(tǒng)本身不碰商戶資金。這直接影響后續(xù)的賬務模型——平臺側只記錄應收應付和渠道流水真正扣款、結算動作全部由通道側完成。技術側要做的配合是把每一筆資金指令的請求方、接收方、金額、流水號、渠道回執(zhí)完整落庫。因為一旦涉及到資金路徑審計拿不出完整的指令鏈路什么問題都說不清。1.3 功能取舍MVP只做三個閉環(huán)我們的一期MVP砍掉了后臺報表、商戶自助配置、批量導入等非核心功能保留的是商戶開戶、收單下單、支付結果回調(diào)、資金歸集指令、每日對賬和異常告警。每個閉環(huán)必須能獨立跑通、獨立對賬、獨立排查。從實際效果看這個克制非常值得。收單閉環(huán)上線兩周后發(fā)現(xiàn)渠道回調(diào)偶發(fā)丟失就是因為我們對支付中狀態(tài)的處理不夠嚴謹。如果沒有把范圍壓縮到最小而是同時上線一堆邊緣功能排查這個問題可能要翻幾套代碼才能定位。功能面越窄排障半徑越小這個規(guī)律在金融服務這類高復雜度項目里尤其明顯。2. 基礎設施選型錢相關的系統(tǒng)可靠性優(yōu)先于炫技金融服務系統(tǒng)的技術選型我的核心原則只有一條能用成熟穩(wěn)定方案解決的絕不用實驗性方案。團隊里有人當時提議引入某個新的服務網(wǎng)格框架來做流量治理我攔住了。不是說新技術不好而是在資金鏈路上任何基礎設施的隱性bug都可能被放大成資金差錯這種風險不值得冒。2.1 應用架構微服務沒錯但不是越碎越好我們最終選了Java技術棧Spring Cloud Alibaba作為微服務底座注冊中心和配置中心都用Nacos。服務劃分上砍到了六個用戶服務、賬戶服務、交易服務、通道服務、風控服務、通知服務。每個服務拆到什么粒度是有講究的。比如賬戶服務和交易服務是拆開的因為賬戶的借貸計息規(guī)則相對穩(wěn)定而交易流程改動的頻率高拆開之后賬戶模型不會被交易需求的頻繁變更影響。通道服務單獨拆出來也很重要因為支付渠道隨時可能增加或替換通道接口的差異需要收斂在一個服務內(nèi)部不能散落到上游。網(wǎng)關用了Spring Cloud Gateway統(tǒng)一做簽名校驗、token鑒權和黑白名單控制。金融服務對外暴露的接口全部要求簽名參數(shù)拼接后加鹽做HMAC-SHA256防止請求被篡改。這個邏輯放在網(wǎng)關層統(tǒng)一處理業(yè)務服務就不用每個都寫一遍。2.2 數(shù)據(jù)模型與存儲賬戶流水表的設計直接決定對賬難度存儲我們用的MySQL 8.0按用戶ID做分庫分表中間件選了ShardingSphere。賬戶余額表和流水表必須分表存儲Redis只做熱點查詢緩存余額以數(shù)據(jù)庫為準。這一點怎么強調(diào)都不過分——任何時候都不能走先更新緩存再寫庫的路徑金融數(shù)據(jù)必須以數(shù)據(jù)庫為準。流水表的設計我建議參考記賬憑證的思路一張流水只有一個方向。也就是說收款和付款不混在一張表里用正負號區(qū)分而是分借貸兩列或者干脆用明細方向字段。這樣每一筆變動都能追溯這筆錢從哪來、到哪去、對應哪個業(yè)務單號、關聯(lián)了哪條渠道回執(zhí)。我們還加了一個賬戶日終匯總表每天凌晨跑批把每個賬戶當天的期初余額、收入?yún)R總、支出匯總、期末余額算好落庫。對賬的時候直接拿這個匯總表和渠道側賬單做維度匹配效率比逐筆比對高得多。如果你把流水表和日終匯總表一并設計好后續(xù)做余額試算平衡會非常省事。2.3 消息中間件金融場景的可靠投遞怎么落地消息中間件我們用的RocketMQ看重的是事務消息和延遲消息的能力。金融鏈路里大量操作是異步的比如支付結果通知商戶、回單生成、風控異步審核。這些場景如果用普通消息生產(chǎn)者發(fā)送成功但消費者處理失敗消息丟了就是一筆死賬。RocketMQ事務消息的方案是先發(fā)半消息本地執(zhí)行完業(yè)務事務后提交確認消費者看到的是確認后的消息如果本地事務回滾半消息自動刪除。我們用這個機制處理了創(chuàng)建代付指令的場景——先寫本地指令表再發(fā)半消息給通道服務通道服務拿到消息后調(diào)渠道接口。整個過程兩邊的狀態(tài)最終一致。延遲消息用在了支付超時自動關單上。用戶下單后30分鐘未支付系統(tǒng)自動把訂單置為關閉狀態(tài)。這個邏輯如果靠定時任務掃表也能做但用延遲消息能減輕數(shù)據(jù)庫壓力消息到了再處理對應訂單命中率更高。實際用下來RocketMQ的延遲消息精度夠用延遲級別的配置也足夠靈活。3. 支付接入與賬務一致性這塊坑最多值得單獨說說支付接入是金融服務項目里最容易出幺蛾子的地方。渠道文檔寫得再好真實聯(lián)調(diào)時總有意外。我們把這塊單獨立項就是因為它是整個系統(tǒng)的腰眼子——上游連業(yè)務下游連資金中間任何一個環(huán)節(jié)出錯賬就對不上。3.1 渠道接入的通用流程與常見坑無論接微信、支付寶還是銀聯(lián)流程都差不多申請商戶號或開放平臺賬號、配置回調(diào)地址和密鑰、下載SDK或?qū)覣PI、聯(lián)調(diào)環(huán)境跑通、測試用例評審、上線前回歸。每一步都有對應的坑。第一個坑是回調(diào)地址的配置遺漏或配錯。很多渠道要求回調(diào)地址必須是公網(wǎng)可訪問的HTTPS地址且要和申請單一致。我們有一次聯(lián)調(diào)時回調(diào)收不到排查半天發(fā)現(xiàn)是渠道側的沙箱環(huán)境要用單獨的測試回調(diào)域名跟正式域名不是同一個值。這種信息通常藏在文檔的常見問題里不仔細看根本發(fā)現(xiàn)不了。第二個坑是渠道側返回碼的語義不統(tǒng)一。有的渠道返回處理中會隔幾秒收到異步通知有的則不會。如果業(yè)務方默認處理中就是成功并把訂單置為已支付對賬時錢沒到就會暴露問題。我們當時的處理是定義了自己的支付狀態(tài)機待支付、支付中、支付成功、支付失敗、已關閉、已退款。渠道返回處理中統(tǒng)一映射為支付中不直接落成功最終以渠道對賬單為準。第三坑是證書管理。銀行存管、代付通道通常要求雙向TLS認證證書文件有有效期。我們線上出過一次代付失敗原因是某個渠道的商戶證書過期了半個月而證書到期前沒有告警。后來我們把所有證書的有效期都錄入了統(tǒng)一配置提前30天發(fā)提醒提前7天發(fā)告警這個教訓算是用生產(chǎn)事故換來的。3.2 冪等設計用唯一流水號擋住重復請求金融系統(tǒng)里重復支付、重復退款是最要命的問題。用戶前端的支付按鈕連點兩次、渠道回調(diào)重復推送、重試任務重復執(zhí)行任何一個環(huán)節(jié)不小心就可能導致資金重復劃撥。我們的做法是給每類資金指令生成一個全局唯一的流水號在數(shù)據(jù)庫落庫時給流水號建唯一索引。插入時如果撞了唯一索引說明請求重復直接把已存在的那條流水返回給調(diào)用方不重新執(zhí)行。這個邏輯用偽代碼表示大致是這樣Transactional public PaymentResult handlePay(PayRequest request) { String bizNo request.getBizNo(); try { paymentMapper.insertUnique(bizNo, request.getAmount(), request.getAccountNo()); } catch (DuplicateKeyException e) { return paymentMapper.queryByBizNo(bizNo); // 冪等返回原結果 } // 后續(xù)真正的扣款邏輯 ... }關鍵點在于唯一流水號必須在業(yè)務處理前插入成功才能保證并發(fā)請求只有一個執(zhí)行體。如果先把業(yè)務處理完再插入流水號兩個并發(fā)請求可能都處理完了再去插入時兜底已經(jīng)來不及了。我們還額外做了一層狀態(tài)機約束已成功的訂單不允許重復執(zhí)行退款已退款的訂單不允許再次扣款。狀態(tài)流轉表里每一步都有before狀態(tài)和after狀態(tài)任何非法流轉直接拒絕。3.3 對賬與差錯處理T1對賬是底線每天凌晨兩點定時任務會從各渠道拉取前一天的賬單文件解析后和本地流水逐筆比對。比對的核心維度是渠道商戶號、渠道流水號、金額、交易時間、交易狀態(tài)。兩邊能匹配上且金額一致的進入已對平池匹配不上或金額不一致的進入差錯池。差錯處理分成三類本地有單、渠道無單這種情況一般是不成功的請求被本地記成了成功需要把本地狀態(tài)回滾到失敗本地無單、渠道有單通常是渠道回調(diào)漏配或者回調(diào)丟失需要補單兩邊有單但金額不一致屬于嚴重異常直接告警到資金運營群原則上不允許自動處理。對賬系統(tǒng)的實施要注意賬單文件的分片和冪等。渠道賬單可能很大幾萬筆甚至幾十萬筆我們按渠道、日期、文件名做分片每個分片的解析任務用分布式鎖保證只執(zhí)行一次。否則重跑一遍容易產(chǎn)生重復流水。這里分享一個經(jīng)驗對賬功能不要等業(yè)務上線后再補一定要和支付功能同時上線。第一天上線的資金流水如果到第三天才能對出來差錯已經(jīng)發(fā)生了很多情況就說不清楚了。我們是上線前就把對賬定時任務跑起來用測試環(huán)境制造差異單來驗證對賬邏輯等正式切量的時候?qū)~已經(jīng)連續(xù)跑了好幾天。4. 風控反欺詐鏈路不是有了規(guī)則引擎就萬事大吉很多團隊對風控的認知停留在接入一個規(guī)則引擎配幾條黑白名單就完事了。實際上規(guī)則只是整個風控鏈路里最表層的部分真正決定系統(tǒng)安全的是數(shù)據(jù)鏈路和處置閉環(huán)。4.1 先搭名單庫和黑白名單再談模型我們的風控一期沒有上復雜的機器學習模型而是先把三類名單建好機構黑名單、個人黑名單、設備黑名單。名單來源包括歷史壞賬戶、渠道方共享的欺詐名單、法院失信名單通過合規(guī)渠道獲取以及業(yè)務運營手工上報的黑名單。名單服務單獨拆出來底層用Redis存熱數(shù)據(jù)查詢接口做成高可用。所有交易在進通道前必經(jīng)風控風控的第一次判斷就是查名單庫。命中黑名單直接攔截命中白名單如平臺內(nèi)部測試商戶、頭部核心客戶走快速通道減少無謂誤傷。這么做是因為在數(shù)據(jù)積累不夠的階段模型的效果很難超過經(jīng)驗規(guī)則而名單庫是規(guī)則里置信度最高、最容易解釋的一類。如果一上來就上模型業(yè)務人員面對模型分數(shù)根本不知道怎么跟商戶解釋風控決策就變成了黑盒子。先把名單和規(guī)則做扎實后面再漸進引入機器學習這是更穩(wěn)妥的路徑。4.2 實時決策鏈路從埋點到處置實時風控決策我們走的是埋點、采集、計算、處置四段式鏈路。前端在關鍵行為上做埋點登錄、下單、支付、修改結算賬戶。埋點數(shù)據(jù)通過消息隊列實時送到風控服務風控服務把行為抽象成事件依次經(jīng)過名單檢查、頻率檢查、額度檢查、規(guī)則引擎最終輸出放行、人工復核、攔截三種結果。頻率檢查的典型場景同設備號在短時間內(nèi)關聯(lián)了多個不同商戶賬號。正常邏輯下一個設備只屬于一個商戶主體如果出現(xiàn)一拖N的情況大概率是批量注冊或養(yǎng)號。我們當時的規(guī)則是單設備號24小時內(nèi)關聯(lián)用戶數(shù)超過3個就告警超過5個直接攔截攔截后需要上傳額外的資質(zhì)材料進行人工申訴。額度檢查則針對大額交易。比如單筆金額超過商戶歷史均值的5倍、單日累計超過該商戶近30日日均的3倍觸發(fā)人工復核。這類規(guī)則看起來粗暴但非常有效。金融欺詐和小額零散交易的區(qū)別往往就體現(xiàn)在異常量級上閾值可以根據(jù)業(yè)務數(shù)據(jù)滾動調(diào)整避免一刀切誤傷。4.3 人工復核閉環(huán)與指標監(jiān)控風控不能只攔截不處理人工復核閉環(huán)必須和決策鏈路同步建設。我們做了個風控工作臺命中復核的工單推送給運營人員運營人查看訂單信息、商戶資質(zhì)、行為序列后做出通過、拒絕、標記可疑三個操作。所有操作留痕后續(xù)如果同一商戶再出問題可以直接追溯之前是誰復核、依據(jù)是什么、查看了哪些數(shù)據(jù)。風控上線后指標跟蹤同樣重要。我建議至少關注四個指標攔截率、誤殺率、人工復核轉化率、放行后逾期/拒付率。前三個指標衡量風控本身的精準度第四個指標衡量放行決策是否靠譜。我們上線三個月后發(fā)現(xiàn)過于激進地調(diào)高額度閾值導致誤殺率升高影響了正常商戶的支付體驗后來改成小額頻繁放行、大額從嚴復核的策略才平衡了業(yè)務增長與風險敞口。5. 上線不是終點壓測、灰度、故障演練一個都不能少金融服務的項目總給人一種上線即成功的錯覺實際上真正的考驗恰恰在上線之后。第一周的生產(chǎn)流量、第一次大促峰值、第一次渠道故障都會暴露你在測試環(huán)境永遠測不出來的問題。5.1 全鏈路壓測先解決支撐多少交易量這個靈魂拷問老板最愛問的一個問題是這個系統(tǒng)能扛多少并發(fā)這個問題的正確回答方式不是拍腦袋而是用壓測數(shù)據(jù)說話。我們做了兩輪壓測第一輪是單服務壓測把通道服務、交易服務、賬戶服務分別壓到CPU達到70%時的QPS找到各服務的單點瓶頸第二輪是全鏈路壓測用JMeter從網(wǎng)關發(fā)起真實交易請求打穿所有服務看整體吞吐量和TP99。全鏈路壓測的場景必須覆蓋三類流量正常支付、重復支付、異常退款。正常支付驗證吞吐重復支付驗證冪等異常退款驗證狀態(tài)機。壓測期間我們還專門模擬了渠道回調(diào)延遲2分鐘的情況看系統(tǒng)會不會因為等待回調(diào)而積累大量半成品訂單。結果真的發(fā)現(xiàn)了一個連接池參數(shù)配置不當?shù)膯栴}——通道服務的HTTP連接池默認keep-alive時間過短渠道回調(diào)延遲一上來連接復用率下降導致新建連接的開銷拖慢了整體TPS。金融系統(tǒng)的壓測還要特別關注GC情況。資金鏈路如果因為Full GC導致請求大面積超時影響的不只是體驗還有訂單狀態(tài)的不確定性。我們當時給交易服務設置了并行GC和CMS GC參數(shù)的組合調(diào)優(yōu)壓測后TP99從480ms降到了260ms。5.2 灰度發(fā)布資金類功能的爆炸半徑控制發(fā)布是另一個高風險場景。普通業(yè)務系統(tǒng)發(fā)個bug最多是頁面報錯金融服務發(fā)個bug可能就是某類交易全部失敗或者資金重復劃撥。我們每次發(fā)版都走灰度發(fā)布默認先切5%流量到新版本觀察15分鐘確認錯誤率和資金差錯為0后再擴大到30%、50%、100%。灰度切流的關鍵在于灰度維度怎么選。按用戶ID哈希切流是最常見的但對金融服務來說更合理的做法是結合業(yè)務維度。我們當時的做法是灰度期間只在白名單商戶通常是內(nèi)部測試商戶和少量友好商戶范圍內(nèi)啟用新版本這樣即使出現(xiàn)問題影響面也限定在可控范圍內(nèi)。對公業(yè)務和零售業(yè)務不同幾百個大商戶的交易量可能占了整體90%很可能一次灰度發(fā)布無意間覆蓋了核心商戶出問題就是大事。資金類功能的發(fā)布比普通功能更謹慎我們還會在版本發(fā)布后跑一次上線對賬專項檢查由定時任務把發(fā)布前后半小時的交易流水和渠道賬單做一次加急比對確保沒有因為新版本邏輯改動導致對賬差異。5.3 可觀測性與審計出了事能自證清白金融服務系統(tǒng)必須做好可觀測性否則出了問題只能翻日志大海撈針。我們接入了Prometheus和Grafana做監(jiān)控每個服務的請求量、錯誤率、耗時分位數(shù)、JVM堆內(nèi)存都做了看板。業(yè)務側還加了自定義指標支付成功率、回調(diào)丟失率、對賬差異筆數(shù)、風控攔截率這些業(yè)務指標比技術指標更能反映系統(tǒng)健康狀態(tài)。審計日志單獨強調(diào)一下。所有資金操作涉及的操作人、操作時間、請求參數(shù)、響應結果、被調(diào)用的渠道接口、渠道返回碼全部記錄在審計日志表中而且這條表只做插入不做修改。合規(guī)審計和糾紛溯源都靠它。有一次商戶投訴某筆代付沒有到賬我們通過審計日志查到該筆請求在通道服務里因為余額不足被拒絕但通知服務沒有把失敗結果推送給商戶原因是一條消息在消費時拋異常后進入了重試隊列重試期間商戶端已經(jīng)超時關閉了頁面。整個排查過程只用了半小時靠的就是完整鏈路日志。我在這個項目里最深的一個體會是金融服務項目里的每一個環(huán)節(jié)都要做好最壞的打算。支付回調(diào)會丟、渠道證書會過期、消息隊列會積壓、流量的突發(fā)永遠超出預期。與其事后救火不如提前把賬務模型、冪等設計、對賬機制、風控閉環(huán)這四件事做扎實。它們不會直接產(chǎn)生業(yè)務亮點卻是所有金融服務的承重墻。最后分享一個小技巧無論系統(tǒng)多完善上線后前三個月一定要安排專人值夜班關注凌晨的對賬任務每天早上的第一件事不是看日報而是看昨晚對賬差異池的明細。金融系統(tǒng)的問題大多數(shù)不會在工作時間爆發(fā)而是在跑批和結算的深夜悄無聲息地出現(xiàn)。你能在早上9點前發(fā)現(xiàn)并修復它這筆業(yè)務的影響可能就只是一筆差錯單拖到下午影響的就是一整天的資金效率和商戶信任。