一、網(wǎng)關(guān)服務(wù)限流熔斷降級

1. 啟動(dòng)sentinel-dashboard控制臺和Nacos注冊中心服務(wù)

啟動(dòng)sentinel-dashboard控制臺
首先放sentinel文件夾文件路徑出輸入cmd，里面輸入

java -jar sentinel-dashboard-1.8.4.jar

2. 在網(wǎng)關(guān)服務(wù)中引入sentinel依賴

<!-- sentinel -->
<dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>

3. 在網(wǎng)關(guān)服務(wù)application.yml中配置sentinel

spring:application:name: zmall-gatewaycloud:nacos:discovery:server-addr: localhost:8848sentinel:transport:port: 9998 #跟控制臺交流的端口,隨意指定一個(gè)未使用的端口即可dashboard: localhost:8080 # 指定控制臺服務(wù)的地址eager: true #當(dāng)服務(wù)啟動(dòng)時(shí)是否與sentinel建立連接web-context-unify: false # 關(guān)閉URL PATH聚合

4. 通過域名直接訪問商品服務(wù)，并登陸到sentinel控制臺配置服務(wù)流控等信息
   
   打開瀏覽器輸入地址：http://zmall.com/index.html

進(jìn)入sentinel控制臺，選中簇點(diǎn)鏈路。在搜索框中輸入搜索關(guān)鍵字index

這個(gè)時(shí)候會(huì)發(fā)現(xiàn)流控操作只能針對具體服務(wù)資源鏈路，而不能針對具體整個(gè)服務(wù)本身進(jìn)行流控操作。所以，阿里特此推出了網(wǎng)關(guān)限流方式來解決以上問題。

5. 重新在網(wǎng)關(guān)服務(wù)模塊pom.xml中加入依賴

<!-- sentinel gateway -->
<dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-alibaba-sentinel-gateway</artifactId>
</dependency>

6. 重新刷新商品服務(wù)，再進(jìn)入sentinel控制臺查看鏈路情況
   
   這是直接針對該微服務(wù)進(jìn)行網(wǎng)關(guān)限流等操作。直接點(diǎn)擊流控，設(shè)置QPS=1、流控模式=直接（默認(rèn)）、流控效果=快速失敗（默認(rèn)）等，最后快速刷新商品服務(wù)地址即可查看流控效果。同時(shí)，也可以配置流控的流控效果為排隊(duì)等待方式，當(dāng)流量多大時(shí)以排隊(duì)等待方式慢慢去消化請求，從而可以起到一個(gè)流量削鋒的目的。

7. 舉例
   加入有人惡意攻擊網(wǎng)站，那么我們加入流控
   
   

當(dāng)有人惡意刷新網(wǎng)站時(shí)，網(wǎng)站就會(huì)自動(dòng)斷開

二、Seata–分布式事務(wù)

2.1 分布式事務(wù)基礎(chǔ)

2.1.1 事務(wù)

事務(wù)指的就是一個(gè)操作單元，在這個(gè)操作單元中的所有操作最終要保持一致的行為，要么所有操作
都成功，要么所有的操作都被撤銷。簡單地說，事務(wù)提供一種“要么什么都不做，要么做全套”機(jī)制。

2.1.2 本地事務(wù)

本地事物其實(shí)可以認(rèn)為是數(shù)據(jù)庫提供的事務(wù)機(jī)制。說到數(shù)據(jù)庫事務(wù)就不得不說，數(shù)據(jù)庫事務(wù)中的四
大特性:

• A：原子性(Atomicity)，一個(gè)事務(wù)中的所有操作，要么全部完成，要么全部不完成
• C：一致性(Consistency)，在一個(gè)事務(wù)執(zhí)行之前和執(zhí)行之后數(shù)據(jù)庫都必須處于一致性狀態(tài)
• I：隔離性(Isolation)，在并發(fā)環(huán)境中，當(dāng)不同的事務(wù)同時(shí)操作相同的數(shù)據(jù)時(shí)，事務(wù)之間互不影響
• D：持久性(Durability)，指的是只要事務(wù)成功結(jié)束，它對數(shù)據(jù)庫所做的更新就必須永久的保存下來

