如果你在金融行業(yè)待過(guò)一段時(shí)間一定對(duì)公司內(nèi)部那一大堆“歷史遺留系統(tǒng)”不陌生。賬戶開在哪套系統(tǒng)、支付走哪個(gè)通道、風(fēng)控規(guī)則配置在哪個(gè)平臺(tái)往往要翻好幾份對(duì)接文檔才能理清楚。我去年接手過(guò)一個(gè)內(nèi)部代號(hào)叫financial-services的項(xiàng)目目標(biāo)就是把這些散落在核心系統(tǒng)、渠道前置、合規(guī)平臺(tái)里的金融能力統(tǒng)一收攏到一層標(biāo)準(zhǔn)化的服務(wù)體系中再以 API 的方式對(duì)外輸出。這篇文章就圍繞這個(gè)項(xiàng)目把我在整體設(shè)計(jì)、模塊拆解、實(shí)操落地和排障過(guò)程中積累的經(jīng)驗(yàn)完整講出來(lái)希望對(duì)正在做金融系統(tǒng)改造、中臺(tái)建設(shè)或者接口服務(wù)化的同行有參考價(jià)值。financial-services這個(gè)項(xiàng)目并不是要替代核心賬務(wù)系統(tǒng)也不是簡(jiǎn)單做一個(gè) API 網(wǎng)關(guān)就完事。它的核心使命是解決“渠道接入難、邏輯重復(fù)、風(fēng)險(xiǎn)口徑不一致”這三個(gè)老問(wèn)題。適合的讀者包括金融科技團(tuán)隊(duì)的后端開發(fā)、系統(tǒng)架構(gòu)師、技術(shù)負(fù)責(zé)人還有剛接觸金融核心系統(tǒng)、想快速了解賬戶、支付、風(fēng)控是怎么協(xié)同工作的新同學(xué)。我會(huì)盡量少講空概念多給實(shí)際操作中的步驟、參數(shù)、排障手段以及那些文檔里不會(huì)寫的坑。1. 項(xiàng)目定位與整體設(shè)計(jì)思路1.1 這個(gè)項(xiàng)目到底要解決什么問(wèn)題先說(shuō)背景。我所在的項(xiàng)目組負(fù)責(zé)某金融機(jī)構(gòu)的互聯(lián)網(wǎng)渠道對(duì)接包括手機(jī)銀行、小程序、開放平臺(tái)等。過(guò)去幾年痛點(diǎn)很明顯每接入一個(gè)新渠道都要跟核心系統(tǒng)的多個(gè)模塊打交道。比如一個(gè)最簡(jiǎn)單的“余額查詢”接口在核心有一套接口在客戶信息管理系統(tǒng)又有一套查詢邏輯到了手機(jī)銀行網(wǎng)關(guān)還要再做一次字段轉(zhuǎn)換和權(quán)限校驗(yàn)。一次需求下來(lái)光聯(lián)調(diào)就要三五天而且經(jīng)常出現(xiàn)不同渠道查出來(lái)的客戶等級(jí)、賬戶狀態(tài)不一致。所以決定啟動(dòng)financial-services項(xiàng)目時(shí)我們定了一個(gè)很樸素的出發(fā)點(diǎn)把能夠標(biāo)準(zhǔn)化的金融能力沉淀下來(lái)讓業(yè)務(wù)方只認(rèn)一套接口、一套數(shù)據(jù)定義、一套錯(cuò)誤碼。這樣不管上游是手機(jī)銀行、柜面還是開放平臺(tái)底層都是走同樣的賬戶服務(wù)、支付服務(wù)和風(fēng)控服務(wù)。新渠道接入的時(shí)間從按周計(jì)算壓縮到按天計(jì)算同時(shí)減少因重復(fù)開發(fā)帶來(lái)的邏輯漂移。這個(gè)項(xiàng)目不是從零開始寫一套銀行核心那是核心系統(tǒng)廠商的事。我們要做的是在核心能力之上建一層服務(wù)化封裝屬于典型的“架構(gòu)防腐層”。你可以把它理解成公司內(nèi)部的 API 服務(wù)層但它比普通 API 網(wǎng)關(guān)多做了幾件重要的事統(tǒng)一客戶視圖、統(tǒng)一賬務(wù)入口、統(tǒng)一風(fēng)控評(píng)估、統(tǒng)一合規(guī)審計(jì)。這也是金融服務(wù)業(yè)和普通互聯(lián)網(wǎng)業(yè)務(wù)最大的區(qū)別不能光為了快還要保證每條鏈路都能說(shuō)清楚“誰(shuí)在什么時(shí)間通過(guò)什么接口做了什么操作”。1.2 為什么不能繼續(xù)“加一層就完事”很多團(tuán)隊(duì)遇到這類問(wèn)題第一反應(yīng)是先買個(gè)網(wǎng)關(guān)把現(xiàn)有接口轉(zhuǎn)發(fā)一下。我承認(rèn)網(wǎng)關(guān)很重要但只做轉(zhuǎn)發(fā)解決不了根本問(wèn)題。金融服務(wù)的痛點(diǎn)往往不在于接口不夠多而在于同樣的金融動(dòng)作被重復(fù)實(shí)現(xiàn)。比如“開戶”直銷銀行做一遍理財(cái)子公司再做一遍券商接口通過(guò)另一套邏輯轉(zhuǎn)發(fā)。每套實(shí)現(xiàn)都可能有自己的校驗(yàn)規(guī)則、客戶分類邏輯、風(fēng)險(xiǎn)等級(jí)判斷業(yè)務(wù)方只能容忍但一到監(jiān)管檢查或者審計(jì)回溯時(shí)就會(huì)發(fā)現(xiàn)不同系統(tǒng)口徑對(duì)不上。所以在financial-services項(xiàng)目里我們堅(jiān)持先做“業(yè)務(wù)梳理”再做“服務(wù)設(shè)計(jì)”。業(yè)務(wù)梳理就是逐條確認(rèn)哪些是基礎(chǔ)能力哪些是流程編排。基礎(chǔ)能力必須收斂比如查詢客戶、查詢賬戶、凍結(jié)/解凍、轉(zhuǎn)賬、交易流水查詢。流程編排可以留在上層比如開戶流程、購(gòu)買理財(cái)流程、貸款申請(qǐng)流程。這樣一個(gè)訂單服務(wù)可以調(diào)用客戶服務(wù)、賬戶服務(wù)、支付服務(wù)、風(fēng)控服務(wù)但不需要自己重新建一套賬戶余額表。服務(wù)層是“原子能力的封裝”流程層是“業(yè)務(wù)場(chǎng)景的編排”這個(gè)邊界一旦清晰后面的架構(gòu)就不會(huì)亂。另一個(gè)關(guān)鍵點(diǎn)是金融項(xiàng)目必須考慮“變更影響面”。如果每接一個(gè)新渠道都直接改核心系統(tǒng)的接口風(fēng)險(xiǎn)極大。因?yàn)楹诵南到y(tǒng)承擔(dān)著賬務(wù)正確性一旦參數(shù)理解偏了輕則接口報(bào)錯(cuò)重則賬務(wù)不一致。我們通過(guò)financial-services服務(wù)層屏蔽底層差異核心系統(tǒng)只需要對(duì)這些標(biāo)準(zhǔn)化服務(wù)提供支撐新渠道不再直接觸達(dá)核心數(shù)據(jù)庫(kù)。這相當(dāng)于給核心系統(tǒng)裝了一道保險(xiǎn)閥既保留了核心的穩(wěn)定又讓上面的業(yè)務(wù)可以快速迭代。1.3 設(shè)計(jì)原則合規(guī)、穩(wěn)定、可回溯金融行業(yè)做技術(shù)方案第一原則常被寫成“安全合規(guī)”但落到代碼層面最實(shí)際的是要回答三個(gè)問(wèn)題數(shù)據(jù)能不能被越權(quán)讀取操作是否留下完整記錄風(fēng)險(xiǎn)事件是否能快速定位和阻斷因此這個(gè)項(xiàng)目從一開始就不是單純按照后端開發(fā)的思路來(lái)設(shè)計(jì)而是把合規(guī)要求擺在功能需求前面。我整理下來(lái)的三個(gè)核心設(shè)計(jì)原則合規(guī)先行客戶敏感信息手機(jī)號(hào)、證件號(hào)、住址在設(shè)計(jì)上做字段級(jí)權(quán)限控制服務(wù)接口不能一次返回所有客戶信息必須按場(chǎng)景選擇最小必要字段。穩(wěn)定優(yōu)先服務(wù)對(duì)下游的失敗要“快速失敗、明確提示”不能讓調(diào)用方猜。超時(shí)時(shí)間和重試策略必須成體系不能各服務(wù)自己拍腦袋。全鏈路可回溯每個(gè)業(yè)務(wù)動(dòng)作要求生成唯一請(qǐng)求流水號(hào)日志中要能串聯(lián)“外部請(qǐng)求號(hào)—服務(wù)內(nèi)部流水號(hào)—核心系統(tǒng)賬務(wù)流水號(hào)”。這三條原則聽起來(lái)像廢話但真正執(zhí)行起來(lái)會(huì)直接影響整個(gè)技術(shù)架構(gòu)。比如為了“可回溯”我們嚴(yán)格要求核心服務(wù)在入口處就生成txn_id并且寫入統(tǒng)一的日志標(biāo)準(zhǔn)結(jié)構(gòu)。為了“合規(guī)”我們不能讓網(wǎng)關(guān)無(wú)腦透?jìng)髡?qǐng)求必須在網(wǎng)關(guān)層識(shí)別接口類型再根據(jù)接口級(jí)別做脫敏和權(quán)限校驗(yàn)。這些都要在前期定好否則后期補(bǔ)起來(lái)成本極高。2. 核心模塊拆解與技術(shù)選型2.1 客戶與賬戶中心所有服務(wù)的起點(diǎn)financial-services的服務(wù)層里客戶與賬戶中心是負(fù)載最高的模塊。手機(jī)銀行查余額、第三方渠道做鑒權(quán)、理財(cái)平臺(tái)算資產(chǎn)都必須從這里拿數(shù)據(jù)。我們并沒有重新設(shè)計(jì)一套復(fù)雜的“客戶主數(shù)據(jù)系統(tǒng)”而是在現(xiàn)有客戶信息系統(tǒng)上做了一層標(biāo)準(zhǔn)服務(wù)先統(tǒng)一接口再逐步反哺數(shù)據(jù)質(zhì)量。實(shí)際拆解時(shí)客戶與賬戶中心包含三個(gè)子能力客戶統(tǒng)一視圖把不同系統(tǒng)中的客戶號(hào)映射到同一個(gè)全局客戶 ID合并同一客戶在直銷銀行、理財(cái)、渠道端的碎片記錄。賬戶生命周期管理開戶、銷戶、凍結(jié)、解凍、止付等操作收斂成標(biāo)準(zhǔn)服務(wù)每個(gè)操作都要求傳入業(yè)務(wù)場(chǎng)景碼和操作員標(biāo)識(shí)。余額與動(dòng)賬查詢不直接允許上游查數(shù)據(jù)庫(kù)表而是通過(guò)帶權(quán)限校驗(yàn)的查詢接口返回結(jié)果避免把底層賬務(wù)結(jié)構(gòu)暴露出去。這里有一個(gè)容易被忽略的設(shè)計(jì)點(diǎn)賬戶余額查詢接口的返回字段不要一股腦把所有余額類型都拋給調(diào)用方。比如手機(jī)銀行只需要“可用余額”但理財(cái)系統(tǒng)還需要“凍結(jié)余額”“在途金額”如果接口同時(shí)返回調(diào)用方容易用錯(cuò)字段。我們?cè)诜?wù)接口上做字段版本控制每個(gè)消費(fèi)方申請(qǐng)接口時(shí)必須明確需要的字段清單。這么做看似增加對(duì)接成本實(shí)際能減少大量線上數(shù)據(jù)誤用問(wèn)題。技術(shù)選型上客戶與賬戶中心我們沒有引入特別重的微服務(wù)框架而是用了常規(guī)的 Spring Boot 服務(wù) Redis 緩存 數(shù)據(jù)庫(kù)分表。核心賬務(wù)仍然在銀行核心系統(tǒng)服務(wù)層只承擔(dān)“查詢聚合”和“操作轉(zhuǎn)發(fā)”。緩存主要用來(lái)緩解核心系統(tǒng)壓力但余額數(shù)據(jù)緩存不能設(shè)置太長(zhǎng)過(guò)期時(shí)間一般不超過(guò) 60 秒并且要帶上版本號(hào)防止并發(fā)更新導(dǎo)致緩存回填舊數(shù)據(jù)。2.2 支付與清算通道鏈路最長(zhǎng)的一環(huán)支付模塊是整個(gè)financial-services項(xiàng)目里最復(fù)雜的一塊因?yàn)樯婕巴獠壳?、資金渠道和內(nèi)部賬務(wù)系統(tǒng)三方聯(lián)動(dòng)。簡(jiǎn)單說(shuō)一個(gè)用戶在商戶App 上發(fā)起支付請(qǐng)求先到我們的統(tǒng)一支付服務(wù)再由支付服務(wù)選擇合適的渠道比如某家銀行快捷支付、某第三方支付、某清算組織通道完成扣款最后結(jié)果異步回調(diào)給商戶。這里最需要花力氣的是“支付路由”和“對(duì)賬”。支付路由不是簡(jiǎn)單輪詢渠道而是要綜合看幾個(gè)維度的參數(shù)渠道優(yōu)先級(jí)、單筆限額、當(dāng)前成功率、渠道維護(hù)時(shí)間窗、商戶指定的通道偏好。我們把這套路由策略做成可配置的規(guī)則表核心字段包括channel_code、weight、limit_amount、start_time、end_time、status。每次支付請(qǐng)求進(jìn)來(lái)路由引擎先加載啟用的渠道列表再按權(quán)重和限額篩選最后做一次實(shí)時(shí)健康度探測(cè)避免把流量打到已經(jīng)故障的渠道上。渠道健康度探測(cè)我建議不要依靠被動(dòng)超時(shí)要在支付路由前加一個(gè)主動(dòng)探測(cè)接口。比如每 10 秒探測(cè)一次渠道網(wǎng)關(guān)的連通性探測(cè)失敗就把渠道臨時(shí)摘除。實(shí)際金融支付場(chǎng)景中第三方渠道偶爾會(huì)有 30 秒以上的抖動(dòng)如果不做摘除網(wǎng)關(guān)超時(shí)和用戶投訴會(huì)讓你焦頭爛額。支付鏈路的對(duì)賬更是金融項(xiàng)目的生命線。我們內(nèi)部強(qiáng)制要求渠道賬單、內(nèi)部支付流水、核心賬務(wù)流水三邊對(duì)平。每日凌晨跑批先以渠道提供的賬單文件為準(zhǔn)將渠道流水與內(nèi)部支付流水做比對(duì)找出“渠道有、內(nèi)部無(wú)”“內(nèi)部有、渠道無(wú)”“金額不一致”三類差異。對(duì)賬的結(jié)果會(huì)生成待處理任務(wù)異常單必須有人工復(fù)核閉環(huán)不能只出個(gè)報(bào)表就完事。因?yàn)橹灰幸还P錯(cuò)賬沒發(fā)現(xiàn)月底結(jié)算時(shí)就會(huì)變成審計(jì)問(wèn)題。2.3 風(fēng)控與合規(guī)引擎金融項(xiàng)目的“守門員”在金融服務(wù)業(yè)里業(yè)務(wù)代碼寫得再好風(fēng)控缺失也可能一夜回到解放前。financial-services項(xiàng)目里風(fēng)控不是單點(diǎn)服務(wù)而是“嵌入鏈路”的引擎。開戶、登錄、支付、修改關(guān)鍵信息等關(guān)鍵動(dòng)作都必須調(diào)用風(fēng)控服務(wù)做實(shí)時(shí)評(píng)估。我們的風(fēng)控引擎主體分為三層規(guī)則層支持可視化配置的規(guī)則比如“單筆金額超過(guò) 5 萬(wàn)且設(shè)備指紋為新設(shè)備則進(jìn)入人工審核”。模型層基于歷史黑樣本訓(xùn)練的評(píng)分模型輸出風(fēng)險(xiǎn)分?jǐn)?shù) 0-100。名單層對(duì)接反洗錢名單、內(nèi)部黑名單、渠道黑名單命中即阻斷或轉(zhuǎn)人工。規(guī)則層我特別推薦把“優(yōu)先級(jí)”和“獨(dú)立生效”設(shè)計(jì)好。業(yè)務(wù)人員經(jīng)常會(huì)說(shuō)“幫我加一條規(guī)則”結(jié)果規(guī)則越來(lái)越多優(yōu)先級(jí)亂掉最后風(fēng)控平臺(tái)自己都不知道哪條生效。所以在結(jié)構(gòu)上我們給每條規(guī)則配置rule_code、priority、action放行/阻斷/人工審核、expire_time。同時(shí)支持規(guī)則版本快照每次調(diào)用的風(fēng)控結(jié)果都會(huì)記錄對(duì)應(yīng)規(guī)則版本這樣復(fù)盤誤殺時(shí)能清楚知道是哪個(gè)版本規(guī)則導(dǎo)致的。為了兼顧用戶體驗(yàn)風(fēng)控引擎還要支持“漸進(jìn)式驗(yàn)證”。普通小額、低風(fēng)險(xiǎn)操作走輕量級(jí)校驗(yàn)即可大額、異常場(chǎng)景再要求短信驗(yàn)證碼、人臉識(shí)別或人工回訪。這樣可以避免一棍子打死所有用戶也能把風(fēng)險(xiǎn)控制在可接受范圍。這個(gè)思路在金融服務(wù)業(yè)非常重要畢竟安全和體驗(yàn)不是互斥的而是靠分層策略來(lái)平衡。3. 實(shí)操過(guò)程從服務(wù)契約到網(wǎng)關(guān)落地3.1 服務(wù)契約先于代碼financial-services項(xiàng)目推進(jìn)過(guò)程中我吃過(guò)一次大虧有一個(gè)新加入的團(tuán)隊(duì)因?yàn)橼s進(jìn)度在接口文檔還沒定的情況下先寫實(shí)現(xiàn)結(jié)果實(shí)現(xiàn)完了發(fā)現(xiàn)另一邊的字段定義完全不同強(qiáng)行聯(lián)調(diào)導(dǎo)致雙方都改了一大堆代碼還引入了潛在的數(shù)據(jù)錯(cuò)亂風(fēng)險(xiǎn)。從那以后我們嚴(yán)格執(zhí)行“契約先行”先定義 OpenAPI 3.0 文檔再寫代碼。服務(wù)契約里除了日常的路徑、參數(shù)、返回結(jié)構(gòu)還必須包含三塊內(nèi)容錯(cuò)誤碼定義不能只返回 HTTP 500必須細(xì)分業(yè)務(wù)錯(cuò)誤碼比如ACCOUNT_FROZEN、BALANCE_NOT_ENOUGH、CUSTOMER_NOT_EXIST。調(diào)用方需要能根據(jù)錯(cuò)誤碼做對(duì)應(yīng)的業(yè)務(wù)分支。冪等策略說(shuō)明每個(gè)接口文檔都要標(biāo)注“是否冪等”“冪等鍵是什么”。例如“資金凍結(jié)”接口必須支持冪等冪等鍵用請(qǐng)求方標(biāo)識(shí)業(yè)務(wù)單號(hào)。限流與配額文檔不能只寫“請(qǐng)謹(jǐn)慎調(diào)用”最好給出明確的默認(rèn)配額和閾值比如“單商戶單日回調(diào)最大次數(shù) 10000 次”。契約文檔的管理也是個(gè)細(xì)節(jié)。我們放在 Git 倉(cāng)庫(kù)每次變更走 MR 評(píng)審接口版本通過(guò) URL 或 header 標(biāo)識(shí)比如“/v1/accounts”和“/v2/accounts”并存。這樣老應(yīng)用不受影響新應(yīng)用逐漸遷移。金融行業(yè)里接口不能“說(shuō)變就變”兼容性比新功能更重要。3.2 統(tǒng)一身份認(rèn)證與權(quán)限模型financial-services面臨的應(yīng)用方很多一部分是內(nèi)部系統(tǒng)一部分是外部合作方。如果每個(gè)應(yīng)用都直接跟核心系統(tǒng)建立獨(dú)立的認(rèn)證方式那基本等于沒有統(tǒng)一安全邊界。我們?cè)O(shè)計(jì)了一套統(tǒng)一身份認(rèn)證模型核心包括應(yīng)用身份每個(gè)接入方發(fā)一個(gè)app_id和密鑰外部應(yīng)用通過(guò) mTLS 或簽名機(jī)制調(diào)用接口。用戶身份面向 C 端操作時(shí)用 OAuth2 token 或業(yè)務(wù)票據(jù)傳遞用戶身份服務(wù)層校驗(yàn)該用戶對(duì)當(dāng)前賬戶是否有操作權(quán)限。訪問(wèn)控制在 API 網(wǎng)關(guān)注冊(cè)每類接口的訪問(wèn)權(quán)限分配“可讀”“可寫”“可執(zhí)行”三級(jí)權(quán)限不再讓核心系統(tǒng)自己判斷能做什么。權(quán)限模型的另一個(gè)重點(diǎn)是“數(shù)據(jù)權(quán)限”。比如代理記賬公司接入后只能查詢自己名下客戶的賬戶信息不能通過(guò)傳參拿到其他人數(shù)據(jù)。我們?cè)诜?wù)層強(qiáng)制解析customer_id與app_id的綁定關(guān)系如果請(qǐng)求嘗試訪問(wèn)非授權(quán)客戶數(shù)據(jù)直接拒絕。這一條實(shí)際處理不好會(huì)出大問(wèn)題因?yàn)楹芏鄡?nèi)部系統(tǒng)默認(rèn)“信任”結(jié)果上線后被外部合作方測(cè)出水平越權(quán)漏洞非常被動(dòng)。建議大家在自測(cè)時(shí)專門寫一個(gè)越權(quán)用例用 A 用戶的 token 嘗試查 B 用戶的賬戶。如果接口返回 200那權(quán)限模型有問(wèn)題必須把校驗(yàn)邏輯前移到網(wǎng)關(guān)或服務(wù)入口。這個(gè)測(cè)試應(yīng)該納入 CI/CD 回歸用例不能只在開發(fā)階段手工測(cè)一次。3.3 冪等、重試與分布式事務(wù)金融服務(wù)接口和普通 CRUD 接口最大的不同是很多操作都涉及資金狀態(tài)變化。網(wǎng)絡(luò)超時(shí)后調(diào)用方往往會(huì)重試如果服務(wù)端沒有冪等保護(hù)就可能重復(fù)扣款或者重復(fù)凍結(jié)。這是線上事故最常見的來(lái)源之一。我在financial-services項(xiàng)目里把冪等保護(hù)做成了一個(gè)通用組件所有寫操作必須走這個(gè)組件。實(shí)現(xiàn)方式不復(fù)雜每次請(qǐng)求進(jìn)入服務(wù)時(shí)先用冪等鍵查 Redis 或數(shù)據(jù)庫(kù)如果存在則直接返回上一次的處理結(jié)果如果不存在則搶占一個(gè)冪等記錄然后執(zhí)行真正的業(yè)務(wù)邏輯。關(guān)鍵參數(shù)包括冪等鍵、請(qǐng)求摘要、首次請(qǐng)求時(shí)間、處理狀態(tài)處理中/成功/失敗。一個(gè)典型配置Keyidempotent:{app_id}:{biz_type}:{biz_txn_no}過(guò)期時(shí)間24 小時(shí)避免太長(zhǎng)造成存儲(chǔ)膨脹請(qǐng)求摘要對(duì)請(qǐng)求關(guān)鍵字段做 MD5防止同一交易號(hào)但請(qǐng)求內(nèi)容不同被誤吞分布式事務(wù)方面金融鏈路涉及多系統(tǒng)但我們沒有引入重量級(jí)分布式事務(wù)框架而是采用更穩(wěn)妥的“本地消息表 對(duì)賬補(bǔ)償”方案。比如支付成功后需要更新賬戶余額、記賬、發(fā)送通知。我們先把支付結(jié)果寫入本地消息表再異步通知下游。如果下游處理失敗定時(shí)任務(wù)會(huì)重新推送直到成功或者進(jìn)入人工處理列表。這樣做的代價(jià)是最終一致會(huì)有幾秒延遲但換來(lái)的是系統(tǒng)穩(wěn)定性金融場(chǎng)景下我寧可接受幾秒延遲也不希望因?yàn)閺?qiáng)事務(wù)鎖導(dǎo)致大面積超時(shí)。需要強(qiáng)調(diào)的是冪等和事務(wù)方案不能靠臨時(shí)拍腦袋必須提前在設(shè)計(jì)文檔里明確。有多少寫接口要支持重試重試的退避策略是什么什么情況下允許人工沖正這些問(wèn)題如果等線上出事再想就晚了。4. 常見問(wèn)題與排查技巧實(shí)錄4.1 對(duì)賬不平先不要急著改賬有一次渠道對(duì)賬跑出來(lái)差了 12 筆財(cái)務(wù)同事很緊張第一反應(yīng)是“能不能把內(nèi)部流水改成和渠道一致”。我攔住他們因?yàn)閷?duì)賬不平的原因有很多盲目改賬可能把正確賬改錯(cuò)。正確做法是先把差異單打出來(lái)按異常類型分類。我們的排查步驟先看渠道側(cè)是否存在“支付成功但回調(diào)失敗”的情況。因?yàn)榍蕾~單會(huì)記錄扣款成功但我們的支付服務(wù)可能沒收到回調(diào)導(dǎo)致內(nèi)部狀態(tài)還是支付中。再查是否存在“內(nèi)部重復(fù)回調(diào)”導(dǎo)致二次通知。網(wǎng)關(guān)側(cè)重復(fù)推送時(shí)如果業(yè)務(wù)處理沒有做冪等可能產(chǎn)生兩條已支付記錄。最后查金額字段的精度差異。如果渠道賬單金額以元為單位內(nèi)部流水以分為單位轉(zhuǎn)換失誤會(huì)造成差幾塊錢的固定差異。對(duì)賬不平先分類再處理。大部分情況下“渠道有、內(nèi)部無(wú)”只需要補(bǔ)記狀態(tài)而“內(nèi)部有、渠道無(wú)”可能要發(fā)起渠道查詢確認(rèn)是否真實(shí)扣款必要時(shí)觸發(fā)退款。切忌直接把缺失的內(nèi)部流水補(bǔ)上去因?yàn)槟强赡苎谏w真實(shí)的資金風(fēng)險(xiǎn)。4.2 接口超時(shí)到底是誰(shuí)慢了接口超時(shí)是最難排查的問(wèn)題之一因?yàn)楸硐笫钦{(diào)用方報(bào)錯(cuò)但根因可能在下游。我們處理過(guò)好幾次類似情況上游反饋“賬戶服務(wù)超時(shí)”但賬戶服務(wù)監(jiān)控指標(biāo)顯示平均耗時(shí)正常。后來(lái)我們把排查手段標(biāo)準(zhǔn)化打開鏈路追蹤查看一次完整請(qǐng)求的調(diào)用樹是網(wǎng)關(guān)耗時(shí)高、客戶中心耗時(shí)高還是核心系統(tǒng)接口耗時(shí)高。如果網(wǎng)關(guān)耗時(shí)高先看是否觸發(fā)了限流或熔斷。網(wǎng)關(guān)默認(rèn)線程池打滿時(shí)請(qǐng)求會(huì)排隊(duì)表現(xiàn)就是超時(shí)。這時(shí)候增加機(jī)器不是根本解法要分析是否有異常流量、是否有慢 SQL 拖垮了線程池。如果客戶中心耗時(shí)高重點(diǎn)看 Redis 緩存是否失效大量請(qǐng)求同時(shí)穿透到數(shù)據(jù)庫(kù)很容易把數(shù)據(jù)庫(kù)連接池打滿。我們有一次就是因?yàn)榫彺?key 過(guò)期時(shí)間設(shè)置成全 5 分鐘導(dǎo)致整點(diǎn)讀數(shù)據(jù)庫(kù)壓力陡增。另外金融接口超時(shí)參數(shù)要區(qū)分“業(yè)務(wù)超時(shí)”和“網(wǎng)絡(luò)超時(shí)”。連接超時(shí)建議短一些3 到 5 秒讀取超時(shí)則要根據(jù)業(yè)務(wù)復(fù)雜度設(shè)置比如簡(jiǎn)單查詢 5 秒涉及人工審核的異步場(chǎng)景要單獨(dú)處理不能把一個(gè)異步流程掛在同步超時(shí)參數(shù)上。這點(diǎn)新手容易混結(jié)果把所有接口統(tǒng)一設(shè)置 30 秒超時(shí)下游掛掉后上游線程被占用 30 秒導(dǎo)致雪崩。我的建議是每個(gè)關(guān)鍵服務(wù)都要壓測(cè)出“基線耗時(shí) P99”并根據(jù)基線設(shè)置超時(shí)而不是憑感覺填一個(gè)數(shù)字。4.3 風(fēng)控誤殺先看特征回溯上線之后最常被業(yè)務(wù)部門吐槽的就是“怎么客戶又被攔截了”。有一次運(yùn)營(yíng)反饋一位正常充值用戶被風(fēng)控阻斷原因是觸發(fā)了“新設(shè)備”、“凌晨 2 點(diǎn)”、“金額接近 5 萬(wàn)”的組合規(guī)則。排查這類問(wèn)題不要直接關(guān)規(guī)則而要回看風(fēng)控結(jié)果信息和規(guī)則版本。我們的風(fēng)控服務(wù)會(huì)記錄每一個(gè)決策因子包括設(shè)備指紋、IP 歸屬地、歷史行為、規(guī)則命中代碼。對(duì)著參數(shù)逐項(xiàng)看定位到具體是哪個(gè)規(guī)則閾值設(shè)置不合理。那次我們發(fā)現(xiàn)問(wèn)題出在設(shè)備指紋庫(kù)更新滯后用戶換了一部新手機(jī)但登錄行為正常風(fēng)控卻因?yàn)椤靶略O(shè)備”這個(gè)單因子直接命中高風(fēng)險(xiǎn)。處理方式是把規(guī)則層的決策邏輯從“單因子強(qiáng)硬阻斷”改成“多因子綜合評(píng)分”并加入“歷史正常交易記錄”的加權(quán)。也就是說(shuō)一次可疑特征不足以直接拒絕只有多個(gè)風(fēng)險(xiǎn)信號(hào)疊加時(shí)才進(jìn)入人工審核或阻斷。風(fēng)控策略調(diào)整后要記錄生效時(shí)間和生效版本方便后期對(duì)誤殺率、資損率做復(fù)盤。別怕調(diào)整閾值帶來(lái)短期風(fēng)險(xiǎn)上升關(guān)鍵是建立監(jiān)控看板次日上午就能看到變化趨勢(shì)。4.4 審計(jì)缺料日志和配置項(xiàng)同樣重要金融項(xiàng)目做到后期審計(jì)檢查是躲不開的。有一次外部審計(jì)要求提供某個(gè)客戶在某段時(shí)間內(nèi)的所有訪問(wèn)記錄我們差點(diǎn)因?yàn)槿罩静煌暾鴮懖怀龃饛?fù)。問(wèn)題出在兩個(gè)地方一是部分服務(wù)只打了業(yè)務(wù)日志沒有打?qū)徲?jì)日志二是日志內(nèi)容里缺少關(guān)鍵操作人、來(lái)源 IP、操作結(jié)果。從那以后我們把審計(jì)日志要求固化到開發(fā)規(guī)范里。任何對(duì)敏感數(shù)據(jù)和關(guān)鍵業(yè)務(wù)操作的訪問(wèn)必須記錄五個(gè)字段操作賬號(hào)、客戶 ID、操作類型、操作時(shí)間、請(qǐng)求流水號(hào)。同時(shí)接口入?yún)⒅械拿艽a、CVN、完整證件號(hào)等敏感字段絕不落日志在網(wǎng)關(guān)層就做脫敏。如果日志和配置項(xiàng)做不到一一對(duì)應(yīng)審計(jì)時(shí)你要解釋“為什么這個(gè)操作沒有記錄”這是非常被動(dòng)的事情。配置管理也要納入審計(jì)。比如風(fēng)控規(guī)則被誰(shuí)改過(guò)、路由渠道權(quán)重被誰(shuí)調(diào)過(guò)系統(tǒng)都需要有操作痕跡。我們直接將配置變更寫入獨(dú)立的審計(jì)日志表與業(yè)務(wù)日志分離。這樣審計(jì)來(lái)查的時(shí)候能從配置維度快速篩選出可能影響資金的變更記錄而不是翻一堆分散的日志文件。5. 金融服務(wù)業(yè)項(xiàng)目的幾條硬經(jīng)驗(yàn)5.1 網(wǎng)關(guān)不是業(yè)務(wù)垃圾桶financial-services項(xiàng)目早期因?yàn)榫W(wǎng)關(guān)用起來(lái)方便大家都想把校驗(yàn)邏輯、轉(zhuǎn)換邏輯、甚至一部分業(yè)務(wù)邏輯塞進(jìn)網(wǎng)關(guān)。等到后期網(wǎng)關(guān)變成一個(gè)大泥球每次上線都要提心吊膽因?yàn)楦膭?dòng)可能影響所有接入方。后來(lái)我們規(guī)定網(wǎng)關(guān)只能做合法合規(guī)的通用事項(xiàng)包括身份認(rèn)證、路由轉(zhuǎn)發(fā)、限流熔斷、日志審計(jì)、敏感字段脫敏。任何跟具體業(yè)務(wù)場(chǎng)景相關(guān)的判斷比如“提現(xiàn)金額不能超過(guò)可提現(xiàn)余額”“理財(cái)產(chǎn)品贖回份額校驗(yàn)”必須下沉到對(duì)應(yīng)的服務(wù)里。每開發(fā)一個(gè)新接口先問(wèn)一句這段邏輯如果放在網(wǎng)關(guān)其他接口會(huì)不會(huì)受影響如果會(huì)就不要放。有人覺得網(wǎng)關(guān)放點(diǎn)業(yè)務(wù)邏輯效率高但這會(huì)讓團(tuán)隊(duì)丟失關(guān)鍵的業(yè)務(wù)邊界。金融系統(tǒng)的長(zhǎng)期維護(hù)靠的是邊界清晰不是局部的小聰明。5.2 測(cè)試用例必須包含臟數(shù)據(jù)和異常時(shí)序普通業(yè)務(wù)系統(tǒng)測(cè)試主要是正常路徑和少量分支金融項(xiàng)目必須把異常時(shí)序當(dāng)成一等公民。比如“凍結(jié)”“解凍”“支付”三個(gè)操作并發(fā)執(zhí)行結(jié)果會(huì)不會(huì)出現(xiàn)“支付已成功但賬戶狀態(tài)仍處于凍結(jié)”再比如“回調(diào)重復(fù)推送”和“訂單關(guān)閉”兩個(gè)動(dòng)作同時(shí)發(fā)生會(huì)不會(huì)出現(xiàn)關(guān)閉后還能入賬我建議針對(duì)核心服務(wù)做一張異常時(shí)序測(cè)試矩陣常見場(chǎng)景包括重復(fù)請(qǐng)求、亂序請(qǐng)求、請(qǐng)求中途下游超時(shí)、渠道回調(diào)延遲、異步任務(wù)重復(fù)執(zhí)行。測(cè)試數(shù)據(jù)也要包含臟數(shù)據(jù)比如賬號(hào)格式非法、金額為 0、金額為負(fù)、小數(shù)位數(shù)超過(guò) 2 位、客戶號(hào)不存在。這些用例可能在開發(fā)階段看起來(lái)“不可能發(fā)生”但上線后都會(huì)遇到。一個(gè)可行的做法是引入基于故障注入的聯(lián)調(diào)環(huán)境在測(cè)試環(huán)境故意讓某個(gè)下游服務(wù)返回 500 或延遲 10 秒看看依賴方表現(xiàn)如何。金融系統(tǒng)的健壯性不是靠代碼 review 看出來(lái)的而是靠把這些場(chǎng)景反復(fù)壓出來(lái)的。5.3 業(yè)務(wù)口徑要和技術(shù)口徑共同維護(hù)我踩過(guò)最深的坑是業(yè)務(wù)部門說(shuō)的“余額”和技術(shù)系統(tǒng)里的“余額”不是同一個(gè)東西。業(yè)務(wù)說(shuō)的余額可能包含“實(shí)時(shí)余額在途資金”技術(shù)上的余額則只指“賬務(wù)余額”。如果接口文檔不做說(shuō)明開發(fā)容易拿錯(cuò)字段產(chǎn)品也容易誤解數(shù)據(jù)。因此financial-services項(xiàng)目里我們專門維護(hù)了一份“業(yè)務(wù)術(shù)語(yǔ)與技術(shù)字段映射表”把每個(gè)術(shù)語(yǔ)的適用范圍、計(jì)算邏輯、排除項(xiàng)全部列清楚。比如“可用余額 賬戶總余額 - 凍結(jié)余額 - 在途凍結(jié)金額”。每次接口上線前產(chǎn)品、開發(fā)、測(cè)試必須過(guò)一遍這條字段定義確認(rèn)理解一致。這個(gè)動(dòng)作雖然枯燥但能省掉后續(xù)大量扯皮和數(shù)據(jù)誤用返工。我再給一個(gè)細(xì)節(jié)建議接口文檔里的字段注釋不要只寫“余額”要寫清楚“賬戶當(dāng)前可用余額單位分不包含凍結(jié)和在途金額”。字段注釋越具體對(duì)接方犯錯(cuò)的概率越低。金融項(xiàng)目溝通成本高很多時(shí)候都是因?yàn)橐粋€(gè)字段注釋寫得太偷懶結(jié)果雙方各自理解上線后數(shù)據(jù)對(duì)不上。最后分享一個(gè)小體會(huì)做financial-services這類項(xiàng)目不要追求“一次性做到完美”。金融系統(tǒng)永遠(yuǎn)會(huì)有歷史包袱、口徑?jīng)_突和不可控的外部依賴。我們更應(yīng)該做的是先把標(biāo)準(zhǔn)服務(wù)邊界劃清再把可觀測(cè)和審計(jì)能力補(bǔ)齊然后讓業(yè)務(wù)在上面快速迭代。每一步都走得穩(wěn)比單純追求速度更符合金融服務(wù)的本質(zhì)。