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