數(shù)據(jù)庫事務(wù)在實(shí)現(xiàn)時(shí)會(huì)將一次事務(wù)涉及的所有操作全部納入到一個(gè)不可分割的執(zhí)行單元，該執(zhí)行單
元中的所有操作要么都成功，要么都失敗，只要其中任一操作執(zhí)行失敗，都將導(dǎo)致整個(gè)事務(wù)的回滾

2.1.3 分布式事務(wù)

分布式事務(wù)指事務(wù)的參與者、支持事務(wù)的服務(wù)器、資源服務(wù)器以及事務(wù)管理器分別位于不同的分布
式系統(tǒng)的不同節(jié)點(diǎn)之上。
簡單的說，就是一次大的操作由不同的小操作組成，這些小的操作分布在不同的服務(wù)器上，且屬于不同
的應(yīng)用，分布式事務(wù)需要保證這些小操作要么全部成功，要么全部失敗。
本質(zhì)上來說，分布式事務(wù)就是為了保證不同數(shù)據(jù)庫的數(shù)據(jù)一致性。

2.1.4 分布式事務(wù)場景

• 單體系統(tǒng)訪問多個(gè)數(shù)據(jù)庫
  一個(gè)服務(wù)需要調(diào)用多個(gè)數(shù)據(jù)庫實(shí)例完成數(shù)據(jù)的增刪改操作

[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機(jī)制,建議將圖片保存下來直接上傳(img-iUhyIGnM-1676028166309)(springcloud_alibaba\1014.png)]

• 多個(gè)微服務(wù)訪問同一個(gè)數(shù)據(jù)庫
  多個(gè)服務(wù)需要調(diào)用一個(gè)數(shù)據(jù)庫實(shí)例完成數(shù)據(jù)的增刪改操作

• 多個(gè)微服務(wù)訪問多個(gè)數(shù)據(jù)庫
  多個(gè)服務(wù)需要調(diào)用一個(gè)數(shù)據(jù)庫實(shí)例完成數(shù)據(jù)的增刪改操作

2.2 分布式事務(wù)解決方案

2.2.1 全局事務(wù)

全局事務(wù)基于DTP模型實(shí)現(xiàn)。DTP是由X/Open組織提出的一種分布式事務(wù)模型——X/Open
Distributed Transaction Processing Reference Model。它規(guī)定了要實(shí)現(xiàn)分布式事務(wù)，需要三種角色：

• AP: Application 應(yīng)用系統(tǒng) (微服務(wù))
• TM: Transaction Manager 事務(wù)管理器 (全局事務(wù)管理)
• RM: Resource Manager 資源管理器 (數(shù)據(jù)庫)

整個(gè)事務(wù)分成兩個(gè)階段:

• 階段一: 表決階段，所有參與者都將本事務(wù)執(zhí)行預(yù)提交，并將能否成功的信息反饋發(fā)給協(xié)調(diào)者。
• 階段二: 執(zhí)行階段，協(xié)調(diào)者根據(jù)所有參與者的反饋，通知所有參與者，步調(diào)一致地執(zhí)行提交或者回
  滾。

優(yōu)點(diǎn)

• 提高了數(shù)據(jù)一致性的概率，實(shí)現(xiàn)成本較低

缺點(diǎn)

• 單點(diǎn)問題: 事務(wù)協(xié)調(diào)者宕機(jī)

• 同步阻塞: 延遲了提交時(shí)間，加長了資源阻塞時(shí)間

• 數(shù)據(jù)不一致: 提交第二階段，依然存在commit結(jié)果未知的情況，有可能導(dǎo)致數(shù)據(jù)不一致

  可靠消息服務(wù)

  基于可靠消息服務(wù)的方案是通過消息中間件保證上、下游應(yīng)用數(shù)據(jù)操作的一致性。假設(shè)有A和B兩個(gè)
  系統(tǒng)，分別可以處理任務(wù)A和任務(wù)B。此時(shí)存在一個(gè)業(yè)務(wù)流程，需要將任務(wù)A和任務(wù)B在同一個(gè)事務(wù)中處
  理。就可以使用消息中間件來實(shí)現(xiàn)這種分布式事務(wù)。
  

  第一步: 消息由系統(tǒng)A投遞到中間件

