習(xí)java spring cloud（八）)
用豆包輔助從頭開始學(xué)習(xí)java spring cloud八昨天學(xué)習(xí)了redis的一些基本操作今天學(xué)習(xí)以理論為主學(xué)習(xí)架構(gòu)理論 RESTful API 規(guī)范。第一部分架構(gòu)演進1.單體架構(gòu)所有功能全部卸載一個springboot工程里面以商城為例用戶、訂單、支付、商品全部在一起一份代碼、一個包一套數(shù)據(jù)庫。這種架構(gòu)的優(yōu)點就是開發(fā)簡單部署簡單小項目效率高。但是缺點也非常明顯1.代碼量大模塊耦合嚴(yán)重改其中一處容易牽連其他功能2.全部功能公用一個實例當(dāng)某一個功能壓力大的時候需要整體擴容不能單獨給高壓力部分?jǐn)U容3.所有人在一個代碼庫開發(fā)代碼沖突頻繁4.一個模塊出現(xiàn)了漏洞整個應(yīng)用可能就宕機了。所以也就限制了這類項目的適用范圍小型項目內(nèi)部管理系統(tǒng)。tips耦合就是兩個功能模塊之間綁的太緊密了當(dāng)a模塊小小改動b模塊也跟著受影響。生活化的類比一下高耦合計算機一體機顯示器、內(nèi)存、cpu、顯卡、風(fēng)扇、電源整體焊死在一塊板子上當(dāng)其中不論是內(nèi)存或是顯示器或是電源存在一點損壞整臺計算機一起報廢低耦合臺式計算機組裝機現(xiàn)在的品牌臺式計算機也大多如此顯卡壞了只需要把顯卡換掉其他部件依舊正?？梢允褂酶鱾€部件通過接口插在一起。為了解決這個問題解耦開始進行項目拆分出現(xiàn)了項目拆分。2.垂直拆分多個單體把大的單體項目按照業(yè)務(wù)類別拆分成多個獨立的單體項目以商城為例用戶系統(tǒng)、訂單系統(tǒng)分成獨立系統(tǒng)各自部署。特點是各個項目代碼完全隔離可以單獨擴容某一個業(yè)務(wù)模塊問題是服務(wù)和服務(wù)之間調(diào)用很麻煩沒有統(tǒng)一的服務(wù)治理數(shù)據(jù)可能存在重復(fù)。3.SOA面向服務(wù)架構(gòu)把公共能力抽離成服務(wù)其他業(yè)務(wù)系統(tǒng)調(diào)用服務(wù)出現(xiàn)了ESB企業(yè)服務(wù)總線所有服務(wù)的交互都從總線走。特點是公共服務(wù)的復(fù)用能力好缺點是ESB總線很重配置復(fù)雜粒度依然偏大適合傳統(tǒng)企業(yè)。tips1ESBEnterprise Service Bus企業(yè)服務(wù)總線在SOA架構(gòu)里面的核心組件想象成一條中央總線網(wǎng)所有的服務(wù)不直接互相調(diào)用全部接入這條ESB總線。當(dāng)服務(wù)A需要調(diào)用服務(wù)B時請求發(fā)送給ESB由ESB做轉(zhuǎn)發(fā)、協(xié)議轉(zhuǎn)換、鑒權(quán)、日志、數(shù)據(jù)格式轉(zhuǎn)換、再轉(zhuǎn)給服務(wù)B。好處就是所有服務(wù)都有ESB管控缺點是ESB本身是一個龐大的、獨立的軟件部署維護麻煩配置繁瑣所有服務(wù)必須經(jīng)過ESBESB癱瘓時成為整個系統(tǒng)的瓶頸點。2粒度粒度就是拆分出來的服務(wù)的大小粒度大指的就是一個服務(wù)里面包含了許許多多的業(yè)務(wù)服務(wù)需要做的事很多相反的粒度小指的是一個服務(wù)職責(zé)單一只做一小塊業(yè)務(wù)。SOA時代基于ESB拆分出來的服務(wù)不夠細以商城舉例只拆分出電商業(yè)務(wù)、會員服務(wù)其中電商業(yè)務(wù)里面同時包含了商品、訂單、庫存等一大堆的業(yè)務(wù)這就是粒度大粒度小就拆成更多、更小、職責(zé)更單一的服務(wù)。以SOA為基礎(chǔ)進一步演進為微服務(wù)架構(gòu)。4.微服務(wù)架構(gòu)把系統(tǒng)拆分成粒度更小、高度自治的業(yè)務(wù)服務(wù)。每一個微服務(wù)獨立開發(fā)、獨立部署、獨立數(shù)據(jù)庫服務(wù)之間通過HTTP/RPC遠程調(diào)用通信。?微服務(wù)優(yōu)點獨立擴容哪個服務(wù)壓力大就只擴容哪個服務(wù)技術(shù)異構(gòu)不同服務(wù)可以選用適合自己的技術(shù)棧局部故障隔離訂單服務(wù)掛掉不會直接導(dǎo)致用戶服務(wù)不可用團隊解耦不同團隊維護不同微服務(wù)代碼互不干擾?微服務(wù)缺點復(fù)雜度大幅上升不再是本地方法調(diào)用變成遠程網(wǎng)絡(luò)調(diào)用引入一堆組件注冊中心、配置中心、網(wǎng)關(guān)、分布式事務(wù)、鏈路追蹤運維成本暴漲需要容器、監(jiān)控、日志分布式帶來新問題網(wǎng)絡(luò)超時、數(shù)據(jù)一致性問題重要認知微服務(wù)不是萬能神器不是項目一用上所有問題自動全部解決小業(yè)務(wù)不要強行上微服務(wù)tips1.SOA、微服務(wù)是軟件架構(gòu)設(shè)計的思想是一套架構(gòu)方案是架構(gòu)演進概念和具體代碼框架不綁定2.Spring Boot是開發(fā)框架用來快速開發(fā)Java應(yīng)用的工具微服務(wù)里的每個服務(wù)是可以使用Spring Boot開發(fā)出來的3.Spring Cloud是微服務(wù)的整套解決方案、是實現(xiàn)微服務(wù)的組件集合是建立在Spring Boot基礎(chǔ)之上的Spring Boot開發(fā)每個服務(wù)Spring Cloud提供微服務(wù)的配套組件比如Nacos 注冊中心、網(wǎng)關(guān)、分布式鎖、分布式事務(wù)等。第二部分微服務(wù)拆分原則1.**按業(yè)務(wù)域拆分最核心**圍繞業(yè)務(wù)能力而不是按技術(shù)層拆分。?錯誤拆法把所有 controller 抽一個服務(wù)所有 service 抽一個服務(wù)。?正確拆法用戶域、訂單域、商品域一個業(yè)務(wù)域作為一個微服務(wù)。2.單一職責(zé)一個微服務(wù)只負責(zé)自己業(yè)務(wù)域的事情。3.高內(nèi)聚低耦合域內(nèi)功能盡量內(nèi)聚服務(wù)之間盡量少依賴。4.數(shù)據(jù)私有微服務(wù)盡量不要跨庫直接訪問別人的表通過接口拿數(shù)據(jù)。第三部分RESTful API 接口規(guī)范這個部分內(nèi)容在我們之前學(xué)習(xí)代碼的時候部分使用過下面學(xué)習(xí)一下基礎(chǔ)理論。核心思想URL 代表「資源」HTTP Method請求方式代表「動作」。URL 里面盡量不要寫動詞不要寫getXXX / addXXX / deleteXXX。資源系統(tǒng)里的實體用戶、訂單、商品、購物車都叫資源。1、HTTP 方法與語義方法含義使用場景示例 URLGET查詢獲取數(shù)據(jù)不修改服務(wù)器數(shù)據(jù)GET /users查詢?nèi)坑脩鬐ET /users/{id}根據(jù) id 查單個用戶POST新增創(chuàng)建新資源POST /users新增一個用戶PUT全量更新把對象完整覆蓋更新所有字段都傳PUT /users/{id}修改 id 對應(yīng)的用戶DELETE刪除刪除資源DELETE /users/{id}刪除指定用戶PATCH局部更新只傳要修改的部分字段項目實際用的少PATCH /users/{id}只修改 agetipsGET 請求不能做新增、修改、刪除GET 會被瀏覽器緩存、日志記錄用來改數(shù)據(jù)會產(chǎn)生安全問題。2、URL 命名規(guī)范資源用名詞復(fù)數(shù)優(yōu)先/users、/orders、/goods獲取單個資源/users/1路徑放 id子資源訂單下面的明細GET /orders/1001/items查詢 1001 號訂單的所有訂單項禁止帶有動作的命名如/getUserById?id1,/addUser,/updateUser,/delUser,動作是要交給對應(yīng)類的方法去執(zhí)行的違背了REST思想tipsREST 思想Representational State Transfer表述性狀態(tài)轉(zhuǎn)移用資源為中心通過 HTTP 標(biāo)準(zhǔn)方法完成對資源的操作不需要額外自定義動作。3、請求參數(shù)我想細心的朋友可能會注意到我們放問某些網(wǎng)頁的時候網(wǎng)址會出現(xiàn)、這樣的符號下面詳細學(xué)習(xí)一下1.路徑變量pathVariable資源唯一標(biāo)識寫在 url 路徑上GET /users/11 是用戶 id。2.query 查詢參數(shù)? 后面過濾、分頁、排序如GET /users?pageNum1pageSize10age20,分頁、篩選條件放在?后面不要寫到路徑里。3.body 請求體POST、PUT新增 / 修改時JSON 放 BodyGET 請求不要使用 body很多網(wǎng)關(guān)、瀏覽器會丟棄 GET 的 body。4、返回數(shù)據(jù)規(guī)范1.使用統(tǒng)一返回體就是我們 common 模塊寫的ResultT2.集合查詢data 返回數(shù)組分頁返回 data 里面包含列表 總條數(shù)。3.異常場景全局異常處理器統(tǒng)一捕獲依然返回 Result 格式 JSON不要返回 html 錯誤頁面。5.HTTP 狀態(tài)碼語義REST 建議200 OK查詢、修改成功201 CreatedPOST 新增資源成功400 Bad Request參數(shù)錯誤404 Not Found訪問的資源不存在500 Internal Server Error服務(wù)內(nèi)部異常實際開發(fā)很多項目 http 狀態(tài)碼統(tǒng)一返回 200業(yè)務(wù)錯誤放到 code 字段里面就是我們 Result 的 code兩種都可以團隊保持統(tǒng)一即可。6、舉一套完整用戶 CRUD REST 示例查詢?nèi)坑脩鬐ET /users查詢單個用戶GET /users/2新增用戶POST /usersbody 傳 json全量修改用戶PUT /users/2body 完整用戶 json刪除用戶DELETE /users/27.無狀態(tài)**每一次 HTTP 請求服務(wù)器不保存客戶端會話狀態(tài)。**每個請求自帶全部需要信息token、參數(shù)服務(wù)端不用記住上一次請求。好處服務(wù)端更容易擴容、集群壞處每次請求都要帶上身份憑證 token。7、現(xiàn)實開發(fā)注意點RESTful 是設(shè)計思想不是強制法律很多公司會做折中。如果業(yè)務(wù)動作不是簡單增刪改查例如用戶登錄、導(dǎo)出沒有合適 HTTP 方法允許 URL 帶動詞POST /users/login這種屬于合理妥協(xié)。RESTful API遵循 REST 思想寫出來的接口。REST 是思想RESTful 是遵循這套思想的實踐產(chǎn)物。簡單 CRUD 嚴(yán)格遵守特殊業(yè)務(wù)動作可以妥協(xié)。第四部分電商系統(tǒng)如何做微服務(wù)拆分這是一道思考題大家可以先自行思考再往下看我們先思考一下參照現(xiàn)在的電商系統(tǒng)想象一下電商系統(tǒng)需要的模塊1.首先是用戶注冊、登錄、用戶信息、地址信息等用戶相關(guān)的2.登錄之后開始查看商品對商品管理的商品信息、分類、圖片、商品的上架和下架信息3.查看商品之后考慮是不是要加入購物車購物車的增刪改查以及分類下架的商品正常的商品4.不論是不是加入購物車都需要考慮是不是下單也就是訂單的增刪改查包括訂單退貨流程5.下單之后就要對應(yīng)商品庫存了商品庫存的增刪改查6.下單的話還要考慮支付問題是對接三方支付還是自有支付暫不考慮對接三方的話接口的調(diào)用和回調(diào)7.下單之后的物流發(fā)貨、物流軌跡查詢等。所以對應(yīng)的拆分思路就是user?service 用戶服務(wù)注冊、登錄、用戶信息、地址管理goods?service 商品服務(wù)商品信息、分類、圖片、商品上下架cart?service 購物車服務(wù)購物車增刪改查order?service 訂單服務(wù)創(chuàng)建訂單、訂單狀態(tài)、訂單查詢stock?service 庫存服務(wù)商品庫存扣減、庫存查詢pay?service 支付服務(wù)對接第三方支付支付回調(diào)logistics?service 物流服務(wù)發(fā)貨、物流軌跡查詢訂單產(chǎn)生和退單過程都調(diào)用商品服務(wù)商品服務(wù)再去調(diào)用庫存服務(wù)訂單并發(fā)產(chǎn)生的商品庫存增減也是事務(wù)問題。第五部分小結(jié)今天學(xué)習(xí)了編程思想的演進過程以及接口規(guī)范的做法最后簡單思考了一下電商系統(tǒng)該如何設(shè)計拆分服務(wù)。截止當(dāng)前第一階段學(xué)習(xí)完畢明天是對第一階段的整體回顧考慮到都是各種問題就直接羅列在今天學(xué)習(xí)的后面了明天不再單獨羅列下一次學(xué)習(xí)進入第二階段學(xué)習(xí)。問題的答案大家自行思考和搜索不再復(fù)述了第一階段通關(guān)驗收清單全部需要可以口述出來一共 6 大項每一項下面附帶提問全部理解清楚才算通關(guān)才能進入 第二階段。題目 1 SpringBoot 自動配置原理說出ConfigurationFull 模式 和 Lite 模式區(qū)別ConditionalOnMissingBean的作用是什么簡單說下 SpringBoot 自動配置的加載原理META?INF/spring/org.springframework.boot.autoconfigure.imports題目 2 common 公共模塊RestControllerAdvice ExceptionHandler作用是什么BizException 自定義業(yè)務(wù)異常和通用 RuntimeException處理器如何區(qū)分處理為什么項目拋出異常不能直接返回原生錯誤頁面要統(tǒng)一封裝為 Result 返回題目 3 獨立單體 SpringBoot MyBatis?PlusMyBatis?Plus 的QueryWrapper條件構(gòu)造器作用是什么::方法引用寫法含義MyBatis?Plus 分頁插件必須配置什么否則分頁 total 總數(shù)不對Druid 數(shù)據(jù)源作用是什么題目 4 Spring 本地事務(wù)事務(wù) ACID 分別代表什么Transactional(rollbackFor Exception.class)rollbackFor 不加會有什么坑說出 2 種以上事務(wù)失效場景非 public、內(nèi)部 this 調(diào)用、try?catch 吃掉異常以及失效原因題目 5 Redis 緩存三大問題緩存穿透現(xiàn)象 解決方案緩存擊穿現(xiàn)象 解決方案緩存雪崩現(xiàn)象 解決方案實操為什么不能直接把 null 存入 RedisTemplateJackson 序列化坑我們是如何解決緩存穿透的題目 6 架構(gòu)演進 RESTful 規(guī)范架構(gòu)演進路線單體 → 垂直拆分 → SOA → 微服務(wù)每個階段簡單特點ESB 是什么SOA 粒度偏大什么意思微服務(wù)優(yōu)點、缺點為什么微服務(wù)不是銀彈微服務(wù)拆分核心原則REST 思想是什么GET/POST/PUT/DELETE 各自語義URL 編寫禁忌什么場景可以適度妥協(xié) REST 規(guī)范簡單說電商系統(tǒng)如何做微服務(wù)拆分用戶、商品、訂單、庫存、支付… 用豆包輔助從頭開始學(xué)習(xí)java spring cloud（八）
用豆包輔助從頭開始學(xué)習(xí)java spring cloud八昨天學(xué)習(xí)了redis的一些基本操作今天學(xué)習(xí)以理論為主學(xué)習(xí)架構(gòu)理論 RESTful API 規(guī)范。第一部分架構(gòu)演進1.單體架構(gòu)所有功能全部卸載一個springboot工程里面以商城為例用戶、訂單、支付、商品全部在一起一份代碼、一個包一套數(shù)據(jù)庫。這種架構(gòu)的優(yōu)點就是開發(fā)簡單部署簡單小項目效率高。但是缺點也非常明顯1.代碼量大模塊耦合嚴(yán)重改其中一處容易牽連其他功能2.全部功能公用一個實例當(dāng)某一個功能壓力大的時候需要整體擴容不能單獨給高壓力部分?jǐn)U容3.所有人在一個代碼庫開發(fā)代碼沖突頻繁4.一個模塊出現(xiàn)了漏洞整個應(yīng)用可能就宕機了。所以也就限制了這類項目的適用范圍小型項目內(nèi)部管理系統(tǒng)。tips耦合就是兩個功能模塊之間綁的太緊密了當(dāng)a模塊小小改動b模塊也跟著受影響。生活化的類比一下高耦合計算機一體機顯示器、內(nèi)存、cpu、顯卡、風(fēng)扇、電源整體焊死在一塊板子上當(dāng)其中不論是內(nèi)存或是顯示器或是電源存在一點損壞整臺計算機一起報廢低耦合臺式計算機組裝機現(xiàn)在的品牌臺式計算機也大多如此顯卡壞了只需要把顯卡換掉其他部件依舊正?？梢允褂酶鱾€部件通過接口插在一起。為了解決這個問題解耦開始進行項目拆分出現(xiàn)了項目拆分。2.垂直拆分多個單體把大的單體項目按照業(yè)務(wù)類別拆分成多個獨立的單體項目以商城為例用戶系統(tǒng)、訂單系統(tǒng)分成獨立系統(tǒng)各自部署。特點是各個項目代碼完全隔離可以單獨擴容某一個業(yè)務(wù)模塊問題是服務(wù)和服務(wù)之間調(diào)用很麻煩沒有統(tǒng)一的服務(wù)治理數(shù)據(jù)可能存在重復(fù)。3.SOA面向服務(wù)架構(gòu)把公共能力抽離成服務(wù)其他業(yè)務(wù)系統(tǒng)調(diào)用服務(wù)出現(xiàn)了ESB企業(yè)服務(wù)總線所有服務(wù)的交互都從總線走。特點是公共服務(wù)的復(fù)用能力好缺點是ESB總線很重配置復(fù)雜粒度依然偏大適合傳統(tǒng)企業(yè)。tips1ESBEnterprise Service Bus企業(yè)服務(wù)總線在SOA架構(gòu)里面的核心組件想象成一條中央總線網(wǎng)所有的服務(wù)不直接互相調(diào)用全部接入這條ESB總線。當(dāng)服務(wù)A需要調(diào)用服務(wù)B時請求發(fā)送給ESB由ESB做轉(zhuǎn)發(fā)、協(xié)議轉(zhuǎn)換、鑒權(quán)、日志、數(shù)據(jù)格式轉(zhuǎn)換、再轉(zhuǎn)給服務(wù)B。好處就是所有服務(wù)都有ESB管控缺點是ESB本身是一個龐大的、獨立的軟件部署維護麻煩配置繁瑣所有服務(wù)必須經(jīng)過ESBESB癱瘓時成為整個系統(tǒng)的瓶頸點。2粒度粒度就是拆分出來的服務(wù)的大小粒度大指的就是一個服務(wù)里面包含了許許多多的業(yè)務(wù)服務(wù)需要做的事很多相反的粒度小指的是一個服務(wù)職責(zé)單一只做一小塊業(yè)務(wù)。SOA時代基于ESB拆分出來的服務(wù)不夠細以商城舉例只拆分出電商業(yè)務(wù)、會員服務(wù)其中電商業(yè)務(wù)里面同時包含了商品、訂單、庫存等一大堆的業(yè)務(wù)這就是粒度大粒度小就拆成更多、更小、職責(zé)更單一的服務(wù)。以SOA為基礎(chǔ)進一步演進為微服務(wù)架構(gòu)。4.微服務(wù)架構(gòu)把系統(tǒng)拆分成粒度更小、高度自治的業(yè)務(wù)服務(wù)。每一個微服務(wù)獨立開發(fā)、獨立部署、獨立數(shù)據(jù)庫服務(wù)之間通過HTTP/RPC遠程調(diào)用通信。?微服務(wù)優(yōu)點獨立擴容哪個服務(wù)壓力大就只擴容哪個服務(wù)技術(shù)異構(gòu)不同服務(wù)可以選用適合自己的技術(shù)棧局部故障隔離訂單服務(wù)掛掉不會直接導(dǎo)致用戶服務(wù)不可用團隊解耦不同團隊維護不同微服務(wù)代碼互不干擾?微服務(wù)缺點復(fù)雜度大幅上升不再是本地方法調(diào)用變成遠程網(wǎng)絡(luò)調(diào)用引入一堆組件注冊中心、配置中心、網(wǎng)關(guān)、分布式事務(wù)、鏈路追蹤運維成本暴漲需要容器、監(jiān)控、日志分布式帶來新問題網(wǎng)絡(luò)超時、數(shù)據(jù)一致性問題重要認知微服務(wù)不是萬能神器不是項目一用上所有問題自動全部解決小業(yè)務(wù)不要強行上微服務(wù)tips1.SOA、微服務(wù)是軟件架構(gòu)設(shè)計的思想是一套架構(gòu)方案是架構(gòu)演進概念和具體代碼框架不綁定2.Spring Boot是開發(fā)框架用來快速開發(fā)Java應(yīng)用的工具微服務(wù)里的每個服務(wù)是可以使用Spring Boot開發(fā)出來的3.Spring Cloud是微服務(wù)的整套解決方案、是實現(xiàn)微服務(wù)的組件集合是建立在Spring Boot基礎(chǔ)之上的Spring Boot開發(fā)每個服務(wù)Spring Cloud提供微服務(wù)的配套組件比如Nacos 注冊中心、網(wǎng)關(guān)、分布式鎖、分布式事務(wù)等。第二部分微服務(wù)拆分原則1.**按業(yè)務(wù)域拆分最核心**圍繞業(yè)務(wù)能力而不是按技術(shù)層拆分。?錯誤拆法把所有 controller 抽一個服務(wù)所有 service 抽一個服務(wù)。?正確拆法用戶域、訂單域、商品域一個業(yè)務(wù)域作為一個微服務(wù)。2.單一職責(zé)一個微服務(wù)只負責(zé)自己業(yè)務(wù)域的事情。3.高內(nèi)聚低耦合域內(nèi)功能盡量內(nèi)聚服務(wù)之間盡量少依賴。4.數(shù)據(jù)私有微服務(wù)盡量不要跨庫直接訪問別人的表通過接口拿數(shù)據(jù)。第三部分RESTful API 接口規(guī)范這個部分內(nèi)容在我們之前學(xué)習(xí)代碼的時候部分使用過下面學(xué)習(xí)一下基礎(chǔ)理論。核心思想URL 代表「資源」HTTP Method請求方式代表「動作」。URL 里面盡量不要寫動詞不要寫getXXX / addXXX / deleteXXX。資源系統(tǒng)里的實體用戶、訂單、商品、購物車都叫資源。1、HTTP 方法與語義方法含義使用場景示例 URLGET查詢獲取數(shù)據(jù)不修改服務(wù)器數(shù)據(jù)GET /users查詢?nèi)坑脩鬐ET /users/{id}根據(jù) id 查單個用戶POST新增創(chuàng)建新資源POST /users新增一個用戶PUT全量更新把對象完整覆蓋更新所有字段都傳PUT /users/{id}修改 id 對應(yīng)的用戶DELETE刪除刪除資源DELETE /users/{id}刪除指定用戶PATCH局部更新只傳要修改的部分字段項目實際用的少PATCH /users/{id}只修改 agetipsGET 請求不能做新增、修改、刪除GET 會被瀏覽器緩存、日志記錄用來改數(shù)據(jù)會產(chǎn)生安全問題。2、URL 命名規(guī)范資源用名詞復(fù)數(shù)優(yōu)先/users、/orders、/goods獲取單個資源/users/1路徑放 id子資源訂單下面的明細GET /orders/1001/items查詢 1001 號訂單的所有訂單項禁止帶有動作的命名如/getUserById?id1,/addUser,/updateUser,/delUser,動作是要交給對應(yīng)類的方法去執(zhí)行的違背了REST思想tipsREST 思想Representational State Transfer表述性狀態(tài)轉(zhuǎn)移用資源為中心通過 HTTP 標(biāo)準(zhǔn)方法完成對資源的操作不需要額外自定義動作。3、請求參數(shù)我想細心的朋友可能會注意到我們放問某些網(wǎng)頁的時候網(wǎng)址會出現(xiàn)、這樣的符號下面詳細學(xué)習(xí)一下1.路徑變量pathVariable資源唯一標(biāo)識寫在 url 路徑上GET /users/11 是用戶 id。2.query 查詢參數(shù)? 后面過濾、分頁、排序如GET /users?pageNum1pageSize10age20,分頁、篩選條件放在?后面不要寫到路徑里。3.body 請求體POST、PUT新增 / 修改時JSON 放 BodyGET 請求不要使用 body很多網(wǎng)關(guān)、瀏覽器會丟棄 GET 的 body。4、返回數(shù)據(jù)規(guī)范1.使用統(tǒng)一返回體就是我們 common 模塊寫的ResultT2.集合查詢data 返回數(shù)組分頁返回 data 里面包含列表 總條數(shù)。3.異常場景全局異常處理器統(tǒng)一捕獲依然返回 Result 格式 JSON不要返回 html 錯誤頁面。5.HTTP 狀態(tài)碼語義REST 建議200 OK查詢、修改成功201 CreatedPOST 新增資源成功400 Bad Request參數(shù)錯誤404 Not Found訪問的資源不存在500 Internal Server Error服務(wù)內(nèi)部異常實際開發(fā)很多項目 http 狀態(tài)碼統(tǒng)一返回 200業(yè)務(wù)錯誤放到 code 字段里面就是我們 Result 的 code兩種都可以團隊保持統(tǒng)一即可。6、舉一套完整用戶 CRUD REST 示例查詢?nèi)坑脩鬐ET /users查詢單個用戶GET /users/2新增用戶POST /usersbody 傳 json全量修改用戶PUT /users/2body 完整用戶 json刪除用戶DELETE /users/27.無狀態(tài)**每一次 HTTP 請求服務(wù)器不保存客戶端會話狀態(tài)。**每個請求自帶全部需要信息token、參數(shù)服務(wù)端不用記住上一次請求。好處服務(wù)端更容易擴容、集群壞處每次請求都要帶上身份憑證 token。7、現(xiàn)實開發(fā)注意點RESTful 是設(shè)計思想不是強制法律很多公司會做折中。如果業(yè)務(wù)動作不是簡單增刪改查例如用戶登錄、導(dǎo)出沒有合適 HTTP 方法允許 URL 帶動詞POST /users/login這種屬于合理妥協(xié)。RESTful API遵循 REST 思想寫出來的接口。REST 是思想RESTful 是遵循這套思想的實踐產(chǎn)物。簡單 CRUD 嚴(yán)格遵守特殊業(yè)務(wù)動作可以妥協(xié)。第四部分電商系統(tǒng)如何做微服務(wù)拆分這是一道思考題大家可以先自行思考再往下看我們先思考一下參照現(xiàn)在的電商系統(tǒng)想象一下電商系統(tǒng)需要的模塊1.首先是用戶注冊、登錄、用戶信息、地址信息等用戶相關(guān)的2.登錄之后開始查看商品對商品管理的商品信息、分類、圖片、商品的上架和下架信息3.查看商品之后考慮是不是要加入購物車購物車的增刪改查以及分類下架的商品正常的商品4.不論是不是加入購物車都需要考慮是不是下單也就是訂單的增刪改查包括訂單退貨流程5.下單之后就要對應(yīng)商品庫存了商品庫存的增刪改查6.下單的話還要考慮支付問題是對接三方支付還是自有支付暫不考慮對接三方的話接口的調(diào)用和回調(diào)7.下單之后的物流發(fā)貨、物流軌跡查詢等。所以對應(yīng)的拆分思路就是user?service 用戶服務(wù)注冊、登錄、用戶信息、地址管理goods?service 商品服務(wù)商品信息、分類、圖片、商品上下架cart?service 購物車服務(wù)購物車增刪改查order?service 訂單服務(wù)創(chuàng)建訂單、訂單狀態(tài)、訂單查詢stock?service 庫存服務(wù)商品庫存扣減、庫存查詢pay?service 支付服務(wù)對接第三方支付支付回調(diào)logistics?service 物流服務(wù)發(fā)貨、物流軌跡查詢訂單產(chǎn)生和退單過程都調(diào)用商品服務(wù)商品服務(wù)再去調(diào)用庫存服務(wù)訂單并發(fā)產(chǎn)生的商品庫存增減也是事務(wù)問題。第五部分小結(jié)今天學(xué)習(xí)了編程思想的演進過程以及接口規(guī)范的做法最后簡單思考了一下電商系統(tǒng)該如何設(shè)計拆分服務(wù)。截止當(dāng)前第一階段學(xué)習(xí)完畢明天是對第一階段的整體回顧考慮到都是各種問題就直接羅列在今天學(xué)習(xí)的后面了明天不再單獨羅列下一次學(xué)習(xí)進入第二階段學(xué)習(xí)。問題的答案大家自行思考和搜索不再復(fù)述了第一階段通關(guān)驗收清單全部需要可以口述出來一共 6 大項每一項下面附帶提問全部理解清楚才算通關(guān)才能進入 第二階段。題目 1 SpringBoot 自動配置原理說出ConfigurationFull 模式 和 Lite 模式區(qū)別ConditionalOnMissingBean的作用是什么簡單說下 SpringBoot 自動配置的加載原理META?INF/spring/org.springframework.boot.autoconfigure.imports題目 2 common 公共模塊RestControllerAdvice ExceptionHandler作用是什么BizException 自定義業(yè)務(wù)異常和通用 RuntimeException處理器如何區(qū)分處理為什么項目拋出異常不能直接返回原生錯誤頁面要統(tǒng)一封裝為 Result 返回題目 3 獨立單體 SpringBoot MyBatis?PlusMyBatis?Plus 的QueryWrapper條件構(gòu)造器作用是什么::方法引用寫法含義MyBatis?Plus 分頁插件必須配置什么否則分頁 total 總數(shù)不對Druid 數(shù)據(jù)源作用是什么題目 4 Spring 本地事務(wù)事務(wù) ACID 分別代表什么Transactional(rollbackFor Exception.class)rollbackFor 不加會有什么坑說出 2 種以上事務(wù)失效場景非 public、內(nèi)部 this 調(diào)用、try?catch 吃掉異常以及失效原因題目 5 Redis 緩存三大問題緩存穿透現(xiàn)象 解決方案緩存擊穿現(xiàn)象 解決方案緩存雪崩現(xiàn)象 解決方案實操為什么不能直接把 null 存入 RedisTemplateJackson 序列化坑我們是如何解決緩存穿透的題目 6 架構(gòu)演進 RESTful 規(guī)范架構(gòu)演進路線單體 → 垂直拆分 → SOA → 微服務(wù)每個階段簡單特點ESB 是什么SOA 粒度偏大什么意思微服務(wù)優(yōu)點、缺點為什么微服務(wù)不是銀彈微服務(wù)拆分核心原則REST 思想是什么GET/POST/PUT/DELETE 各自語義URL 編寫禁忌什么場景可以適度妥協(xié) REST 規(guī)范簡單說電商系統(tǒng)如何做微服務(wù)拆分用戶、商品、訂單、庫存、支付…