做金融科技平臺這些年有一個感受越來越強(qiáng)烈市面上講financial-services的資料要么是宏觀趨勢分析讀著云里霧里要么是零散的代碼片段拼不出完整系統(tǒng)。真正把賬戶、交易、支付路由、對賬、合規(guī)這些模塊串起來講透的內(nèi)容其實(shí)非常少。我經(jīng)歷了從零搭建一個金融服務(wù)平臺的全過程踩過不少坑也沉淀了一些可以復(fù)用的設(shè)計(jì)思路。這篇文章我會把整個系統(tǒng)的核心模塊、關(guān)鍵技術(shù)決策和排障過程完整梳理一遍寫給那些正在構(gòu)建支付、錢包或交易中臺的團(tuán)隊(duì)也寫給想系統(tǒng)理解金融科技系統(tǒng)架構(gòu)的開發(fā)者。內(nèi)容偏實(shí)戰(zhàn)不會堆概念。1. 從零搭建金融服務(wù)平臺先想清楚它到底該做什么很多人一聽到做金融服務(wù)的平臺第一反應(yīng)就是趕緊畫系統(tǒng)架構(gòu)圖、選數(shù)據(jù)庫、定技術(shù)棧。這其實(shí)順序反了。金融系統(tǒng)的復(fù)雜度根本不在技術(shù)而在業(yè)務(wù)規(guī)則和資金安全的約束。技術(shù)選型錯了可以重構(gòu)業(yè)務(wù)規(guī)則想錯了損失的是真金白銀。1.1 financial-services不是支付系統(tǒng)那么簡單我接手這個代號為financial-services的項(xiàng)目時團(tuán)隊(duì)給的描述很簡短做一個能付錢、能收錢、能查賬單的后臺。聽起來像支付系統(tǒng)但真正落地時你會發(fā)現(xiàn)一個完整的金融服務(wù)平臺至少包含四個層次賬務(wù)核心層賬戶體系、記賬引擎、余額管理這是整個系統(tǒng)的地基交易處理層充值、支付、退款、提現(xiàn)等業(yè)務(wù)動作的狀態(tài)機(jī)流轉(zhuǎn)渠道接入層對接銀行、第三方支付、清算機(jī)構(gòu)等外部渠道處理成功、失敗、未知三種回調(diào)結(jié)果運(yùn)營與風(fēng)控層對賬系統(tǒng)、風(fēng)控規(guī)則引擎、審批流、權(quán)限審計(jì)這四個層次不是并列關(guān)系而是有嚴(yán)格的依賴順序。地基是賬務(wù)核心上面才能蓋交易處理再往上是渠道接入最外層才是運(yùn)營工具。很多項(xiàng)目失敗就是因?yàn)闆]有想清楚賬務(wù)核心才是金融系統(tǒng)的真正底座一上來就接渠道、做業(yè)務(wù)等到賬不平的時候才發(fā)現(xiàn)底層賬戶模型根本撐不住。1.2 第一版架構(gòu)邊界先行以賬戶和交易為核心確定邊界是架構(gòu)設(shè)計(jì)的第一步。我最終劃定的是五個微服務(wù)每個服務(wù)只負(fù)責(zé)一個業(yè)務(wù)領(lǐng)域account-service賬戶生命周期管理負(fù)責(zé)開戶、銷戶、凍結(jié)、密碼管理ledger-service記賬引擎只做借貸流水登記和余額計(jì)算不關(guān)心業(yè)務(wù)含義payment-service交易編排把充值、支付、退款等動作翻譯成記賬指令channel-service渠道接入與路由統(tǒng)一管理所有外部支付通道reconciliation-service對賬與差錯處理定時拉取渠道賬單和內(nèi)部流水比對每個微服務(wù)獨(dú)立部署、獨(dú)立數(shù)據(jù)庫服務(wù)之間通過事件或API通信。這個劃分的核心原則是賬本和賬戶分離、交易和渠道分離。賬本永遠(yuǎn)只記錄資金變動不摻入業(yè)務(wù)狀態(tài)交易層只表達(dá)業(yè)務(wù)意圖具體和哪個渠道通信由路由層決定。這樣設(shè)計(jì)的好處是任何一個渠道出問題最多影響channel-service不會波及賬務(wù)核心。2. 賬戶與流水設(shè)計(jì)資金系統(tǒng)最容易翻車的地方賬戶體系是整個financial-services平臺上最不能出錯的部分。如果業(yè)務(wù)邏輯寫錯了頂多體驗(yàn)不好賬戶余額算錯了那就是資金事故。這一章我重點(diǎn)講三個最容易翻車的設(shè)計(jì)點(diǎn)。2.1 余額模型選型單賬戶余額還是多明細(xì)流水剛起步的團(tuán)隊(duì)最容易犯的錯誤是直接在賬戶表里存一個balance字段每次交易直接改余額再用事務(wù)鎖保證安全。這個設(shè)計(jì)在交易量極低時沒問題但一旦業(yè)務(wù)復(fù)雜起來你根本說不清某筆余額是怎么來的審計(jì)完全無法進(jìn)行。更穩(wěn)妥的做法是余額冗余加流水追加。具體來說是兩張表配合賬戶表存放當(dāng)前余額balance和最近更新時間balance可以理解為快照流水表每一筆資金變動追加一條記錄包含記賬方向、變動金額、變動后余額、業(yè)務(wù)訂單號、渠道流水號有人會問這兩者不一致怎么辦這就是關(guān)鍵點(diǎn)。余額和流水的更新必須在同一個數(shù)據(jù)庫事務(wù)里完成先寫流水再更新余額利用唯一約束保證轉(zhuǎn)換順序不會混亂。任何余額更新都必須基于流水累計(jì)不允許出現(xiàn)沒有流水支撐的余額變動。賬戶表只保留當(dāng)前狀態(tài)流水表是真正的審計(jì)依據(jù)。為什么很多銀行系統(tǒng)查賬效率不高因?yàn)樗麄儼蚜魉陀囝~混在一張超級大表里。我見過生產(chǎn)環(huán)境中有團(tuán)隊(duì)把賬戶表balance字段直接存成decimal(18,2)雖然精度夠但后來加幣種支持時幾乎重構(gòu)了整個表結(jié)構(gòu)。建議賬戶模型里預(yù)留幣種字段、賬本類型字段哪怕第一版只有人民幣單一幣種也不要省這些擴(kuò)展位。2.2 冪等、防重放與并發(fā)控制三個必踩的坎資金系統(tǒng)最危險的問題不是并發(fā)性能差而是同一個請求被重復(fù)執(zhí)行了兩次。支付網(wǎng)關(guān)超時重試、前端按鈕雙擊、消息隊(duì)列重復(fù)消費(fèi)這些都是冪等痛點(diǎn)的來源。我的解決方案是引入請求冪等表。每個業(yè)務(wù)操作在入口生成一個全局唯一的request_idUUID落庫時對這個request_id建唯一索引。如果同一請求再次到達(dá)數(shù)據(jù)庫唯一約束直接擋住應(yīng)用層返回之前已處理的結(jié)果而不是重新執(zhí)行業(yè)務(wù)邏輯。這樣做的好處是冪等邏輯下沉到數(shù)據(jù)庫層面就算應(yīng)用層并發(fā)多實(shí)例也能兜住。防重放和冪等是兩件事。防重放要解決的是攻擊者把抓到的請求再發(fā)一遍。支付接口尤其要防核心手段是timestamp加nonce簽名校驗(yàn)。請求頭帶上毫秒時間戳和32位隨機(jī)字符串服務(wù)端檢查時間偏差超過5分鐘直接拒絕再查nonce是否已使用過。并發(fā)控制方面不要依賴先查詢再更新的read-check-write模式一定要用條件更新SQLUPDATE account SET balance balance - 100, version version 1 WHERE account_id u_001 AND status ACTIVE AND balance 100;注意這里的balance 100條件非常重要它把余額是否充足的校驗(yàn)和余額扣減兩個動作合并為一個原子操作避免高并發(fā)下余額被扣成負(fù)數(shù)。affected rows為0時再區(qū)分是余額不足還是賬戶狀態(tài)異常。用version字段做樂觀鎖更保險更新失敗提示用戶重試。2.3 資金流水不可變原則流水表一旦寫入就絕不允許update和delete只能通過追加紅沖藍(lán)補(bǔ)流水來糾正錯誤。這是會計(jì)學(xué)的核心原則在程序里同樣適用。我見過有同事為了方便直接update流水把金額從100改成120結(jié)果所有下游統(tǒng)計(jì)全亂了。正確的做法是如果某筆交易金額錯了先登記一條負(fù)數(shù)沖正流水把原流水業(yè)務(wù)狀態(tài)標(biāo)記為已沖正再補(bǔ)一條正確的流水。實(shí)現(xiàn)上可以在流水表加一個deleted標(biāo)識列不建議。我會建議追加一個related_txn_id字段指向被沖正的原流水號。這樣審計(jì)時順著related_txn_id就能追到完整的資金流轉(zhuǎn)鏈。這個設(shè)計(jì)也方便對賬系統(tǒng)在出現(xiàn)長短款時自動生成差錯流水。3. 支付路由與渠道接入從可用性到成本的最小化博弈金融服務(wù)平臺逃不開的一件事就是對接外部支付渠道。渠道一多問題就來了每家的報文格式不一樣、回調(diào)機(jī)制不一樣、費(fèi)率不一樣、成功率也不一樣。怎么讓上層業(yè)務(wù)無感知地調(diào)任意渠道同時還能根據(jù)策略選擇最優(yōu)渠道這就是渠道接入層要解決的。3.1 渠道接入的通用抽象層設(shè)計(jì)對接渠道的第一步不是看文檔而是抽象出所有渠道的共性。不管是中國銀聯(lián)、支付寶、微信還是海外的Stripe支付請求的核心參數(shù)其實(shí)就幾類訂單號、金額、幣種、回調(diào)地址、商品描述、附加數(shù)據(jù)?；卣{(diào)報文的核心參數(shù)也是固定的渠道交易號、業(yè)務(wù)狀態(tài)、完成時間、原始請求數(shù)據(jù)?；谶@個共性我在channel-service里定義了一套統(tǒng)一的Adapters接口每個渠道實(shí)現(xiàn)一個AdapterbuildPayRequest 把內(nèi)部統(tǒng)一支付請求翻譯成渠道特有參數(shù)parseNotify 把渠道回調(diào)解析成統(tǒng)一回調(diào)事件queryOrder 主動查單用于補(bǔ)償回調(diào)丟失refund 退款申請適配器模式在這個場景下非常合適。新增渠道時業(yè)務(wù)方只需要寫一個Adapter實(shí)現(xiàn)再在配置中心注冊渠道參數(shù)。所有渠道差異被封裝在Adapter內(nèi)部上層payment-service完全不感知當(dāng)前用的是哪個渠道。3.2 路由決策可用性、成本和成功率的權(quán)重渠道多了以后路由就是一個多目標(biāo)決策問題。同一筆100元的支付A渠道成功率99.2%但費(fèi)率0.6%B渠道成功率98.5%但費(fèi)率0.38%。選哪個沒有絕對答案只有基于權(quán)重打分的最優(yōu)解。我給渠道定義了一組實(shí)時特征加靜態(tài)特征的評分體系指標(biāo)權(quán)重說明近15分鐘成功率0.35從監(jiān)控系統(tǒng)實(shí)時拉取平均響應(yīng)時間0.25從監(jiān)控系統(tǒng)實(shí)時拉取費(fèi)率0.20靜態(tài)配置越低得分越高單筆限額匹配度0.10大額優(yōu)先限額高的渠道渠道健康度0.10主動探測是否可用每次支付請求到達(dá)時路由模塊會實(shí)時計(jì)算各渠道得分選擇最高分渠道發(fā)起支付如果主渠道調(diào)用失敗自動按得分排序降級到備用渠道。這里有個容易忽略的細(xì)節(jié)降級邏輯必須對用戶無感知如果主渠道失敗后返回給用戶的是支付失敗請重試那用戶體驗(yàn)會很差。正確做法是內(nèi)部自動重試備用渠道最多重試一次重試不能再換渠道避免多個渠道同時產(chǎn)生交易。3.3 回調(diào)冪等與掉單處理渠道回調(diào)是最容易出問題的環(huán)節(jié)?；卣{(diào)可能延遲、可能重復(fù)、可能丟失甚至可能先通知失敗再通知成功。所以回調(diào)處理的第一原則是只認(rèn)狀態(tài)不信順序。我在回調(diào)統(tǒng)一入口設(shè)計(jì)了狀態(tài)機(jī)校驗(yàn)只有允許的狀態(tài)遷移才執(zhí)行操作。比如支付失敗回調(diào)到了但訂單狀態(tài)已經(jīng)是支付成功此時絕不能把訂單改回失敗。反過來支付成功回調(diào)到達(dá)時即使之前收到過失敗通知也必須以成功為準(zhǔn)。這個以終態(tài)為準(zhǔn)的邏輯非常關(guān)鍵。掉單問題靠主動查單兜底。我的方案是每個待支付訂單有一個延遲查詢?nèi)蝿?wù)超時未收到回調(diào)時定時向渠道發(fā)起主動查單。查單結(jié)果精確到這個狀態(tài)才好處理如果渠道顯示已支付本地立即更新成功如果渠道顯示未支付則繼續(xù)等待或提醒用戶。這里我說一個經(jīng)驗(yàn)不要用固定時間輪詢而是采用指數(shù)退避比如支付后10秒、30秒、60秒、5分鐘各查一次避免給渠道造成無謂的查詢壓力。4. 一次真實(shí)的對賬排障賬不平的那一夜對賬單是金融系統(tǒng)的照妖鏡。無論代碼寫得多么嚴(yán)謹(jǐn)只要上線跑一段時間總能被對賬系統(tǒng)找出一些驚喜。我印象最深的一次賬不平發(fā)生在平臺上線后第三周。4.1 對賬設(shè)計(jì)內(nèi)部賬 vs 渠道賬單對賬的核心思想很簡單把內(nèi)部系統(tǒng)的交易流水和外部渠道的對賬單逐筆核對找出兩邊不一致的記錄。但落地細(xì)節(jié)遠(yuǎn)沒有這么簡單。先建立兩邊數(shù)據(jù)源。內(nèi)部側(cè)取ledger-service中所有當(dāng)天的支付成功流水外部側(cè)下載各渠道的T1結(jié)算賬單。兩邊都以渠道訂單號金額狀態(tài)作為比對維度。比對結(jié)果分成幾類兩邊一致且金額相等的記為平賬內(nèi)部有但渠道沒有的記為短款渠道有但內(nèi)部沒有的記為長款兩邊都有但金額不一致的記為差錯。對賬任務(wù)用定時調(diào)度跑每天晚上拉去全量賬單出來逐批比對。日單量大就按交易時間分片再并行比對對賬結(jié)果落庫后觸發(fā)告警通知財務(wù)和研發(fā)。4.2 長短款的完整排查鏈路從現(xiàn)象到根因那一次告警說的是某天出現(xiàn)了一筆內(nèi)部顯示支付成功、渠道對賬單里沒有的短款金額是598元。我當(dāng)時的第一反應(yīng)是查payment-service的日志看這筆單子的完整生命周期。結(jié)果是支付請求發(fā)出后渠道一直沒有回調(diào)本地訂單狀態(tài)停留在處理中。到了超時查單的時間點(diǎn)查單接口返回了支付成功代碼隨即更新訂單狀態(tài)為成功并調(diào)用了記賬接口。問題出在查單結(jié)果和回調(diào)結(jié)果存在時間窗口。渠道的查單接口返回成功但實(shí)際結(jié)算文件中并沒有這筆交易。原因后來查清楚了那筆交易在渠道側(cè)確實(shí)進(jìn)入了支付流程但因渠道內(nèi)部風(fēng)控攔截交易最終被回滾查單接口剛好在回滾前的極短窗口內(nèi)返回了成功而我方查單邏輯沒有對返回結(jié)果做二次驗(yàn)證。這個坑的教訓(xùn)是查單返回成功后不能只更新本地狀態(tài)就完事還要過一次渠道側(cè)的交易狀態(tài)確認(rèn)或者等一個渠道的正式結(jié)算通知。更穩(wěn)妥的對賬補(bǔ)償策略是查單發(fā)現(xiàn)渠道側(cè)成功但本地交易狀態(tài)異常時先落地為待確認(rèn)單等待次日對賬結(jié)果再最終入賬。寧可讓用戶看到支付處理中也不要誤報支付成功導(dǎo)致資金損失。修復(fù)方案并不復(fù)雜查單邏輯中增加了一個對渠道狀態(tài)碼的更嚴(yán)格校驗(yàn)只有當(dāng)渠道明確返回交易終態(tài)成功時才標(biāo)記本地成功。同時增加渠道對賬單的二次比對任務(wù)對查單確認(rèn)的訂單在T1對賬時自動復(fù)核。4.3 補(bǔ)償機(jī)制的落地經(jīng)驗(yàn)經(jīng)過那次事故我把對賬系統(tǒng)的補(bǔ)償機(jī)制完善成了三層第一層交易層補(bǔ)償。處理超時訂單的主動查單、狀態(tài)置位、退款觸發(fā)第二層對賬層補(bǔ)償。處理對賬發(fā)現(xiàn)的長款自動退款、短款自動補(bǔ)記第三層人工處理平臺。對無法自動處理的差異生成工單給運(yùn)營和財務(wù)逐筆確認(rèn)這三層缺一不可。第二層對賬補(bǔ)償有個細(xì)節(jié)值得說一下對于渠道對賬單有但內(nèi)部系統(tǒng)沒有的交易不要直接補(bǔ)記成功。先要驗(yàn)證這筆交易是否關(guān)聯(lián)了本地存在但狀態(tài)沒有更新的訂單如果找不到關(guān)聯(lián)訂單再標(biāo)記為待人工核查。原因很簡單有可能這筆交易是非法套用的支付憑證如果盲目補(bǔ)記等于承認(rèn)了一個來源不明的資產(chǎn)變動這在金融上是絕對不能接受的。5. 合規(guī)與安全護(hù)欄做金融科技的第一課在金融科技這個領(lǐng)域能不能做是一回事能做什么、怎么安全地做是另一回事。很多項(xiàng)目技術(shù)在市面上屬于很成熟的水平最后死于合規(guī)審查。我在搭建financial-services平臺時把合規(guī)和安全拆成了幾個硬性要求寫進(jìn)了系統(tǒng)設(shè)計(jì)而不是事后補(bǔ)救。5.1 權(quán)限模型最小權(quán)限原則的工程化落地金融服務(wù)平臺的每一項(xiàng)操作都可能涉及資金所以權(quán)限控制不能停留在簡單的角色區(qū)分上。我把權(quán)限模型設(shè)計(jì)成RBAC加數(shù)據(jù)范圍雙重控制。功能權(quán)限控制用戶能操作哪些功能比如創(chuàng)建訂單、審核退款、修改費(fèi)率數(shù)據(jù)權(quán)限控制用戶能訪問哪些數(shù)據(jù)范圍比如普通運(yùn)營只能看自己負(fù)責(zé)的商戶財務(wù)經(jīng)理可看全量實(shí)現(xiàn)上可以在用戶表引入department_id、merchant_id字段所有數(shù)據(jù)查詢SQL強(qiáng)制追加數(shù)據(jù)范圍過濾條件。這個過濾條件不能只靠前端隱藏按鈕必須由后端統(tǒng)一攔截。我寫過一個注解式權(quán)限校驗(yàn)組件核心方法是解析當(dāng)前登錄用戶的上下文自動在查詢條件上拼接權(quán)限過濾SQL從根上防止越權(quán)查詢。涉及資金變動的高危操作比如退款、調(diào)賬強(qiáng)制執(zhí)行二次審批和操作員不兼容規(guī)則即操作人和審批人不能是同一個人。這條在系統(tǒng)里用審批流配置寫死不允許繞過。5.2 數(shù)據(jù)脫敏與加密安全底線金融系統(tǒng)里最敏感的數(shù)據(jù)是用戶身份信息和銀行卡信息。這些信息如果明文存儲在數(shù)據(jù)庫一旦泄露就是重大安全事故。我的做法是分級加密存儲。手機(jī)號、身份證號存儲時加密展示時脫敏只顯示前三位后四位銀行卡號存儲時加密調(diào)用渠道接口時才動態(tài)解密支付密碼只存儲加鹽哈希鹽值每個用戶獨(dú)立不允許反向解密這里說一個實(shí)際操作經(jīng)驗(yàn)不要把加密邏輯散落在各個業(yè)務(wù)代碼里應(yīng)該在ORM層面做一個統(tǒng)一字段加密器用注解標(biāo)記加密字段。業(yè)務(wù)代碼無感知讀寫加密解密統(tǒng)一走組件。密鑰管理用獨(dú)立的密鑰管理服務(wù)密鑰輪換時只需新老密鑰并行解密校驗(yàn)不影響業(yè)務(wù)。安全評審時也容易通過因?yàn)閷徲?jì)鏈完整。5.3 業(yè)務(wù)合規(guī)檢查清單最后是合規(guī)。不同業(yè)務(wù)形態(tài)、不同地區(qū)的監(jiān)管要求差別很大但有幾個通用檢查項(xiàng)是繞不開的持牌經(jīng)營支付業(yè)務(wù)、放貸業(yè)務(wù)、基金銷售業(yè)務(wù)都需要相應(yīng)的金融牌照具體涉及的牌照種類在這里不展開但任何金融服務(wù)都必須先確認(rèn)資質(zhì)邊界客戶身份識別開戶流程必須采集客戶身份信息并做實(shí)名核驗(yàn)交易監(jiān)測大額和可疑交易要有監(jiān)測和上報機(jī)制數(shù)據(jù)留存交易記錄、日志、憑證至少要滿足多年的保存期限要求信息披露協(xié)議、費(fèi)率、風(fēng)險提示需要在用戶操作的關(guān)鍵路徑上明確展示投訴處理要有一套完整的售后與投訴響應(yīng)流程這些合規(guī)要求不是靠開發(fā)階段就能全部完成的應(yīng)該從第一天就納入產(chǎn)品設(shè)計(jì)。比如開戶頁面必須采集哪些字段、交易后必須給用戶推送哪些信息、日志需要保留哪些字段這些在需求評審階段就要確認(rèn)。等到產(chǎn)品做完了再補(bǔ)合規(guī)往往是傷筋動骨的改造。6. 上線前后那些事壓測、監(jiān)控與應(yīng)急預(yù)案系統(tǒng)開發(fā)完只是開始金融系統(tǒng)上線前的驗(yàn)證和上線后的運(yùn)維才是真正考驗(yàn)工程能力的環(huán)節(jié)。6.1 上線前的壓測別只測正常路徑壓測是金融系統(tǒng)上線前最重要也最容易走形式的環(huán)節(jié)。很多團(tuán)隊(duì)壓測只測正常路徑的TPS測完發(fā)現(xiàn)能扛住幾千并發(fā)就宣布性能達(dá)標(biāo)這是遠(yuǎn)遠(yuǎn)不夠的。我的壓測方案會覆蓋三類場景正常路徑模擬正常的支付、退款、查詢請求測算最大QPS和99分位耗時異常路徑模擬渠道超時、渠道報錯、批量退款、對賬任務(wù)同時跑高峰看系統(tǒng)有沒有雪崩風(fēng)險數(shù)據(jù)量積壓模擬大量待查單訂單堆積時調(diào)度系統(tǒng)能否穩(wěn)定消化積壓壓測時重點(diǎn)盯的是依賴資源的連接池水位。數(shù)據(jù)庫連接池、Redis連接池、HTTP連接池在任何一條鏈路抖動時都可能成為瓶頸。我壓測時曾經(jīng)發(fā)現(xiàn)渠道響應(yīng)變慢后HTTP連接池被占滿導(dǎo)致正常查單請求排隊(duì)連鎖反應(yīng)到對賬任務(wù)失敗。這類問題只有在異常路徑壓測中才暴露得出來。6.2 監(jiān)控指標(biāo)與告警臨界值金融系統(tǒng)的監(jiān)控必須做到三個維度全覆蓋業(yè)務(wù)狀態(tài)維度各渠道支付成功率、退款成功率、訂單平均處理時長、對賬差異筆數(shù)。這些直接反映業(yè)務(wù)健康度技術(shù)性能維度接口QPS、響應(yīng)時間、錯誤率、JVM內(nèi)存、GC時間。技術(shù)異常往往先于業(yè)務(wù)異常出現(xiàn)資金安全維度單邊賬數(shù)量、調(diào)賬筆數(shù)、退款異常、余額不平。這些指標(biāo)一旦異常必須最高優(yōu)先級告警告警不能拍腦袋設(shè)值。成功率告警我設(shè)為連續(xù)5分鐘內(nèi)低于99.5%觸發(fā)對賬差異筆數(shù)超過0且持續(xù)30分鐘未處理觸發(fā)。閾值的核心邏輯是寧可多告警也不要漏告警但告警要分級避免疲勞轟炸。高優(yōu)告警直接電話通知研發(fā)負(fù)責(zé)人中低優(yōu)先告警進(jìn)IM群。我還加了一個資金變動總量監(jiān)控單位時間內(nèi)入賬和出賬金額的波動幅超過閾值會告警這可以很快捕捉到異常交易或系統(tǒng)邏輯錯誤。6.3 資金安全的應(yīng)急預(yù)案資金系統(tǒng)必須預(yù)設(shè)應(yīng)急預(yù)案不預(yù)演等于沒有預(yù)案。我的做法是提前寫好一份故障手冊覆蓋常見場景支付渠道大規(guī)模超時、數(shù)據(jù)庫主從延遲導(dǎo)致余額不一致、對賬任務(wù)失敗、關(guān)鍵服務(wù)宕機(jī)。每個預(yù)案都寫明觸發(fā)條件、影響范圍、處理步驟、責(zé)任人和回滾方案。比如渠道超時預(yù)案第一步是立即把路由權(quán)重切到備用渠道第二步是啟動限流保護(hù)內(nèi)部系統(tǒng)第三步才是排查根因。順序?yàn)槭裁粗匾驗(yàn)楣收蠒r最先要止損止損完成后再解決問題。我還建立了一個演練機(jī)制每個季度挑一個非高峰期隨機(jī)模擬故障進(jìn)行演練讓值班人員熟悉預(yù)案執(zhí)行路徑。這個習(xí)慣救過我一次一次數(shù)據(jù)庫連接池泄漏事故因?yàn)檠菥氝^大家按預(yù)案第一時間切流量業(yè)務(wù)只中斷了4分鐘。7. 最后聊幾句我個人的體會從零搭建financial-services平臺這個項(xiàng)目我最大的收獲不是學(xué)會了幾種技術(shù)組件而是建立了資金無小事的系統(tǒng)思維。任何一個環(huán)節(jié)的疏忽都可能在某一天以賬不平、資金損失的形式爆發(fā)出來。如果只讓我分享一條核心經(jīng)驗(yàn)?zāi)蔷褪琴~戶流水不可變、操作冪等、狀態(tài)機(jī)明確、對賬自動兜底這四條做到位金融系統(tǒng)的地基就是穩(wěn)的。技術(shù)棧反而是次要的不同團(tuán)隊(duì)可以選不同的方案但設(shè)計(jì)原則是跨語言跨架構(gòu)通用的。另外給正在做類似項(xiàng)目的朋友一個建議不要把合規(guī)和安全當(dāng)作上線前才做的事。從第一行代碼開始就按生產(chǎn)環(huán)境的標(biāo)準(zhǔn)要求自己。數(shù)據(jù)該脫敏的脫敏日志該留的留權(quán)限該控的控接口該鑒權(quán)的鑒權(quán)。等到業(yè)務(wù)量上來之后再補(bǔ)這些東西成本會成倍增加。最后分享一個實(shí)操小技巧在開發(fā)環(huán)境里定時跑一版對賬任務(wù)哪怕渠道賬單用mock數(shù)據(jù)。養(yǎng)成習(xí)慣后每次改動賬務(wù)相關(guān)代碼都能立刻發(fā)現(xiàn)流水和余額是否被破壞。我們團(tuán)隊(duì)就是靠著這個習(xí)慣提前發(fā)現(xiàn)了好幾次潛在的賬務(wù)問題避免了上線后的資金事故。做金融科技小心永遠(yuǎn)不會多余。