1. 在系統(tǒng)A處理任務(wù)A前，首先向消息中間件發(fā)送一條消息
2. 消息中間件收到后將該條消息持久化，但并不投遞。持久化成功后，向A回復(fù)一個(gè)確認(rèn)應(yīng)答
3. 系統(tǒng)A收到確認(rèn)應(yīng)答后，則可以開始處理任務(wù)A
4. 任務(wù)A處理完成后，向消息中間件發(fā)送Commit或者Rollback請求。該請求發(fā)送完成后，對系統(tǒng)A而
   言，該事務(wù)的處理過程就結(jié)束了
5. 如果消息中間件收到Commit，則向B系統(tǒng)投遞消息；如果收到Rollback，則直接丟棄消息。但是
   如果消息中間件收不到Commit和Rollback指令，那么就要依靠"超時(shí)詢問機(jī)制"。

超時(shí)詢問機(jī)制
系統(tǒng)A除了實(shí)現(xiàn)正常的業(yè)務(wù)流程外，還需提供一個(gè)事務(wù)詢問的接口，供消息中間件調(diào)
用。當(dāng)消息中間件收到發(fā)布消息便開始計(jì)時(shí)，如果到了超時(shí)沒收到確認(rèn)指令，就會(huì)主動(dòng)調(diào)用
系統(tǒng)A提供的事務(wù)詢問接口詢問該系統(tǒng)目前的狀態(tài)。該接口會(huì)返回三種結(jié)果，中間件根據(jù)三
種結(jié)果做出不同反應(yīng)：
提交:將該消息投遞給系統(tǒng)B
回滾:直接將條消息丟棄

處理中:繼續(xù)等待

第二步: 消息由中間件投遞到系統(tǒng)B
消息中間件向下游系統(tǒng)投遞完消息后便進(jìn)入阻塞等待狀態(tài)，下游系統(tǒng)便立即進(jìn)行任務(wù)的處理，任務(wù)
處理完成后便向消息中間件返回應(yīng)答。

• 如果消息中間件收到確認(rèn)應(yīng)答后便認(rèn)為該事務(wù)處理完畢
• 如果消息中間件在等待確認(rèn)應(yīng)答超時(shí)之后就會(huì)重新投遞，直到下游消費(fèi)者返回消費(fèi)成功響應(yīng)為止。

一般消息中間件可以設(shè)置消息重試的次數(shù)和時(shí)間間隔，如果最終還是不能成功投遞，則需要手工干
預(yù)。這里之所以使用人工干預(yù)，而不是使用讓Ａ系統(tǒng)回滾，主要是考慮到整個(gè)系統(tǒng)設(shè)計(jì)的復(fù)雜度問
題。
基于可靠消息服務(wù)的分布式事務(wù)，前半部分使用異步，注重性能；后半部分使用同步，注重開發(fā)成本。

2.2.2 最大努力通知

最大努力通知也被稱為定期校對，其實(shí)是對第二種解決方案的進(jìn)一步優(yōu)化。它引入了本地消息表來
記錄錯(cuò)誤消息，然后加入失敗消息的定期校對功能，來進(jìn)一步保證消息會(huì)被下游系統(tǒng)消費(fèi)。

第一步: 消息由系統(tǒng)A投遞到中間件

1. 處理業(yè)務(wù)的同一事務(wù)中，向本地消息表中寫入一條記錄
2. 準(zhǔn)備專門的消息發(fā)送者不斷地發(fā)送本地消息表中的消息到消息中間件，如果發(fā)送失敗則重試

第二步: 消息由中間件投遞到系統(tǒng)B

1. 消息中間件收到消息后負(fù)責(zé)將該消息同步投遞給相應(yīng)的下游系統(tǒng)，并觸發(fā)下游系統(tǒng)的任務(wù)執(zhí)行
2. 當(dāng)下游系統(tǒng)處理成功后，向消息中間件反饋確認(rèn)應(yīng)答，消息中間件便可以將該條消息刪除，從而該
   事務(wù)完成
