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