在金融行業(yè)做技術(shù)或者產(chǎn)品多多少少都會遇到這樣一個(gè)倉庫或者項(xiàng)目代號就叫financial-services。第一次接手的時(shí)候你可能會覺得它只是一個(gè)普通的業(yè)務(wù)服務(wù)真正深入進(jìn)去才發(fā)現(xiàn)賬戶、支付、清算、風(fēng)控、對賬全在里面牽一發(fā)動全身。這篇內(nèi)容就不聊宏觀概念了來點(diǎn)實(shí)際的——把我在金融服務(wù)類項(xiàng)目里踩過的坑、驗(yàn)證過的方案和那些文檔里不寫的判斷邏輯一次性說清楚。1. 拆解一個(gè)真實(shí)的金融服務(wù)項(xiàng)目賬戶、支付、賬本三件套任何一個(gè)被稱為financial-services的項(xiàng)目無論描述文檔寫得多華麗落地時(shí)都繞不開三樣?xùn)|西賬戶體系、支付通道、賬本流水。這三者構(gòu)成了整個(gè)業(yè)務(wù)系統(tǒng)的地基。地基不穩(wěn)上游的營銷、貸款、理財(cái)、積分兌換全是空中樓閣。1.1 項(xiàng)目范圍為什么總是失控我見過不少團(tuán)隊(duì)在啟動階段把financial-services想象成一個(gè)大而全的平臺今天想接支付明天想上錢包后天又打算做企業(yè)虛擬賬戶。結(jié)果排期一拖再拖核心場景遲遲跑不通。原因很簡單金融系統(tǒng)的邊界不是靠功能多少劃分的而是靠資金流和數(shù)據(jù)流劃分的。一個(gè)項(xiàng)目如果叫financial-services通常意味著它至少承擔(dān)了以下職責(zé)中的兩到三項(xiàng)用戶資產(chǎn)賬戶的創(chuàng)建與余額生命周期管理支付交易的發(fā)起、受理、回調(diào)與異常處理交易流水的記錄、匯總以及對賬處理面向內(nèi)部或外部的資金合規(guī)審計(jì)支持建議在項(xiàng)目啟動時(shí)先做一件事畫一張資金流向圖。哪個(gè)環(huán)節(jié)產(chǎn)生訂單哪個(gè)環(huán)節(jié)凍結(jié)資金哪個(gè)環(huán)節(jié)清算到賬哪個(gè)環(huán)節(jié)產(chǎn)生退款。這張圖畫清楚項(xiàng)目范圍自然就收斂了。1.2 賬戶體系余額不是存?zhèn)€數(shù)字那么簡單很多從普通業(yè)務(wù)轉(zhuǎn)過來的同事對賬戶體系最大的誤解就是——認(rèn)為余額就是數(shù)據(jù)庫表里的一個(gè)字段加錢就 update減錢就 update。但在金融服務(wù)系統(tǒng)里余額遠(yuǎn)遠(yuǎn)不是一個(gè)值而是一組約束條件下的狀態(tài)推導(dǎo)結(jié)果。一套可用的賬戶體系至少需要拆出以下幾個(gè)維度可用余額——用戶當(dāng)下能夠發(fā)起的支付、提現(xiàn)操作上限。凍結(jié)余額——已經(jīng)進(jìn)入交易流程但尚未完成清算的資金比如下單未支付、退款處理中。在途余額——已經(jīng)完成扣款但尚未到達(dá)商戶賬戶的資金常見于支付渠道結(jié)算周期內(nèi)。我參與過的項(xiàng)目里第一版就是只設(shè)計(jì)了可用余額字段結(jié)果上線第三天就出了亂子用戶下單后支付成功但渠道回調(diào)延遲系統(tǒng)在回調(diào)前已經(jīng)扣減了可用余額回調(diào)后再次扣減導(dǎo)致余額對不上。后來重構(gòu)為凍結(jié)金額和可用金額分離的邏輯這類問題才從根上消失。1.3 賬本與流水的核心對賬賬本系統(tǒng)是金融服務(wù)項(xiàng)目里最容易被低估的部分。很多團(tuán)隊(duì)的流水表就是一張記錄表字段能存下訂單號、金額、時(shí)間就完事。但實(shí)際上流水的核心價(jià)值在于可復(fù)核。一條合格的金融流水應(yīng)當(dāng)回答四個(gè)問題這筆錢從哪個(gè)賬戶來來源賬戶標(biāo)識這筆錢到哪個(gè)賬戶去目標(biāo)賬戶標(biāo)識這筆交易對應(yīng)哪一筆業(yè)務(wù)憑證關(guān)聯(lián)訂單號這筆交易在哪個(gè)時(shí)間點(diǎn)被哪個(gè)系統(tǒng)操作操作節(jié)點(diǎn)時(shí)間戳只有滿足這四個(gè)基本條件后續(xù)的對賬才能自動跑起來。對賬這件事做得好是系統(tǒng)可靠性最后一道防線做得差就是每個(gè)月底最折磨人的手工勞動。2. 支付通道對接為什么團(tuán)隊(duì)會在這里耗掉兩三個(gè)月每個(gè)financial-services項(xiàng)目都躲不開支付。如果項(xiàng)目只是對接一個(gè)支付渠道那兩個(gè)月內(nèi)基本能上線但如果是聚合支付或自建支付網(wǎng)關(guān)那時(shí)間翻倍是很正常的。原因不在于支付渠道API本身有多復(fù)雜而在于上線后出現(xiàn)的各種邊界情況往往是聯(lián)調(diào)階段根本預(yù)演不到的。2.1 支付網(wǎng)關(guān)的核心流程一個(gè)最簡化的支付流程是這樣業(yè)務(wù)系統(tǒng)創(chuàng)建訂單標(biāo)記為“待支付”。后端請求支付渠道下單接口拿到支付憑證。前端拉起支付用戶在渠道側(cè)完成付款。支付渠道異步回調(diào)業(yè)務(wù)系統(tǒng)通知支付結(jié)果。業(yè)務(wù)系統(tǒng)校驗(yàn)回調(diào)合法性更新訂單與賬戶余額。用戶查詢訂單狀態(tài)完成后續(xù)業(yè)務(wù)。其中第 4、5 兩步是絕大多數(shù)事故高發(fā)地帶。2.2 回調(diào)處理冪等是第一原則支付渠道的回調(diào)通知因?yàn)榫W(wǎng)絡(luò)延遲、渠道重試、服務(wù)重啟等原因同一筆訂單的同一成功結(jié)果被通知兩次甚至更多次是常態(tài)。所以回調(diào)處理的最高準(zhǔn)則就是冪等。落到代碼層面至少要做三件事第一用訂單號加業(yè)務(wù)狀態(tài)做唯一校驗(yàn)。訂單已經(jīng)是“支付成功”狀態(tài)時(shí)后續(xù)回調(diào)直接返回成功不再重復(fù)處理。第二用一個(gè)獨(dú)立的流水號記錄每一次回調(diào)。哪怕是重復(fù)回調(diào)也應(yīng)當(dāng)留痕方便排查。第三金額校驗(yàn)必須雙向?；卣{(diào)解密后除了驗(yàn)簽還要確認(rèn)渠道回調(diào)金額和本地訂單金額一致。我親眼見過渠道側(cè)配置錯(cuò)誤導(dǎo)致回調(diào)金額不一致的情況如果沒有這一步校驗(yàn)而直接入賬后果不堪設(shè)想。// 冪等處理示例先查狀態(tài)再決定是否入賬 public void handlePayCallback(PayCallbackRequest request) { Order order orderRepository.findByOrderNo(request.getOrderNo()); // 狀態(tài)已終態(tài)則直接返回避免重復(fù)入賬 if (PAID.equals(order.getStatus())) { return; } if (!validateAmount(order, request.getPayAmount())) { throw new MismatchException(金額不一致); } accountService.credit(order.getUserId(), request.getPayAmount()); orderRepository.updateStatus(order.getId(), PAID); }2.3 掉單與退款最常見的兩處摩擦掉單指的是用戶已經(jīng)付款但業(yè)務(wù)系統(tǒng)沒有收到成功狀態(tài)。問題多出在三種情況回調(diào)丟失、前端主動查單接口設(shè)計(jì)不完善、或渠道結(jié)算后才發(fā)現(xiàn)訂單未被處理。業(yè)內(nèi)通用解法是主動查單補(bǔ)償。支付成功后前端保持查單輪詢后端另設(shè)定時(shí)任務(wù)每隔一段時(shí)間拉取一段時(shí)間內(nèi)的“支付中”訂單主動向渠道詢問真實(shí)狀態(tài)。再做得穩(wěn)一點(diǎn)還會在每日對賬文件中找出業(yè)務(wù)系統(tǒng)漏掉的支付記錄進(jìn)行批量補(bǔ)單。退款的問題則集中在退款狀態(tài)的不確定性上。渠道退款有時(shí)是即時(shí)完成有時(shí)要走銀行通道需要數(shù)日。系統(tǒng)設(shè)計(jì)上一定要把“退款中”當(dāng)作獨(dú)立狀態(tài)并給用戶明確提示后臺要支持退款重發(fā)、退款查詢、以及退款結(jié)果反向回調(diào)。如果把這些都當(dāng)作“按下按鈕就結(jié)束”來處理客服工單會堆滿整個(gè)團(tuán)隊(duì)。3. 實(shí)時(shí)風(fēng)控規(guī)則引擎與第一道防線資損這件事做金融服務(wù)的團(tuán)隊(duì)沒有誰可以假裝看不見。從薅羊毛到盜刷從惡意退貨到批量注冊風(fēng)控做得不到位業(yè)務(wù)越火損失越大。但風(fēng)控的目標(biāo)從來不是“極速攔截所有風(fēng)險(xiǎn)訂單”而是在風(fēng)險(xiǎn)與體驗(yàn)之間找平衡。3.1 先分清風(fēng)控要攔的是什么我在實(shí)際項(xiàng)目里把風(fēng)控場景拆成了四類不同場景判斷邏輯差別很大欺詐風(fēng)險(xiǎn)盜刷、盜號支付、偽造交易——特征是單點(diǎn)行為異常需要實(shí)時(shí)攔截。營銷風(fēng)險(xiǎn)批量注冊、刷優(yōu)惠券、套現(xiàn)——特征是多賬號關(guān)聯(lián)需要數(shù)據(jù)挖掘。信用風(fēng)險(xiǎn)借款場景下的用戶還款能力評估——特征是歷史行為模型需要機(jī)器學(xué)習(xí)。操作風(fēng)險(xiǎn)員工誤操作、內(nèi)部越權(quán)——特征是權(quán)限與審計(jì)需要慢速但全面的審計(jì)鏈路。實(shí)時(shí)風(fēng)控主要用于前兩類。規(guī)則引擎、模型評分、名單系統(tǒng)三位一體構(gòu)成實(shí)時(shí)判斷的核心。3.2 規(guī)則引擎的落地順序很多人一上來就想上機(jī)器學(xué)習(xí)模型我建議先別急。規(guī)則引擎是性價(jià)比最高的第一步。它的核心是一個(gè)決策表輸入訂單特征輸出“放行、人工審核、拒絕”。我常用的一組基礎(chǔ)特征用戶注冊時(shí)長小于 N 天的用戶高額交易一率進(jìn)人工審核。單設(shè)備關(guān)聯(lián)賬號數(shù)同一設(shè)備指紋關(guān)聯(lián)賬號超過 N直接拒絕。下單地址與常用地址距離超過一定閾值加強(qiáng)校驗(yàn)。支付頻次同一用戶一小時(shí)內(nèi)支付筆數(shù)超過 N觸發(fā)限流。規(guī)則引擎的關(guān)鍵不在規(guī)則數(shù)量而在規(guī)則可運(yùn)維。規(guī)則的增刪改必須支持后臺配置而不是每次都發(fā)版。我見過一個(gè)團(tuán)隊(duì)把規(guī)則寫死在代碼里業(yè)務(wù)因?yàn)榛顒庸?jié)奏調(diào)規(guī)則每次都要升級系統(tǒng)運(yùn)營和開發(fā)的矛盾每天都在升級。3.3 風(fēng)控與體驗(yàn)的權(quán)衡風(fēng)控做得太松資損上升做得太緊誤殺率讓用戶大量流失。在實(shí)際運(yùn)營中我會用一個(gè)指標(biāo)來校準(zhǔn)——誤殺率。每攔截 100 筆訂單里有多少筆實(shí)際上是正常用戶這個(gè)數(shù)字必須持續(xù)追蹤。降低誤殺率的常用手段包括分層風(fēng)控不同等級用戶不同閾值、申訴通道用戶被攔截后提供證明材料、以及灰度放行對不確定訂單先放行但延長結(jié)算周期。另外風(fēng)控決策一定要寫入審計(jì)日志。出了問題不是看模型解釋而是看當(dāng)時(shí)的完整上下文。4. 安全合規(guī)與數(shù)據(jù)紅線哪些是不能省的設(shè)計(jì)金融服務(wù)類項(xiàng)目安全合規(guī)不是可選項(xiàng)而是隱藏架構(gòu)的一部分。尤其當(dāng)系統(tǒng)面向真實(shí)用戶、真實(shí)資金的時(shí)候“先上線再補(bǔ)安全”這種思路是走不通的。以下這三項(xiàng)是無論如何都不能省的底線設(shè)計(jì)。4.1 敏感數(shù)據(jù)的加密與脫敏用戶身份證號、銀行卡號、手機(jī)號、地址這些都屬于敏感數(shù)據(jù)必須在存儲層加密。我的建議是數(shù)據(jù)庫存儲采用字段級加密密鑰由獨(dú)立的密鑰管理系統(tǒng)管理業(yè)務(wù)側(cè)讀出后再按需解密。需要注意的是為了支持模糊查重例如判斷手機(jī)號是否已注冊可以設(shè)計(jì)獨(dú)立的哈希索引列用不可逆算法處理用于查詢的字段值而真正可解密的密文單獨(dú)存放。這樣既不暴露明文又保證了查詢性能。同時(shí)前端展示必須脫敏。銀行卡號顯示后四位、手機(jī)號中間四位打星號這些規(guī)則要在接口層統(tǒng)一處理不能下放到每個(gè)業(yè)務(wù)方自行拼接。4.2 權(quán)限模型按角色、按場景最小授權(quán)金融服務(wù)系統(tǒng)的后臺權(quán)限不能是簡單的管理員和普通員工兩類。至少要拆出以下幾類角色運(yùn)營角色只讀數(shù)據(jù)、可發(fā)券不可提現(xiàn)、財(cái)務(wù)角色可看對賬、可操作退款但不可修改費(fèi)率、客服角色僅可查看自己權(quán)限范圍內(nèi)的用戶資料、開發(fā)運(yùn)維角色可看日志、不可直接改業(yè)務(wù)數(shù)據(jù)。另一個(gè)容易踩坑的地方是操作權(quán)限與數(shù)據(jù)權(quán)限要分開。一個(gè)客服可能有“查看訂單”的操作權(quán)限但數(shù)據(jù)權(quán)限只允許查看自己所在分區(qū)的訂單。操作權(quán)限用 RBAC基于角色的訪問控制解決數(shù)據(jù)權(quán)限建議用規(guī)則注入的方式在查詢層統(tǒng)一追加過濾條件。4.3 審計(jì)日志不是給機(jī)器看的是給追溯用的金融服務(wù)項(xiàng)目的審計(jì)日志比普通日志要求更嚴(yán)格。第一重要操作沒有刪除只能追加。第二日志里必須包含操作者、操作時(shí)間、操作前狀態(tài)、操作后狀態(tài)、IP、操作原因。第三審計(jì)日志不能和業(yè)務(wù)日志混在一起要獨(dú)立存儲且具有高可靠性。我遇到過審計(jì)日志寫入業(yè)務(wù)庫的情況結(jié)果業(yè)務(wù)庫出故障審計(jì)日志也跟著丟了最后外部要求提供操作追溯記錄時(shí)團(tuán)隊(duì)非常被動。后來我們把審計(jì)日志獨(dú)立走一套消息隊(duì)列寫入雖然短期內(nèi)增加了開發(fā)量但之后的每一次爭議投訴處理都輕松得多。5. 從 0 到 1 的選型與團(tuán)隊(duì)協(xié)作哪些投入最值得最后一個(gè)部分聊聊實(shí)際啟動一個(gè)financial-services項(xiàng)目時(shí)技術(shù)選型和管理協(xié)作上最值得花精力的地方。5.1 技術(shù)選型別為了“新”而“新”金融服務(wù)項(xiàng)目真正考驗(yàn)的不是能否寫出某個(gè)炫技算法而是能否在資金鏈路的每個(gè)環(huán)節(jié)都保證一致性、可靠性、可追溯性。因此我個(gè)人的選型原則是核心鏈路用成熟技術(shù)邊緣場景再考慮創(chuàng)新。核心存儲優(yōu)先選擇強(qiáng)一致的數(shù)據(jù)庫賬務(wù)數(shù)據(jù)必須事務(wù)強(qiáng)一致不能用最終一致性來賭對賬。支付的異步補(bǔ)償可以用消息隊(duì)列但消息隊(duì)列本身要選具備事務(wù)消息或至少可靠投遞能力的不能讓消息丟失。緩存可以用在交易查詢等讀多寫少的場景。但余額的讀取不能先查緩存——余額變化必須直接落在數(shù)據(jù)庫事務(wù)里緩存只能作為展示層輔助通過流水版本號控制失效。5.2 高可用部署最容易忽略的點(diǎn)金融項(xiàng)目通常要求 99.9% 以上的可用性部署層面必須考慮多機(jī)房容災(zāi)和故障轉(zhuǎn)移。但比起這些基礎(chǔ)設(shè)施能力我更想提兩個(gè)最容易忽略的小點(diǎn)。一個(gè)是時(shí)間同步。金融系統(tǒng)的賬務(wù)流水、對賬文件、審計(jì)日志都依賴一致的服務(wù)器時(shí)間。很多小團(tuán)隊(duì)忽視了 NTP 同步導(dǎo)致不同服務(wù)器記錄的事件時(shí)序錯(cuò)亂排查問題時(shí)非常痛苦。另一個(gè)是降級開關(guān)。支付服務(wù)和風(fēng)控服務(wù)必須有明確的降級預(yù)案。比如風(fēng)控系統(tǒng)掛掉時(shí)是不是應(yīng)該自動放行“自動放行”在大部分場景下是正確選擇因?yàn)閿r不了總比把整個(gè)業(yè)務(wù)拖死強(qiáng)。但這個(gè)開關(guān)一定要顯式設(shè)計(jì)而不是等事故發(fā)生時(shí)再找代碼。5.3 團(tuán)隊(duì)協(xié)作金融項(xiàng)目最值錢的是一種能力做金融服務(wù)項(xiàng)目團(tuán)隊(duì)里一定要有一個(gè)人能畫清“錢從哪來到哪去”的鏈路。這個(gè)人可以是資深開發(fā)、可以是架構(gòu)師、也可以是懂賬務(wù)的產(chǎn)品經(jīng)理。團(tuán)隊(duì)里但凡缺少這種角色賬務(wù)設(shè)計(jì)要么過度復(fù)雜要么漏洞百出。日常協(xié)作上任何涉及資金流向的改動都需要拉上財(cái)務(wù)側(cè)提前評審不要等代碼合入了再模擬驗(yàn)證。另外資金鏈路的測試要專門設(shè)計(jì)一套交易模擬器能夠造出重復(fù)回調(diào)、金額不一致、渠道超時(shí)、補(bǔ)單并發(fā)這四類異常每次發(fā)布前至少把核心鏈路跑一遍。在我自己的實(shí)踐里金融服務(wù)項(xiàng)目最難的不是某個(gè)單一技術(shù)點(diǎn)而是整個(gè)團(tuán)隊(duì)對“資金安全”的敬畏程度。規(guī)則定清楚、異常設(shè)計(jì)到位、日志留完整絕大多數(shù)事故都是可以提前規(guī)避的。以上這些是我一次次踩坑后沉淀下來的經(jīng)驗(yàn)希望能給你的項(xiàng)目帶來一些實(shí)際參考。