簡(jiǎn)介尚品甄選電商平臺(tái)全棧開(kāi)發(fā)項(xiàng)目資料包面向具備Java基礎(chǔ)并希望掌握微服務(wù)架構(gòu)的開(kāi)發(fā)者用于解決從零搭建可擴(kuò)展、可維護(hù)電商系統(tǒng)的實(shí)踐需求。內(nèi)容涵蓋基于Java17與Spring Cloud微服務(wù)的前后端代碼、用戶與商品訂單管理系統(tǒng)以及Redis緩存、MinIO對(duì)象存儲(chǔ)、Docker容器化部署等完整集成方案覆蓋用戶注冊(cè)登錄、商品瀏覽、購(gòu)物車、訂單管理等核心業(yè)務(wù)流程。壓縮包共505個(gè)文件整體約3.06MB主要包含185個(gè)Java源碼、99個(gè)JS腳本、52個(gè)Vue組件、52個(gè)XML配置、17個(gè)YAML環(huán)境配置及圖片、SQL、Dockerfile、開(kāi)發(fā)說(shuō)明文檔等目錄結(jié)構(gòu)清晰便于按模塊對(duì)照學(xué)習(xí)。目前已有82人學(xué)習(xí)下載適合用于電商項(xiàng)目實(shí)戰(zhàn)練習(xí)、微服務(wù)架構(gòu)設(shè)計(jì)參考或畢業(yè)設(shè)計(jì)拓展。同時(shí)附帶詳細(xì)開(kāi)發(fā)文檔與附贈(zèng)資源可幫助理解代碼結(jié)構(gòu)、部署流程及各微服務(wù)組件的協(xié)作方式快速遷移應(yīng)用到自有項(xiàng)目之中。1. 這個(gè)項(xiàng)目是什么一套把 Java17、SpringCloud 和中間件串起來(lái)的電商全棧實(shí)踐很多做后臺(tái)或全棧的同學(xué)看到“Java17 與 SpringCloud 微服務(wù)架構(gòu)”這個(gè)組合第一反應(yīng)是“我是不是要裝一堆中間件、連不連得起來(lái)”。實(shí)際上這套電商平臺(tái)項(xiàng)目的實(shí)踐價(jià)值就是把一條完整鏈路講清楚了Java17 編譯器與 SpringBoot 3.x 的匹配、SpringCloud 里注冊(cè)中心與網(wǎng)關(guān)的分工、Redis 緩存和 MinIO 文件存儲(chǔ)的接入以及最后的 Docker 容器化部署。適合兩類人一類是畢業(yè)設(shè)計(jì)或課設(shè)要交微服務(wù)作品的學(xué)生另一類是在單體系統(tǒng)里待久了、想看看典型分布式方案怎么落地的開(kāi)發(fā)者。它不像是“造一個(gè)淘寶”更像是一條可以反復(fù)復(fù)現(xiàn)走通的技術(shù)主線值得照著敲一遍再按自己的業(yè)務(wù)改。2. 架構(gòu)拆解五類基礎(chǔ)服務(wù)怎么分工選型理由與版本匹配2.1 Java17 不是換個(gè) JDK 版本那么簡(jiǎn)單Spring Boot 3.x 的兼容矩陣標(biāo)題把 Java17 放在最前面是有原因的。Java17 是 LTS 版本但在 Spring Boot 3.x 之前很多團(tuán)隊(duì)只在把玩階段用過(guò)它。真正讓 Java17 成為微服務(wù)基線的是 Spring Boot 3.x它把整個(gè)運(yùn)行時(shí)基線抬到了 Java17同時(shí)把javax.*包遷移到了jakarta.*。這意味著你從 Java8 項(xiàng)目直接拷貝代碼過(guò)來(lái)大概率會(huì)遇到兩個(gè)問(wèn)題javax.servlet找不到、Lombok 版本太老直接報(bào)編譯錯(cuò)。我一般會(huì)在父 POM 里固定這樣一組參數(shù)properties java.version17/java.version maven.compiler.source17/maven.compiler.source maven.compiler.target17/maven.compiler.target spring-boot.version3.2.5/spring-boot.version spring-cloud.version2023.0.3/spring-cloud.version spring-cloud-alibaba.version2023.0.1.2/spring-cloud-alibaba.version lombok.version1.18.32/lombok.version /properties這里最關(guān)鍵的是 Spring Cloud 與 Spring Cloud Alibaba 的版本要和 Spring Boot 3.2.x 對(duì)齊否則 Nacos 客戶端啟動(dòng)時(shí)會(huì)報(bào)包沖突。Lombok 必須用到 1.18.26 以上因?yàn)榕f版本對(duì) Java17 的 record 和密封類支持不完整。另一個(gè)容易翻車的點(diǎn)是依賴樹(shù)里殘留了老的javax.annotation-apiSpring Boot 3.x 下應(yīng)該統(tǒng)一走jakarta.annotation不然運(yùn)行期會(huì)看到NoClassDefFoundError。Java17 本體除了配合框架也值得在業(yè)務(wù)代碼里實(shí)際用起來(lái)。比如 DTO 可以寫(xiě)成 recordpublic record SkuDTO(Long id, String name, BigDecimal price, Integer stock) { }這段代碼替代了傳統(tǒng)的手寫(xiě) getter/setter/構(gòu)造器反編譯后仍然是完整的類文件。要注意 record 不能被繼承也不適合放 JPA 實(shí)體只適合做傳輸對(duì)象和接口返回值。如果你在項(xiàng)目里看到CglibAopProxy報(bào)錯(cuò)先檢查是不是把 record 當(dāng)成了被代理的 Bean。2.2 SpringCloud 組件的角色分工注冊(cè)、網(wǎng)關(guān)、配置與遠(yuǎn)程調(diào)用SpringCloud 是一組組件集合不是單一框架。這個(gè)電商項(xiàng)目里的典型組合是 Nacos 做注冊(cè)中心和配置中心、Spring Cloud Gateway 做統(tǒng)一入口、OpenFeign 做服務(wù)間調(diào)用。相比 Eureka 加 Zuul 的老組合Nacos 自帶了配置管理可以少部署一個(gè)配置服務(wù)Gateway 基于 WebFlux不占 Tomcat 線程適合做路由轉(zhuǎn)發(fā)和統(tǒng)一鑒權(quán)。這個(gè)項(xiàng)目的服務(wù)劃分不復(fù)雜常見(jiàn)做法是拆成用戶、商品、訂單、網(wǎng)關(guān)四個(gè)可獨(dú)立啟動(dòng)的模塊服務(wù)名端口核心職責(zé)主要依賴gateway8080統(tǒng)一入口、路由轉(zhuǎn)發(fā)、登錄鑒權(quán)Gateway、Nacos Discoveryuser-service8101用戶注冊(cè)登錄、收貨地址、后臺(tái)管理員Spring MVC、Redis、MinIOproduct-service8102商品分類、SKU 管理、商品緩存、圖片上傳Spring MVC、Redis、MinIOorder-service8103購(gòu)物車、訂單創(chuàng)建、庫(kù)存扣減、支付回調(diào)預(yù)留Spring MVC、Redis、OpenFeignGateway 端口對(duì)外是 8080業(yè)務(wù)服務(wù)端口不直接暴露只在 Docker 內(nèi)網(wǎng)互通。前端請(qǐng)求先到網(wǎng)關(guān)網(wǎng)關(guān)按路徑前綴把/api/user/**轉(zhuǎn)發(fā)到 user-service把/api/product/**轉(zhuǎn)發(fā)到 product-service。這種方式在本地開(kāi)發(fā)時(shí)也能跑通只是需要把網(wǎng)關(guān)的routes配置從 Nacos 拉取而不是寫(xiě)死在 yml 里。2.3 Redis 和 MinIO 在電商模塊里的落點(diǎn)緩存、會(huì)話、鎖與對(duì)象存儲(chǔ)Redis 在這個(gè)項(xiàng)目里承擔(dān)了三件事驗(yàn)證碼與 Token 的臨時(shí)存儲(chǔ)、熱點(diǎn)商品緩存、庫(kù)存預(yù)扣減。不要把 Redis 當(dāng)成數(shù)據(jù)庫(kù)用它的價(jià)值在于把高頻讀寫(xiě)的壓力從 MySQL 上扛走。MinIO 則負(fù)責(zé)商品圖片、品牌 Logo、用戶頭像這類靜態(tài)文件文件本身不落數(shù)據(jù)庫(kù)數(shù)據(jù)庫(kù)只存 URL。RedisTemplate 的序列化方式直接決定你能不能從 Redis Desktop Manager 里看到可讀數(shù)據(jù)。默認(rèn)的 JdkSerializationRedisSerializer 會(huì)把 key 變成一串二進(jìn)制亂碼排查問(wèn)題時(shí)非常痛苦。我一般會(huì)單獨(dú)配置一個(gè) StringRedisTemplate 處理 key再配一個(gè)帶 Jackson 序列化的 RedisTemplate 處理 ValueConfiguration public class RedisConfig { Bean public RedisTemplateString, Object redisTemplate(RedisConnectionFactory factory) { RedisTemplateString, Object template new RedisTemplate(); template.setConnectionFactory(factory); GenericJackson2JsonRedisSerializer serializer new GenericJackson2JsonRedisSerializer(); template.setKeySerializer(RedisSerializer.string()); template.setHashKeySerializer(RedisSerializer.string()); template.setValueSerializer(serializer); template.setHashValueSerializer(serializer); template.afterPropertiesSet(); return template; } }參數(shù)說(shuō)明RedisSerializer.string()直接使用 UTF-8 字符集key 在客戶端工具里可讀GenericJackson2JsonRedisSerializer會(huì)把對(duì)象的類型信息作為class字段寫(xiě)進(jìn) JSON反序列化時(shí)才能還原成原類型。代價(jià)是 JSON 體積稍大、包含類型元數(shù)據(jù)適合緩存結(jié)構(gòu)簡(jiǎn)單的商品 DTO。如果你的緩存對(duì)象里帶 LocalDateTime還要額外注冊(cè) JavaTimeModule否則反序列化會(huì)報(bào)InvalidDefinitionException這也是個(gè)高頻踩坑點(diǎn)。3. 跑通最小工程Maven 依賴、Redis 緩存與 MinIO 配置模板3.1 搭建工程骨架父 POM 與 Java17 編譯參數(shù)項(xiàng)目建議采用多模塊 Maven 結(jié)構(gòu)父模塊只放依賴管理和公共插件不寫(xiě)業(yè)務(wù)代碼。子模塊按gateway、user-service、product-service、order-service、common劃分。common里只放統(tǒng)一返回體、異常碼、分頁(yè)對(duì)象不引入 Spring Cloud 組件避免業(yè)務(wù)服務(wù)被迫多加載一堆網(wǎng)關(guān)依賴。父 POM 的依賴管理里最值得注意的不是數(shù)量而是 Spring Cloud Alibaba 的 BOM 必須排在其他 Spring Cloud 組件之前。Alibaba BOM 會(huì)覆蓋部分組件版本如果聲明順序反了Nacos Client 和 Spring Cloud Commons 之間會(huì)出現(xiàn)版本倒掛dependencyManagement dependencies dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-alibaba-dependencies/artifactId version2023.0.1.2/version typepom/type scopeimport/scope /dependency dependency groupIdorg.springframework.cloud/groupId artifactIdspring-cloud-dependencies/artifactId version2023.0.3/version typepom/type scopeimport/scope /dependency /dependencies /dependencyManagement子模塊里只需要聲明用到的 starter不需要寫(xiě)版本號(hào)。這里建議所有服務(wù)都只引入spring-boot-starter-web和spring-cloud-starter-alibaba-nacos-discovery需要配置中心的服務(wù)再加spring-cloud-starter-alibaba-nacos-config。不要把spring-boot-starter-data-redis放進(jìn) common因?yàn)樗鼤?huì)觸發(fā)自動(dòng)配置讓沒(méi)有 Redis 需求的網(wǎng)關(guān)服務(wù)也去嘗試連接 Redis。3.2 三份基礎(chǔ)配置模板bootstrap、application.yml 與 Docker ComposeSpring Cloud Alibaba 項(xiàng)目的配置文件通常分兩份bootstrap.yml負(fù)責(zé)連接 Nacos 配置中心application.yml負(fù)責(zé)本地?cái)?shù)據(jù)源和中間件連接。bootstrap.yml在 Spring Boot 3.x 里默認(rèn)不再自動(dòng)加載需要額外引入依賴dependency groupIdorg.springframework.cloud/groupId artifactIdspring-cloud-starter-bootstrap/artifactId /dependency如果不加這個(gè)依賴你寫(xiě)的bootstrap.yml會(huì)被靜默忽略Nacos 配置中心永遠(yuǎn)連不上服務(wù)注冊(cè)倒是正常。這個(gè)坑非常隱蔽表現(xiàn)是啟動(dòng)日志里完全沒(méi)有 Nacos Config 相關(guān)輸出。application.yml的核心配置如下注意區(qū)分環(huán)境spring: data: redis: host: 127.0.0.1 port: 6379 password: timeout: 3s lettuce: pool: max-active: 16 max-idle: 8 min-idle: 2 servlet: multipart: max-file-size: 10MB max-request-size: 30MB minio: endpoint: http://127.0.0.1:9000 access-key: minioadmin secret-key: minioadmin bucket: mall-images參數(shù)說(shuō)明timeout: 3s指的是獲取連接的超時(shí)時(shí)間不是讀寫(xiě)超時(shí)。池參數(shù)max-active: 16在并發(fā)不高時(shí)足夠如果商品列表接口每秒 QPS 超過(guò) 500建議調(diào)大到 64否則 Lettuce 會(huì)頻繁等待連接。MinIO 的endpoint要寫(xiě) API 端口 9000不是控制臺(tái)端口 9001很多人把這兩者搞混導(dǎo)致本地能開(kāi)管理頁(yè)面但代碼一直連不上。3.3 商品緩存回源的最小實(shí)現(xiàn)緩存穿透、擊穿與失效商品詳情是電商項(xiàng)目里最適合做緩存的接口。一個(gè) SKU 的詳情讀取頻率遠(yuǎn)高于寫(xiě)入頻率而且數(shù)據(jù)維度簡(jiǎn)單。下面這段代碼是商品詳情接口的常見(jiàn)實(shí)現(xiàn)邏輯不復(fù)雜但把緩存穿透和擊穿都擋住了public SkuDTO getSkuDetail(Long skuId) { String key sku:detail: skuId; String cached stringRedisTemplate.opsForValue().get(key); if (cached ! null) { return JSON.parseObject(cached, SkuDTO.class); } // 加鎖只允許一個(gè)線程回源數(shù)據(jù)庫(kù) String lockKey sku:lock: skuId; Boolean locked stringRedisTemplate.opsForValue() .setIfAbsent(lockKey, 1, Duration.ofSeconds(10)); if (Boolean.TRUE.equals(locked)) { try { SkuDTO sku skuMapper.selectById(skuId); if (sku null) { // 空值緩存防止穿透 stringRedisTemplate.opsForValue() .set(key, , Duration.ofSeconds(60)); } else { stringRedisTemplate.opsForValue() .set(key, JSON.toJSONString(sku), Duration.ofMinutes(30)); } return sku; } finally { stringRedisTemplate.delete(lockKey); } } else { // 沒(méi)搶到鎖的請(qǐng)求短暫睡眠后重試 Thread.sleep(50); return getSkuDetail(skuId); } }代碼邏輯是標(biāo)準(zhǔn)的 Cache Aside 模式先查緩存緩存未命中就通過(guò)setIfAbsent搶鎖搶到鎖的線程回源數(shù)據(jù)庫(kù)并重建緩存其他線程睡眠 50 毫秒后遞歸重試。setIfAbsent加過(guò)期時(shí)間這一步是原子的不會(huì)出現(xiàn)“加了鎖但沒(méi)設(shè)過(guò)期時(shí)間”的死鎖場(chǎng)景也不用手動(dòng)拼接 SETNX 和 EXPIRE 兩條命令?？罩稻彺娌荒苁÷苑駝t惡意請(qǐng)求用一個(gè)不存在的 ID 就能打穿到數(shù)據(jù)庫(kù)。要注意的是鎖粒度。這里的鎖 key 是skuId意思是同一個(gè) SKU 只有一個(gè)線程回源不同 SKU 之間互不影響。如果把鎖粒度做到整個(gè)商品列表那么列表接口一旦緩存失效所有商品的詳情請(qǐng)求會(huì)全部排隊(duì)延遲會(huì)被放大到不可接受。4. 避坑與排查Redis 超時(shí)、MinIO 啟動(dòng)失敗、Docker 虛擬化檢查4.1 Redis 連接報(bào) Command timed out 或 Connection reset先查這些參數(shù)現(xiàn)象服務(wù)啟動(dòng)正常第一次訪問(wèn)接口時(shí)拋出io.lettuce.core.RedisCommandTimeoutException: Command timed out after 3 second(s)或者Connection reset by peer。原因Windows 上使用 Redis 內(nèi)存版時(shí)沒(méi)有配置最大堆內(nèi)存服務(wù)端在內(nèi)存抖動(dòng)時(shí)無(wú)法響應(yīng)更常見(jiàn)的另一個(gè)原因是不小心把spring.redis.timeout配成了 3000 毫秒以下而接口里同時(shí)做了多個(gè) Redis 操作累計(jì)等待超過(guò)閾值。解決如果能打開(kāi) Redis 命令行窗口先執(zhí)行CONFIG GET timeout確保服務(wù)端沒(méi)有默認(rèn)掛起。然后檢查連接池配置把獲取連接超時(shí)設(shè)為 3 秒把 Lettuce 讀寫(xiě)超時(shí)放到 5 秒兩者不要混用。Windows 上運(yùn)行 redis-server 時(shí)建議加參數(shù)redis-server --maxheap 256mb否則 Redis 在內(nèi)存壓力下會(huì)直接卡死。這個(gè)坑在 Docker 里不明顯因?yàn)?Linux 容器會(huì)動(dòng)態(tài)分配內(nèi)存但在本地 Windows 開(kāi)發(fā)時(shí)很容易碰到。4.2 MinIO 啟動(dòng)后前端訪問(wèn)失敗端口、桶策略與啟動(dòng)參數(shù)現(xiàn)象Docker 里 MinIO 容器起來(lái)了瀏覽器能打開(kāi) 9001 端口的管理界面但前端或后端訪問(wèn) 9000 端口上傳文件時(shí)總是連接失敗或者上傳成功但圖片 URL 打開(kāi)報(bào) 403。原因第一MinIO 有兩個(gè)端口9000 是 S3 API 端口9001 是控制臺(tái)端口代碼里必須用 9000 作為 endpoint第二桶權(quán)限是 private生成的 URL 沒(méi)有簽名瀏覽器自然無(wú)權(quán)限讀取第三Docker 啟動(dòng)時(shí)環(huán)境變量MINIO_ROOT_USER和MINIO_ROOT_PASSWORD寫(xiě)在兩行但 yml 文件縮進(jìn)錯(cuò)誤導(dǎo)致只生效了一半。解決容器啟動(dòng)后先確認(rèn)端口映射正確然后單獨(dú)建桶并設(shè)置訪問(wèn)策略。常見(jiàn)做法是上傳時(shí)生成預(yù)簽名 URL或者把圖片桶設(shè)為 publicdocker exec -it minio sh mc alias set local http://127.0.0.1:9000 minioadmin minioadmin mc mb --ignore-existing local/mall-images mc anonymous set download local/mall-images參數(shù)說(shuō)明anonymous set download是把桶設(shè)置為公開(kāi)下載適合商品圖片這類不需要鑒權(quán)的靜態(tài)資源。頭像、身份證照片等隱私文件不能這樣處理應(yīng)該在上傳時(shí)生成預(yù)簽名 URL 并設(shè)置有效期。4.3 Docker Desktop 報(bào) virtualisation support wasnt detectedBIOS 與 WSL2 排查現(xiàn)象Windows 11 上安裝 Docker Desktop 后啟動(dòng)失敗彈窗提示virtualization support wasnt detected或者直接提示Docker Desktop failed to start because virtualisation support wasnt detected。原因最常見(jiàn)的是 BIOS 里 Intel VT-x 或 AMD-V 沒(méi)有開(kāi)啟其次是 Windows 的 Hyper-V 功能沒(méi)有啟用。Docker Desktop 依賴虛擬化能力跟電腦內(nèi)存、硬盤(pán)空間關(guān)系不大。解決先打開(kāi)任務(wù)管理器在“性能”頁(yè)查看“虛擬化”是否顯示“已啟用”。如果顯示“已禁用”需要重啟電腦進(jìn) BIOS 開(kāi)啟 Intel Virtualization Technology不同主板位置不一樣一般藏在 Advanced 或 Security 菜單下。如果 BIOS 已開(kāi)啟但 Docker 仍報(bào)錯(cuò)再執(zhí)行以下命令啟用 Windows 功能然后重啟dism.exe /Online /Enable-Feature /FeatureName:Microsoft-Hyper-V-All /All dism.exe /Online /Enable-Feature /FeatureName:VirtualMachinePlatform /All注意啟用 Hyper-V 后如果還用 Vmware 或 VirtualBox兩者可能沖突。另一個(gè)思路是 Docker Desktop 設(shè)置里把后端從 Hyper-V 切換到 WSL2但前提是 WSL2 已安裝。沒(méi)有安裝的話執(zhí)行wsl --install重啟后再打開(kāi) Docker Desktop。這個(gè)坑的解決路徑不只一條關(guān)鍵是先把“虛擬化是否可用”這個(gè)問(wèn)題定位清楚后面才談得上拉鏡像。4.4 docker pull minio 失敗鏡像 tag 與平臺(tái)架構(gòu)匹配現(xiàn)象執(zhí)行docker pull minio/minio時(shí)進(jìn)度條卡住或者拉取完成后啟動(dòng)容器立刻退出日志里出現(xiàn)exec format error。原因exec format error說(shuō)明鏡像架構(gòu)與主機(jī)不匹配常見(jiàn)于 Apple Silicon 或 ARM 設(shè)備上拉了 amd64 鏡像。而拉取卡住的原因往往不是版本號(hào)錯(cuò)誤而是 tag 寫(xiě)了一個(gè)不存在或很少人用的具體版本號(hào)Docker Hub 上解析不到。解決先確認(rèn)主機(jī)架構(gòu)然后顯式指定平臺(tái)參數(shù)和標(biāo)準(zhǔn) tag。常見(jiàn)做法是使用官方最新穩(wěn)定 tagminio/minio:latest在多數(shù) Docker 版本下會(huì)自動(dòng)選擇對(duì)應(yīng)架構(gòu)的鏡像。如果在 ARM 設(shè)備上必須要 x86 鏡像可以加--platform linux/amd64docker pull --platform linux/amd64 minio/minio:latest這里不建議在 Compose 文件里寫(xiě)死一個(gè)冷門(mén) tag因?yàn)槟銚Q一臺(tái)機(jī)器可能就拉不到了。用latest雖然可重復(fù)性差一些但作為本地開(kāi)發(fā)環(huán)境可獲取性優(yōu)先級(jí)更高。4.5 Java17 編譯啟動(dòng)時(shí)遇到的 Lombok 與 SLF4J 沖突現(xiàn)象代碼在 IDEA 里編譯正常mvn clean package也成功但java -jar啟動(dòng)后立刻報(bào)java.lang.ExceptionInInitializerError或ClassNotFoundException: org.slf4j.Logger。原因Lombok 的注解處理器版本低于 1.18.26無(wú)法正確識(shí)別 Java17 的字節(jié)碼版本會(huì)在 class 文件里留下無(wú)效的引用SLF4J 的問(wèn)題則是項(xiàng)目里同時(shí)引入了log4j-slf4j-impl和logback-classic兩個(gè)綁定同時(shí)存在啟動(dòng)時(shí)互相爭(zhēng)搶。解決Lombok 統(tǒng)一升到 1.18.32并把 Lombok 的provided作用域?qū)懬宄LF4J 沖突使用 Maven 依賴樹(shù)排查把多余的綁定排除掉。排除后執(zhí)行mvn dependency:tree檢查確保slf4j-api只保留一個(gè)版本這是最直接的驗(yàn)證方式。5. 容器化部署與驗(yàn)證用 Docker Compose 編排五個(gè)基礎(chǔ)服務(wù)5.1 編排文件設(shè)計(jì)把 MySQL、Redis、MinIO 和 Nacos 放在同一網(wǎng)絡(luò)本地跑通之后容器化部署是把項(xiàng)目從“能運(yùn)行”變成“能被別人運(yùn)行”的關(guān)鍵一步。用 Docker Compose 管理的好處是所有中間件和業(yè)務(wù)服務(wù)都能一鍵拉起不用在每臺(tái)機(jī)器上手動(dòng)裝 MySQL、Redis、Nacos。Compose 文件里要把所有服務(wù)放進(jìn)同一個(gè)自定義網(wǎng)絡(luò)這樣服務(wù)名就是主機(jī)名例如mysql、redis、minio可以直接作為連接地址。先看中間件部分的編排services: mysql: image: mysql:8.0 container_name: mall-mysql environment: MYSQL_ROOT_PASSWORD: root123 MYSQL_DATABASE: mall ports: - 3306:3306 volumes: - ./data/mysql:/var/lib/mysql - ./sql/init.sql:/docker-entrypoint-initdb.d/init.sql healthcheck: test: [CMD, mysqladmin, ping, -h, localhost] interval: 10s retries: 5 redis: image: redis:7.2 container_name: mall-redis command: [redis-server, --appendonly, yes] ports: - 6379:6379 volumes: - ./data/redis:/data minio: image: minio/minio:latest container_name: mall-minio command: server /data --console-address :9001 environment: MINIO_ROOT_USER: minioadmin MINIO_ROOT_PASSWORD: minioadmin ports: - 9000:9000 - 9001:9001 volumes: - ./data/minio:/data參數(shù)說(shuō)明MySQL 的docker-entrypoint-initdb.d目錄下只執(zhí)行首次初始化腳本如果數(shù)據(jù)卷里已經(jīng)有舊數(shù)據(jù)重新創(chuàng)建容器時(shí)不會(huì)再次執(zhí)行。Redis 的--appendonly yes開(kāi)啟 AOF 持久化避免容器重啟后緩存數(shù)據(jù)丟失但注意這會(huì)增加磁盤(pán)寫(xiě)入量本地開(kāi)發(fā)可以接受。MinIO 的command里server /data是 API 服務(wù)入口--console-address :9001指定控制臺(tái)端口兩個(gè)端口缺一不可漏掉console-address會(huì)導(dǎo)致控制臺(tái)默認(rèn)端口沖突。5.2 構(gòu)建腳本模板等待就緒再啟動(dòng)業(yè)務(wù)服務(wù)業(yè)務(wù)服務(wù)依賴 Nacos 和數(shù)據(jù)庫(kù)如果 Compose 里所有服務(wù)同時(shí)啟動(dòng)業(yè)務(wù)服務(wù)可能在 Nacos 還沒(méi)注冊(cè)好時(shí)就退出重試。Compose 的depends_on只控制啟動(dòng)順序不保證 Nacos 已就緒。我一般會(huì)在啟動(dòng)腳本里寫(xiě)一個(gè)簡(jiǎn)單的等待循環(huán)#!/bin/bash echo 等待 Nacos 啟動(dòng)... until curl -s http://127.0.0.1:8848/nacos/v1/console/health/readiness | grep -q true; do sleep 2 done echo Nacos 已就緒開(kāi)始構(gòu)建并啟動(dòng)業(yè)務(wù)服務(wù) docker compose up -d --build gateway user-service product-service order-service docker compose logs -f --tail100 gateway邏輯說(shuō)明curl請(qǐng)求 Nacos 的 health 接口返回內(nèi)容里包含true才繼續(xù)執(zhí)行否則每 2 秒重試。把“等待基礎(chǔ)設(shè)施就緒”和“啟動(dòng)業(yè)務(wù)服務(wù)”分成兩個(gè)階段比在 Compose 里堆depends_on更可靠。注意docker compose up -d --build會(huì)重新構(gòu)建鏡像如果你只是改了配置沒(méi)改代碼直接docker compose restart更快。5.3 部署后的驗(yàn)證清單緩存命中、存儲(chǔ)桶可達(dá)、網(wǎng)關(guān)路由部署完成不代表業(yè)務(wù)可用建議按以下順序驗(yàn)證最終效果docker compose ps docker exec -it mall-redis redis-cli ping curl -s http://127.0.0.1:8080/api/product/sku/1 redis-cli --scan --pattern sku:detail:* curl -s -X PUT http://127.0.0.1:9000/mall-images/test.png \ -H Content-Type: image/png --data-binary test.png參數(shù)說(shuō)明redis-cli ping驗(yàn)證 Redis 可寫(xiě)訪問(wèn)商品詳情接口后在 Redis 里掃描sku:detail:*前綴能查到鍵說(shuō)明緩存已經(jīng)寫(xiě)入對(duì) MinIO 的 9000 端口發(fā)起 PUT 請(qǐng)求能返回 200 說(shuō)明 API 端口和桶權(quán)限都正常。這四個(gè)檢查點(diǎn)覆蓋了中間件、緩存回源、網(wǎng)關(guān)路由和文件存儲(chǔ)任何一個(gè)失敗都能快速縮小問(wèn)題范圍。6. 進(jìn)階與驗(yàn)證把庫(kù)存扣減做成防超賣并給簡(jiǎn)歷留一個(gè)能講的技術(shù)點(diǎn)6.1 用 Redis 原子操作把庫(kù)存扣減改成防超賣訂單服務(wù)的核心難點(diǎn)是庫(kù)存扣減。如果直接用 MySQL 的update stock set count count - 1 where sku_id ?在高并發(fā)下會(huì)出現(xiàn)行鎖競(jìng)爭(zhēng)如果用 Java 代碼先查再寫(xiě)就必然存在超賣窗口。常見(jiàn)做法是把庫(kù)存預(yù)扣減放到 Redis 里用原子腳本處理再異步同步到 MySQLString script if tonumber(redis.call(get, KEYS[1])) tonumber(ARGV[1]) then return redis.call(decrby, KEYS[1], ARGV[1]) else return -1 end ; DefaultRedisScriptLong redisScript new DefaultRedisScript(script, Long.class); Long result stringRedisTemplate.execute( redisScript, Collections.singletonList(stock:sku: skuId), String.valueOf(count) );邏輯說(shuō)明腳本先取出庫(kù)存值如果充足就執(zhí)行decrby扣減否則返回 -1。整個(gè)判斷和扣減在 Redis 里是原子的不涉及 Java 層面的并發(fā)問(wèn)題。返回 -1 時(shí)客戶端直接提示庫(kù)存不足返回正數(shù)時(shí)再生成訂單并發(fā)送消息給 MySQL 異步落庫(kù)。這套方案的好處是扣減性能接近 Redis 的極限壞處是 Redis 和 MySQL 之間存在短暫不一致需要引入定時(shí)對(duì)賬或 MQ 最終一致性處理這也是面試時(shí)可以展開(kāi)講三分鐘的技術(shù)點(diǎn)。6.2 壓測(cè)和觀察手段別只盯著接口通不通部署完成后建議做一輪簡(jiǎn)單壓測(cè)觀察接口在并發(fā)下的表現(xiàn)。用ab工具就能看出緩存是否有效ab -n 5000 -c 100 -k http://127.0.0.1:8080/api/product/sku/1壓測(cè)時(shí)重點(diǎn)看三個(gè)指標(biāo)Redis 命中率、接口平均響應(yīng)時(shí)間、Docker 容器 CPU 占用。緩存命中率可以在 Redis 里執(zhí)行INFO stats查看keyspace_hits和keyspace_misses的比值。如果命中率低于 90%說(shuō)明緩存 key 的設(shè)計(jì)或過(guò)期時(shí)間不合理優(yōu)先檢查是不是把用戶維度數(shù)據(jù)放進(jìn)了公共商品緩存。如果 Redis CPU 高但 MySQL CPU 低說(shuō)明查詢邏輯沒(méi)問(wèn)題瓶頸可能出在序列化方式上可以考慮換更緊湊的 JSON 序列化或直接緩存二進(jìn)制字節(jié)。6.3 一個(gè)值得長(zhǎng)期保留的習(xí)慣我做完這類項(xiàng)目后的習(xí)慣是留一個(gè)獨(dú)立的docs/目錄里面記錄每個(gè)中間件的啟動(dòng)命令、端口約定和踩過(guò)的坑尤其是版本兼容矩陣和 Compose 啟動(dòng)順序這類信息。下次重新部署或換機(jī)器時(shí)不至于從零摸索。一句話收尾微服務(wù)項(xiàng)目的復(fù)雜度不在代碼量而在“服務(wù)連起來(lái)之后的表現(xiàn)”希望這個(gè)項(xiàng)目能幫你真正跑通一條完整的電商鏈路也祝你少踩幾個(gè)我踩過(guò)的坑。本文還有配套的精品資源點(diǎn)擊獲取