3. 對于投遞失敗的消息，利用重試機(jī)制進(jìn)行重試，對于重試失敗的，寫入錯(cuò)誤消息表
4. 消息中間件需要提供失敗消息的查詢接口，下游系統(tǒng)會(huì)定期查詢失敗消息，并將其消費(fèi)

這種方式的優(yōu)缺點(diǎn)：

• 優(yōu)點(diǎn)： 一種非常經(jīng)典的實(shí)現(xiàn)，實(shí)現(xiàn)了最終一致性。
• 缺點(diǎn)： 消息表會(huì)耦合到業(yè)務(wù)系統(tǒng)中，如果沒有封裝好的解決方案，會(huì)有很多雜活需要處理。

2.2.3 TCC事事務(wù)

TCC即為Try Confirm Cancel，它屬于補(bǔ)償型分布式事務(wù)。TCC實(shí)現(xiàn)分布式事務(wù)一共有三個(gè)步驟：

• Try：嘗試待執(zhí)行的業(yè)務(wù)
  這個(gè)過程并未執(zhí)行業(yè)務(wù)，只是完成所有業(yè)務(wù)的一致性檢查，并預(yù)留好執(zhí)行所需的全部資源
• Confirm：確認(rèn)執(zhí)行業(yè)務(wù)
  確認(rèn)執(zhí)行業(yè)務(wù)操作，不做任何業(yè)務(wù)檢查， 只使用Try階段預(yù)留的業(yè)務(wù)資源。通常情況下，采用TCC
  則認(rèn)為 Confirm階段是不會(huì)出錯(cuò)的。即：只要Try成功，Confirm一定成功。若Confirm階段真的
  出錯(cuò)了，需引入重試機(jī)制或人工處理。
• Cancel：取消待執(zhí)行的業(yè)務(wù)
  取消Try階段預(yù)留的業(yè)務(wù)資源。通常情況下，采用TCC則認(rèn)為Cancel階段也是一定成功的。若
  Cancel階段真的出錯(cuò)了，需引入重試機(jī)制或人工處理。

TCC兩階段提交與XA兩階段提交的區(qū)別是：
XA是資源層面的分布式事務(wù)，強(qiáng)一致性，在兩階段提交的整個(gè)過程中，一直會(huì)持有資源的鎖。
TCC是業(yè)務(wù)層面的分布式事務(wù)，最終一致性，不會(huì)一直持有資源的鎖。
TCC事務(wù)的優(yōu)缺點(diǎn)：

• 優(yōu)點(diǎn)：把數(shù)據(jù)庫層的二階段提交上提到了應(yīng)用層來實(shí)現(xiàn)，規(guī)避了數(shù)據(jù)庫層的2PC性能低下問題。

• 缺點(diǎn)：TCC的Try、Confirm和Cancel操作功能需業(yè)務(wù)提供，開發(fā)成本高。

三、Seata介紹

2019 年 1 月，阿里巴巴中間件團(tuán)隊(duì)發(fā)起了開源項(xiàng)目 Fescar（Fast & EaSy Commit And
Rollback），其愿景是讓分布式事務(wù)的使用像本地事務(wù)的使用一樣，簡單和高效，并逐步解決開發(fā)者們
遇到的分布式事務(wù)方面的所有難題。后來更名為 Seata，意為：Simple Extensible Autonomous
Transaction Architecture，是一套分布式事務(wù)解決方案。
Seata的設(shè)計(jì)目標(biāo)是對業(yè)務(wù)無侵入，因此從業(yè)務(wù)無侵入的2PC方案著手，在傳統(tǒng)2PC的基礎(chǔ)上演進(jìn)。
它把一個(gè)分布式事務(wù)理解成一個(gè)包含了若干分支事務(wù)的全局事務(wù)。全局事務(wù)的職責(zé)是協(xié)調(diào)其下管轄的分
支事務(wù)達(dá)成一致，要么一起成功提交，要么一起失敗回滾。此外，通常分支事務(wù)本身就是一個(gè)關(guān)系數(shù)據(jù)
庫的本地事務(wù)。

