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