汽車資訊網(wǎng)站聽起來像是早十年就該被做濫了的項(xiàng)目但真到自己動(dòng)手設(shè)計(jì)實(shí)現(xiàn)時(shí)才發(fā)現(xiàn)里面藏著不少值得琢磨的細(xì)節(jié)。不是簡單堆幾個(gè)頁面、連一個(gè)數(shù)據(jù)庫就能交差的尤其是當(dāng)你希望它像一個(gè)真正能跑起來的產(chǎn)品而不是課程設(shè)計(jì)級別的Demo。這段時(shí)間我從零搭了一套基于Spring Boot的汽車資訊系統(tǒng)從功能拆分到實(shí)際編碼落地踩了一些坑也想明白了一些設(shè)計(jì)上的取舍。這篇就把整個(gè)設(shè)計(jì)實(shí)現(xiàn)過程拆開聊聊把關(guān)鍵的選擇邏輯和代碼細(xì)節(jié)一并捋清楚。1. 項(xiàng)目整體設(shè)計(jì)與功能拆解1.1 核心需求解析做系統(tǒng)之前先得把汽車資訊網(wǎng)站到底要解決什么問題拆明白。汽車資訊類網(wǎng)站的典型使用場景是什么用戶上來想干什么無非三類需求。第一類是瀏覽資訊包括新車發(fā)布、車型評測、行業(yè)動(dòng)態(tài)、導(dǎo)購?fù)扑]之類的內(nèi)容。第二類是互動(dòng)表達(dá)看到感興趣的文章點(diǎn)個(gè)贊、收藏一下、留個(gè)評論。第三類是內(nèi)容管理也就是網(wǎng)站運(yùn)營方要能發(fā)布文章、管理欄目、審核評論、查看數(shù)據(jù)?；谶@些場景系統(tǒng)的角色可以劃分為兩類。一類是普通用戶另一類是內(nèi)容管理員。用戶端需要的是清晰的內(nèi)容展示、順滑的瀏覽體驗(yàn)、以及基礎(chǔ)的互動(dòng)能力。管理員端則需要一個(gè)能支撐日常內(nèi)容維護(hù)的后臺(tái)界面和配套接口。把需求落成功能模塊大概是這樣一張清單用戶模塊注冊、登錄、個(gè)人信息查看與維護(hù)資訊模塊文章列表、文章詳情、分類篩選、關(guān)鍵詞搜索互動(dòng)模塊點(diǎn)贊、收藏、評論、評論列表管理模塊欄目管理、文章發(fā)布與上下架、評論審核刪除、用戶狀態(tài)管理數(shù)據(jù)統(tǒng)計(jì)模塊資訊瀏覽量統(tǒng)計(jì)、熱門排行這套功能邊界看著基礎(chǔ)但實(shí)際做起來涉及很多設(shè)計(jì)決策。比如用戶登錄用傳統(tǒng)的Session還是用JWT資訊搜索用數(shù)據(jù)庫模糊查詢還是引入搜索引擎權(quán)限校驗(yàn)寫死在代碼里還是用Spring Security做統(tǒng)一攔截這些問題的答案決定了整個(gè)項(xiàng)目寫起來是順滑還是別扭。1.2 功能模塊邊界劃分模塊邊界如果劃不清楚寫代碼的時(shí)候很容易出現(xiàn)這個(gè)Service該放哪的糾結(jié)。我按職責(zé)把系統(tǒng)分成了五個(gè)核心模塊每個(gè)模塊只關(guān)心自己范圍內(nèi)的事情用戶模塊user負(fù)責(zé)賬號的注冊、登錄、鑒權(quán)。這里包含用戶基本信息表、登錄狀態(tài)管理、個(gè)人資料接口但不負(fù)責(zé)具體資訊內(nèi)容的加工。資訊模塊content負(fù)責(zé)文章、欄目、標(biāo)簽的增刪改查。一篇資訊從創(chuàng)建到展示經(jīng)過欄目歸屬、狀態(tài)校驗(yàn)、內(nèi)容組裝全部在這個(gè)模塊內(nèi)閉環(huán)?；?dòng)模塊interaction處理點(diǎn)贊、收藏、評論三類行為。這個(gè)模塊與用戶模塊、資訊模塊會(huì)有關(guān)聯(lián)但通過userId和articleId做弱耦合互不直接操作對方的表。管理模塊admin面向前臺(tái)管理員的接口集合。它調(diào)用用戶模塊和資訊模塊的底層服務(wù)但在Controller層與管理端接口分開便于做獨(dú)立的權(quán)限控制。統(tǒng)計(jì)模塊stats負(fù)責(zé)瀏覽量計(jì)數(shù)和排行數(shù)據(jù)的產(chǎn)出。為了不拖慢主流程我把它設(shè)計(jì)為異步采集、定時(shí)匯總的模式而不是每次請求都去做重聚合運(yùn)算。這樣劃分之后開發(fā)次序就很清晰了。先做用戶和資訊兩大基礎(chǔ)模塊因?yàn)樗鼈兂休d了系統(tǒng)的骨架?；?dòng)模塊隨后接入因?yàn)樗蕾嚽皟烧叩闹麈IID做關(guān)聯(lián)。統(tǒng)計(jì)模塊放最后等基礎(chǔ)功能穩(wěn)定之后再考慮數(shù)據(jù)的挖掘和展示。2. 技術(shù)選型與核心工具解析2.1 框架選型背后的理由Spring Boot本身解決的核心痛點(diǎn)是配置繁瑣、依賴管理混亂。用了它之后以往SSH時(shí)代那一大堆XML配置基本可以丟掉了一個(gè)啟動(dòng)類加約定大于配置的理念能夠把精力集中在業(yè)務(wù)代碼上。具體到這個(gè)項(xiàng)目我選用了Spring Boot 2.7.x版本。之所以沒有選擇最新的3.x主要考慮到生態(tài)兼容性的問題很多配套的第三方組件對3.x的Jakarta命名空間支持還不夠完善。對于一個(gè)資訊網(wǎng)站這種CRUD密集型業(yè)務(wù)來說2.7.x已經(jīng)綽綽有余而且網(wǎng)上踩坑資料也多遇到了問題容易查到解決方案。在持久層框架上我選了MyBatis-Plus。在實(shí)際開發(fā)中單表的增刪改查如果用原生的MyBatis需要手動(dòng)寫大量的重復(fù)SQL。MyBatis-Plus的BaseMapper提供了現(xiàn)成的通用方法配合Wrapper構(gòu)造器可以應(yīng)對絕大多數(shù)查詢場景讓我能省下時(shí)間專注在復(fù)雜查詢的SQL優(yōu)化上。安全框架用的是Spring Security加JWT。Session方案的痛點(diǎn)在于服務(wù)端要存狀態(tài)、處理跨域時(shí)很麻煩、水平擴(kuò)展時(shí)還要考慮Session共享這些對前后端分離的架構(gòu)都不友好。JWT令牌是無狀態(tài)的服務(wù)端不用保存會(huì)話客戶端帶著Token請求就行了。配合Spring Security的過濾器鏈做統(tǒng)一鑒權(quán)邏輯清晰也符合現(xiàn)在主流的前后端分離開發(fā)模式。2.2 數(shù)據(jù)存儲(chǔ)與檢索方案選型數(shù)據(jù)庫毫無疑問是MySQL。汽車資訊系統(tǒng)的數(shù)據(jù)模型不算復(fù)雜主要是用戶表、資訊表、評論表這幾張核心表MySQL的InnoDB引擎在事務(wù)支持和行級鎖方面的表現(xiàn)足夠勝任。但是資訊的搜索功能光用MySQL會(huì)有點(diǎn)難受。文章標(biāo)題和內(nèi)容的模糊查詢?nèi)绻苯由螸IKE %關(guān)鍵詞%在數(shù)據(jù)量大了之后性能會(huì)明顯下降。不過我考慮到這個(gè)項(xiàng)目的定位是中小規(guī)模的業(yè)務(wù)場景初期不引入Elasticsearch這種重組件。我采用的折中方案是先用MySQL的全文索引配合必要的查詢優(yōu)化處理搜索需求同時(shí)在表結(jié)構(gòu)設(shè)計(jì)時(shí)預(yù)留text字段的檢索余地。如果未來資訊量真的漲到幾十萬條再平滑遷移到Elasticsearch也不遲。緩存層我用了Redis。在這個(gè)項(xiàng)目里Redis承擔(dān)兩個(gè)職責(zé)一是存儲(chǔ)熱點(diǎn)資訊的詳情數(shù)據(jù)避免每次請求都穿透到數(shù)據(jù)庫二是維護(hù)部分統(tǒng)計(jì)計(jì)數(shù)比如瀏覽量這種高頻寫入的數(shù)據(jù)直接走Redis的INCR命令定時(shí)刷入MySQL。這樣不僅查詢快了數(shù)據(jù)庫的壓力也小了很多。2.3 配置管理設(shè)計(jì)配置管理這塊我按照環(huán)境拆分了配置文件。開發(fā)環(huán)境用application-dev.yml生產(chǎn)環(huán)境用application-prod.yml主配置文件里只放兩類環(huán)境通用的配置項(xiàng)。數(shù)據(jù)源、Redis連接、日志級別這些按環(huán)境區(qū)分開的配置在各自的配置文件里單獨(dú)維護(hù)。有一個(gè)細(xì)節(jié)容易被忽略數(shù)據(jù)庫密碼、JWT密鑰這類敏感信息不應(yīng)該明文寫在配置文件里。在部署階段我改為通過環(huán)境變量的方式注入配置文件中只保留占位符。這是從安全角度考量的做法雖然本地開發(fā)時(shí)會(huì)麻煩一點(diǎn)但能避免密碼泄露的風(fēng)險(xiǎn)。3. 數(shù)據(jù)庫設(shè)計(jì)與核心模塊實(shí)現(xiàn)3.1 核心表結(jié)構(gòu)設(shè)計(jì)數(shù)據(jù)庫設(shè)計(jì)是整個(gè)系統(tǒng)動(dòng)工前的第一道工序表結(jié)構(gòu)定得不合理后面所有代碼寫起來都別扭。我用了大概半天時(shí)間梳理字段、確定關(guān)聯(lián)關(guān)系最終落成這幾張核心表。用戶表users的設(shè)計(jì)除了常規(guī)的id、用戶名、密碼之外我額外加了status字段做賬號狀態(tài)標(biāo)記以及avatar、phone這類可選信息字段。密碼字段我選用了BCrypt加密后的哈希值存儲(chǔ)固定長度60字符所以字段類型設(shè)為varchar(60)就足夠了。資訊表articles是內(nèi)容的核心載體字段相對多?；拘畔?biāo)題、摘要、正文內(nèi)容、封面圖URL、所屬欄目ID。狀態(tài)字段用來區(qū)分草稿、已發(fā)布、已下架幾種狀態(tài)。瀏覽數(shù)字段用于展示閱讀量。為了防止管理后臺(tái)編輯時(shí)內(nèi)容過大影響查詢性能我把正文單獨(dú)放在longtext類型的body字段里列表查詢時(shí)只select必要字段不把正文撈出來。評論表comments記錄了用戶對資訊的評論內(nèi)容。除了正文和關(guān)聯(lián)的文章ID我還設(shè)計(jì)了parent_id字段支持樓中樓的回復(fù)場景。另外通過audit_status字段控制評論的展示狀態(tài)新評論默認(rèn)處于待審核狀態(tài)管理員確認(rèn)無違規(guī)后才對外展示?；?dòng)關(guān)系表和統(tǒng)計(jì)計(jì)數(shù)我單獨(dú)處理。點(diǎn)贊、收藏這類行為記錄關(guān)聯(lián)表我會(huì)連帶著把用戶的ID、內(nèi)容ID加上做成唯一約束避免用戶重復(fù)操作產(chǎn)生臟數(shù)據(jù)。瀏覽量和點(diǎn)贊數(shù)的數(shù)值字段直接冗余在文章表里通過事務(wù)保證關(guān)聯(lián)表和計(jì)數(shù)的一致性。3.2 權(quán)限體系與接口設(shè)計(jì)規(guī)范接口設(shè)計(jì)遵循RESTful風(fēng)格資源的動(dòng)作通過HTTP方法表達(dá)通過URL定位資源。登錄注冊用POST獲取文章列表用GET刪除評論用DELETE更新的操作用PUT。接口路徑上也能清晰看出資源層級比如/articles/{id}/comments是某篇文章的評論列表/users/{id}/favorites是某用戶的收藏列表。接口分兩類來設(shè)計(jì)權(quán)限。一類是公開接口比如注冊登錄、文章列表、文章詳情。另一類是認(rèn)證接口比如發(fā)布評論、點(diǎn)贊收藏、進(jìn)入后臺(tái)管理必須攜帶有效的Token才能訪問。后臺(tái)管理的權(quán)限需要單獨(dú)分級管理員可以管理資訊內(nèi)容和用戶狀態(tài)普通操作員只能維護(hù)資訊內(nèi)容。Spring Security里通過配置多個(gè)SecurityFilterChain實(shí)現(xiàn)不同的安全規(guī)則/api/admin/開頭的路徑走管理端認(rèn)證規(guī)則/api/user/開頭的路徑走用戶端認(rèn)證規(guī)則兩個(gè)鏈互不干擾。3.3 核心表DDL與數(shù)據(jù)關(guān)系示意在設(shè)計(jì)階段我整理出了核心表之間的關(guān)系脈絡(luò)作為開發(fā)時(shí)手寫SQL和數(shù)據(jù)訪問的依據(jù)。項(xiàng)目里并不使用外鍵約束關(guān)聯(lián)關(guān)系完全通過邏輯上的ID對應(yīng)來維護(hù)這樣在分庫分表或數(shù)據(jù)歸檔時(shí)不會(huì)受物理外鍵的拖累。用戶表和資訊表的關(guān)系主要體現(xiàn)在創(chuàng)建者字段上。文章表里存user_id表示誰發(fā)布了這篇文章。資訊表和欄目的關(guān)系則通過column_id來歸屬欄目欄目表負(fù)責(zé)維護(hù)一層分類信息。用戶與資訊的互動(dòng)關(guān)系通過中間表表達(dá)比如用戶表與資訊表的點(diǎn)贊關(guān)系映射成一張favorites表里面只存user_id和article_id?？紤]到一篇資訊下評論數(shù)量比較多評論表里單獨(dú)存article_id做索引分頁查出指定文章的評論列表。字段命名時(shí)我堅(jiān)持了統(tǒng)一規(guī)范主鍵統(tǒng)一叫id外鍵關(guān)聯(lián)統(tǒng)一用xxx_id的格式時(shí)間字段統(tǒng)一叫create_time和update_time。這樣即使項(xiàng)目做到后期接手同事也能快速理解數(shù)據(jù)結(jié)構(gòu)不用翻著文檔猜來猜去。3.4 分頁查詢與數(shù)據(jù)組裝優(yōu)化列表頁和后臺(tái)管理頁都離不開分頁。MyBatis-Plus的分頁插件使用很簡單傳入當(dāng)前頁和每頁條數(shù)就能拿到分頁結(jié)果。但真正需要花心思的是分頁之外的數(shù)據(jù)組裝。文章列表接口返回給前端時(shí)不能只給數(shù)據(jù)庫里的原始字段。前端還需要知道作者的名字、文章所屬的欄目名稱、以及點(diǎn)贊和評論的計(jì)數(shù)。如果用循環(huán)去數(shù)據(jù)庫里逐條查關(guān)聯(lián)數(shù)據(jù)N1問題就出現(xiàn)了列表接口會(huì)慢得讓人崩潰。我的處理辦法是先查出當(dāng)前頁的文章ID集合然后用IN查詢一次性查出所有關(guān)聯(lián)的用戶信息、欄目信息、計(jì)數(shù)信息在內(nèi)存里做一次Map匹配組裝。這樣無論一頁是10條還是20條記錄查詢次數(shù)都保持在一個(gè)穩(wěn)定的數(shù)量級性能表現(xiàn)非常好。4. 關(guān)鍵功能實(shí)操與代碼落地4.1 基于JWT的登錄鑒權(quán)實(shí)現(xiàn)登錄功能看起來簡單實(shí)際上涉及Spring Security的過濾器鏈配置、JWT工具類的封裝、以及UserDetailsService的對接幾個(gè)環(huán)節(jié)任何一個(gè)地方銜接不上登錄流程都跑不通。先看JWT工具類的核心邏輯。生成Token時(shí)我把用戶ID和用戶名放進(jìn)了claims里同時(shí)設(shè)置了過期時(shí)間。解析Token時(shí)通過密鑰校驗(yàn)簽名并從claims中提取用戶IDComponent public class JwtTokenProvider { private final String secretKey your-secret-key-at-least-32-chars-long; private final long validityInMilliseconds 7200000; // 2小時(shí) public String createToken(Long userId, String username) { Date now new Date(); Date validity new Date(now.getTime() validityInMilliseconds); return Jwts.builder() .setSubject(String.valueOf(userId)) .claim(username, username) .setIssuedAt(now) .setExpiration(validity) .signWith(Keys.hmacShaKeyFor(secretKey.getBytes()), SignatureAlgorithm.HS256) .compact(); } public Long getUserIdFromToken(String token) { Claims claims Jwts.parserBuilder() .setSigningKey(secretKey.getBytes()) .build() .parseClaimsJws(token) .getBody(); return Long.valueOf(claims.getSubject()); } public boolean validateToken(String token) { try { Jwts.parserBuilder().setSigningKey(secretKey.getBytes()).build().parseClaimsJws(token); return true; } catch (JwtException | IllegalArgumentException e) { return false; } } }實(shí)際項(xiàng)目中密鑰不應(yīng)該硬編碼在代碼里應(yīng)該通過配置中心或環(huán)境變量注入這里只是便于演示。認(rèn)證過濾器的職責(zé)是從請求頭里讀取Token校驗(yàn)通過后把用戶信息放進(jìn)SecurityContext中讓后續(xù)的接口可以直接獲取當(dāng)前登錄用戶Component public class JwtAuthenticationFilter extends OncePerRequestFilter { Autowired private JwtTokenProvider jwtTokenProvider; Override protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException { String token resolveToken(request); if (token ! null jwtTokenProvider.validateToken(token)) { Long userId jwtTokenProvider.getUserIdFromToken(token); UsernamePasswordAuthenticationToken authentication new UsernamePasswordAuthenticationToken(userId, null, Collections.emptyList()); SecurityContextHolder.getContext().setAuthentication(authentication); } filterChain.doFilter(request, response); } private String resolveToken(HttpServletRequest request) { String bearerToken request.getHeader(Authorization); if (bearerToken ! null bearerToken.startsWith(Bearer )) { return bearerToken.substring(7); } return null; } }登錄接口本身比較簡單先根據(jù)用戶名查出用戶再用BCrypt校驗(yàn)密碼是否匹配匹配通過就生成Token返回給前端。這里有一個(gè)設(shè)計(jì)上的小決策查詢用戶時(shí)如果查不到不應(yīng)該直接拋異常而是統(tǒng)一拋一個(gè)業(yè)務(wù)異常讓全局異常處理器把用戶名或密碼錯(cuò)誤的提示返回給前端避免暴露用戶是否存在的信息。4.2 資訊列表與詳情接口實(shí)現(xiàn)資訊列表接口是面向用戶的主入口需要考慮分類篩選、發(fā)布時(shí)間排序、分頁等因素。如果是后臺(tái)管理的列表接口還需要疊加狀態(tài)篩選能力兩套場景應(yīng)該分開實(shí)現(xiàn)。用戶端列表接口我用條件構(gòu)造器實(shí)現(xiàn)Override public PageResultArticleVO getPublishedArticles(Long columnId, int page, int size) { PageArticle pageParam new Page(page, size); LambdaQueryWrapperArticle wrapper new LambdaQueryWrapper(); wrapper.eq(Article::getStatus, 1); // 已發(fā)布 if (columnId ! null) { wrapper.eq(Article::getColumnId, columnId); } wrapper.orderByDesc(Article::getPublishTime); PageArticle articlePage articleMapper.selectPage(pageParam, wrapper); ListArticleVO voList buildArticleVOList(articlePage.getRecords()); return new PageResult(voList, articlePage.getTotal()); }buildArticleVOList方法里處理數(shù)據(jù)組裝的問題。通過收集全部記錄里的userId和columnId分別查詢得到用戶Map和欄目Map再遍歷填充private ListArticleVO buildArticleVOList(ListArticle records) { if (records null || records.isEmpty()) { return Collections.emptyList(); } SetLong userIds records.stream().map(Article::getUserId).collect(Collectors.toSet()); SetLong columnIds records.stream().map(Article::getColumnId).collect(Collectors.toSet()); MapLong, String userNames userService.getUserNamesByIds(userIds); MapLong, String columnNames columnService.getColumnNamesByIds(columnIds); return records.stream().map(article - { ArticleVO vo new ArticleVO(); BeanUtils.copyProperties(article, vo); vo.setAuthorName(userNames.getOrDefault(article.getUserId(), 未知用戶)); vo.setColumnName(columnNames.getOrDefault(article.getColumnId(), 未分類)); return vo; }).collect(Collectors.toList()); }文章詳情的實(shí)現(xiàn)比列表多一點(diǎn)細(xì)節(jié)。每次訪問詳情頁瀏覽量都要加一。我選擇直接更新文章表中的view_count字段通過Redis的INCR緩存熱點(diǎn)數(shù)據(jù)異步刷盤。為了減少高并發(fā)下的鎖競爭更新瀏覽量的SQL只針對主鍵做條件更新不校驗(yàn)原值Update(UPDATE articles SET view_count view_count 1 WHERE id #{articleId}) void increaseViewCount(Param(articleId) Long articleId);這樣做雖然極端場景下會(huì)有少量計(jì)數(shù)丟失但換取的是寫入性能的提升。對資訊系統(tǒng)來說瀏覽量的精準(zhǔn)度并不是業(yè)務(wù)核心指標(biāo)完全夠用。4.3 全文搜索的落地實(shí)現(xiàn)搜索這塊我沒有引入Elasticsearch而是用了MySQL的全文索引配合MyBatis-Plus的自定義SQL。一張資訊表要支持標(biāo)題和內(nèi)容的搜索在表結(jié)構(gòu)上先做文章建表時(shí)給title和body字段加上全文索引或者通過ALTER TABLE動(dòng)態(tài)添加ALTER TABLE articles ADD FULLTEXT INDEX ft_title_body (title, body);查詢時(shí)使用MATCH AGAINST語法來做相關(guān)度匹配Select(SELECT * FROM articles WHERE MATCH(title, body) AGAINST(#{keyword} IN NATURAL LANGUAGE MODE) AND status 1 ORDER BY publish_time DESC LIMIT #{offset}, #{size}) ListArticle searchByFullText(Param(keyword) String keyword, Param(offset) int offset, Param(size) int size);在使用過程中發(fā)現(xiàn)一個(gè)值得注意的點(diǎn)全文索引的檢索模式分為自然語言模式和布爾模式自然語言模式的匹配更加智能但相關(guān)度的排序用戶感知不明顯。在對搜索體驗(yàn)要求更高的場景下可以改用布爾模式配合加減號干預(yù)排序。不過這個(gè)方案也有委屈的地方中文分詞的支持不如專業(yè)搜索引擎好在資訊網(wǎng)站的搜索詞多半是品牌名、車型名這類明確詞匯匹配效果還算理想。4.4 評論與互動(dòng)的并發(fā)控制評論功能看起來只是插入一條記錄但埋了一個(gè)并發(fā)隱患。如果同一時(shí)間大量用戶給同一篇文章發(fā)評論評論計(jì)數(shù)應(yīng)該平滑增長。我在實(shí)現(xiàn)評論插入的同時(shí)通過事務(wù)把評論數(shù)和文章表的評論計(jì)數(shù)更新放在一起保證兩者不會(huì)出現(xiàn)長短腿。點(diǎn)贊功能的冪等性很關(guān)鍵用戶重復(fù)點(diǎn)擊不應(yīng)該產(chǎn)生多條記錄。我的做法是在點(diǎn)贊表中建立user_id和article_id的唯一索引插入時(shí)捕獲DuplicateKeyException如果出現(xiàn)重復(fù)記錄就返回已點(diǎn)贊的友好提示避免前端誤以為操作失敗。取消點(diǎn)贊時(shí)直接物理刪除對應(yīng)記錄簡單高效。另外值得提的是在我的設(shè)計(jì)里評論是有審核狀態(tài)的。用戶發(fā)出的評論先落在待審核狀態(tài)管理員在后臺(tái)審核通過后展示出來。這個(gè)流程會(huì)讓首次寫評論的用戶產(chǎn)生發(fā)出去了怎么看不到的疑問所以前端需要在交互上明確提示評論處于待審核狀態(tài)這個(gè)體驗(yàn)細(xì)節(jié)很容易被忽略。5. 常見問題與排查技巧實(shí)錄5.1 鑒權(quán)失效的經(jīng)典場景前后端分離開發(fā)時(shí)聯(lián)調(diào)階段最容易出的問題就是跨域?qū)е虑岸藥Р涣薚oken。瀏覽器在跨域請求時(shí)如果前端代碼沒有顯式設(shè)置withCredentials或者后端沒有配置允許攜帶憑證請求頭里的Authorization會(huì)被瀏覽器吃掉后端自然拿不到Token。排查這類問題時(shí)我先在瀏覽器的Network面板里看請求頭是否包含Authorization。如果請求頭本身就沒有Token說明問題出在前端或網(wǎng)關(guān)層。如果請求頭里有Token但接口還是返回401那就要看后端的過濾器是否被Spring Security的過濾鏈正確加載了。一個(gè)容易被忽略的點(diǎn)是自定義過濾器必須注冊到Security的過濾鏈中才能生效僅僅聲明成Component有時(shí)不會(huì)自動(dòng)加入。5.2 分頁查詢中數(shù)據(jù)重復(fù)與丟失MyBatis-Plus分頁插件使用中最經(jīng)典的坑是排序字段不唯一導(dǎo)致的分頁數(shù)據(jù)偏移。如果文章列表里有大量文章發(fā)布時(shí)間相同排序不穩(wěn)定就會(huì)造成同一篇文章在翻頁時(shí)重復(fù)出現(xiàn)或漏掉。解決思路是排序時(shí)增加一個(gè)唯一字段作為次級排序條件比如先按publish_time倒序再按id倒序這樣每一條記錄的順序都是確定性的。這個(gè)調(diào)整在數(shù)據(jù)量大了之后能明顯感受到翻頁體驗(yàn)的變化。另一個(gè)常見問題是分頁插件失效。如果MyBatis-Plus的分頁插件沒有配置攔截器或者配置了但因?yàn)榘鼟呙桧樞騿栴}沒有加載所有分頁查詢都會(huì)變成全表查詢。排查時(shí)可以在日志里看SQL語句末尾是否拼接了LIMIT關(guān)鍵字來快速定位。5.3 緩存穿透與緩存擊穿引入Redis緩存后我實(shí)際遇到過兩類數(shù)據(jù)問題。一類是緩存穿透也就是用戶頻繁請求一條根本不存在的文章ID每次請求都會(huì)壓到數(shù)據(jù)庫給數(shù)據(jù)庫帶來不必要的查詢壓力。解決的辦法很簡單在緩存中存儲(chǔ)一個(gè)空值的占位標(biāo)記并設(shè)置較短的過期時(shí)間這樣同一無效ID的反復(fù)查詢不會(huì)每次都打到數(shù)據(jù)庫。另一類是緩存擊穿熱門的資訊緩存過期瞬間大量請求同時(shí)涌入數(shù)據(jù)庫。我用了一個(gè)分布式鎖的間接方案來緩解當(dāng)緩存失效時(shí)只允許一個(gè)線程去數(shù)據(jù)庫查詢并回填緩存其他線程先等待緩存重建完成后再讀取。簡單實(shí)現(xiàn)了一個(gè)基于Redis的SETNX鎖雖然不如Redisson那么完善但應(yīng)對中小規(guī)模系統(tǒng)的熱點(diǎn)數(shù)據(jù)已經(jīng)夠用。5.4 文件上傳與存儲(chǔ)策略的實(shí)際考量資訊網(wǎng)站的封面圖和正文插圖涉及圖片上傳的問題。本地磁盤存儲(chǔ)雖然簡單但在部署到云服務(wù)器后會(huì)有兩個(gè)麻煩一是磁盤空間有限二是后續(xù)遷移成本高。我當(dāng)時(shí)采用的是本地目錄存儲(chǔ)配合Nginx靜態(tài)映射的方案上傳接口把文件保存到服務(wù)器指定目錄返回給前端的是經(jīng)過Nginx映射后的訪問URL。實(shí)現(xiàn)上傳接口時(shí)有兩個(gè)細(xì)節(jié)需要注意。一是文件名的生成不能用用戶上傳的原始文件名否則很容易出現(xiàn)重名覆蓋和路徑穿越的安全問題我用UUID重命名后保留了原始擴(kuò)展名作為后綴。二是需要做文件類型的白名單校驗(yàn)只允許jpg、png、webp這幾個(gè)常用的圖片格式防止惡意用戶上傳可執(zhí)行文件偽裝成圖片。文件大小也要做限制我設(shè)置了單張圖片5MB的上限超出就直接拒絕。5.5 后臺(tái)管理接口的安全加固后臺(tái)管理接口暴露出去之后如果只有登錄認(rèn)證沒有其他防護(hù)措施容易被批量調(diào)用造成數(shù)據(jù)泄露或資源消耗。除了登錄鑒權(quán)之外我還加了兩個(gè)層面的防護(hù)。第一層是管理端接口全部走獨(dú)立路徑前綴在Spring Security中對該路徑單獨(dú)配置權(quán)限要求只有具有對應(yīng)角色的人才允許訪問。第二層是對管理端的敏感操作加操作日志管理員刪除資訊或強(qiáng)制下架文章時(shí)系統(tǒng)會(huì)記錄下操作人的ID、操作時(shí)間和操作內(nèi)容方便事后追溯。接口的防刷處理在實(shí)際運(yùn)營中也是必要的一環(huán)。我在網(wǎng)關(guān)層增加了一個(gè)簡單的計(jì)數(shù)器同一IP在單位時(shí)間內(nèi)調(diào)用管理端接口的次數(shù)超過閾值就會(huì)被臨時(shí)封禁。這個(gè)邏輯用Redis的INCR加EXPIRE就能實(shí)現(xiàn)代碼量不大但能把絕大多數(shù)惡意請求擋在外面。6. 項(xiàng)目運(yùn)行效果與個(gè)人實(shí)操心得6.1 從本地聯(lián)調(diào)到模擬部署的完整鏈路項(xiàng)目開發(fā)完成后的聯(lián)調(diào)階段我習(xí)慣先按正常業(yè)務(wù)流走一遍全流程模擬真實(shí)用戶從注冊登錄到瀏覽收藏評論的完整路徑。這一遍的目的不是找Bug而是感受操作邏輯是否順暢。聯(lián)調(diào)通過后進(jìn)入部署準(zhǔn)備階段我選用寶塔面板配合Docker的方式完成模擬部署。Spring Boot應(yīng)用打成Jar包后通過Docker鏡像運(yùn)行MySQL和Redis用Docker Compose統(tǒng)一編排。容器化部署的好處是環(huán)境一致性有保障換一臺(tái)服務(wù)器也能快速拉起全套服務(wù)。Docker Compose的核心配置大致長這樣version: 3.8 services: mysql: image: mysql:8.0 container_name: car-news-mysql environment: MYSQL_ROOT_PASSWORD: root123456 MYSQL_DATABASE: car_news ports: - 3306:3306 volumes: - ./mysql-data:/var/lib/mysql redis: image: redis:7.0 container_name: car-news-redis ports: - 6379:6379 app: build: . container_name: car-news-app depends_on: - mysql - redis ports: - 8080:8080 environment: SPRING_PROFILES_ACTIVE: prod DB_HOST: mysql DB_PASSWORD: root123456 REDIS_HOST: redis容器化的過程中有一個(gè)經(jīng)常出問題的點(diǎn)應(yīng)用容器啟動(dòng)時(shí)MySQL容器可能還沒就緒連接數(shù)據(jù)庫直接報(bào)錯(cuò)。雖然depends_on能控制容器的啟動(dòng)順序但并不能保證數(shù)據(jù)庫服務(wù)已經(jīng)完成初始化。我加了一個(gè)簡單的健康檢查腳本應(yīng)用啟動(dòng)前先檢測MySQL的3306端口是否可連接直到確認(rèn)數(shù)據(jù)庫就緒后才啟動(dòng)Spring Boot應(yīng)用這個(gè)細(xì)節(jié)幫我節(jié)省了不少排查時(shí)間。6.2 開發(fā)中反復(fù)踩過的幾個(gè)真實(shí)坑踩坑經(jīng)驗(yàn)往往比功能代碼更有價(jià)值。我印象最深的是第一個(gè)版本里把所有Service實(shí)現(xiàn)都優(yōu)先考慮做事務(wù)無論讀操作還是寫操作都加上Transactional。結(jié)果在查看資訊列表時(shí)因?yàn)槭聞?wù)中的查詢持有數(shù)據(jù)庫連接時(shí)間過長并發(fā)量上來后連接池被占滿整個(gè)應(yīng)用直接不可用。后來我給只讀操作去掉了事務(wù)把事務(wù)粒度縮小到真正的寫操作上才解決了這個(gè)問題。還有一個(gè)坑是關(guān)于前端跨域配置的。開發(fā)環(huán)境下我用Vue壓理了代理轉(zhuǎn)發(fā)生產(chǎn)環(huán)境則通過Nginx反向代理統(tǒng)一處理后端沒有開啟全局跨域配置。之所以刻意這樣設(shè)計(jì)是因?yàn)榘阉锌缬蚍艑挄?huì)讓接口暴露在任意域名的惡意請求下產(chǎn)生不必要風(fēng)險(xiǎn)。通過反向代理集中管理域名的白名單策略能收得更緊安全上也更有底氣。JWT密鑰的管理也值得專門說一句。最初我把密鑰直接寫在配置文件中后來考慮到部署環(huán)境的差異化改成通過環(huán)境變量注入。這樣做的原因很簡單如果代碼倉庫泄露密鑰也一起泄露攻擊者就能自己偽造Token直接以管理員身份訪問后臺(tái)后果不堪設(shè)想。密鑰的管理看起來是個(gè)小細(xì)節(jié)但在安全鏈條上是至關(guān)重要的一環(huán)。6.3 這個(gè)系統(tǒng)還能往哪些方向擴(kuò)展這套系統(tǒng)現(xiàn)在的狀態(tài)是功能完整、邏輯清晰但要是放在真實(shí)運(yùn)營場景里還有不少可以深入的空間。搜索方面如果資訊積累到一定量級MySQL全文索引的短板會(huì)逐漸顯現(xiàn)。到時(shí)候可以平滑地引入Elasticsearch把搜索單獨(dú)拆成微服務(wù)與主站的業(yè)務(wù)邏輯解耦。資訊內(nèi)容的個(gè)性化推薦也是一個(gè)值得做的方向基于用戶的歷史閱讀記錄做簡單的標(biāo)簽偏好統(tǒng)計(jì)就能在首頁給出千人千面的資訊流這在提升用戶留存上效果很明顯。后臺(tái)的運(yùn)營能力也可以繼續(xù)加深。比如加上定時(shí)發(fā)布功能讓運(yùn)營人員提前備稿增加數(shù)據(jù)報(bào)表模塊按天維度統(tǒng)計(jì)各欄目的瀏覽量趨勢。這些功能與現(xiàn)有架構(gòu)互不沖突甚至可以在不改動(dòng)現(xiàn)有核心代碼的前提下以增量方式開發(fā)上線。對想做畢業(yè)設(shè)計(jì)或者面試項(xiàng)目展示的朋友來說基礎(chǔ)版本搭好后按這幾個(gè)方向做迭代增值里面的技術(shù)含量是完全足夠展開來講的。最后想給準(zhǔn)備動(dòng)手做這類系統(tǒng)的朋友一個(gè)建議一定不要一頭扎進(jìn)代碼里先花時(shí)間把表結(jié)構(gòu)設(shè)計(jì)好、把模塊邊界理清楚動(dòng)手寫代碼的時(shí)候會(huì)順暢得多。我當(dāng)時(shí)在表結(jié)構(gòu)設(shè)計(jì)上多花了一個(gè)晚上后面整個(gè)開發(fā)過程中來回頭修改表結(jié)構(gòu)的情況幾乎沒有發(fā)生。技術(shù)框架一直在迭代但數(shù)據(jù)模型和業(yè)務(wù)邏輯的分析能力才是這類系統(tǒng)真正考驗(yàn)人的地方。