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