畢設(shè)選“基于微服務(wù)架構(gòu)的招聘平臺(tái)的設(shè)計(jì)與實(shí)現(xiàn)”這個(gè)題目是我當(dāng)年翻了兩天選題列表之后才定下來的。招聘平臺(tái)這個(gè)業(yè)務(wù)域足夠完整求職者、招聘者、企業(yè)、職位、簡歷、投遞、面試通知這些環(huán)節(jié)串起來就是一條真實(shí)業(yè)務(wù)鏈路不像圖書管理、商城那樣容易做得“一眼假”而微服務(wù)架構(gòu)這個(gè)關(guān)鍵詞本身又是評審時(shí)最能集中提問的技術(shù)加分項(xiàng)。這篇文章就把整個(gè)項(xiàng)目從選題邏輯、服務(wù)拆分、核心鏈路設(shè)計(jì)到部署排錯(cuò)、源碼整理的完整過程寫出來配套源碼也按工程化方式整理了目錄給正在做類似題目的同學(xué)一個(gè)能直接參考的版本。1. 這個(gè)畢業(yè)設(shè)計(jì)的選題邏輯招聘平臺(tái)為什么適合微服務(wù)架構(gòu)1.1 招聘業(yè)務(wù)天然就是多角色、多模塊的長鏈路場景先看平臺(tái)里有哪些角色求職者要注冊賬號、維護(hù)簡歷、搜索職位、投遞簡歷、接收面試邀請招聘者要維護(hù)企業(yè)資料、發(fā)布職位、篩選簡歷、發(fā)起面試平臺(tái)管理員要審核企業(yè)、管理職位分類、查看運(yùn)營數(shù)據(jù)。這個(gè)角色矩陣決定了系統(tǒng)最少要有三套對外入口而每套入口背后的數(shù)據(jù)模型和業(yè)務(wù)邏輯差異都很大。這正好是微服務(wù)的理想土壤。微服務(wù)強(qiáng)調(diào)的“圍繞業(yè)務(wù)能力組織服務(wù)”在招聘平臺(tái)上特別直觀用戶服務(wù)管賬號和身份企業(yè)服務(wù)管公司信息職位服務(wù)管崗位上下線簡歷服務(wù)管履歷數(shù)據(jù)投遞服務(wù)管一次應(yīng)聘行為的完整生命周期。各模塊雖然存在依賴關(guān)系但邊界比一般管理系統(tǒng)清晰得多拆開之后每個(gè)服務(wù)都能獨(dú)立講清楚自己做了什么論文里的架構(gòu)圖也不會(huì)畫得云里霧里。我當(dāng)時(shí)最實(shí)際的看法是選題要選一個(gè)“業(yè)務(wù)能拆開、技術(shù)能展開、演示能出效果”的場景。招聘平臺(tái)三條用戶鏈路都有獨(dú)立頁面、獨(dú)立接口、獨(dú)立數(shù)據(jù)天然適合用多服務(wù)去承載。如果換成新聞管理系統(tǒng)或宿舍管理系統(tǒng)硬拆微服務(wù)更像為了做微服務(wù)而做微服務(wù)答辯時(shí)第一個(gè)追問“你這里為什么必須拆”就會(huì)很難答。1.2 單體系統(tǒng)也能實(shí)現(xiàn)但技術(shù)上的“可講性”差很多并不是說單體做不了這個(gè)平臺(tái)。用 Spring Boot 寫一個(gè)大工程目錄分 controller、service、mapper照樣能把求職者和招聘者的功能全部跑通甚至開發(fā)效率更高、部署更省事。但作為畢業(yè)設(shè)計(jì)要回答的不只是“系統(tǒng)能用”還要回答“你掌握了哪些技術(shù)、解決了哪些問題”。單體唯一的討論空間是代碼分層是否清晰、表結(jié)構(gòu)是否合理這些問題的深度有限。而微服務(wù)架構(gòu)能把以下問題全部帶出來服務(wù)如何注冊發(fā)現(xiàn)、網(wǎng)關(guān)如何統(tǒng)一路由、多個(gè)服務(wù)之間怎么遠(yuǎn)程調(diào)用、跨服務(wù)的數(shù)據(jù)一致性怎么保證、分布式環(huán)境下登錄態(tài)怎么處理、海量職位數(shù)據(jù)怎么搜索。這些問題每一個(gè)對應(yīng)一套成熟的中間件或解決方案寫在論文里自然顯得充實(shí)答辯時(shí)也容易展開。用生活里的類比來說單體好比一間小飯館所有菜都在一個(gè)廚房里做簡單直接微服務(wù)則是美食廣場每個(gè)檔口獨(dú)立排煙、獨(dú)立下水但是共享廣場的客流和統(tǒng)一管理。代價(jià)是消防、排水、招商這些基礎(chǔ)設(shè)施問題全都冒出來了——對畢設(shè)而言這些“基礎(chǔ)設(shè)施問題”恰恰是加分項(xiàng)。1.3 技術(shù)棧選型與版本匹配的硬核現(xiàn)實(shí)技術(shù)選型我建議直接走國內(nèi)用得最多的那一套就業(yè)市場熟悉、社區(qū)資料多、答辯時(shí)老師也聽得懂后端 Java Spring Boot Spring Cloud Alibaba服務(wù)注冊與配置中心用 Nacos遠(yuǎn)程調(diào)用用 OpenFeign網(wǎng)關(guān)用 Spring Cloud Gateway數(shù)據(jù)庫 MySQL緩存 Redis消息隊(duì)列 RabbitMQ搜索 Elasticsearch文件存儲(chǔ)用 MinIO前端 Vue Element UI。這套組合最大的坑是版本兼容。Spring Boot、Spring Cloud、Spring Cloud Alibaba 三者對版本有嚴(yán)格要求不匹配時(shí)啟動(dòng)會(huì)報(bào)一堆莫名其妙的錯(cuò)。我當(dāng)時(shí)定的版本組合如下已經(jīng)跑通組件版本說明Spring Boot2.7.182.x 系列里維護(hù)時(shí)間較長的穩(wěn)定版Spring Cloud2021.0.8與 Spring Boot 2.7 官方對應(yīng)Spring Cloud Alibaba2021.0.5.0對應(yīng)提供 Nacos、Sentinel 等能力Nacos2.2.3注冊中心與配置中心MySQL8.0各服務(wù)獨(dú)立庫Elasticsearch7.17.9職位搜索索引存儲(chǔ)提示先確定 Spring Boot 版本再去查 Spring Cloud 的 Release Train 對應(yīng)關(guān)系最后根據(jù) spring-cloud-alibaba 的版本說明選 Alibaba 那一層。三層版本一定要一起鎖定不要單獨(dú)升級其中一個(gè)。2. 服務(wù)拆分與數(shù)據(jù)庫設(shè)計(jì)避免做成“分布式單體”的踩坑記錄2.1 九個(gè)核心服務(wù)的職責(zé)劃分與數(shù)據(jù)庫歸屬很多同學(xué)把微服務(wù)做成“分布式單體”的原因只有一個(gè)按代碼分層拆不按業(yè)務(wù)拆。比如拆出 controller 模塊、service 模塊、mapper 模塊這等于把單體換了個(gè)殼服務(wù)之間交叉調(diào)用極其混亂。正確做法是按業(yè)務(wù)領(lǐng)域拆每個(gè)服務(wù)內(nèi)部自己再走 controller-service-mapper 分層。我最終拆成九個(gè)服務(wù)每個(gè)服務(wù)配獨(dú)立數(shù)據(jù)庫表和服務(wù)的對應(yīng)關(guān)系如下服務(wù)名稱核心職責(zé)核心表auth-service注冊、登錄、令牌簽發(fā)用戶賬號表、角色表user-service求職者信息、簡歷基礎(chǔ)信息、收藏求職者表、收藏表company-service企業(yè)信息維護(hù)、HR 與企業(yè)綁定企業(yè)表、招聘者表job-service職位發(fā)布、下線、分類管理職位表、職位分類表resume-service簡歷完整內(nèi)容管理教育、項(xiàng)目、技能簡歷主表、教育經(jīng)歷表、項(xiàng)目經(jīng)歷表application-service投遞記錄、狀態(tài)流轉(zhuǎn)、面試邀約投遞表、狀態(tài)變更表notification-service站內(nèi)信、系統(tǒng)消息、郵件通知消息表search-service職位索引、關(guān)鍵詞搜索依賴 Elasticsearch 索引file-service圖片和附件簡歷的上傳、下載文件元數(shù)據(jù)表加上最外層的 gateway 和公共服務(wù) common/api 模塊整個(gè)倉庫的頂層結(jié)構(gòu)是platform-server聚合工程下面平鋪十個(gè)子模塊。為什么把求職者個(gè)人信息和簡歷內(nèi)容拆成兩個(gè)服務(wù)因?yàn)楹啔v內(nèi)容是一個(gè)可以多次編輯的附屬復(fù)雜實(shí)體而用戶基本信息被認(rèn)證、收藏等其他服務(wù)頻繁引用拆開之后可以避免簡歷表的大字段拖慢用戶服務(wù)的常規(guī)操作。2.2 獨(dú)立庫之后的關(guān)聯(lián)查詢難題聚合由接口來完成拆庫最明顯的感受是以前一條 SQL 通過 JOIN 就能查出的列表現(xiàn)在查不出來了。舉我開發(fā)時(shí)真實(shí)的一個(gè)例子管理后臺(tái)需要顯示“某職位下的投遞列表”期望列包括職位名、求職者姓名、簡歷完成度、投遞時(shí)間。在單體時(shí)代這就是application表 JOINjob表和user表。拆庫之后沒有跨庫 JOIN 可用我的做法是三步走第一步由 application-service 按職位 ID 分頁查出投遞記錄第二步從記錄里取出 user_id 集合批量調(diào)用 user-service 的一個(gè)聚合接口拿到姓名和簡歷完成度第三步再從 job-service 查出職位名。前端看到的是一個(gè)接口后端實(shí)際由三個(gè)服務(wù)配合完成。這個(gè)“批量調(diào)用后再內(nèi)存拼接”的模式是整個(gè)項(xiàng)目的核心套路。它比 N1 查詢好一點(diǎn)的地方在于兩次遠(yuǎn)程調(diào)用都是批量傳 ID、批量返回結(jié)果而不是每條記錄調(diào)一次接口否則列表 50 條數(shù)據(jù)會(huì)觸發(fā) 100 次網(wǎng)絡(luò)請求測試時(shí)直接卡死。為了減少冗余調(diào)用我還給 user-service 的“用戶基礎(chǔ)信息批量查詢”接口加了本地緩存5 分鐘內(nèi)同一個(gè)用戶集合不會(huì)二次查庫。2.3 公共約定統(tǒng)一響應(yīng)、Feign API 模塊與異常處理服務(wù)一多各寫各的返回格式會(huì)讓聯(lián)調(diào)變成災(zāi)難。我一開始沒定約定結(jié)果 user-service 返回{code:200, data:...}job-service 返回{success:true, result:...}網(wǎng)關(guān)層做統(tǒng)一封裝時(shí)差點(diǎn)改瘋。后來把所有跨服務(wù)響應(yīng)統(tǒng)一成ResultT結(jié)構(gòu)包含 code、message、data 三個(gè)字段分頁統(tǒng)一用PageResultT里面固定是 list、total、pageNum、pageSize。Feign 客戶端也不直接寫在業(yè)務(wù)服務(wù)里而是單獨(dú)拆一個(gè) api 模塊每個(gè)服務(wù)自己的 Feign 接口和 DTO 放在對應(yīng)包下。這樣做的好處是比如 application-service 想調(diào) job-service 的接口只需要在 api 模塊里定義一個(gè) JobClient 接口并加上FeignClient(name job-service)兩個(gè)服務(wù)同時(shí)依賴這個(gè) api 模塊即可。服務(wù)提供方實(shí)現(xiàn) Controller服務(wù)消費(fèi)方調(diào) Feign 接口兩邊不產(chǎn)生循環(huán)依賴接口變更也會(huì)因?yàn)?DTO 共用而第一時(shí)間在編譯期暴露。3. 最關(guān)鍵的一環(huán)簡歷投遞鏈路里的分布式事務(wù)與數(shù)據(jù)一致性3.1 一次投遞操作實(shí)際觸達(dá)了哪些服務(wù)這是整個(gè)項(xiàng)目里我最花心思的業(yè)務(wù)。用戶在前端點(diǎn)“投遞簡歷”時(shí)并不僅僅在 application-service 里插一條記錄。正常流程下它要同時(shí)做四件事創(chuàng)建投遞記錄、更新 job-service 中該職位的投遞次數(shù)、給招聘者生成一條站內(nèi)通知、如果該用戶此前收藏過這個(gè)職位則把收藏狀態(tài)置為已投遞。四個(gè)動(dòng)作分屬四個(gè)服務(wù)任意一個(gè)失敗都會(huì)造成數(shù)據(jù)對不上。我第一次設(shè)計(jì)時(shí)天真地直接在 application-service 的本地事務(wù)里用 Feign 依次調(diào)用另外三個(gè)服務(wù)結(jié)果其中一個(gè)調(diào)用超時(shí)就會(huì)導(dǎo)致投遞記錄和通知狀態(tài)不一致。3.2 果斷放棄強(qiáng)一致本地消息表 事件通知我沒有使用重量級的 Seata原因是演示環(huán)境下搭建成本高而且這種業(yè)務(wù)場景可以接受短暫不一致。最終采用的是“本地消息表 事件通知”的最終一致性方案思路如下。application-service 在本地?cái)?shù)據(jù)庫中除了投遞主表還有一張 outbox 事件表。用戶投遞時(shí)我在同一個(gè)本地事務(wù)里做兩件事插入投遞記錄插入一條狀態(tài)為“待發(fā)送”的事件記錄。本地事務(wù)保證這兩條數(shù)據(jù)要么都成功要么都失敗不會(huì)出現(xiàn)投遞成功卻沒發(fā)通知的情況。業(yè)務(wù)主流程執(zhí)行完后一個(gè)定時(shí)任務(wù)輪詢 outbox 表中“待發(fā)送”的數(shù)據(jù)把事件投遞到 RabbitMQ 的交換機(jī)同時(shí)將本地狀態(tài)改為“已發(fā)送”。job-service、notification-service、user-service 各寫一個(gè)消息監(jiān)聽器分別消費(fèi)對應(yīng)的事件去更新投遞次數(shù)、發(fā)送站內(nèi)信、更新收藏狀態(tài)。主流程不用等待這些結(jié)果所以接口響應(yīng)非常快萬一某些消費(fèi)者處理失敗消息進(jìn)入重試隊(duì)列重試一定次數(shù)后進(jìn)入死信隊(duì)列由人工檢查或定時(shí)補(bǔ)償處理。3.3 冪等消費(fèi)與補(bǔ)償機(jī)制測試中反復(fù)出現(xiàn)的重復(fù)消息引入消息之后就面臨重復(fù)消費(fèi)問題。RabbitMQ 的自動(dòng)確認(rèn)機(jī)制是消息一旦被收到就確認(rèn)如果消費(fèi)者處理完業(yè)務(wù)邏輯之后崩潰了消息不會(huì)重新投遞如果改成手動(dòng)確認(rèn)又可能因?yàn)榫W(wǎng)絡(luò)原因出現(xiàn)同一消息被投遞兩次。不管怎樣消費(fèi)端必須做冪等。我在每個(gè)消費(fèi)者入口都先查一次本地業(yè)務(wù)表job-service 里更新投遞次數(shù)前先根據(jù)事件內(nèi)的 applicationId 查詢“次數(shù)變更記錄表”如果已經(jīng)存在就直接 ACK 并返回notification-service 發(fā)送站內(nèi)信前同樣按 applicationId 查自己的“通知流水表”。配合數(shù)據(jù)庫對該流水號建唯一索引雙保險(xiǎn)避免重復(fù)通知。測試時(shí)我故意對 job-service 的監(jiān)聽器做了一次線程阻斷重啟服務(wù)后消息重新入隊(duì)結(jié)果同一事件被消費(fèi)了兩次但計(jì)數(shù)表中的記錄只插入了一條投遞次數(shù)只加了一次。這個(gè)演示動(dòng)作很能說明“最終一致性 冪等設(shè)計(jì)”的價(jià)值答辯時(shí)可以作為一個(gè)實(shí)際驗(yàn)證點(diǎn)講給評委聽。3.4 投遞狀態(tài)機(jī)把業(yè)務(wù)節(jié)點(diǎn)的每一步都變成可見數(shù)據(jù)投遞狀態(tài)我設(shè)計(jì)成一個(gè)狀態(tài)機(jī)枚舉值包括待處理、已查看、已邀約、已錄用、已拒絕、已取消。狀態(tài)變化規(guī)則明確寫在 application-service 里只有高校招聘者端根據(jù)操作觸發(fā)用戶端取消只在“待處理/已查看”階段允許錄用必須從“已邀約”狀態(tài)流轉(zhuǎn)。狀態(tài)變更都會(huì)往 state_record 表寫入一條流水記錄舊狀態(tài)、新狀態(tài)、操作人、時(shí)間。這個(gè)表的直接價(jià)值是前端時(shí)間軸組件能展示簡歷從投遞到錄用每一步的軌跡后臺(tái)也能按狀態(tài)速度統(tǒng)計(jì)每個(gè)職位的平均處理時(shí)長。其實(shí)這一步已經(jīng)不單單是功能還為論文里的數(shù)據(jù)分析部分提供了數(shù)據(jù)來源。我在論文里放了幾張狀態(tài)分布餅圖和漏斗圖答辯時(shí)明顯比純頁面截圖更有說服力。4. 網(wǎng)關(guān)、認(rèn)證與前端聯(lián)調(diào)讓用戶感覺是“一個(gè)平臺(tái)”的幕后工作4.1 JWT 在網(wǎng)關(guān)的統(tǒng)一校驗(yàn)與用戶上下文透傳微服務(wù)拆分之后登錄狀態(tài)不能再像單體那樣依賴服務(wù)端 Session因?yàn)橛脩粽埱罂赡艿谝淮蔚?application-service第二次到 resume-service兩個(gè)服務(wù)沒有共享的 Session 存儲(chǔ)。我當(dāng)時(shí)直接用 JWT Redis 的組合用戶登錄成功后auth-service 簽發(fā) token 并下發(fā)網(wǎng)關(guān)的全局過濾器攔截所有請求校驗(yàn)簽名和有效期并根據(jù)用戶請求頭中的 token 解析出用戶 id 和角色。校驗(yàn)通過后網(wǎng)關(guān)向轉(zhuǎn)發(fā)目標(biāo)請求中追加兩個(gè)自定義請求頭X-User-Id和X-User-Role。各個(gè)業(yè)務(wù)服務(wù)不自己解析 token只需要從請求頭取用戶 id 即可。這一步省去了每個(gè)服務(wù)引入 JWT 解析庫的麻煩也保證了密鑰只在網(wǎng)關(guān)層維護(hù)。服務(wù)間調(diào)用時(shí)有一個(gè)很容易忽略的點(diǎn)Feign 默認(rèn)不會(huì)自動(dòng)傳遞請求頭。application-service 調(diào) job-service 時(shí)如果目標(biāo)接口需要用戶 id我就在 Feign 的請求攔截器里把當(dāng)前的X-User-Id頭轉(zhuǎn)發(fā)過去。否則目標(biāo)服務(wù)拿不到調(diào)用者身份審計(jì)日志里所有跨服務(wù)操作都會(huì)變成未知用戶。4.2 文件服務(wù)獨(dú)立部署與附件簡歷上傳路徑簡歷附件、企業(yè) logo、職位圖片都是文件數(shù)量不大但類型多。我沒有把文件存在業(yè)務(wù)服務(wù)本地磁盤而是單獨(dú)上了 file-service MinIO。理由很簡單業(yè)務(wù)服務(wù)可能部署多個(gè)實(shí)例文件落本地會(huì)導(dǎo)致 A 實(shí)例上傳的文件在 B 實(shí)例上訪問不到獨(dú)立文件服務(wù)能把存儲(chǔ)和業(yè)務(wù)徹底解耦。前端上傳的流程是先請求 file-service 獲取一個(gè)預(yù)簽名上傳地址然后直接把文件 PUT 到 MinIO業(yè)務(wù)提交時(shí)攜帶返回的文件 id 和 URL。預(yù)簽名的好處是上傳流量不經(jīng)過后端服務(wù)服務(wù)端只管理元數(shù)據(jù)演示時(shí)用大附件也不會(huì)拖垮網(wǎng)關(guān)。這里還藏著一個(gè)坑如果不設(shè)置網(wǎng)關(guān)的請求體大小限制上傳會(huì)得到 413 錯(cuò)誤。我在 gateway 的配置里對以/api/file開頭的路由單獨(dú)設(shè)置了更大的限制參數(shù)同時(shí) Nginx 層也同步調(diào)整實(shí)測 10MB 以內(nèi)的簡歷附件都能穩(wěn)定傳輸。4.3 前端聯(lián)調(diào)階段最耗時(shí)的三個(gè)真實(shí)問題聯(lián)調(diào)階段有大量時(shí)間消耗在三個(gè)問題和業(yè)務(wù)無關(guān)但體驗(yàn)差異巨大。第一個(gè)是跨域。前端開發(fā)服務(wù)器跑在 8080 端口請求走網(wǎng)關(guān)的 8888 端口瀏覽器跨域攔截非常頻繁。最終我沒有在每個(gè)服務(wù)上配 CORS而是在網(wǎng)關(guān)層統(tǒng)一配置跨域規(guī)則前端只需要代理到網(wǎng)關(guān)地址即可。第二個(gè)是 token 過期處理。JWT 有效時(shí)長我設(shè)為 2 小時(shí)超過后請求返回 401。前端 axios 攔截器里對所有 401 做了統(tǒng)一處理清除本地 token 并跳轉(zhuǎn)登錄頁。如果不做這個(gè)統(tǒng)一處理用戶會(huì)在某個(gè)子功能頁面突然卡住要手動(dòng)清緩存才能恢復(fù)。第三個(gè)是接口路徑前綴。九個(gè)服務(wù)有九套 Controller 路徑前端如果直接訪問會(huì)出現(xiàn)大量雜亂調(diào)用我讓所有請求統(tǒng)一走網(wǎng)關(guān)前綴路由例如/api/job/**轉(zhuǎn)發(fā)到 job-service/api/resume/**轉(zhuǎn)發(fā)到 resume-service。前端 axios 的基礎(chǔ)地址只配一個(gè)網(wǎng)關(guān)地址業(yè)務(wù)代碼里寫相對路徑即可。5. 搜索與推薦模塊讓畢設(shè)從“普通 CRUD”升級為“有點(diǎn)東西”5.1 搜索方案演進(jìn)從 SQL LIKE 到 Elasticsearch 分詞檢索前期為了快速跑通功能職位搜索用的是 MySQL 的LIKE %關(guān)鍵詞%。數(shù)據(jù)量幾百條時(shí)感受不到問題當(dāng)我用腳本生成五千條職位數(shù)據(jù)后一次搜索要 200 毫秒以上而且“Java工程師”搜不到“Java開發(fā)工程師”因?yàn)殛P(guān)鍵詞完全匹配不上。這暴露了關(guān)系型數(shù)據(jù)庫做全文搜索的兩個(gè)天花板性能瓶頸和中文分詞能力不足。后期引入 Elasticsearch 后我在 job-service 發(fā)布和更新職位時(shí)通過 RabbitMQ 發(fā)送索引事件search-service 消費(fèi)后調(diào)用文檔 API 寫入索引。索引字段包括職位標(biāo)題、職位描述、技能標(biāo)簽、城市、薪資范圍。使用前需要安裝 ik 分詞插件中文分詞才能把“Java開發(fā)工程師”正確切分為“Java/開發(fā)/工程師”。搜索接口的返回策略是由 search-service 負(fù)責(zé)解析用戶輸入、執(zhí)行查詢、拿到職位 id 集合和命中分?jǐn)?shù)再批量調(diào)用 job-service 查詢職位詳情。這樣搜索結(jié)果頁上展示的職位信息仍然來自業(yè)務(wù)數(shù)據(jù)庫不會(huì)出現(xiàn)索引字段和數(shù)據(jù)庫字段不一致的問題。5.2 推薦模塊如何做到“能講原理又不過度復(fù)雜”推薦功能是很多畢設(shè)的加分點(diǎn)但一上來就寫協(xié)同過濾和 Word2Vec 會(huì)把項(xiàng)目周期拖垮。我的落地方案是“基于標(biāo)簽匹配 熱度加權(quán)”的內(nèi)容推薦給每個(gè)職位打技能標(biāo)簽Java、Python、前端、算法等簡歷填寫時(shí)也讓用戶選擇期望技能標(biāo)簽系統(tǒng)按標(biāo)簽重合度計(jì)算初始得分再疊加職位熱度、發(fā)布時(shí)間新鮮度和收藏量做加權(quán)排序。比如一個(gè)同時(shí)選了 Java 和 Spring Boot 標(biāo)簽的求職者系統(tǒng)會(huì)把包含這兩個(gè)標(biāo)簽的職位命中分?jǐn)?shù)抬高再優(yōu)先展示新鮮發(fā)布的職位。邏輯上它不復(fù)雜但在演示效果上非常自然注冊時(shí)選擇標(biāo)簽、完善簡歷、瀏覽首頁推薦每一步數(shù)據(jù)都能呼應(yīng)上。答辯時(shí)可以真誠地說這是一個(gè)輕量級內(nèi)容推薦如果數(shù)據(jù)量上來會(huì)換成 Embedding 向量檢索表明你了解演進(jìn)路線而不是不懂。這個(gè)模塊我還做了一個(gè)人工干預(yù)規(guī)則如果求職者最近五天內(nèi)瀏覽過某類職位瀏覽記錄會(huì)進(jìn)入 Redis 緩存推薦接口會(huì)把同類職位的權(quán)重再提高 15%。規(guī)則雖然簡單但足以在演示時(shí)制造“越用越精準(zhǔn)”的觀感。5.3 構(gòu)造測試數(shù)據(jù)與演示效果別等答辯時(shí)才發(fā)現(xiàn)搜不出東西推薦和搜索都需要數(shù)據(jù)量才能看出效果。我用 Python 腳本生成了一批模擬職位數(shù)據(jù)包括職位標(biāo)題、描述、標(biāo)簽、薪資、城市、發(fā)布時(shí)間另一個(gè)腳本生成模擬求職者數(shù)據(jù)。總共構(gòu)造了約 6000 個(gè)職位和 300 個(gè)用戶發(fā)布的職位按時(shí)間均勻分布以避開“首頁最新職位十頁都翻不完”的情況。建議測試數(shù)據(jù)腳本要和源碼一起放并寫清楚怎么重新生成。我見過很多同學(xué)手動(dòng)造一百條數(shù)據(jù)答辯前換臺(tái)機(jī)器發(fā)現(xiàn)數(shù)據(jù)庫是空的當(dāng)場手忙尾亂有了腳本就可以一鍵復(fù)活演示環(huán)境。演示串場順序我當(dāng)時(shí)也排練過先在管理后臺(tái)發(fā)布一個(gè)新職位然后在求職端搜索剛才的關(guān)鍵詞接著用有標(biāo)簽偏好的用戶登錄首頁看推薦最后體驗(yàn)投遞鏈路并到招聘者端收到站內(nèi)信。整條鏈路從一個(gè)動(dòng)作觸發(fā)多個(gè)服務(wù)協(xié)作的效果一目了然比反復(fù)切頁面翻列表更有說服力。6. 開發(fā)完成之后源碼整理、演示環(huán)境部署與答辯準(zhǔn)備6.1 源碼目錄結(jié)構(gòu)與 README 的工程規(guī)范項(xiàng)目做完源碼整理是很多同學(xué)忽略但評委一定會(huì)看的部分。合理的目錄結(jié)構(gòu)應(yīng)該讓一個(gè)陌生人打開倉庫就能看懂入口在哪。我的工程結(jié)構(gòu)大致如下。platform-root ├── api # Feign 接口與跨服務(wù) DTO ├── common # 統(tǒng)一返回、異常處理、工具類 ├── gateway # 網(wǎng)關(guān)服務(wù) ├── auth-service # 認(rèn)證服務(wù) ├── user-service # 用戶服務(wù) ├── company-service # 企業(yè)服務(wù) ├── job-service # 職位服務(wù) ├── resume-service # 簡歷服務(wù) ├── application-service # 投遞服務(wù) ├── notification-service # 通知服務(wù) ├── search-service # 搜索服務(wù) ├── file-service # 文件服務(wù) ├── frontend # 前端工程 ├── sql # 初始化數(shù)據(jù)庫腳本 ├── script # 測試數(shù)據(jù)生成腳本 └── docs # 架構(gòu)設(shè)計(jì)文檔、接口文檔README 里我建議固定寫五塊內(nèi)容項(xiàng)目簡介與功能清單、架構(gòu)圖、環(huán)境要求與版本號、本地啟動(dòng)步驟、默認(rèn)測試賬號。啟動(dòng)步驟要寫具體到先啟動(dòng) Nacos再啟動(dòng)網(wǎng)關(guān)再按依賴順序啟動(dòng)業(yè)務(wù)服務(wù)很多老師會(huì)根據(jù) README 在本地實(shí)際操作驗(yàn)證寫清楚就是隱性加分項(xiàng)。6.2 演示環(huán)境部署踩過的坑端口、內(nèi)存、時(shí)區(qū)、分詞器這部分是實(shí)戰(zhàn)頻率最高的地方我把沿路填平的坑列成一個(gè)印象深刻的清單。第一個(gè)是 Nacos 的端口。Nacos 2.x 默認(rèn)客戶端通信除了 8848 還需要 9848 端口。我曾在防火墻只放行 8848 的機(jī)器上部署所有服務(wù)反復(fù)注冊失敗排查半天才發(fā)現(xiàn)是 9848 被擋。Nacos 的配置里不對齊新舊端口服務(wù)就一直連不上注冊中心。第二個(gè)是服務(wù)內(nèi)存不夠。九個(gè)服務(wù)全部默認(rèn) JVM 啟動(dòng)參數(shù)的話演示筆記本 16G 內(nèi)存也會(huì)吃緊。我給每個(gè)服務(wù)的啟動(dòng)腳本統(tǒng)一加了-Xmx128m -Xms64m網(wǎng)關(guān)和 auth-service 略高內(nèi)存占用降到 3G 以內(nèi)多開幾個(gè)服務(wù)也不會(huì)卡死。記得在文檔里寫明這是因?yàn)楣?jié)省演示資源而故意調(diào)低的內(nèi)存參數(shù)避免被誤以為代碼有泄漏。第三個(gè)是 MySQL 連接串的時(shí)區(qū)。服務(wù)第一次連接 MySQL 8.0 時(shí)報(bào)時(shí)區(qū)錯(cuò)誤連接串加上serverTimezoneAsia/Shanghai就解決。第四個(gè)是 Elasticsearch 啟動(dòng)后沒裝 ik 分詞插件就導(dǎo)入索引中文職位名被切成一個(gè)個(gè)單字搜“大數(shù)據(jù)”只匹配到“大”和“數(shù)據(jù)”兩個(gè)孤立詞結(jié)果排序完全錯(cuò)亂。分詞器這件事我記得特別深因?yàn)樾Ч町愔庇^到截圖對比時(shí)不用解釋一個(gè)字。6.3 如果重新做一遍我會(huì)優(yōu)先優(yōu)化的四個(gè)環(huán)節(jié)整套系統(tǒng)開發(fā)、測試、演示下來有些地方我認(rèn)為還能更好。如果一個(gè)同學(xué)要以這個(gè)項(xiàng)目為基礎(chǔ)繼續(xù)改進(jìn)我最建議從四個(gè)環(huán)節(jié)下手。第一個(gè)是引入服務(wù)熔斷和限流。目前跨服務(wù)調(diào)用只是做了超時(shí)設(shè)置沒有引入 Sentinel 做熔斷降級。如果投遞服務(wù)調(diào)用通知服務(wù)持續(xù)超時(shí)調(diào)用線程很快被堆積整個(gè)服務(wù)都可能拖掛。加上熔斷之后通知服務(wù)異常時(shí)快速失敗并返回提示用戶體驗(yàn)會(huì)好很多。第二個(gè)是核心鏈路考慮分布式事務(wù)組件。本地消息表方案可靠但開發(fā)成本高事務(wù)消息和服務(wù)狀態(tài)散落各服務(wù)排查鏈路需要打開很多日志。后期如果面向生產(chǎn)我會(huì)把簡歷投遞這個(gè)短鏈路改用 Seata 的 AT 模式直連交易代碼會(huì)簡化很大一部分。第三個(gè)是前端先 Mock 再聯(lián)調(diào)。我一開始邊寫前端邊等后端接口兩邊經(jīng)?；ハ嗤线M(jìn)度。重新做的話前端先按接口文檔 Mock 數(shù)據(jù)把頁面全部跑通后端就緒后再把 Mock 切到真實(shí)網(wǎng)關(guān)聯(lián)調(diào)效率至少能提升三分之一。第四個(gè)是引入統(tǒng)一日志鏈路追蹤。服務(wù)調(diào)用鏈橫跨多個(gè)服務(wù)時(shí)出問題是靠日志里的請求 ID 手動(dòng)串聯(lián)查找的非常痛苦。重新做的話我會(huì)在網(wǎng)關(guān)生成 traceId 并順勢傳遞到所有下游服務(wù)集中收集到 ELK 里定位問題時(shí)間可以從分鐘級降到秒級。說到底畢業(yè)設(shè)計(jì)折騰幾個(gè)月最后拿到的不是一句“答辯通過”而是對“一個(gè)完整系統(tǒng)是如何被設(shè)計(jì)出來的”有了身體記憶。微服務(wù)架構(gòu)是加分項(xiàng)但真正讓你站穩(wěn)的永遠(yuǎn)是那些親手踩過的坑、親手補(bǔ)上的邊界。這個(gè)項(xiàng)目里的配套源碼已經(jīng)把上述絕大部分內(nèi)容按工程標(biāo)準(zhǔn)整理好了后續(xù)開發(fā)、二次擴(kuò)展都有現(xiàn)成的起點(diǎn)這也是我最初想把它做成畢業(yè)設(shè)計(jì)的原因。