2PC即兩階段提交協(xié)議，是將整個(gè)事務(wù)流程分為兩個(gè)階段，準(zhǔn)備階段（Prepare phase）、提交階段（commit phase），2是指兩個(gè)階段，P是指準(zhǔn)備階段，C是指提交階段。

Seata主要由三個(gè)重要組件組成：

• TC：Transaction Coordinator 事務(wù)協(xié)調(diào)器，管理全局的分支事務(wù)的狀態(tài)，用于全局性事務(wù)的提交
  和回滾。
• TM：Transaction Manager 事務(wù)管理器，用于開啟、提交或者回滾全局事務(wù)。
• RM：Resource Manager 資源管理器，用于分支事務(wù)上的資源管理，向TC注冊分支事務(wù)，上報(bào)分
  支事務(wù)的狀態(tài)，接受TC的命令來提交或者回滾分支事務(wù)。

用例說明：

用戶購買商品的業(yè)務(wù)邏輯：

• Storage服務(wù)：對給定的商品扣除倉儲(chǔ)數(shù)量。

• Order服務(wù)：根據(jù)采購需求創(chuàng)建訂單。

• Account服務(wù)：從用戶帳戶中扣除余額。

• Business服務(wù)：創(chuàng)建訂單的同時(shí)需完成對商品庫存扣減及用戶賬號余額扣除操作。

Seata的執(zhí)行流程如下:

1. Business業(yè)務(wù)服務(wù)TM申請向TC開啟一個(gè)全局事務(wù)，TC就會(huì)創(chuàng)建一個(gè)全局事務(wù)并返回一個(gè)唯一的XID

2. Storage服務(wù)的RM向TC注冊分支事務(wù)，并及其納入XID對應(yīng)全局事務(wù)的管轄

3. Storage服務(wù)執(zhí)行分支事務(wù)，向數(shù)據(jù)庫做操作，對給定的商品扣除倉儲(chǔ)數(shù)量

4. Order服務(wù)的RM向TC注冊分支事務(wù)，并及其納入XID對應(yīng)全局事務(wù)的管轄

5. Order服務(wù)執(zhí)行分支事務(wù)，向數(shù)據(jù)做操作，創(chuàng)建訂單

6. Order服務(wù)開始遠(yuǎn)程調(diào)用Account服務(wù)，此時(shí)XID會(huì)在微服務(wù)的調(diào)用鏈上傳播

7. Account服務(wù)的RM向TC注冊分支事務(wù)，并將其納入XID對應(yīng)的全局事務(wù)的管轄

8. Account服務(wù)執(zhí)行分支事務(wù)，向數(shù)據(jù)庫做操作，從用戶賬戶中扣除余額

9. 全局事務(wù)調(diào)用鏈處理完畢，TM根據(jù)有無異常向TC發(fā)起全局事務(wù)的提交或者回滾

10. TC協(xié)調(diào)其管轄之下的所有分支事務(wù)， 決定是否回滾

Seata實(shí)現(xiàn)2PC與傳統(tǒng)2PC的差別：

1. 架構(gòu)層次方面，傳統(tǒng)2PC方案的 RM 實(shí)際上是在數(shù)據(jù)庫層，RM本質(zhì)上就是數(shù)據(jù)庫自身，通過XA協(xié)
   議實(shí)現(xiàn)，而 Seata的RM是以jar包的形式作為中間件層部署在應(yīng)用程序這一側(cè)的。
2. 兩階段提交方面，傳統(tǒng)2PC無論第二階段的決議是commit還是rollback，事務(wù)性資源的鎖都要保
   持到Phase2完成才釋放。而Seata的做法是在Phase1 就將本地事務(wù)提交，這樣就可以省去Phase2
   持鎖的時(shí)間，整體提高效率。

四、 Seata實(shí)現(xiàn)分布式事務(wù)控制

本示例通過Seata中間件實(shí)現(xiàn)分布式事務(wù)，模擬電商中的下單和扣庫存的過程
我們通過訂單微服務(wù)執(zhí)行下單操作，然后由訂單微服務(wù)調(diào)用商品微服務(wù)扣除庫存

4.1 案例基本代碼（異常模擬）