去年年底接手了一個傳統(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ù)分布式路線。這篇博文會把當初的拆分思路、技術(shù)選型、落地過程以及踩過的坑全部寫出來給正在做薪酬系統(tǒng)或準備微服務(wù)化的團隊一個真實參考。很多人一聽到“薪酬系統(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判斷硬編碼維護成本極高。第三個痛點是數(shù)據(jù)庫單點。所有模塊共用同一個 MySQL 實例月報統(tǒng)計、工資單查詢、審批流全部打在同一張庫上。大促式查詢來了索引再優(yōu)化也只是延緩問題。我們把用戶量撐到 2 萬以后一個簡單的分頁查詢在發(fā)薪日都可能要三秒以上。說到底單體不是不能用而是當業(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)一認證與鑒權(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里維護了部門、崗位、職級、員工狀態(tài)等基礎(chǔ)數(shù)據(jù)在auth-service里實現(xiàn) RBAC 模型。用戶登錄后拿到的不只是菜單列表還有一個“數(shù)據(jù)可見范圍”的表達式例如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)。這里有個容易被忽視的細節(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ī)則里存放計算表達式和優(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ù)而是只保護資金變更這一條核心鏈路。發(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 鎖失效、重試機制抽風數(shù)據(jù)庫層面也能擋住重復(fù)發(fā)放。后面我在“高頻問題”部分還會展開講這個坑。3. 技術(shù)選型與基礎(chǔ)設(shè)施落地3.1 注冊中心、網(wǎng)關(guān)與配置中心技術(shù)棧選型不能只追新還要考慮團隊運維能力。我們最終選了 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 認證鑒權(quán)Spring Security JWT OAuth2認證這塊我們單獨做了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)進來的請求里讀取用戶信息對于直接暴露的接口必須二次校驗簽名JWT 的有效期我們設(shè)置得比較短默認 30 分鐘配合 refresh token 刷新。為什么不設(shè)置 7 天因為員工離職、調(diào)崗后權(quán)限變化必須盡快生效JWT 一旦簽發(fā)有效期太長舊 token 還能繼續(xù)訪問這是薪酬系統(tǒng)不能接受的安全隱患。 refresh token 刷新時會檢查用戶當前是否還有效如果員工已離職直接拒絕刷新。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(當前發(fā)放批次正在處理中請勿重復(fù)操作); } try { // 執(zhí)行業(yè)務(wù)邏輯更新批處理狀態(tài) } finally { if (lock.isHeldByCurrentThread()) { lock.unlock(); } }Redisson 自帶看門狗機制默認會把鎖持有時間自動續(xù)期避免業(yè)務(wù)執(zhí)行時間過長導(dǎo)致鎖自動過期。 這里特別強調(diào)鎖的 key 必須帶業(yè)務(wù)維度比如salary:pay:{batchId}不能全局一把鎖。否則不同批次之間會互相阻塞嚴重降低發(fā)薪效率。分布式鎖解決的是并發(fā)問題但不是冪等的全部。接口層還要做冪等校驗比如前端在提交付款時生成一個paymentNo后端用這個唯一流水號判斷是否已經(jīng)處理過。Redis 里加一個SETNX paymentNo 1 EX 24h作為第一層過濾數(shù)據(jù)庫唯一索引作為兜底。3.4 文件存儲與消息隊列工資條 PDF、社保繳納明細、銀行回盤文件等附件不適合直接放 MySQLBLOB 查詢會拖垮數(shù)據(jù)庫性能。最開始我圖省事用 FastDFS結(jié)果配置復(fù)雜、社區(qū)維護進度慢后來直接換成了 MinIO。MinIO 部署成本低支持 S3 協(xié)議和 Spring Boot 集成非常順。文件上傳路徑我們默認不走網(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ù)照樣泄露。這個理念我在團隊里強調(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避免一個接口一個命名風格。另外工資單列表頁通常要做金額區(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因為運維團隊初期只有兩個人K8s 的復(fù)雜度反而會拖慢節(jié)奏。Docker Compose 解決多服務(wù)編排已經(jīng)夠用后端服務(wù)掛了可以在編排層自動重啟。等并發(fā)量上來、需要彈縮容時再平滑遷移到 K8s配合 HPA 自動擴縮容。5.2 日志聚合與鏈路追蹤微服務(wù)排錯最怕的是什么一個請求從網(wǎng)關(guā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ù)估上線前我們對核心鏈路做了壓測。壓測目標很明確模擬發(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)大比如默認 5 秒改成 10 秒減少注冊中心的壓力。這些細節(jié)不壓測根本發(fā)現(xiàn)不了。6. 實戰(zhàn)中高頻問題與排查技巧6.1 一不小心重復(fù)發(fā)薪冪等設(shè)計這是開發(fā)過程中最驚險的一次事故。測試環(huán)境做發(fā)薪演練時財務(wù)點了一次“確認發(fā)放”前端按鈕沒做 loading 限制連點了三下。后端在沒上分布式鎖和唯一索引之前數(shù)據(jù)庫里生成了三條發(fā)放流水銀行回盤文件金額直接翻了三倍。后來我們復(fù)盤加了四層防護前端按鈕在請求期間禁用防止誤操作后端接口用同一個paymentNo做 Redis 冪等判斷Redisson 分布式鎖保護同一批次的并發(fā)處理數(shù)據(jù)庫salary_payment_log表加uk_batch_staff唯一索引四層防護層層設(shè)卡最壞情況也只是第二次請求報錯而不會多扣一筆錢。 這里要特別提醒業(yè)務(wù)邏輯里千萬別依賴“先查詢再判斷狀態(tài)”的簡單判斷因為并發(fā)請求可能同時查詢到同一狀態(tài)必須在寫入時用唯一索引或悲觀鎖兜底。6.2 Excel導(dǎo)出撐爆內(nèi)存薪酬報表導(dǎo)出是一個非常典型的坑。第一次導(dǎo)出 5 萬條工資明細時直接用 Apache POI 的XSSFWorkbook程序直接 OOM服務(wù)重啟后連正常登錄都變慢了。原因是XSSFWorkbook會把所有格子對象都創(chuàng)建并常駐內(nèi)存數(shù)據(jù)量大時極其消耗堆內(nèi)存。后來改用SXSSFWorkbook它是流式版本可以一邊寫入一邊滑動窗口刷新SXSSFWorkbook workbook new SXSSFWorkbook(1000); Sheet sheet workbook.createSheet(工資明細); 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 默認對下游請求的響應(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)只承擔短請求超時風險大大降低。文件上傳也有類似問題。工資單附件如果走網(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等危險片段防止惡意文件被當工資條下發(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é)資金失敗”會先查當前資金流水是否已存在存在則直接改成成功狀態(tài)不作重復(fù)扣減。這張表上線后我們才真正敢說分布式事務(wù)是可控的。最后再說一個個人習(xí)慣薪酬系統(tǒng)上線前不管時間多緊一定要做一次完整的“發(fā)薪演練”拿整月真實數(shù)據(jù)跑一遍算薪、審批、資金凍結(jié)、生成回盤文件的流程。演練中發(fā)現(xiàn)的每一處數(shù)據(jù)差異都要追溯到根因并記錄在案。我在這個項目里最大的體會是薪酬系統(tǒng)的技術(shù)難點不在某個框架的 API而在你面對數(shù)字不一致時能否快速定位是精度問題、事務(wù)問題、還是冪等問題。這套排查能力比會寫多少行代碼都重要。