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