1. 項(xiàng)目概述與需求拆解1.1 外賣(mài)點(diǎn)餐配送系統(tǒng)到底做了什么外賣(mài)點(diǎn)餐配送系統(tǒng)說(shuō)白了就是把用戶下單、商家做餐、騎手配送這條鏈路搬到線上并且用一套后臺(tái)把所有角色串起來(lái)。這個(gè)標(biāo)題里有個(gè)容易被忽略的點(diǎn)——員工與忘記密碼。也就是說(shuō)這套系統(tǒng)不只是給C端用戶點(diǎn)外賣(mài)用的它還有完整的運(yùn)營(yíng)后臺(tái)和員工賬號(hào)體系。系統(tǒng)里的角色至少包括C端用戶瀏覽菜品、下單、支付、查看訂單狀態(tài)、申請(qǐng)退款。商家端菜品管理、訂單接單/拒單、出餐通知。騎手端搶單/接單、取餐、配送、標(biāo)記送達(dá)。平臺(tái)運(yùn)營(yíng)員工審核商家、處理糾紛、運(yùn)營(yíng)配置。系統(tǒng)管理員賬號(hào)權(quán)限管理、數(shù)據(jù)看板、系統(tǒng)配置。在這套系統(tǒng)里員工端忘記密碼就是一個(gè)非常典型的業(yè)務(wù)需求——不是只有用戶需要找回密碼后臺(tái)運(yùn)營(yíng)人員同樣需要。而且員工密碼重置涉及權(quán)限安全不能馬虎。我見(jiàn)過(guò)很多類(lèi)似的畢設(shè)或?qū)嵱?xùn)項(xiàng)目往往把精力全放在C端點(diǎn)餐頁(yè)面上結(jié)果一到員工管理、密碼找回這種不起眼的功能就草草了事。實(shí)際上這種功能恰恰是面試官和評(píng)審老師最?lèi)?ài)追問(wèn)的點(diǎn)你怎么保證重置密碼的安全性Token有效期怎么設(shè)計(jì)驗(yàn)證碼怎么防刷這些細(xì)節(jié)才是項(xiàng)目的含金量所在。1.2 為什么這套系統(tǒng)必須上微服務(wù)分布式先說(shuō)結(jié)論一個(gè)外賣(mài)系統(tǒng)如果只在單機(jī)SpringBoot里做代碼也能跑通但一旦考慮真實(shí)場(chǎng)景——高并發(fā)下單、騎手搶單、多端同時(shí)在線、持續(xù)迭代上線——單體應(yīng)用就會(huì)變成瓶頸。外賣(mài)系統(tǒng)天然適合微服務(wù)拆分原因是它的業(yè)務(wù)域足夠清晰業(yè)務(wù)域典型職責(zé)拆分收益用戶服務(wù)C端注冊(cè)登錄、地址管理獨(dú)立擴(kuò)展應(yīng)對(duì)大促峰值商家服務(wù)店鋪信息、菜品管理與用戶流量隔離訂單服務(wù)下單、訂單狀態(tài)流轉(zhuǎn)核心鏈路重點(diǎn)保障配送服務(wù)騎手管理、派單、軌跡獨(dú)立伸縮搶單場(chǎng)景并發(fā)高支付服務(wù)支付回調(diào)、對(duì)賬第三方交互隔離故障員工/認(rèn)證服務(wù)后臺(tái)賬號(hào)、權(quán)限、密碼管理安全邊界獨(dú)立審計(jì)這不是為了炫技。分布式帶來(lái)的核心價(jià)值是故障隔離和獨(dú)立擴(kuò)展。比如中午高峰期訂單服務(wù)壓力大但商家服務(wù)可能很閑微服務(wù)架構(gòu)下你可以只給訂單服務(wù)加副本而不是把整個(gè)系統(tǒng)垂直擴(kuò)容一遍。當(dāng)然微服務(wù)也意味著復(fù)雜度轉(zhuǎn)移——服務(wù)怎么發(fā)現(xiàn)、配置怎么管理、請(qǐng)求怎么路由、鏈路怎么追蹤、事務(wù)怎么保證這些都是單體應(yīng)用壓根不用操心的事。標(biāo)題里寫(xiě)了SpringCloud就是要把這一整套分布式基礎(chǔ)設(shè)施落地到項(xiàng)目里這也是這個(gè)項(xiàng)目真正的學(xué)習(xí)價(jià)值。1.3 適合誰(shuí)讀、讀完能落地什么這篇文章適合三類(lèi)人用SpringBootVue做過(guò)單體項(xiàng)目想上一個(gè)微服務(wù)分布式項(xiàng)目的人。你會(huì)發(fā)現(xiàn)從單體到微服務(wù)核心不是代碼量變大而是思維模式變了——你要開(kāi)始考慮服務(wù)邊界、網(wǎng)絡(luò)調(diào)用、數(shù)據(jù)一致性。正在做外賣(mài)/電商類(lèi)畢設(shè)或?qū)嵱?xùn)項(xiàng)目的人。我會(huì)把業(yè)務(wù)模塊拆解、表結(jié)構(gòu)設(shè)計(jì)、接口契約、狀態(tài)機(jī)設(shè)計(jì)都講清楚可以直接參考。準(zhǔn)備面試的人。外賣(mài)系統(tǒng)是面試中極其常見(jiàn)的業(yè)務(wù)場(chǎng)景訂單狀態(tài)的流轉(zhuǎn)、分布式事務(wù)的處理、并發(fā)場(chǎng)景的鎖設(shè)計(jì)都是高頻考點(diǎn)。這篇文章里的踩坑經(jīng)驗(yàn)就是最好的面試素材。讀完這篇文章你能收獲的不只是怎么搭一個(gè)SpringCloud項(xiàng)目而是完整的外賣(mài)業(yè)務(wù)建模思路、微服務(wù)拆分方法論、分布式場(chǎng)景的實(shí)操解法以及一套可以直接復(fù)用的員工密碼找回安全方案。2. 整體架構(gòu)設(shè)計(jì)與技術(shù)選型2.1 模塊拆分六個(gè)微服務(wù)怎么劃邊界微服務(wù)拆分有一個(gè)核心原則高內(nèi)聚、低耦合按業(yè)務(wù)能力劃分而不是按代碼層劃分。很多人第一次做微服務(wù)容易犯的錯(cuò)是拆得太碎——把菜品管理和店鋪管理都拆成獨(dú)立服務(wù)結(jié)果一個(gè)下單接口要調(diào)用五六個(gè)服務(wù)鏈路長(zhǎng)到無(wú)法排查。外賣(mài)系統(tǒng)的合理拆分方式是上面表格里的六邊形用戶服務(wù)、商家服務(wù)、訂單服務(wù)、配送服務(wù)、支付服務(wù)、員工/認(rèn)證服務(wù)。每個(gè)服務(wù)獨(dú)立數(shù)據(jù)庫(kù)服務(wù)之間只通過(guò)API通信禁止直接操作對(duì)方的表。這里有一個(gè)很重要的設(shè)計(jì)決策為什么用戶服務(wù)和員工服務(wù)要分開(kāi)因?yàn)镃端用戶和后臺(tái)員工是兩套完全不同的賬號(hào)體系。C端用戶用手機(jī)號(hào)驗(yàn)證碼登錄后臺(tái)員工用用戶名密碼登錄權(quán)限模型也不同。用戶服務(wù)面對(duì)的是海量C端流量員工服務(wù)面對(duì)的是少量后臺(tái)操作兩者的安全級(jí)別和擴(kuò)展策略完全不一樣。強(qiáng)行合并會(huì)讓安全審計(jì)變得非常困難。訂單服務(wù)和配送服務(wù)為什么要拆想象一個(gè)場(chǎng)景用戶下單后訂單服務(wù)要?jiǎng)?chuàng)建訂單配送服務(wù)要生成配送任務(wù)。如果兩個(gè)服務(wù)不拆騎手搶單的并發(fā)流量會(huì)直接影響下單接口的穩(wěn)定性。拆開(kāi)之后訂單服務(wù)和配送服務(wù)各自獨(dú)立伸縮訂單寫(xiě)庫(kù)慢也不會(huì)牽連騎手端刷單。數(shù)據(jù)庫(kù)層面每個(gè)服務(wù)獨(dú)立庫(kù)。為了讓文章有落地感下面給訂單庫(kù)的核心表舉個(gè)例子-- 訂單主表 CREATE TABLE order_main ( id bigint(20) NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL COMMENT 訂單號(hào), user_id bigint(20) NOT NULL COMMENT 用戶ID, shop_id bigint(20) NOT NULL COMMENT 店鋪ID, total_amount decimal(10,2) NOT NULL COMMENT 訂單總金額, status tinyint(4) NOT NULL COMMENT 訂單狀態(tài) 0待支付 1已支付 2商家接單 3配送中 4已完成 5已取消, address_detail varchar(255) NOT NULL COMMENT 配送地址, create_time datetime NOT NULL, update_time datetime NOT NULL, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_user_id (user_id), KEY idx_shop_id (shop_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT訂單主表;訂單狀態(tài)用tinyint而不是直接存字符串這是個(gè)常見(jiàn)的取舍——存數(shù)字節(jié)省空間、查詢高效但可讀性差所以代碼里一定要有對(duì)應(yīng)的枚舉類(lèi)。我在實(shí)際項(xiàng)目里見(jiàn)過(guò)有人把狀態(tài)直接映射成中文存庫(kù)當(dāng)時(shí)看著方便后來(lái)統(tǒng)計(jì)報(bào)表時(shí)恨不得全都重來(lái)。2.2 技術(shù)選型SpringBoot SpringCloud Vue的組合邏輯這套技術(shù)棧組合是非常成熟的前后端分離 微服務(wù)標(biāo)準(zhǔn)方案選它的邏輯很實(shí)在。SpringBoot負(fù)責(zé)微服務(wù)的基礎(chǔ)開(kāi)發(fā)框架。它解決了Spring配置地獄的問(wèn)題讓一個(gè)獨(dú)立的微服務(wù)可以快速啟動(dòng)和部署。每個(gè)微服務(wù)內(nèi)部還是傳統(tǒng)的三層架構(gòu)Controller - Service - Mapper開(kāi)發(fā)成本低Java程序員幾乎沒(méi)有學(xué)習(xí)成本。SpringCloud提供微服務(wù)治理全家桶。我用的核心組件包括Spring Cloud Gateway統(tǒng)一入口網(wǎng)關(guān)處理鑒權(quán)、路由轉(zhuǎn)發(fā)、限流。選Gateway而不是Zuul是因?yàn)镚ateway基于WebFlux性能和吞吐量明顯更好而且Spring官方主推。Nacos服務(wù)注冊(cè)與發(fā)現(xiàn) 配置中心。比Eureka更強(qiáng)Eureka只管注冊(cè)發(fā)現(xiàn)配置管理還得再搭Config ServerNacos一站式搞定。OpenFeign服務(wù)間聲明式HTTP調(diào)用。寫(xiě)一個(gè)接口加幾個(gè)注解就能完成服務(wù)間通信比手動(dòng)寫(xiě)RestTemplate省太多代碼。Sentinel流量控制和熔斷降級(jí)。外賣(mài)系統(tǒng)高峰期的流量是突發(fā)的必須有熔斷限流保護(hù)核心服務(wù)。Sleuth Zipkin鏈路追蹤。微服務(wù)排障的必備工具否則一個(gè)請(qǐng)求串了五六個(gè)服務(wù)出了問(wèn)題你都不知道在哪一環(huán)。Vue負(fù)責(zé)前端展示層。我用了Vue3 Element Plus Vite的組合Vue3的組合式API寫(xiě)業(yè)務(wù)邏輯更清爽Element Plus做后臺(tái)管理界面特別快。前端工程按角色拆成三個(gè)獨(dú)立應(yīng)用用戶端H5、商家端Web、騎手端App或H5、運(yùn)營(yíng)后臺(tái)Web分項(xiàng)目開(kāi)發(fā)部署。前端和后端的交互全部通過(guò)Gateway走HTTP/JSON開(kāi)發(fā)期配置代理解決跨域上線后由Nginx統(tǒng)一轉(zhuǎn)發(fā)。這里要點(diǎn)一句很多人初學(xué)微服務(wù)的誤區(qū)不要為了微服務(wù)而微服務(wù)。如果你的項(xiàng)目就兩個(gè)模塊、預(yù)估QPS不超過(guò)100單體分布式緩存完全夠用硬上微服務(wù)只會(huì)給自己增加運(yùn)維負(fù)擔(dān)。這套系統(tǒng)上微服務(wù)是因?yàn)樗臉I(yè)務(wù)邊界清晰、多端并發(fā)場(chǎng)景真實(shí)、需要獨(dú)立擴(kuò)展這些條件必須滿足才值得拆。2.3 分布式組件清單與關(guān)鍵參數(shù)我花了大量時(shí)間在組件的環(huán)境搭建上這里直接給一份可用的選型清單組件版本選型用途關(guān)鍵配置說(shuō)明Nacos2.2.x注冊(cè)中心 配置中心啟動(dòng)時(shí)設(shè)置standalone模式生產(chǎn)環(huán)境至少3節(jié)點(diǎn)集群Spring Cloud Gateway2021.x統(tǒng)一入口配置路由斷言、過(guò)濾器鏈、限流策略O(shè)penFeign內(nèi)置服務(wù)間調(diào)用設(shè)置連接超時(shí)和讀取超時(shí)避免默認(rèn)1秒超時(shí)導(dǎo)致調(diào)用失敗Sentinel1.8.x熔斷限流降級(jí)核心接口設(shè)置QPS閾值和熔斷策略Zipkin2.x鏈路追蹤配合Sleuth收集調(diào)用鏈數(shù)據(jù)Redis6.x緩存 分布式鎖用于菜品緩存、驗(yàn)證碼存儲(chǔ)、訂單防重復(fù)提交RabbitMQ3.x消息隊(duì)列訂單超時(shí)未支付取消、派單消息通知MySQL8.x業(yè)務(wù)數(shù)據(jù)存儲(chǔ)每個(gè)微服務(wù)獨(dú)立庫(kù)建議開(kāi)啟binlog這里要強(qiáng)調(diào)一個(gè)經(jīng)驗(yàn)Nacos和Spring Cloud的版本兼容性是個(gè)大坑。網(wǎng)上很多教程直接復(fù)制官方文檔結(jié)果啟動(dòng)報(bào)各種莫名其妙的錯(cuò)最后排查半天發(fā)現(xiàn)是版本不匹配。我的建議是直接在Spring Cloud Alibaba的官方版本說(shuō)明里查對(duì)應(yīng)關(guān)系Spring Boot 2.6.x就配合Spring Cloud 2021.0.x和Spring Cloud Alibaba 2021.0.4.0鎖死版本再開(kāi)發(fā)。3. 核心業(yè)務(wù)模塊設(shè)計(jì)與實(shí)現(xiàn)3.1 點(diǎn)餐下單全流程的服務(wù)鏈路用戶點(diǎn)餐下單這個(gè)流程表面上看就是前端提交一個(gè)訂單但微服務(wù)架構(gòu)下的完整鏈路是這樣的用戶點(diǎn)擊下單前端請(qǐng)求Gateway網(wǎng)關(guān)解析JWT Token確認(rèn)用戶身份。Gateway根據(jù)路由規(guī)則把請(qǐng)求轉(zhuǎn)發(fā)到訂單服務(wù)。訂單服務(wù)先做冪等校驗(yàn)基于用戶ID店鋪ID最近30秒內(nèi)的訂單查重防止用戶重復(fù)點(diǎn)提交導(dǎo)致重復(fù)下單。訂單服務(wù)調(diào)用商家服務(wù)遠(yuǎn)程獲取菜品列表和最新價(jià)格校驗(yàn)菜品是否下架、庫(kù)存是否充足。校驗(yàn)通過(guò)后訂單服務(wù)創(chuàng)建訂單數(shù)據(jù)狀態(tài)為待支付。訂單服務(wù)發(fā)送MQ消息觸發(fā)支付服務(wù)生成支付單同時(shí)啟動(dòng)延遲隊(duì)列超過(guò)15分鐘未支付自動(dòng)取消訂單。用戶支付成功后支付服務(wù)回調(diào)訂單服務(wù)訂單狀態(tài)流轉(zhuǎn)為已支付。這個(gè)過(guò)程里最有技術(shù)含量的兩個(gè)點(diǎn)遠(yuǎn)程調(diào)用如何保證數(shù)據(jù)一致以及訂單創(chuàng)建如何做冪等。先講冪等。用戶網(wǎng)絡(luò)不好時(shí)往往會(huì)瘋狂點(diǎn)提交訂單如果后端不做冪等控制一次下單就變成三四單。我的實(shí)現(xiàn)方案是在訂單服務(wù)里加一個(gè)Redis Key鍵是order:submit:{userId}:{shopId}值為訂單號(hào)過(guò)期時(shí)間設(shè)30秒。提交時(shí)先嘗試寫(xiě)入如果Key已存在則直接返回已存在的訂單號(hào)。這樣既實(shí)現(xiàn)了冪等又緩存了用戶最近訂單前端可以直接跳轉(zhuǎn)支付頁(yè)。再看遠(yuǎn)程調(diào)用的一致性。訂單服務(wù)調(diào)商家服務(wù)校驗(yàn)菜品時(shí)如果商家服務(wù)超時(shí)了怎么辦直接報(bào)錯(cuò)讓用戶重新下單還是保存草稿我的選擇是核心校驗(yàn)不通過(guò)就快速失敗讓用戶重試。因?yàn)椴似穬r(jià)格和庫(kù)存是強(qiáng)約束條件不能為了用戶體驗(yàn)用舊數(shù)據(jù)下單寧可讓用戶重新選一次也不能產(chǎn)生一筆錯(cuò)誤訂單。3.2 訂單狀態(tài)機(jī)與配送派單邏輯訂單狀態(tài)是外賣(mài)系統(tǒng)的骨架我用了狀態(tài)機(jī)來(lái)管理而不是在Service層隨手改狀態(tài)。先定義一個(gè)枚舉public enum OrderStatusEnum { WAIT_PAY(0, 待支付), PAID(1, 已支付), SHOP_ACCEPT(2, 商家已接單), DELIVERING(3, 配送中), COMPLETED(4, 已完成), CANCELLED(5, 已取消); private Integer code; private String desc; // 狀態(tài)流轉(zhuǎn)合法性校驗(yàn) public boolean canTransferTo(OrderStatusEnum target) { switch (this) { case WAIT_PAY: return target PAID || target CANCELLED; case PAID: return target SHOP_ACCEPT || target CANCELLED; case SHOP_ACCEPT: return target DELIVERING || target CANCELLED; case DELIVERING: return target COMPLETED; default: return false; } } }為什么用狀態(tài)機(jī)因?yàn)橛唵螤顟B(tài)流轉(zhuǎn)有嚴(yán)格的順序如果不做任何限制一個(gè)bug就可能讓已完成的訂單退回待支付。狀態(tài)機(jī)把合法的流轉(zhuǎn)路徑集中定義在一個(gè)地方所有修改訂單狀態(tài)的操作都必須經(jīng)過(guò)狀態(tài)機(jī)校驗(yàn)。測(cè)試時(shí)只需要針對(duì)狀態(tài)機(jī)寫(xiě)單元測(cè)試不需要把所有業(yè)務(wù)流程跑一遍省太多事了。配送派單的邏輯我單獨(dú)說(shuō)因?yàn)檫@是外賣(mài)系統(tǒng)區(qū)別于普通電商的核心場(chǎng)景。騎手搶單是一個(gè)典型的并發(fā)場(chǎng)景。同一個(gè)配送任務(wù)同時(shí)推送給多個(gè)騎手誰(shuí)先搶到就歸誰(shuí)。這個(gè)功能如果直接在數(shù)據(jù)庫(kù)層面做比如UPDATE delivery_task SET rider_id ? WHERE id ? AND rider_id IS NULL在MySQL默認(rèn)隔離級(jí)別下會(huì)出現(xiàn)超賣(mài)——兩個(gè)騎手同時(shí)讀到rider_id為NULL同時(shí)更新成功數(shù)據(jù)就被覆蓋了。我當(dāng)時(shí)先用數(shù)據(jù)庫(kù)樂(lè)觀鎖做了一版結(jié)果高并發(fā)測(cè)試下丟單率很高。后來(lái)?yè)Q成了Redis分布式鎖 任務(wù)狀態(tài)雙重校驗(yàn)的方案public boolean grabOrder(Long taskId, Long riderId) { String lockKey delivery:grab: taskId; String lockValue UUID.randomUUID().toString(); boolean locked redisTemplate.opsForValue() .setIfAbsent(lockKey, lockValue, 10, TimeUnit.SECONDS); if (!locked) { return false; // 已經(jīng)有騎手在搶 } try { // 二次檢查任務(wù)狀態(tài) DeliveryTask task deliveryTaskMapper.selectById(taskId); if (task.getRiderId() ! null || task.getStatus() ! DeliveryStatusEnum.WAIT_GRAB.getCode()) { return false; } int updateRows deliveryTaskMapper.grabTask(taskId, riderId); return updateRows 0; } finally { // Lua腳本釋放鎖防止誤刪別人的鎖 String script if redis.call(get,KEYS[1]) ARGV[1] then return redis.call(del,KEYS[1]) else return 0 end; redisTemplate.execute(new DefaultRedisScript(script, Long.class), Arrays.asList(lockKey), lockValue); } }這個(gè)方案里兩個(gè)關(guān)鍵細(xì)節(jié)鎖的過(guò)期時(shí)間一定不能太短否則任務(wù)還沒(méi)處理完鎖就自動(dòng)釋放了另一個(gè)騎手就能趁虛而入釋放鎖時(shí)不能直接DEL要先判斷值是不是自己設(shè)置的避免把別人的鎖刪掉。這兩個(gè)點(diǎn)面試時(shí)都屬于一問(wèn)一個(gè)準(zhǔn)的細(xì)節(jié)。3.3 員工模塊與忘記密碼的完整方案標(biāo)題里特別寫(xiě)了員工 忘記密碼我猜有不少同學(xué)在這個(gè)功能上翻過(guò)車(chē)。員工忘記密碼看起來(lái)簡(jiǎn)單——不就是發(fā)個(gè)驗(yàn)證碼改個(gè)密碼嗎但放到微服務(wù)架構(gòu)和真實(shí)業(yè)務(wù)里至少要回答這幾個(gè)問(wèn)題第一員工密碼存在哪里員工屬于員工/認(rèn)證服務(wù)密碼不能明文存。我用的是BCrypt加密而不是MD5。BCrypt自帶隨機(jī)鹽同樣的密碼每次加密結(jié)果都不同而且計(jì)算復(fù)雜度可調(diào)暴力破解成本遠(yuǎn)高于MD5。另外員工密碼不能存在用戶服務(wù)的數(shù)據(jù)庫(kù)里否則后臺(tái)賬號(hào)和C端用戶混在一起權(quán)限邊界就崩了。第二怎么驗(yàn)證忘記密碼的人確實(shí)是本人我提供兩種方式產(chǎn)品上可以配置手機(jī)號(hào)驗(yàn)證碼員工賬號(hào)綁定手機(jī)號(hào)發(fā)送驗(yàn)證碼校驗(yàn)身份。驗(yàn)證碼用Redis存有效期5分鐘每個(gè)手機(jī)號(hào)60秒內(nèi)只能發(fā)一次。防刷策略必須做——否則接口泄露后會(huì)被短信轟炸驗(yàn)證碼成本蹭蹭漲。管理員重置如果員工手機(jī)號(hào)也換綁了就由管理員在后臺(tái)發(fā)起重置生成一個(gè)一次性重置鏈接發(fā)給員工。這個(gè)鏈接帶Token有效期2小時(shí)用一次就失效。第三重置密碼的Token怎么設(shè)計(jì)這是最容易出安全問(wèn)題的地方。我的設(shè)計(jì)如下public class PasswordResetToken { // 業(yè)務(wù)IDemployeeId private Long targetId; // 隨機(jī)Token至少32字節(jié)用SecureRandom生成 private String token; // 過(guò)期時(shí)間 private LocalDateTime expireTime; }Token生成不能用UUID簡(jiǎn)單糊弄UUID雖然隨機(jī)但包含時(shí)間戳信息安全性不夠強(qiáng)。要用SecureRandom生成128位隨機(jī)數(shù)再轉(zhuǎn)Base64字符串。Token只存Hash值入庫(kù)萬(wàn)一數(shù)據(jù)庫(kù)泄露攻擊者也拿不到有效Token。第四忘記密碼的完整流程長(zhǎng)什么樣我把后端接口的時(shí)序理一下1. POST /auth/forgot-password 提交員工賬號(hào)或手機(jī)號(hào) 2. 員工服務(wù)校驗(yàn)賬號(hào)存在生成6位數(shù)字驗(yàn)證碼 3. 驗(yàn)證碼存入Rediskeyforgot:code:{phone}過(guò)期5分鐘 4. 調(diào)用短信服務(wù)發(fā)送驗(yàn)證碼 5. POST /auth/verify-code 校驗(yàn)驗(yàn)證碼 6. 校驗(yàn)通過(guò)后生成PasswordResetToken返回給前端 7. 前端跳轉(zhuǎn)重置密碼頁(yè)提交新密碼 Token 8. 員工服務(wù)校驗(yàn)Token有效性和過(guò)期時(shí)間 9. 更新密碼BCrypt加密Token立即作廢 10. 記錄安全日志誰(shuí)在什么時(shí)間從什么IP重置了密碼第五安全審計(jì)怎么做這一點(diǎn)很多項(xiàng)目都會(huì)漏掉。密碼重置屬于敏感操作必須記錄審計(jì)日志。我單獨(dú)建了一張employee_security_log表記錄員工ID、操作類(lèi)型登錄成功、登錄失敗、修改密碼、重置密碼、IP地址、User-Agent、操作時(shí)間。這張表的價(jià)值在于一旦發(fā)生賬號(hào)被盜或內(nèi)部信息泄露可以通過(guò)日志還原操作鏈路。這里必須加粗提醒不要把驗(yàn)證碼放在前端代碼里寫(xiě)死。我在檢查別人項(xiàng)目時(shí)真的見(jiàn)過(guò)前端寫(xiě)死驗(yàn)證碼123456的騷操作雖然調(diào)試方便但上線后就是巨大的安全漏洞。驗(yàn)證碼必須由服務(wù)端生成、存Redis、校驗(yàn)也在服務(wù)端前端只負(fù)責(zé)把用戶輸入的驗(yàn)證碼傳給后端。4. 分布式與微服務(wù)落地中的硬核問(wèn)題4.1 服務(wù)間調(diào)用與鑒權(quán)統(tǒng)一微服務(wù)架構(gòu)里服務(wù)間調(diào)用是常態(tài)——訂單服務(wù)要調(diào)商家服務(wù)、配送服務(wù)要調(diào)用戶服務(wù)。但這個(gè)調(diào)來(lái)調(diào)去會(huì)帶來(lái)一個(gè)麻煩每個(gè)服務(wù)都要做鑒權(quán)嗎我的答案是在網(wǎng)關(guān)統(tǒng)一鑒權(quán)服務(wù)間調(diào)用通過(guò)內(nèi)部Token識(shí)別。用戶帶著JWT Token請(qǐng)求進(jìn)來(lái)這個(gè)Token只在網(wǎng)關(guān)被解析驗(yàn)證一次驗(yàn)證通過(guò)后網(wǎng)關(guān)把解析出來(lái)的用戶信息userId、角色等放在請(qǐng)求頭里轉(zhuǎn)發(fā)給下游服務(wù)。下游服務(wù)信任網(wǎng)關(guān)不重復(fù)解析JWT只處理業(yè)務(wù)。這樣做的收益很直接鑒權(quán)邏輯只維護(hù)一份服務(wù)開(kāi)發(fā)專注業(yè)務(wù)即可不用每寫(xiě)一個(gè)接口都拿一套JWT工具類(lèi)。但這里有一個(gè)坑網(wǎng)關(guān)到下游是內(nèi)部調(diào)用如果網(wǎng)關(guān)被繞過(guò)怎么辦比如運(yùn)維把某個(gè)服務(wù)的端口直接暴露了。我的方案是所有微服務(wù)只綁定內(nèi)網(wǎng)IP通過(guò)防火墻和Nacos注冊(cè)地址雙重限制外部無(wú)法直接訪問(wèn)。服務(wù)間所有請(qǐng)求必須攜帶內(nèi)部Token內(nèi)部服務(wù)統(tǒng)一配置的調(diào)用憑證下游服務(wù)用一個(gè)全局過(guò)濾器校驗(yàn)這個(gè)Token是否存在不存在直接拒絕。實(shí)際開(kāi)發(fā)里還有一個(gè)高頻率出現(xiàn)的問(wèn)題OpenFeign調(diào)用超時(shí)。Feign默認(rèn)連接超時(shí)1秒、讀取超時(shí)1秒這在本地跑可能夠用線上一次數(shù)據(jù)庫(kù)慢查詢就可能超時(shí)。我當(dāng)時(shí)被坑得很慘下單鏈路偶爾超時(shí)失敗排查半天才發(fā)現(xiàn)是Feign超時(shí)太短。全局配置如下feign: client: config: default: connectTimeout: 3000 readTimeout: 5000同時(shí)一定要配置Feign的熔斷降級(jí)。否則下游服務(wù)掛了上游服務(wù)會(huì)一直等待超時(shí)然后把線程池耗盡引發(fā)服務(wù)雪崩。我配了Sentinel的Feign降級(jí)下游不可用時(shí)返回一個(gè)友好的錯(cuò)誤提示而不是讓用戶看到一串超時(shí)異常堆棧。4.2 分布式事務(wù)下單、扣庫(kù)存、支付、派單怎么保持一致單體應(yīng)用里一次下單的事務(wù)直接包在Transactional里就完事了。但微服務(wù)架構(gòu)下訂單服務(wù)、庫(kù)存服務(wù)、支付服務(wù)各自有獨(dú)立數(shù)據(jù)庫(kù)本地事務(wù)根本無(wú)法跨庫(kù)保證一致性。這就是分布式事務(wù)問(wèn)題。我先說(shuō)結(jié)論實(shí)際項(xiàng)目里放棄強(qiáng)一致追求最終一致。因?yàn)橛唵蜗到y(tǒng)的高并發(fā)場(chǎng)景下強(qiáng)一致方案比如2PC的吞吐量太拉胯而且實(shí)現(xiàn)復(fù)雜度極高可維護(hù)性差。我采用的方案是Seata的AT模式配合本地消息表處理非核心鏈路。Seata AT模式的好處是對(duì)業(yè)務(wù)代碼侵入極小——它就是通過(guò)攔截SQL記錄數(shù)據(jù)快照在全局事務(wù)提交或回滾時(shí)自動(dòng)補(bǔ)償。你不用像TCC那樣得手寫(xiě)Confirm和Cancel方法。但是Seata AT模式有一個(gè)必須要知道的前提它要求全局事務(wù)內(nèi)的所有服務(wù)都必須接入同一個(gè)Seata Server。如果某個(gè)服務(wù)是第三方的比如支付服務(wù)沒(méi)法接入Seata怎么辦這種情況我換成了事務(wù)消息方案支付回調(diào)成功的消息發(fā)送到RabbitMQ訂單服務(wù)監(jiān)聽(tīng)消息消費(fèi)成功就更新訂單狀態(tài)消費(fèi)失敗就重試。消息中間件充當(dāng)了不同服務(wù)之間的數(shù)據(jù)一致性協(xié)調(diào)者。舉一個(gè)下單扣庫(kù)存的典型流程1. 訂單服務(wù)本地開(kāi)啟事務(wù)創(chuàng)建訂單 寫(xiě)一條鎖定庫(kù)存消息到本地消息表 2. 本地事務(wù)提交成功后異步任務(wù)把消息發(fā)送到MQ 3. 庫(kù)存服務(wù)消費(fèi)MQ消息執(zhí)行扣減庫(kù)存操作 4. 扣減成功回執(zhí)消息扣減失敗重試或進(jìn)死信隊(duì)列人工處理 5. 訂單服務(wù)查看到庫(kù)存扣減成功更新訂單為可支付狀態(tài)這一步里最關(guān)鍵的設(shè)計(jì)是下單和寫(xiě)消息必須在一個(gè)本地事務(wù)里。如果先發(fā)消息再寫(xiě)訂單消息發(fā)出去了訂單還沒(méi)建庫(kù)存扣了卻沒(méi)訂單歸屬數(shù)據(jù)就亂了。本地消息表是整個(gè)方案可靠性的兜底。我還踩過(guò)一個(gè)分布式事務(wù)的坑回滾時(shí)數(shù)據(jù)不一致。有一次用戶下單后支付超時(shí)訂單服務(wù)要回滾但庫(kù)存服務(wù)已經(jīng)扣減成功了。排查發(fā)現(xiàn)是Seata的全局事務(wù)超時(shí)時(shí)間設(shè)置太短支付回調(diào)比全局事務(wù)超時(shí)晚到了一步。最后把全局事務(wù)超時(shí)從30秒調(diào)到2分鐘并且支付回調(diào)增加了重試機(jī)制才徹底解決。4.3 分布式鎖搶單和庫(kù)存扣減的并發(fā)控制上一節(jié)提到騎手搶單用了Redis分布式鎖這里展開(kāi)講一下分布式鎖在庫(kù)存扣減場(chǎng)景的通用做法。外賣(mài)系統(tǒng)的庫(kù)存場(chǎng)景和電商不太一樣電商是商品庫(kù)存被很多人搶外賣(mài)是菜品當(dāng)日限量比如招牌菜每天只出30份。點(diǎn)餐高峰期多個(gè)用戶同時(shí)下單同一道限量菜必須保證不超賣(mài)。我用的是Redis分布式鎖 數(shù)據(jù)庫(kù)樂(lè)觀鎖的雙保險(xiǎn)方案public boolean deductStock(Long dishId, Integer quantity) { String lockKey stock:deduct: dishId; String lockValue UUID.randomUUID().toString(); boolean locked redisTemplate.opsForValue() .setIfAbsent(lockKey, lockValue, 3, TimeUnit.SECONDS); if (!locked) { // 獲取鎖失敗說(shuō)明有并發(fā)在扣減同一菜品庫(kù)存直接失敗讓用戶重試 return false; } try { int rows dishStockMapper.deductStockIfEnough(dishId, quantity); return rows 0; } finally { // Lua腳本釋放鎖 releaseLock(lockKey, lockValue); } }對(duì)應(yīng)的SQL是UPDATE dish_stock SET stock stock - #{quantity} WHERE dish_id #{dishId} AND stock #{quantity}這里有三道防線Redis分布式鎖確保同一時(shí)刻只有一個(gè)線程執(zhí)行檢查庫(kù)存-扣減庫(kù)存的操作。SQL條件更新stock #{quantity}保證庫(kù)存不足時(shí)更新失敗即使鎖被極端情況繞過(guò)也不會(huì)超賣(mài)。數(shù)據(jù)庫(kù)行鎖InnoDB的更新操作自動(dòng)鎖行多個(gè)實(shí)例并發(fā)更新同一行時(shí)由數(shù)據(jù)庫(kù)層面保證順序。很多人會(huì)問(wèn)既然SQL已經(jīng)用條件更新保證了不超賣(mài)為什么還用分布式鎖答案是性能。如果沒(méi)有鎖多個(gè)請(qǐng)求同時(shí)執(zhí)行UPDATEInnoDB的行鎖會(huì)讓后面的請(qǐng)求排隊(duì)等待庫(kù)存扣減在高并發(fā)下變成串行。加了Redis鎖大部分請(qǐng)求在Redis這一層就被攔下了落到數(shù)據(jù)庫(kù)的實(shí)際并發(fā)量大幅降低數(shù)據(jù)庫(kù)壓力小很多。還有一個(gè)高頻問(wèn)題Redisson的分布式鎖和手動(dòng)用RedisTemplate寫(xiě)鎖有什么區(qū)別Redisson的RLock是開(kāi)箱即用的成熟方案自帶看門(mén)狗自動(dòng)續(xù)期不用自己處理鎖超時(shí)和誤刪問(wèn)題。如果項(xiàng)目里已經(jīng)引了Redisson直接用它就好省去自己造輪子。我上面的例子用手動(dòng)實(shí)現(xiàn)是為了讓讀者理解原理生產(chǎn)環(huán)境我會(huì)優(yōu)先選Redisson。5. 常見(jiàn)問(wèn)題與排查經(jīng)驗(yàn)實(shí)錄5.1 網(wǎng)關(guān)超時(shí)與全局異常處理微服務(wù)項(xiàng)目上線后第一個(gè)高頻事故就是網(wǎng)關(guān)超時(shí)。前端等不到響應(yīng)、用戶反復(fù)刷新、后端日志里全是超時(shí)異常這種場(chǎng)景我在項(xiàng)目里處理過(guò)好幾次。網(wǎng)關(guān)超時(shí)根源是Spring Cloud Gateway默認(rèn)的響應(yīng)超時(shí)時(shí)間非常短一個(gè)請(qǐng)求經(jīng)過(guò)網(wǎng)關(guān)到下游服務(wù)下游處理超過(guò)幾秒網(wǎng)關(guān)就主動(dòng)斷開(kāi)。而外賣(mài)下單鏈路里訂單服務(wù)要調(diào)用商家服務(wù)和支付服務(wù)第一次調(diào)用往往涉及初始化連接耗時(shí)就上去了。我的解決方案是分層設(shè)置超時(shí)網(wǎng)關(guān)到下游spring.cloud.gateway.httpclient.response-timeout設(shè)置成10秒。Feign服務(wù)間調(diào)用connectTimeout 3秒、readTimeout 5秒。數(shù)據(jù)庫(kù)超時(shí)MySQL連接池中maxLifetime和connectionTimeout合理配置避免線程池堆積。前端Axios超時(shí)設(shè)置30秒并做超時(shí)重試提示。與超時(shí)配套的是全局異常處理。微服務(wù)每個(gè)服務(wù)都自己寫(xiě)try-catch會(huì)導(dǎo)致大量重復(fù)代碼我統(tǒng)一寫(xiě)了一個(gè)全局異常處理器捕獲業(yè)務(wù)異常、參數(shù)校驗(yàn)異常、兜底異常統(tǒng)一返回約定的JSON格式{ code: 500, message: 系統(tǒng)繁忙請(qǐng)稍后重試, traceId: a3f0c9d2e1b845f6 }traceId特別重要它是鏈路追蹤的入口標(biāo)識(shí)。前端報(bào)錯(cuò)時(shí)用戶截圖里只要帶上這個(gè)ID我就能用Zipkin定位到具體是哪個(gè)服務(wù)、哪個(gè)環(huán)節(jié)出了問(wèn)題排查效率提升一個(gè)量級(jí)。5.2 服務(wù)之間數(shù)據(jù)不一致的排查思路微服務(wù)架構(gòu)里最讓人頭疼的就是數(shù)據(jù)不一致——訂單顯示待支付但用戶已經(jīng)付款配送任務(wù)顯示配送中但訂單還是商家接單狀態(tài)。這種問(wèn)題往往沒(méi)有明顯的報(bào)錯(cuò)日志只有用戶投訴或?qū)~時(shí)才能發(fā)現(xiàn)。我總結(jié)出一套排查思路第一步看鏈路追蹤。用Zipkin找到這筆異常訂單對(duì)應(yīng)的一次完整調(diào)用鏈路看每一步的耗時(shí)和狀態(tài)碼。如果哪一步出現(xiàn)異常或超時(shí)問(wèn)題基本就鎖定在這。第二步看MQ消息消費(fèi)。很多數(shù)據(jù)不一致是因?yàn)橄G失或重復(fù)消費(fèi)。檢查RabbitMQ的死信隊(duì)列看看有沒(méi)有消費(fèi)失敗的消息堆積。我遇到過(guò)支付回調(diào)消息因JSON格式問(wèn)題消費(fèi)失敗重試3次后進(jìn)入死信隊(duì)列導(dǎo)致訂單一直是待支付狀態(tài)——這種問(wèn)題不看MQ日志根本發(fā)現(xiàn)不了。第三步看本地消息表。如果用了本地消息表方案檢查這張表的message_status字段看有沒(méi)有一直停在待發(fā)送或發(fā)送失敗狀態(tài)的記錄。我踩過(guò)一次坑本地消息表的定時(shí)任務(wù)被運(yùn)維誤殺了消息一個(gè)都沒(méi)發(fā)出去所有訂單卡在待支付狀態(tài)排查了一上午才定位到。第四步對(duì)賬兜底。最終手段是每天凌晨跑一個(gè)對(duì)賬任務(wù)比對(duì)訂單服務(wù)和支付服務(wù)的交易記錄發(fā)現(xiàn)不一致就自動(dòng)告警人工介入修復(fù)。這個(gè)對(duì)賬任務(wù)不能省它是數(shù)據(jù)一致性的最后一道防線。這里有一個(gè)重要的認(rèn)知微服務(wù)架構(gòu)里不可能消滅數(shù)據(jù)不一致只能縮短不一致的持續(xù)時(shí)間。設(shè)計(jì)目標(biāo)是把不一致的時(shí)間窗口控制在秒級(jí)甚至毫秒級(jí)而不是追求永遠(yuǎn)一致。5.3 Vue前端與微服務(wù)后端的聯(lián)調(diào)心得前端和后端聯(lián)調(diào)是項(xiàng)目開(kāi)發(fā)里最磨人的環(huán)節(jié)微服務(wù)架構(gòu)下這個(gè)問(wèn)題被放大了——前端要對(duì)接的不止一個(gè)后端服務(wù)而是通過(guò)網(wǎng)關(guān)統(tǒng)一暴露的多個(gè)API。我的聯(lián)調(diào)經(jīng)驗(yàn)可以濃縮成三條第一接口契約先行。開(kāi)發(fā)前先定義好每個(gè)接口的URL、請(qǐng)求參數(shù)、響應(yīng)結(jié)構(gòu)并維護(hù)一份Swagger文檔。我在項(xiàng)目里要求所有服務(wù)必須開(kāi)啟springdoc接口文檔前端根據(jù)文檔開(kāi)發(fā)后端根據(jù)文檔測(cè)試。沒(méi)有契約約束前端等接口、后端改接口兩邊互相猜工期無(wú)限拉長(zhǎng)。第二前端只認(rèn)網(wǎng)關(guān)地址。開(kāi)發(fā)環(huán)境下前端環(huán)境變量里配置VITE_API_BASE_URL/api通過(guò)Vite的代理轉(zhuǎn)發(fā)到本地網(wǎng)關(guān)。這樣前端代碼里不會(huì)出現(xiàn)任何后端服務(wù)地址上線后只需改代理配置或Nginx轉(zhuǎn)發(fā)前端代碼一行不用動(dòng)。Vite開(kāi)發(fā)代理配置大致是這樣// vite.config.js export default defineConfig({ server: { proxy: { /api: { target: http://localhost:8080, // 網(wǎng)關(guān)地址 changeOrigin: true, pathRewrite: { ^/api: } } } } })第三不要在前端處理任何業(yè)務(wù)狀態(tài)流轉(zhuǎn)。我見(jiàn)過(guò)有前端代碼里寫(xiě)了如果訂單狀態(tài)是2就顯示商家已接單這種邏輯后來(lái)后端狀態(tài)加了新枚舉前端忘了同步頁(yè)面顯示錯(cuò)亂。正確做法是后端返回狀態(tài)枚舉的code和desc前端只展示desc不做業(yè)務(wù)判斷。狀態(tài)機(jī)邏輯只屬于后端前端只管展示。聯(lián)調(diào)中還有一個(gè)讓我記憶深刻的坑本地跨域問(wèn)題明明配置了還是報(bào)錯(cuò)。后來(lái)發(fā)現(xiàn)是Cookie跨域——JWT放在請(qǐng)求頭里沒(méi)問(wèn)題但為了存用戶狀態(tài)我在Token里塞了用戶信息Cookie的SameSite屬性導(dǎo)致跨域攜帶不了Cookie。最后把登錄態(tài)方案改成了前端存儲(chǔ)Token、請(qǐng)求頭攜帶Token的模式徹底繞開(kāi)Cookie跨域問(wèn)題。寫(xiě)在最后的一些體會(huì)這個(gè)項(xiàng)目從搭建框架到跑通全流程前后花了大幾周時(shí)間?；仡^看我個(gè)人最大的感觸是微服務(wù)真正的難點(diǎn)不在于框架怎么搭而在于業(yè)務(wù)怎么拆、數(shù)據(jù)怎么保持一致、問(wèn)題怎么快速定位。很多人一上來(lái)就照抄官方Demo搭了個(gè)注冊(cè)中心和網(wǎng)關(guān)以為微服務(wù)就入門(mén)了結(jié)果一寫(xiě)真實(shí)業(yè)務(wù)就卡殼——訂單要跨服務(wù)查數(shù)據(jù)、狀態(tài)要跨服務(wù)流轉(zhuǎn)、并發(fā)要跨服務(wù)控制每個(gè)問(wèn)題都比單體時(shí)代復(fù)雜一個(gè)量級(jí)。外賣(mài)點(diǎn)餐配送系統(tǒng)作為微服務(wù)實(shí)踐項(xiàng)目確實(shí)值得做業(yè)務(wù)場(chǎng)景足夠豐富每一個(gè)模塊都能挖出有價(jià)值的技術(shù)點(diǎn)而且技術(shù)棧通用性強(qiáng)做完這一套電商、本地生活、即時(shí)配送類(lèi)系統(tǒng)的核心套路基本都能復(fù)用。也希望這篇文章里關(guān)于員工密碼找回、訂單狀態(tài)機(jī)、分布式鎖的細(xì)節(jié)能幫你少踩幾個(gè)坑。