前陣子一直在忙一個代號叫 financial-services 內(nèi)部項目的重構(gòu)這個項目說白了就是一套面向金融服務(wù)場景的通用數(shù)字化服務(wù)平臺。不是那種給人一種高深莫測感覺的量化交易系統(tǒng)也不涉及任何復(fù)雜金融模型它更像是一套“運(yùn)營中臺”——負(fù)責(zé)把分散在不同業(yè)務(wù)方的行情數(shù)據(jù)、用戶行為數(shù)據(jù)、賬務(wù)流水?dāng)?shù)據(jù)統(tǒng)一收進(jìn)來清洗、計算、存儲再通過規(guī)則引擎和接口服務(wù)輸出給前端展示、風(fēng)險識別和業(yè)務(wù)決策使用。我之所以想把這次實踐經(jīng)驗完整寫出來是因為這個項目踩了不少坑也沉淀了一些通用方法論。不管你是做后端開發(fā)、數(shù)據(jù)工程還是剛到金融類公司做技術(shù)平臺多多少少都能從中找到一些參考。尤其是一些架構(gòu)選型的取舍、實時指標(biāo)計算的細(xì)節(jié)以及生產(chǎn)環(huán)境里常見的臟數(shù)據(jù)和延遲問題這些都不是參考文檔能告訴你的。如果你正準(zhǔn)備搭一套類似的內(nèi)部數(shù)據(jù)服務(wù)平臺那這篇文章應(yīng)該能幫你少走幾條彎路。1. 項目背景與整體設(shè)計思路1.1 這個項目到底要解決什么問題先說背景。業(yè)務(wù)側(cè)有多個渠道包括移動端、網(wǎng)頁端、合作方接口都會產(chǎn)生大量的服務(wù)數(shù)據(jù)。過去這些數(shù)據(jù)各自為政業(yè)務(wù)A關(guān)心交易量業(yè)務(wù)B關(guān)心用戶活躍度業(yè)務(wù)C關(guān)心異常波動每個團(tuán)隊各自拉數(shù)據(jù)、各自建表、各自開發(fā)報表最后口徑對不上指標(biāo)算出來的結(jié)果經(jīng)常相差百分之二三十領(lǐng)導(dǎo)問起來誰也說不太清楚。financial-services 這個項目最初的目標(biāo)非常樸素把數(shù)據(jù)統(tǒng)一收口建立一個穩(wěn)定的指標(biāo)計算平臺。但做著做著發(fā)現(xiàn)光“統(tǒng)一收口”還不夠因為業(yè)務(wù)方對實時性的要求越來越高。以前跑T1的離線報表還行現(xiàn)在業(yè)務(wù)方希望一個活動上線后能實時看到用戶參與情況、交易成功率、異常波動預(yù)警。這就把項目的技術(shù)重心從“批量處理”推向了“實時/準(zhǔn)實時計算”。所以最終這個項目的核心定位是三塊數(shù)據(jù)接入標(biāo)準(zhǔn)化、指標(biāo)計算統(tǒng)一化、預(yù)警輸出自動化。聽起來不復(fù)雜但真正落地時每一塊都有不少細(xì)節(jié)。1.2 技術(shù)選型的思考過程選型永遠(yuǎn)不是選最火的而是選最適合團(tuán)隊維護(hù)的。因為初期調(diào)研的時候我也考慮過直接上完整的流式計算框架比如 Flink甚至也想過用 ClickHouse 做實時數(shù)倉。但最后綜合團(tuán)隊情況選了一條更務(wù)實的路線Kafka 作為消息管道統(tǒng)一接入各類數(shù)據(jù)源一套自研的指標(biāo)計算服務(wù)負(fù)責(zé)做清洗、聚合和規(guī)則判斷結(jié)果寫入 MySQL 和 Redis對外提供 REST API 和 WebSocket 推送。為什么沒有用 Flink其實也不是不能而是學(xué)習(xí)成本和運(yùn)維成本的問題。團(tuán)隊當(dāng)時對 Java 和 Spring Boot 非常熟悉但對 Flink 的部署、調(diào)優(yōu)、狀態(tài)后端管理并不熟練。對于這樣一個不算超大規(guī)模的指標(biāo)計算場景用 Kafka 解耦自研聚合服務(wù)完全能支撐業(yè)務(wù)量而且出現(xiàn)問題時團(tuán)隊自己能快速排查。我個人的原則是在滿足性能指標(biāo)的前提下盡量選擇團(tuán)隊有掌控力的技術(shù)棧不要為了簡歷好看去引入后續(xù)沒人維護(hù)得動的東西。當(dāng)然這套設(shè)計也有明顯的短板。自研計算服務(wù)的水平擴(kuò)展性不如 Flink 這類專業(yè)框架如果未來每秒寫入量達(dá)到幾十萬條就不得不重構(gòu)。但考慮到業(yè)務(wù)增長曲線這個風(fēng)險在接下來兩年內(nèi)是可控的而且我也在設(shè)計上做了分片處理留了一條擴(kuò)展的后路。1.3 架構(gòu)的整體分層一個容易被忽略的點是架構(gòu)圖看著簡單真正落地時要區(qū)分清楚數(shù)據(jù)分層和業(yè)務(wù)分層。數(shù)據(jù)層面我分了四層采集層、傳輸層、計算層、服務(wù)層。采集層由各業(yè)務(wù)線通過 SDK 或 API 上報數(shù)據(jù)傳輸層是 Kafka負(fù)責(zé)削峰填谷計算層是核心承載數(shù)據(jù)清洗、指標(biāo)計算、規(guī)則匹配服務(wù)層對外提供查詢接口和消息推送。業(yè)務(wù)層面則是圍繞“指標(biāo)”來組織而不是圍繞“數(shù)據(jù)源”來組織。比如用戶活躍度這個指標(biāo)它可能來源于用戶埋點、登錄日志、接口調(diào)用日志等多個數(shù)據(jù)源。如果按數(shù)據(jù)源組織邏輯后期指標(biāo)擴(kuò)展時會非常痛苦按指標(biāo)組織邏輯新增數(shù)據(jù)源只需要在接入層做一次適配后續(xù)所有指標(biāo)都能自動復(fù)用。這個設(shè)計看起來是架構(gòu)層面的小事但其實決定了后續(xù)所有開發(fā)效率。我還做了一個很關(guān)鍵的決策計算服務(wù)內(nèi)部分了兩條鏈路一條是實時鏈路一條是準(zhǔn)實時鏈路。實時鏈路處理延遲敏感類的指標(biāo)比如今日交易總額、當(dāng)前在線用戶數(shù)秒級刷新準(zhǔn)實時鏈路處理需要跨時段對比的指標(biāo)比如環(huán)比增長率、異常波動檢測分鐘級計算。這樣做的好處是不會因為少數(shù)復(fù)雜指標(biāo)拖慢整體實時性也讓開發(fā)時可以按需取舍計算深度。2. 核心模塊拆分與細(xì)節(jié)解析2.1 數(shù)據(jù)接入層管好格式才能少踩坑數(shù)據(jù)接入是整個平臺的地基也是最容易出現(xiàn)臟數(shù)據(jù)的地方。接入層我采用了 Topic 加版本號的策略而不是簡單一個 Topic 走天下。每個業(yè)務(wù)方上報數(shù)據(jù)時必須帶上 schema 版本號沒有帶的一律進(jìn)“待修復(fù)隊列”通過一個管理后臺讓業(yè)務(wù)方自己去查看和修正。前期會有些陣痛業(yè)務(wù)方覺得怎么這么麻煩但到了后期做指標(biāo)對齊時你就會發(fā)現(xiàn)這個約束實在救了大命。協(xié)議上當(dāng)時也糾結(jié)過是用 JSON 還是 Protobuf。坦誠講JSON 在調(diào)試時非常友好但做復(fù)雜嵌套結(jié)構(gòu)的時候校驗成本太高解析性能也一般。最終用了 JSON JSON Schema 校驗而不是直接上 Protobuf。原因是團(tuán)隊當(dāng)時人手不足Protobuf 的代碼生成和版本管理需要額外投入而 JSON Schema 允許業(yè)務(wù)方在管理后臺通過配置來調(diào)整校驗規(guī)則靈活度高很多。等業(yè)務(wù)量上來之后再考慮遷移到 Protobuf也是一個可行的演進(jìn)路徑。接入層的另一個隱藏細(xì)節(jié)是“冪等”。Kafka 提供了至少一次投遞語義這在數(shù)據(jù)上報場景下意味著重復(fù)消息幾乎一定會出現(xiàn)。我們在接入層生成了一個針對消息體內(nèi)容的 hash 值存在 Redis 里做去重過期時間設(shè)置為 24 小時。這個處理看似簡單但極大地減少了后續(xù)計算層的重復(fù)計數(shù)問題尤其是做交易量這類累加型指標(biāo)時沒有冪等處理數(shù)據(jù)會有很多水分。2.2 指標(biāo)計算層窗口、口徑與聚合一鍋端指標(biāo)計算層是平臺的大腦也是代碼量最集中的地方。我在這一層實現(xiàn)了一套輕量級的“指標(biāo)引擎”核心思路是聲明式配置每個指標(biāo)由三個要素定義——數(shù)據(jù)源過濾條件聚合邏輯。數(shù)據(jù)源決定去哪些 Topic 取數(shù)過濾條件決定哪些記錄參與計算聚合邏輯負(fù)責(zé)怎么算。業(yè)務(wù)方新增一個指標(biāo)時只要走配置中心提交一份定義計算服務(wù)會自動編譯成可執(zhí)行的算子鏈不需要重新發(fā)版?？赡苡腥藭枮槭裁床挥矛F(xiàn)成的流計算平臺或者直接用 SQL 去定義指標(biāo)其實在前期調(diào)研時SQL確實是備選方案但實際業(yè)務(wù)中有很多非標(biāo)準(zhǔn)化的邏輯例如“剔除內(nèi)部測試賬號”“排除特定來源的重復(fù)請求”這些用SQL表達(dá)比較繞。把指標(biāo)計算留在代碼里用配置驅(qū)動反而最靈活。窗口計算是這個模塊里最難啃的骨頭。實時指標(biāo)往往涉及到滑動窗口比如“過去5分鐘的交易成功率”。要實現(xiàn)這個我用 Redis 的 ZSET 按時間戳存儲每個數(shù)據(jù)點每次計算時通過 score 范圍查詢?nèi)〕龃翱趦?nèi)的數(shù)據(jù)再批量執(zhí)行聚合。這個方案在數(shù)據(jù)量不大時性能很好看但一旦窗口內(nèi)數(shù)據(jù)量突破幾十萬ZSET 的操作延遲就會明顯上升。后來我做了采樣策略對于高吞吐的指標(biāo)在寫入 Redis 之前做一次預(yù)聚合把單條消息聚合成秒級的計數(shù)再把秒級計數(shù)存入 ZSET。這個優(yōu)化直接將窗口查詢的數(shù)據(jù)量減少了兩個數(shù)量級。聚合一端還需要特別注意“重算”的問題。消息延遲亂序在分布式場景下是常態(tài)比如一條 10:00:01 的數(shù)據(jù)可能 10:01:30 才到。如果你在窗口關(guān)閉的瞬間就固化結(jié)果這條遲到的數(shù)據(jù)就永久丟失了。我對每個指標(biāo)配置了一個“允許延遲時間”默認(rèn) 30 秒。窗口關(guān)閉后先出一版結(jié)果延遲時間到期后再做一次修訂計算如果結(jié)果有變化推送一條修訂消息給下游。這種“先初算、后修正”的模式在業(yè)務(wù)容忍范圍內(nèi)是一個極其實用的折中方案。2.3 規(guī)則引擎與預(yù)警中心讓異常自動被發(fā)現(xiàn)業(yè)務(wù)方對平臺的一個核心期望是“別讓我們天天盯著報表異常了你得告訴我們”。這就需要一個簡單但高效的規(guī)則引擎。我這里沒有引入 Drools 這類重量級規(guī)則框架而是實現(xiàn)了一個基于 Groovy 腳本的輕量級規(guī)則沙箱。每條規(guī)則由兩部分組成觸發(fā)條件一段表達(dá)式動作推送消息、打標(biāo)記、調(diào)用回調(diào)接口。規(guī)則配置支持灰度發(fā)布可以先讓 10% 的流量實驗觀察效果沒問題再全量開放。規(guī)則容易寫但預(yù)警風(fēng)暴難防。最常見的情況是某個指標(biāo)在短時間內(nèi)抖動規(guī)則頻繁觸發(fā)業(yè)務(wù)方收到幾十條同一個原因的告警慢慢就會產(chǎn)生“告警疲勞”把推送直接屏蔽掉。踩過這個坑之后我特意實現(xiàn)了在不同規(guī)則上的靈活防護(hù)策略一是預(yù)熱規(guī)則觸發(fā)后要連續(xù) N 次持續(xù)命中才真正發(fā)出預(yù)警二是冷卻同一規(guī)則兩次預(yù)警之間必須至少間隔 5 分鐘三是聚合同一對象的多條預(yù)警合并成一條摘要摘要里附帶最近一段時間的趨勢數(shù)據(jù)。這樣調(diào)整后的實際效果告警量減少了約 60%業(yè)務(wù)方反而更愿意處理預(yù)警信息了。規(guī)則引擎里還有一個容易被忽略的能力動態(tài)閾值。有些指標(biāo)在業(yè)務(wù)高峰和低谷時的波動差異很大如果閾值寫死不是誤報就是漏報。我的方案是讓平臺自動維護(hù)每個指標(biāo)的歷史置信區(qū)間以過去7天同一時間段的均值加減三倍標(biāo)準(zhǔn)差作為動態(tài)基線規(guī)則配置時可以引用這個基線。比如可以設(shè)定“當(dāng)指標(biāo)值低于基線下限的20%時觸發(fā)預(yù)警”這個能力上線之后異常識別的準(zhǔn)確率提升明顯。2.4 對外服務(wù)層既要查得到也要推得動平臺對外提供的服務(wù)主要有兩類查詢類 API 和實時推送通道。查詢類 API 相對常規(guī)基于 MySQL 和 Redis 的一二級緩存模式熱點指標(biāo)走 Redis歷史明細(xì)走 MySQL。這里有一個經(jīng)驗值得分享對于指標(biāo)查詢接口我強(qiáng)烈建議不要在 API 層再引入復(fù)雜的OR映射框架直接用一個輕量的查詢對象組裝 SQL 即可。因為指標(biāo)查詢基本都是固定模式的聚合查詢過度設(shè)計只會增加排查問題的難度。實時推送這一塊用的是 WebSocket配合一個輕量的推送網(wǎng)關(guān)。網(wǎng)關(guān)維護(hù)著每個業(yè)務(wù)方的訂閱列表當(dāng)指標(biāo)計算結(jié)果有更新時把變更記錄推給所有訂閱了該指標(biāo)的服務(wù)端連接。為了不讓推送消息成為瓶頸推送頻率做了限流同一指標(biāo)每秒最多推送一條合并后的快照數(shù)據(jù)。實際運(yùn)營下來推送最考驗的不是吞吐而是連接狀態(tài)的維護(hù)——客戶端斷線重連、心跳超時這些看似簡單的問題在實際聯(lián)調(diào)中比寫核心邏輯還磨人。查詢 API 還有一個磨人的點就是“指標(biāo)對齊”。同樣的“今日總交易額”不同端展示不一樣會讓人對平臺失去信任。所以我在服務(wù)層做了一個快照表每五分鐘生成一次所有核心指標(biāo)的全局快照所有查詢默認(rèn)讀取快照而不是實時精確值。這樣不同服務(wù)方看到的數(shù)據(jù)是一致的只是有最多五分鐘的延遲。對于對實時性要求更高的看板提供實時接口但會明確標(biāo)注是“實時值”避免混用。3. 實操過程從0到1的實現(xiàn)路徑3.1 整體技術(shù)棧與項目結(jié)構(gòu)整個項目后端使用 Java 17 Spring Boot 3.x消息中間件用 Kafka 3.x緩存用 Redis 6.x存儲用 MySQL 8.x。布式環(huán)境那就不用想了剛開始是在單機(jī)環(huán)境開發(fā)調(diào)試之后通過 Docker-Compose 部署到三臺測試服務(wù)器上。項目代碼本身按 Maven 多模塊組織大致結(jié)構(gòu)如下financial-services ├── financial-common # 公共代碼工具類、統(tǒng)一返回結(jié)構(gòu)、異常定義 ├── financial-collect # 數(shù)據(jù)接入服務(wù)接收HTTP上報、校驗、寫Kafka ├── financial-compute # 指標(biāo)計算服務(wù)消費(fèi)Kafka、清洗聚合、寫Redis/MySQL ├── financial-rule # 規(guī)則引擎服務(wù)加載規(guī)則、執(zhí)行判定、觸發(fā)動作 ├── financial-api # 查詢與推送服務(wù)REST API WebSocket推送 └── financial-admin # 管理后臺指標(biāo)配置、數(shù)據(jù)修復(fù)、規(guī)則配置對于剛開始做類似平臺的同學(xué)我建議即使項目很小也盡量按這種縱向切分來組織模塊。因為接入、計算、規(guī)則、服務(wù)四塊的部署頻率完全不同混在一個單體應(yīng)用里一次計算邏輯的改動可能還要連帶推送服務(wù)重新發(fā)布非常容易引發(fā)線上事故。3.2 接入與校驗鏈路的實現(xiàn)接入服務(wù)本質(zhì)上是替業(yè)務(wù)方扛住所有“可能出問題”的地方。業(yè)務(wù)方只需要按約定把一個數(shù)據(jù)結(jié)構(gòu) POST 過來剩下的工作全部在 financial-collect 里完成。數(shù)據(jù)接入的代碼核心分三步接收請求、schema 校驗、投遞到 Kafka。第一步比較簡單直接用一個 Controller 接收 JSON 字符串不急著反序列化成強(qiáng)類型對象因為后續(xù)字段可能變化強(qiáng)類型反而限制靈活性。第二步是校驗用預(yù)加載的 JSON Schema 對消息體做校驗失敗的進(jìn)入修復(fù)隊列并通知業(yè)務(wù)方。第三步是投遞這里關(guān)鍵在于為每條消息生成業(yè)務(wù)主鍵式的去重ID把來源標(biāo)識、業(yè)務(wù)ID、發(fā)生時間拼接后做 MD5。實現(xiàn)時想說一個前面提到的坑接入層在處理量突然翻倍時會遇到線程池打滿導(dǎo)致請求超時的情況。常規(guī)思路是調(diào)大線程池但真正的問題是 Kafka 生產(chǎn)者發(fā)送后等待確認(rèn)的時間過長。后來我在代碼里把 batch.size 從默認(rèn)的 16KB 調(diào)到了 64KBlinger.ms 調(diào)整到 10mssend 的吞吐量明顯上漲CPU 反而下降了。這種調(diào)優(yōu)不復(fù)雜但需要你在壓測時關(guān)注生產(chǎn)者的各項指標(biāo)曲線。3.3 指標(biāo)計算的代碼骨架計算服務(wù)的代碼骨架是消費(fèi) Kafka 消息、按指標(biāo)路由、執(zhí)行過濾條件、執(zhí)行聚合算子、寫入結(jié)果。這個骨架本身不新奇但有幾個細(xì)節(jié)我認(rèn)為值得分享出來。第一是消息路由。我收到了業(yè)務(wù)方上報的消息并不直接按照消息類型去查表而是在消息的 header 里塞入了動態(tài)類型標(biāo)記比如metric-type: user_active消費(fèi)端拿到后直接按這個標(biāo)記定位到預(yù)先注冊的計算單元省去了解析嵌套JSON后再判斷類型的損耗。第二是過濾條件的處理。過濾條件我實現(xiàn)成一個 Python 風(fēng)格的表達(dá)式引擎引入一個輕量級表達(dá)式解析庫配置人員可以在管理后臺寫類似channel ! internal_test and amount 0這樣的表達(dá)式保存后會編譯成一個可執(zhí)行的對象每次消息到達(dá)時在內(nèi)存中執(zhí)行。這樣既擺脫了硬編碼又不會因為頻繁拼接字符串而誤傷性能。第三是聚合算子。聚合算子根據(jù)指標(biāo)類型分成 Sum、Count、Avg、DistinctCount、MaxMin 五類。每一類算子都有一個對應(yīng)的裝飾鏈比如 Counter 算子會先經(jīng)過去重器再到累加器再到窗口存儲。這種裝飾鏈模式的好處是新增一個指標(biāo)類型時不需要改聚合核心只要在配置里指定算子鏈即可。下面是計算服務(wù)消費(fèi)并處理一個實時指標(biāo)的核心示例為了保持篇幅簡潔省略部分細(xì)節(jié)Component public class MetricComputeConsumer { KafkaListener(topics ${metric.input.topic}, containerFactory kafkaContainerFactory) public void onMessage(ConsumerRecordString, String record) { MetricEnvelope envelope JsonUtil.parse(record.value(), MetricEnvelope.class); MetricConfig config metricRegistry.getConfig(envelope.getMetricType()); if (config null) { deadLetterService.submit(record); return; } boolean match expressionEngine.evaluate(config.getFilterExpression(), envelope.getPayload()); if (!match) { return; } Object result aggregatorChain.execute(config.getAggregatorChain(), envelope.getPayload()); resultStore.saveWindowedResult(config.getMetricKey(), result); notificationGateway.pushIfSubscribed(config.getMetricKey(), result); } }我不建議把代碼寫得過于抽象但上面這個核心鏈路的抽象程度是合適的每個組件只負(fù)責(zé)一件小事新指標(biāo)上線時基本不用改 Java 代碼只改配置。這帶來的直接收益就是業(yè)務(wù)方提一個指標(biāo)需求從提報到上線的時間從原來的一周壓縮到了幾小時。3.4 規(guī)則引擎的實現(xiàn)思路規(guī)則引擎我選擇了 Groovy 腳本加一個受限的沙箱。每個規(guī)則腳本被嚴(yán)格限制執(zhí)行時間默認(rèn)500毫秒內(nèi)運(yùn)行在獨(dú)立的線程池里如果超時會被強(qiáng)制中斷。這樣做確實有安全上的考量——不允許規(guī)則腳本訪問系統(tǒng)類、文件、網(wǎng)絡(luò)等敏感資源表達(dá)式語法上限制掉 System、Runtime、ProcessBuilder 等危險類。在金融內(nèi)部業(yè)務(wù)場景這個安全級別完全夠用。規(guī)則入?yún)⒌脑O(shè)計也值得一提。每個規(guī)則會收到一個統(tǒng)一的上下文對象RuleContext里面包含當(dāng)前指標(biāo)的最新值、歷史基線、同比環(huán)比、關(guān)聯(lián)對象ID等。腳本里只需要寫類似這樣的代碼if (ctx.currentValue ctx.baselineLowerBound * 0.8) { return new RuleAction(warning, 指標(biāo)低于基線下限20%) } return new RuleAction(none, )這個上下文對象的設(shè)計讓規(guī)則編寫者完全不需要關(guān)注數(shù)據(jù)怎么查、怎么算只需要專注于業(yè)務(wù)判斷邏輯大大降低了使用門檻。甚至業(yè)務(wù)分析師經(jīng)過簡單培訓(xùn)后也能自己寫基礎(chǔ)規(guī)則這就是平臺類的價值所在。規(guī)則執(zhí)行結(jié)果的輸出也做了標(biāo)準(zhǔn)化。輸出的RuleAction中包含動作類型和描述后續(xù)會交給動作執(zhí)行器去處理。動作執(zhí)行器實現(xiàn)了多種通道Webhook 回調(diào)、內(nèi)部 IM 推送、短信發(fā)送、郵件通知。每種通道在實現(xiàn)時都做了限流和降級單個通道異常時不會影響其他通道這是預(yù)警系統(tǒng)在生產(chǎn)環(huán)境里必須具備的韌性。3.5 可觀測性與監(jiān)控設(shè)計一個數(shù)據(jù)平臺如果自身沒有監(jiān)控那出了問題排查起來真的跟大海撈針一樣。我在系統(tǒng)里埋了三類監(jiān)控指標(biāo)接入層監(jiān)控上報量、校驗失敗率、Kafka 積壓量、計算層監(jiān)控處理延遲、聚合耗時、窗口命中率、服務(wù)層監(jiān)控查詢QPS、推送成功率、WebSocket 連接數(shù)。這些監(jiān)控指標(biāo)通過 Prometheus 采集在 Grafana 上展示。核心告警項包括Kafka 消費(fèi)積壓超過閾值、計算引擎任務(wù)執(zhí)行超時率偏高、推送通道成功率低于99%。還有一個小細(xì)節(jié)是鏈路追蹤。因為消息從接入到計算到推送要經(jīng)過多個服務(wù)沒有唯一追蹤ID很難定位問題。我在消息進(jìn)入接入層時生成了一個全局 traceId隨消息一起寫入 Kafka 的 header整個鏈路全程透傳。日志框架里統(tǒng)一打印這個 traceId這樣遇到“某條數(shù)據(jù)沒算出來”的問題可以直接用 traceId 查所有日志節(jié)點效率提升不止一點半點。4. 我踩過的坑與調(diào)優(yōu)記錄4.1 消費(fèi)端不均衡導(dǎo)致的計算傾斜平臺上線初期我發(fā)現(xiàn)有個 Topic 的消費(fèi)速度一直跟不上生產(chǎn)速度但看消費(fèi)者組的整體積壓量又不高。后來排查發(fā)現(xiàn)是 key 分布不均勻造成的某個熱點業(yè)務(wù)方的數(shù)據(jù)占了總數(shù)據(jù)量的 70%消息全部 hash 到了同一個分區(qū)那個分區(qū)的消費(fèi)者忙成狗其他消費(fèi)者閑得長草。這個問題給了我一個很深的教訓(xùn)在選擇 Kafka 分區(qū) key 時不能直接用業(yè)務(wù)方ID而要結(jié)合消息內(nèi)的一個子維度做組合散列。比如業(yè)務(wù)方ID加渠道ID必要時要再加一個隨機(jī)鹽確保消息能相對均勻地分散到各分區(qū)。修改之后分區(qū)消費(fèi)量從“三七開”變得基本均衡。這屬于那種你不在生產(chǎn)環(huán)境大規(guī)模跑一次就絕對發(fā)現(xiàn)不了的坑。4.2 Redis 大Key問題差點把緩存打爆做滑動窗口指標(biāo)時最初把所有明細(xì)消息都塞進(jìn)了同一個 ZSET導(dǎo)致某些熱點指標(biāo)對應(yīng)的 ZSET 里數(shù)據(jù)量巨大單個 Key 的 value 達(dá)到了好幾十MB。那次 Redis 的 INFO 里內(nèi)存直接告警ZSET 操作延遲也飆到了幾百毫秒連帶著其他指標(biāo)的計算也被拖慢了。后來做了兩件事解決。第一引入“小窗口預(yù)聚合”秒級聚合成一條計數(shù)再進(jìn)入 ZSET明細(xì)數(shù)據(jù)落 MySQL 做離線查詢。第二給 ZSET 設(shè)置一個不過期的滾動清理策略每次寫入時順帶刪除超過窗口范圍兩倍的老數(shù)據(jù)避免數(shù)據(jù)只增不減。這個改動上線后Redis 內(nèi)存占用下降了 70%ZSET 操作耗時重回亞毫秒級別。遇到這個問題的同時我也更加確信像 Redis 這類組件用得好不好很多時候取決于你對數(shù)據(jù)生命周期的設(shè)計而不是組件本身的性能。4.3 指標(biāo)修正導(dǎo)致的口徑爭議前面提到我做了窗口修正策略但這個策略上線后引來了新問題業(yè)務(wù)方在午間看到“今日流水總額”出現(xiàn)了回退后臺就炸了覺得數(shù)據(jù)算錯了。其實就是先初算的版本少算了幾條遲到的消息修正后金額反而更準(zhǔn)確但業(yè)務(wù)方只看到了“數(shù)字變小”。為這件事開的會讓我深刻意識到技術(shù)上的正確不一定等于業(yè)務(wù)上的可接受。后來的做法是對于對外展示的核心業(yè)務(wù)指標(biāo)默認(rèn)不啟用修正覆蓋而是通過一個“修訂標(biāo)記”來提示業(yè)務(wù)方當(dāng)前結(jié)果可能會修正。同時在管理后臺提供“修正生效時間”配置業(yè)務(wù)方如果追求極致的準(zhǔn)確可以把允許延遲時間拉長前提是接受展示延遲。這些都是系統(tǒng)設(shè)計時容易忽略的“非功能需求”但實際運(yùn)營中它們往往比功能需求更能決定項目的成敗。你辛辛苦苦實現(xiàn)了高性能的計算引擎卻因為在數(shù)據(jù)展示口徑上沒溝通好最后業(yè)務(wù)方還是覺得平臺“不靠譜”那就太可惜了。4.4 預(yù)警風(fēng)暴壓測時才暴露預(yù)警模塊在功能測試階段沒有發(fā)現(xiàn)問題因為測試數(shù)據(jù)量小觸發(fā)頻率低。但一次全鏈路壓測中模擬了幾倍于正常流量的數(shù)據(jù)預(yù)警服務(wù)中心瞬間打了幾百條推送導(dǎo)致內(nèi)部網(wǎng)關(guān)超時。當(dāng)時我的第一反應(yīng)不是調(diào)大推送線程池而是立刻想著怎么從源頭控制預(yù)警數(shù)量。前面所說的預(yù)熱、冷卻、聚合三層策略正是在這種背景下實現(xiàn)的。壓測結(jié)果驗證了策略的有效性同等流量下最終發(fā)出的預(yù)警數(shù)量下降了一個數(shù)量級。這條經(jīng)驗也適用于所有事件驅(qū)動型系統(tǒng)預(yù)警機(jī)制必須有自我保護(hù)能力否則系統(tǒng)一但進(jìn)入故障狀態(tài)海量冗余通知會讓故障雪上加霜。5. 關(guān)鍵配置與參數(shù)參考5.1 Kafka相關(guān)參數(shù)配置Kafka 參數(shù)這個東西很多人喜歡照抄網(wǎng)上的推薦值但不同業(yè)務(wù)場景差別真的很大。我這里給出的是消息體較小、高峰流量較大的金融數(shù)據(jù)場景下的一組參考配置。參數(shù)推薦值說明batch.size64KB批量發(fā)送閾值調(diào)大能提升吞吐linger.ms10ms等待更多消息的時間兼顧延遲和吞吐acksall確保寫入副本成功compression.typelz4減少網(wǎng)絡(luò)帶寬占用max.poll.records500單次消費(fèi)拉取條數(shù)避免堆積太多內(nèi)存enable.auto.commitfalse手動提交偏移量防止重復(fù)消費(fèi)或丟失關(guān)于enable.auto.commit我想多說一句生產(chǎn)環(huán)境建議一定關(guān)閉自動提交改用手動提交配合處理成功的業(yè)務(wù)邏輯。雖然手動提交代碼上麻煩一點但能有效避免“消費(fèi)了消息但處理失敗卻把偏移量提交了”的問題。很多數(shù)據(jù)不一致的隱形故障根源就出在這里。5.2 Redis與MySQL的存儲劃分這一塊我做一個總體的劃分。實時性要求高的指標(biāo)結(jié)果、滑動窗口數(shù)據(jù)、去重集合全部放 Redis冷數(shù)據(jù)、歷史明細(xì)、預(yù)警記錄、配置快照放 MySQL。Redis 里我建議用 HASH 結(jié)構(gòu)存指標(biāo)快照用一個 KEY 表示“指標(biāo)名”field 表示“統(tǒng)計周期”value 存 JSON 序列化的結(jié)果對象。這樣查詢一個指標(biāo)多個時間段的數(shù)據(jù)時只需要一次 HGETALL非常高效。線下數(shù)據(jù)表的設(shè)計其實并沒有很復(fù)雜但我在建表時做了一件降低后續(xù)心智負(fù)擔(dān)的事情所有核心表都帶一個record_snapshot_no字段每次全局指標(biāo)快照生成時這個編號單調(diào)遞增。業(yè)務(wù)方如果需要分析某一時刻的全局口徑只需要通過快照編號去查詢不需要跨表核對時間戳。5.3 告警配置參數(shù)模板告警配置我提供一個基礎(chǔ)模板你可以根據(jù)項目情況微調(diào)。核心思路是告警不是越多越好要讓預(yù)警真正能落地處理寧可少而準(zhǔn)不可多而濫。alert: preheat_count: 3 # 連續(xù)觸發(fā)多少次后才告警 cooldown_seconds: 300 # 同一規(guī)則告警冷卻時間 aggregate_window: 60 # 聚合窗口秒 max_push_rate: 5 # 每秒鐘最大推送條數(shù) dynamic_baseline: enabled: true history_days: 7 lower_ratio: 0.8順帶提一下max_push_rate這個參數(shù)的意義。它不是限制業(yè)務(wù)方的接收能力而是保護(hù)平臺自身。當(dāng)出現(xiàn)大規(guī)模故障時限流會讓預(yù)警延遲一點點時間但這遠(yuǎn)比把網(wǎng)關(guān)打爆導(dǎo)致所有通知都發(fā)不出去要靠譜得多。6. 后續(xù)擴(kuò)展與個人體會這套平臺上線運(yùn)行之后業(yè)務(wù)方的反饋整體是積極的。過去一個新指標(biāo)從提需求到看到數(shù)據(jù)動輒兩三周現(xiàn)在基本當(dāng)天就能在平臺上配置上線。早期最核心的“指標(biāo)口徑不統(tǒng)一”問題也通過快照機(jī)制和統(tǒng)一配置中心得到了很大改善。我自己的體會是做這類平臺型項目技術(shù)能力其實只是基礎(chǔ)最難的部分往往是對業(yè)務(wù)的抽象以及和各種業(yè)務(wù)方在口徑問題上的耐心溝通。如果后續(xù)要繼續(xù)演進(jìn)我比較看好的方向是引入一套輕量級的“指標(biāo)血緣”能力。也就是說讓每個指標(biāo)能從數(shù)據(jù)源一路追溯到最終的報表展示中間經(jīng)過了哪些過濾、哪些算子、哪些修正全部可視化呈現(xiàn)。當(dāng)業(yè)務(wù)指標(biāo)出現(xiàn)異常時順著血緣圖就能快速定位到是哪條鏈路的數(shù)據(jù)出了變化。這個能力目前市面上有一些商業(yè)產(chǎn)品在提供但自研實現(xiàn)一個基礎(chǔ)版本并沒有想象中那么難。最后再分享一個個人經(jīng)驗開發(fā)這類數(shù)據(jù)平臺時一定要把“數(shù)據(jù)質(zhì)量”當(dāng)成一等公民在架構(gòu)設(shè)計階段就預(yù)留好校驗、修復(fù)、對賬的能力而不是等項目上線了再補(bǔ)。數(shù)據(jù)質(zhì)量的基礎(chǔ)設(shè)施建得越早后期業(yè)務(wù)擴(kuò)張時你越從容。很多問題看著是業(yè)務(wù)規(guī)則問題深挖到底都是數(shù)據(jù)質(zhì)量問題。地基穩(wěn)了上面蓋什么樣的業(yè)務(wù)大樓都不怕。