去年年底接手了一個傳統(tǒng)制造企業(yè)的薪酬系統(tǒng)重構(gòu)項目老系統(tǒng)是單體 Spring Boot JSP每個月工資核算報表要跑兩個小時發(fā)薪高峰期接口經(jīng)常超時人事、財務(wù)、IT 三撥人為數(shù)據(jù)對不上來回扯皮。我們最終用 Spring Boot Vue Spring Cloud 重新做了一套企業(yè)員工薪酬工資管理系統(tǒng)并且選擇了微服務(wù)分布式路線。這篇博文會把當(dāng)初的拆分思路、技術(shù)選型、落地過程以及踩過的坑全部寫出來給正在做薪酬系統(tǒng)或準(zhǔn)備微服務(wù)化的團(tuán)隊一個真實參考。很多人一聽到“薪酬系統(tǒng)”第一反應(yīng)是這么核心的業(yè)務(wù)也敢拆微服務(wù)我的答案是敢但必須想清楚邊界。這套系統(tǒng)表面上只是算工資、發(fā)工資、出報表背后卻牽扯組織人員、考勤、個稅、社保、資金、審批、消息通知等多個業(yè)務(wù)域。如果繼續(xù)在單體里堆代碼每一個新需求都像在鋼絲上跳舞。下面我從為什么拆、怎么拆、踩了什么坑三個層面展開。1. 為什么薪酬系統(tǒng)敢用微服務(wù)架構(gòu)1.1 單體薪酬系統(tǒng)的三個痛點老系統(tǒng)最讓人頭疼的是算薪流程完全串行。每個月 15 號發(fā)薪日人事在白天導(dǎo)入考勤和績效數(shù)據(jù)晚上觸發(fā)批量計算第二早上財務(wù)才能看到工資單。一旦某個部門數(shù)據(jù)有誤整個批處理重新跑CPU 跑滿、數(shù)據(jù)庫連接耗盡其他業(yè)務(wù)系統(tǒng)也跟著卡頓。這是典型的單體資源隔離問題一個慢任務(wù)拖垮了所有模塊。第二個痛點是權(quán)限邊界非常模糊。薪酬數(shù)據(jù)是敏感度極高的數(shù)據(jù)但老系統(tǒng)只有角色和菜單權(quán)限沒有數(shù)據(jù)權(quán)限。換句話說只要有“薪資查詢”菜單的人理論上能翻全公司任何人的工資條。后來我們加了部門維度過濾卻只能靠 SQL 中大量if判斷硬編碼維護(hù)成本極高。第三個痛點是數(shù)據(jù)庫單點。所有模塊共用同一個 MySQL 實例月報統(tǒng)計、工資單查詢、審批流全部打在同一張庫上。大促式查詢來了索引再優(yōu)化也只是延緩問題。我們把用戶量撐到 2 萬以后一個簡單的分頁查詢在發(fā)薪日都可能要三秒以上。說到底單體不是不能用而是當(dāng)業(yè)務(wù)域之間需要獨立擴縮容、獨立權(quán)限控制、獨立發(fā)布頻率的時候它已經(jīng)成了瓶頸。1.2 微服務(wù)拆分的邊界與原則微服務(wù)不是拆得越碎越好尤其薪酬系統(tǒng)這類強一致、強審計的業(yè)務(wù)拆得過度會帶來災(zāi)難。我們遵循了一個核心原則按“業(yè)務(wù)變化頻率”和“數(shù)據(jù)安全邊界”劃分而不是按頁面劃分。最終拆出來的服務(wù)包括auth-service統(tǒng)一認(rèn)證與鑒權(quán)org-service組織架構(gòu)、員工檔案、崗位職級attendance-service考勤結(jié)果匯總salary-engine-service薪酬規(guī)則配置與算薪引擎payroll-service工資單、發(fā)放批次、回盤數(shù)據(jù)finance-service資金凍結(jié)、代發(fā)賬戶管理approval-service審批流notification-service短信、站內(nèi)信、郵件通知gateway-service統(tǒng)一入口網(wǎng)關(guān)這里強調(diào)一個關(guān)鍵點我們沒有單獨拆一個“報表服務(wù)”而是把報表功能放在了payroll-service里。因為報表強依賴工資單表結(jié)構(gòu)拆出去只會增加跨服務(wù)聚合的復(fù)雜度。類似這種“看似獨立、實際強耦合”的功能留在原服務(wù)反而更合理。每個服務(wù)獨立數(shù)據(jù)庫服務(wù)之間禁止直連數(shù)據(jù)庫必須通過 API 調(diào)用。這一條規(guī)則在執(zhí)行初期很痛但后期收益極大。比如后來考勤接口查詢變慢我們只需要給attendance-service單獨擴容完全不影響工資單查詢。2. 核心模塊拆解與數(shù)據(jù)模型設(shè)計2.1 用戶與組織權(quán)限模塊薪酬系統(tǒng)的權(quán)限設(shè)計必須同時具備“功能權(quán)限”和“數(shù)據(jù)權(quán)限”。我們在org-service里維護(hù)了部門、崗位、職級、員工狀態(tài)等基礎(chǔ)數(shù)據(jù)在auth-service里實現(xiàn) RBAC 模型。用戶登錄后拿到的不只是菜單列表還有一個“數(shù)據(jù)可見范圍”的表達(dá)式例如department_id IN (1001, 1002)。在實際項目里我們參考了若依微服務(wù) plus 的權(quán)限模型用戶、角色、菜單、部門數(shù)據(jù)權(quán)限四層。 角色不再直接關(guān)聯(lián)用戶而是關(guān)聯(lián)“用戶-部門-崗位”的組合這樣人員調(diào)崗后權(quán)限自動失效不必手動重新授權(quán)。這里有個容易被忽視的細(xì)節(jié)薪酬的敏感操作查看他人工資條、調(diào)整薪資項、導(dǎo)出工資單必須記錄操作日志。我們專門加了salary_access_log表記錄操作人、操作時間、IP、請求參數(shù)摘要。審計日志表單獨存放在payroll-service庫里不能和業(yè)務(wù)表混在一起避免誤操作被刪掉。2.2 薪資核算模塊設(shè)計工資項拆成三大類應(yīng)發(fā)項、扣款項、專項附加項。每個員工通過salary_rule表關(guān)聯(lián)自己適用的薪資規(guī)則規(guī)則里存放計算表達(dá)式和優(yōu)先級。例如基本工資固定金額崗位工資固定金額績效工資基本工資 × 績效系數(shù)加班費小時工資 × 加班小時數(shù) × 倍率社保公積金按基數(shù)比例計算個稅累計預(yù)扣法計算我們在salary-engine-service中用 Groovy 腳本引擎解析計算規(guī)則。為什么不用 Java 硬編碼因為財務(wù)每個月都可能調(diào)整扣款項和補貼項硬編碼意味著每個調(diào)整都要走一次發(fā)版。Groovy 腳本存儲在數(shù)據(jù)庫里修改后可以即時生效同時配合規(guī)則版本號做回溯。計算精度必須用BigDecimal入庫金額四舍五入保留兩位小數(shù)中間計算結(jié)果保留四位小數(shù)。這里我舉一個真實計算過程某員工基本工資 8000績效系數(shù) 1.2交通補貼 500社保公積金個人繳納部分 1680無專項附加扣除。應(yīng)發(fā)金額 8000 8000 × 1.2 500 18100個稅按累計預(yù)扣法計算假設(shè)累計應(yīng)納稅所得額 21000對應(yīng)稅率 3%個稅 630。實發(fā)金額 18100 - 1680 - 630 15790。 實際代碼中我們絕不會用浮點數(shù)直接相乘否則 0.1 0.2 這類精度問題會讓工資條對不上賬。2.3 分布式事務(wù)跨服務(wù)扣款與發(fā)薪發(fā)薪場景是分布式事務(wù)的高發(fā)區(qū)。算薪完成后系統(tǒng)需要同時做三件事凍結(jié)/扣減資金賬戶余額、生成工資單、記錄發(fā)放流水。這三個操作分別落在finance-service、payroll-service、notification-service上沒法用本地事務(wù)一把梭。我們最終引入 Seata 的 AT 模式但并不是所有接口都用全局事務(wù)而是只保護(hù)資金變更這一條核心鏈路。發(fā)薪接口的執(zhí)行過程大致是salary-engine-service生成工資單數(shù)據(jù)寫入salary_statementpayroll-service創(chuàng)建發(fā)放批次狀態(tài)置為PENDINGfinance-service凍結(jié)對應(yīng)資金賬戶余額三個服務(wù)都成功后全局事務(wù)提交批次狀態(tài)變成COMPLETED如果任何一步失敗AT 模式自動反向補償 SQL回滾已寫入的數(shù)據(jù)這里提醒一句不要把工資單 PDF 生成、郵件通知、短信發(fā)送放入同一個全局事務(wù)。這些非核心操作占用時間長會讓事務(wù)鎖持有時長直線上升。正確做法是事務(wù)只管業(yè)務(wù)狀態(tài)變更事務(wù)提交后再發(fā) MQ 消息讓notification-service異步處理通知。哪怕通知失敗只需要定時任務(wù)補償不影響發(fā)薪結(jié)果。2.4 關(guān)鍵表結(jié)構(gòu)設(shè)計數(shù)據(jù)模型是整個系統(tǒng)最容易翻車的地方。我貼幾張核心表的簡化結(jié)構(gòu)大家可以直接作為落地參考。salary_staff_account員工薪酬檔案表CREATE TABLE salary_staff_account ( id BIGINT PRIMARY KEY AUTO_INCREMENT, staff_id BIGINT NOT NULL COMMENT 員工ID, employee_no VARCHAR(32) NOT NULL COMMENT 工號, bank_account VARCHAR(64) NOT NULL COMMENT 銀行卡號, base_salary DECIMAL(12,2) NOT NULL COMMENT 基本工資, post_salary DECIMAL(12,2) DEFAULT 0 COMMENT 崗位工資, social_security_base DECIMAL(12,2) DEFAULT 0 COMMENT 社?；鶖?shù), housing_fund_base DECIMAL(12,2) DEFAULT 0 COMMENT 公積金基數(shù), account_status TINYINT NOT NULL DEFAULT 1 COMMENT 1有效 0停用, create_time DATETIME NOT NULL, update_time DATETIME NOT NULL, UNIQUE KEY uk_staff_id (staff_id), KEY idx_employee_no (employee_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT員工薪酬檔案表;salary_statement工資單表CREATE TABLE salary_statement ( id BIGINT PRIMARY KEY AUTO_INCREMENT, batch_id BIGINT NOT NULL COMMENT 批次ID, staff_id BIGINT NOT NULL, statement_month CHAR(7) NOT NULL COMMENT 賬期如2026-06, payable_amount DECIMAL(12,2) NOT NULL COMMENT 應(yīng)發(fā)金額, social_security DECIMAL(12,2) NOT NULL COMMENT 社保個人部分, housing_fund DECIMAL(12,2) NOT NULL COMMENT 公積金個人部分, income_tax DECIMAL(12,2) NOT NULL COMMENT 個稅, actual_amount DECIMAL(12,2) NOT NULL COMMENT 實發(fā)金額, status TINYINT NOT NULL DEFAULT 0 COMMENT 0未發(fā)放 1已發(fā)放 2已回盤, create_time DATETIME NOT NULL, update_time DATETIME NOT NULL, UNIQUE KEY uk_staff_month (staff_id, statement_month), KEY idx_batch_id (batch_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT工資單表;salary_payment_log發(fā)放流水表是冪等保障的關(guān)鍵CREATE TABLE salary_payment_log ( id BIGINT PRIMARY KEY AUTO_INCREMENT, payment_no VARCHAR(64) NOT NULL COMMENT 發(fā)放流水號, batch_id BIGINT NOT NULL, staff_id BIGINT NOT NULL, statement_month CHAR(7) NOT NULL, actual_amount DECIMAL(12,2) NOT NULL, payment_status TINYINT NOT NULL DEFAULT 0 COMMENT 0處理中 1成功 2失敗, retry_count INT NOT NULL DEFAULT 0, create_time DATETIME NOT NULL, update_time DATETIME NOT NULL, UNIQUE KEY uk_payment_no (payment_no), UNIQUE KEY uk_batch_staff (batch_id, staff_id), KEY idx_staff_month (staff_id, statement_month) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT薪資發(fā)放流水表;唯一索引uk_batch_staff是最后一道防線就算代碼中 Redis 鎖失效、重試機制抽風(fēng)數(shù)據(jù)庫層面也能擋住重復(fù)發(fā)放。后面我在“高頻問題”部分還會展開講這個坑。3. 技術(shù)選型與基礎(chǔ)設(shè)施落地3.1 注冊中心、網(wǎng)關(guān)與配置中心技術(shù)棧選型不能只追新還要考慮團(tuán)隊運維能力。我們最終選了 Spring Boot 3.2 Spring Cloud 2023.0.x Spring Cloud Alibaba 2023.0.x注冊中心和配置中心都用 Nacos網(wǎng)關(guān)用 Spring Cloud Gateway服務(wù)間調(diào)用用 OpenFeign。Nacos 對比 Eureka 最大的優(yōu)勢是自帶配置中心可以動態(tài)修改線程池參數(shù)、開關(guān)配置不用額外部署 Config Server。比如算薪引擎在發(fā)薪高峰可能需要臨時調(diào)整批量大小直接在 Nacos 上改配置應(yīng)用無需重啟。這個能力在薪酬系統(tǒng)里非常實用因為發(fā)薪日業(yè)務(wù)幾乎不能停機。網(wǎng)關(guān)層我們做了三件事路由轉(zhuǎn)發(fā)、統(tǒng)一鑒權(quán)、灰度發(fā)布。初始版本沒有接入 Sentinel 限流結(jié)果發(fā)薪日流量一上來網(wǎng)關(guān)線程池被打滿我們才意識到網(wǎng)關(guān)也需要限流降級。后來通過 Sentinel 對/payroll/pay這類關(guān)鍵路徑配置了 QPS 限流超過閾值直接返回“系統(tǒng)繁忙”避免把下游服務(wù)拖垮。3.2 認(rèn)證鑒權(quán)Spring Security JWT OAuth2認(rèn)證這塊我們單獨做了auth-service沒有在網(wǎng)關(guān)里做復(fù)雜邏輯。整體流程是用戶通過用戶名密碼登錄auth-service校驗通過后簽發(fā) JWTJWT 中放入user_id、dept_ids、role_codes請求經(jīng)過網(wǎng)關(guān)時GlobalFilter解析 JWT 并校驗簽名校驗通過后Header 中加入X-User-Id、X-Dept-Id等內(nèi)部信任頭再轉(zhuǎn)發(fā)到下游服務(wù)下游服務(wù)只在從網(wǎng)關(guān)進(jìn)來的請求里讀取用戶信息對于直接暴露的接口必須二次校驗簽名JWT 的有效期我們設(shè)置得比較短默認(rèn) 30 分鐘配合 refresh token 刷新。為什么不設(shè)置 7 天因為員工離職、調(diào)崗后權(quán)限變化必須盡快生效JWT 一旦簽發(fā)有效期太長舊 token 還能繼續(xù)訪問這是薪酬系統(tǒng)不能接受的安全隱患。 refresh token 刷新時會檢查用戶當(dāng)前是否還有效如果員工已離職直接拒絕刷新。3.3 分布式鎖與冪等控制發(fā)薪、審批、批量導(dǎo)入這類操作必須防止并發(fā)執(zhí)行。單體時代用synchronized只能鎖單機微服務(wù)部署多個實例后必須用分布式鎖。我們用的 Redis 分布式鎖具體實現(xiàn)基于 RedissonRLock lock redissonClient.getLock(salary:pay: batchId); boolean locked lock.tryLock(5, 30, TimeUnit.SECONDS); if (!locked) { throw new BizException(當(dāng)前發(fā)放批次正在處理中請勿重復(fù)操作); } try { // 執(zhí)行業(yè)務(wù)邏輯更新批處理狀態(tài) } finally { if (lock.isHeldByCurrentThread()) { lock.unlock(); } }Redisson 自帶看門狗機制默認(rèn)會把鎖持有時間自動續(xù)期避免業(yè)務(wù)執(zhí)行時間過長導(dǎo)致鎖自動過期。 這里特別強調(diào)鎖的 key 必須帶業(yè)務(wù)維度比如salary:pay:{batchId}不能全局一把鎖。否則不同批次之間會互相阻塞嚴(yán)重降低發(fā)薪效率。分布式鎖解決的是并發(fā)問題但不是冪等的全部。接口層還要做冪等校驗比如前端在提交付款時生成一個paymentNo后端用這個唯一流水號判斷是否已經(jīng)處理過。Redis 里加一個SETNX paymentNo 1 EX 24h作為第一層過濾數(shù)據(jù)庫唯一索引作為兜底。3.4 文件存儲與消息隊列工資條 PDF、社保繳納明細(xì)、銀行回盤文件等附件不適合直接放 MySQLBLOB 查詢會拖垮數(shù)據(jù)庫性能。最開始我圖省事用 FastDFS結(jié)果配置復(fù)雜、社區(qū)維護(hù)進(jìn)度慢后來直接換成了 MinIO。MinIO 部署成本低支持 S3 協(xié)議和 Spring Boot 集成非常順。文件上傳路徑我們默認(rèn)不走網(wǎng)關(guān)因為工資單批次可能一次性上傳幾千個 PDF網(wǎng)關(guān)作為同步轉(zhuǎn)發(fā)點容易成為瓶頸。正確做法是后端生成預(yù)簽名 URL前端直傳 MinIO上傳完成后回調(diào)后端登記文件元數(shù)據(jù)。這樣既保證了傳輸速度又不會讓網(wǎng)關(guān)長時間被連接占用。消息隊列用了 RocketMQ主要場景包括發(fā)薪完成通知、工資單生成后的回調(diào)、報表導(dǎo)出的異步任務(wù)。RocketMQ 的事務(wù)消息在這里也很合適比如“創(chuàng)建發(fā)放批次”和“發(fā)送 MQ 消息”需要保持一致可以用事務(wù)消息把本地事務(wù)和消息發(fā)送綁定在一起。不過我的經(jīng)驗是事務(wù)消息雖好但不要濫用大多數(shù)場景用普通可靠消息 定時任務(wù)對賬就夠了。4. 前端Vue實現(xiàn)與聯(lián)調(diào)實戰(zhàn)4.1 Vue3 Vite Element Plus 工程化搭建前端我們沒有用老一套 Vue2 Webpack而是選了 Vue3 Vite Element Plus Pinia TypeScript。Vite 的冷啟動速度對開發(fā)體驗提升非常明顯改一行代碼保存后頁面幾乎秒級刷新這在天天調(diào)整表格和表單的薪酬管理后臺里能省下大量等待時間。工程目錄采用按業(yè)務(wù)模塊劃分的方式src/ api/ # 所有接口請求 assets/ components/ layouts/ # 布局組件 router/ # 動態(tài)路由 store/ # Pinia views/ auth/ dashboard/ payroll/ report/ system/ utils/環(huán)境配置上.env.development里設(shè)置VITE_API_BASE_URL/api然后在vite.config.ts里配置代理到本地網(wǎng)關(guān)server: { port: 5173, proxy: { /api: { target: http://localhost:8080, changeOrigin: true, rewrite: path path.replace(/^\/api/, ) } } }之所以開發(fā)環(huán)境用代理而不是直接填http://localhost:8080是為了避開跨域問題同時讓代碼里的請求路徑保持統(tǒng)一。生產(chǎn)環(huán)境由 Nginx 把/api反向代理到網(wǎng)關(guān)前端代碼不需要區(qū)分環(huán)境。4.2 動態(tài)路由、權(quán)限指令與數(shù)據(jù)字典薪酬系統(tǒng)的菜單權(quán)限不是靜態(tài)寫死的不同角色登錄后看到的側(cè)邊欄完全不同。我們通過登錄接口返回菜單樹然后前端動態(tài)添加路由router.addRoute({ path: item.path, name: item.name, component: () import(../views/${item.component}.vue), meta: { title: item.title, icon: item.icon } });菜單控制只是一部分按鈕級權(quán)限同樣重要。比如“發(fā)放工資”按鈕只有財務(wù)主管角色能看到普通財務(wù)人員登錄后按鈕直接消失。我們用自定義指令v-permission實現(xiàn)app.directive(permission, { mounted(el, binding) { const requiredPerms binding.value; const userPerms useUserStore().perms; const hasPermission userPerms.some(p requiredPerms.includes(p)); if (!hasPermission) { el.parentNode?.removeChild(el); } } });注意一點前端權(quán)限只能提升交互體驗不能作為安全邊界。后端接口必須再做一次權(quán)限校驗否則繞過前端工具直接調(diào)用接口敏感數(shù)據(jù)照樣泄露。這個理念我在團(tuán)隊里強調(diào)了很多次。數(shù)據(jù)字典也是薪酬系統(tǒng)的剛需。銀行列表、工資項類型、發(fā)放渠道、員工狀態(tài)等都用字典管理前端寫成通用Select組件不再一頁頁重復(fù)拉表單枚舉值。我們用了簡單的靜態(tài)字典配置 后端接口刷新緩存沒有引入很重的字典服務(wù)夠用就好。4.3 前后端聯(lián)調(diào)跨域、網(wǎng)關(guān)與Mock數(shù)據(jù)微服務(wù)架構(gòu)下前端只面向網(wǎng)關(guān)一個入口不要直接面對面訪問各服務(wù)地址。聯(lián)調(diào)階段經(jīng)常出現(xiàn)的狀況是前端說接口 404后端說服務(wù)正常最后發(fā)現(xiàn)是路由路徑?jīng)]匹配上。我們在網(wǎng)關(guān)里把/api/auth/**路由到auth-service把/api/payroll/**路由到payroll-service前綴必須統(tǒng)一不然排查起來非常痛苦。聯(lián)調(diào)過程中后端接口還沒寫完我們用 Mock 數(shù)據(jù)并行開發(fā)。這里不推薦在真實代碼里寫死if (mock) return xxx而是啟動一個獨立的 Mock Server比如用json-server或Mock.js的獨立 dev server。開發(fā)環(huán)境通過 Vite 代理切換到 Mock Server等后端接口就緒只改一行代理地址即可。 前后端約定好接口字段命名規(guī)范用camelCase避免一個接口一個命名風(fēng)格。另外工資單列表頁通常要做金額區(qū)間篩選可能會用到防抖和分頁緩存。我們踩過一個坑Element Plus 表格在切換篩選條件時查詢參數(shù)里的pageNo沒有重置為 1導(dǎo)致用戶在第一頁篩選后跳到了其他頁數(shù)據(jù)看著像“憑空消失”。代碼里統(tǒng)一在篩選條件變化時重置頁碼這個問題就解決了。系統(tǒng)里的操作演示視頻我們順手接了一個支持 m3u8 的播放組件放在幫助中心給業(yè)務(wù)人員看培訓(xùn)錄像。這不是核心功能但對新手人事專員來說比厚厚的手冊有用得多。5. 分布式部署與運維監(jiān)控5.1 容器化部署Docker Compose 到 K8s微服務(wù)落地后部署復(fù)雜度直線上升。我們前期沒有直接上 K8s而是先用 Docker Compose 編排Nacos、MySQL、Redis、MinIO、RocketMQ 都作為基礎(chǔ)設(shè)施容器化運行業(yè)務(wù)服務(wù)也用 Docker 鏡像跑在獨立容器里。每新增一個服務(wù)就寫一個Dockerfile用 Maven 構(gòu)建出可執(zhí)行 jar再用多階段構(gòu)建精簡鏡像FROM maven:3.9-eclipse-temurin-17 AS builder WORKDIR /build COPY pom.xml . RUN mvn dependency:go-offline COPY src ./src RUN mvn package -DskipTests FROM eclipse-temurin:17-jre WORKDIR /app COPY --frombuilder /build/target/*.jar app.jar EXPOSE 8080 ENTRYPOINT [java, -jar, app.jar]為什么沒用 K8s因為運維團(tuán)隊初期只有兩個人K8s 的復(fù)雜度反而會拖慢節(jié)奏。Docker Compose 解決多服務(wù)編排已經(jīng)夠用后端服務(wù)掛了可以在編排層自動重啟。等并發(fā)量上來、需要彈縮容時再平滑遷移到 K8s配合 HPA 自動擴縮容。5.2 日志聚合與鏈路追蹤微服務(wù)排錯最怕的是什么一個請求從網(wǎng)關(guān)進(jìn)入調(diào)用auth-service、payroll-service、finance-service某一步慢了卻不知道慢在哪里。所以我們從第一天就上了鏈路追蹤選擇了 SkyWalking它有開箱即用的 UI對 Spring Cloud 支持很好不需要侵入式改代碼。每個服務(wù)在日志中必須攜帶traceId和userId。我們用 logback 配置在日志輸出中自動帶上 MDC 里的參數(shù)pattern%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level [%traceId] [%userId] %logger{36} - %msg%n/pattern這樣在排查問題時可以按照traceId把同一請求在網(wǎng)關(guān)和各服務(wù)之間的日志全部串起來。日志文件統(tǒng)一輸出到掛載目錄再用 Filebeat 采集到 Elasticsearch最終在 Kibana 里按關(guān)鍵字搜索。沒有這套東西微服務(wù)查一次錯可能要翻三個服務(wù)日志效率極低。5.3 壓測與容量預(yù)估上線前我們對核心鏈路做了壓測。壓測目標(biāo)很明確模擬發(fā)薪日 2 萬員工的算薪批量操作以及同時在線 500 人的日常查詢操作。日常查詢鏈路我們用 JMeter 并發(fā) 100 線程循環(huán)跑工資單分頁、員工查詢、部門薪酬匯總。壓測發(fā)現(xiàn)4 核 8G 實例部署一個payroll-service加 MySQL大概能支撐 300 QPS平均響應(yīng) 380ms。但算薪引擎是 CPU 密集型任務(wù)涉及大量 BigDecimal 運算同樣規(guī)格的實例單獨跑 2 萬員工批次只要 12 分鐘如果和其他服務(wù)混布在同一臺機器上響應(yīng)時間會惡化到秒級。 所以最終把salary-engine-service獨立部署并對 JVM 堆內(nèi)存做了充分配置避免在批量算薪時觸發(fā)頻繁 Full GC。壓測還發(fā)現(xiàn) Nacos 注冊中心在服務(wù)實例反復(fù)注冊注銷時如果堆內(nèi)存過小CPU 會飆升。解決方法一是給 Nacos 足夠的堆內(nèi)存二是把服務(wù)心跳刷新時間調(diào)大比如默認(rèn) 5 秒改成 10 秒減少注冊中心的壓力。這些細(xì)節(jié)不壓測根本發(fā)現(xiàn)不了。6. 實戰(zhàn)中高頻問題與排查技巧6.1 一不小心重復(fù)發(fā)薪冪等設(shè)計這是開發(fā)過程中最驚險的一次事故。測試環(huán)境做發(fā)薪演練時財務(wù)點了一次“確認(rèn)發(fā)放”前端按鈕沒做 loading 限制連點了三下。后端在沒上分布式鎖和唯一索引之前數(shù)據(jù)庫里生成了三條發(fā)放流水銀行回盤文件金額直接翻了三倍。后來我們復(fù)盤加了四層防護(hù)前端按鈕在請求期間禁用防止誤操作后端接口用同一個paymentNo做 Redis 冪等判斷Redisson 分布式鎖保護(hù)同一批次的并發(fā)處理數(shù)據(jù)庫salary_payment_log表加uk_batch_staff唯一索引四層防護(hù)層層設(shè)卡最壞情況也只是第二次請求報錯而不會多扣一筆錢。 這里要特別提醒業(yè)務(wù)邏輯里千萬別依賴“先查詢再判斷狀態(tài)”的簡單判斷因為并發(fā)請求可能同時查詢到同一狀態(tài)必須在寫入時用唯一索引或悲觀鎖兜底。6.2 Excel導(dǎo)出撐爆內(nèi)存薪酬報表導(dǎo)出是一個非常典型的坑。第一次導(dǎo)出 5 萬條工資明細(xì)時直接用 Apache POI 的XSSFWorkbook程序直接 OOM服務(wù)重啟后連正常登錄都變慢了。原因是XSSFWorkbook會把所有格子對象都創(chuàng)建并常駐內(nèi)存數(shù)據(jù)量大時極其消耗堆內(nèi)存。后來改用SXSSFWorkbook它是流式版本可以一邊寫入一邊滑動窗口刷新SXSSFWorkbook workbook new SXSSFWorkbook(1000); Sheet sheet workbook.createSheet(工資明細(xì)); int rowNo 0; for (SalaryStatement stmt : pageData) { Row row sheet.createRow(rowNo); row.createCell(0).setCellValue(stmt.getStaffId()); row.createCell(1).setCellValue(stmt.getActualAmount().doubleValue()); if (rowNo % 5000 0) { // 觸發(fā)窗口刷新釋放舊行 } }同時導(dǎo)出操作從同步接口改成后臺異步任務(wù)前端提交導(dǎo)出請求后立即返回“任務(wù)已提交”后臺分頁查詢數(shù)據(jù)庫每 5000 條刷新一次臨時文件最終把臨時文件合并后上傳到 MinIO再通過 WebSocket 通知前端下載鏈接。這樣即使導(dǎo)出 20 萬條數(shù)據(jù)也不會對在線查詢產(chǎn)生影響。6.3 網(wǎng)關(guān)超時與文件上傳限制Spring Cloud Gateway 默認(rèn)對下游請求的響應(yīng)時間有限制而發(fā)薪批次接口因為要執(zhí)行全局事務(wù)可能超過 30 秒。最初上線時前端等不到結(jié)果直接報網(wǎng)關(guān)超時但后端事務(wù)還在跑財務(wù)不確定到底發(fā)沒發(fā)非常尷尬。解決方案不是簡單調(diào)大網(wǎng)關(guān)超時時間而是把長任務(wù)改為異步。發(fā)薪接口收到請求后立刻寫入一個批次任務(wù)狀態(tài)為PENDING同步返回“任務(wù)已提交”。后續(xù)執(zhí)行結(jié)果通過 WebSocket 或輪詢接口反饋。這樣網(wǎng)關(guān)只承擔(dān)短請求超時風(fēng)險大大降低。文件上傳也有類似問題。工資單附件如果走網(wǎng)關(guān)大文件傳輸會占用網(wǎng)關(guān)線程。我們改用預(yù)簽名 URL 直傳 MinIO 后網(wǎng)關(guān)連文件內(nèi)容都不經(jīng)手壓力小了不少。再配合 Nginx 層設(shè)置client_max_body_size才真正把上傳鏈路做穩(wěn)。上傳 PDF 時我們還增加了全局過濾器解析 PDF 內(nèi)容并檢查是否存在script等危險片段防止惡意文件被當(dāng)工資條下發(fā)。6.4 分布式事務(wù)補償表設(shè)計Seata 的 AT 模式能解決大多數(shù)字段級回滾但并不代表我們可以完全不寫補償代碼。一旦全局事務(wù)分支超時或 TC 重啟可能會出現(xiàn)懸空事務(wù)。我們專門建了一張compensation_record表CREATE TABLE compensation_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, transaction_id VARCHAR(64) NOT NULL, service_name VARCHAR(64) NOT NULL, data_type VARCHAR(32) NOT NULL, data_id BIGINT NOT NULL, action_type VARCHAR(16) NOT NULL COMMENT CREATE/UPDATE/DELETE, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待補償 1已補償 2失敗, retry_count INT NOT NULL DEFAULT 0, last_error TEXT, create_time DATETIME NOT NULL, update_time DATETIME NOT NULL, UNIQUE KEY uk_transaction_data (transaction_id, service_name, data_type, data_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT分布式事務(wù)補償表;定時任務(wù)每兩分鐘掃描status 0的記錄按action_type做補償操作。補償邏輯同樣要具備冪等性例如補償“凍結(jié)資金失敗”會先查當(dāng)前資金流水是否已存在存在則直接改成成功狀態(tài)不作重復(fù)扣減。這張表上線后我們才真正敢說分布式事務(wù)是可控的。最后再說一個個人習(xí)慣薪酬系統(tǒng)上線前不管時間多緊一定要做一次完整的“發(fā)薪演練”拿整月真實數(shù)據(jù)跑一遍算薪、審批、資金凍結(jié)、生成回盤文件的流程。演練中發(fā)現(xiàn)的每一處數(shù)據(jù)差異都要追溯到根因并記錄在案。我在這個項目里最大的體會是薪酬系統(tǒng)的技術(shù)難點不在某個框架的 API而在你面對數(shù)字不一致時能否快速定位是精度問題、事務(wù)問題、還是冪等問題。這套排查能力比會寫多少行代碼都重要。