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