本次内容概述 1. seata內建 2. feign + sentinel +seata + @ControllerAdvice 互相影響産生的事務問題整理
1.seata部署
2.seata配置
這兩步可以參考很多部署文檔，把比較容易出問題的地方說明下
3.測試
一些總結說明：
熔斷的概念不能和下遊服務挂掉，注冊中心不可用混淆。熔斷應了解為多次逾時達到熔斷門檻值而直接不進入代碼塊。
結合上一篇sentinel的配置可以得到如下結論
本地事務在不配置blockHandler、fallback情況下，熔斷或流控抛出異常可被@Transactional攔截并保證事務；
feign事務在不配置blockHandler、fallback類的情況下，熔斷或流控抛出異常可被@Transactional攔截并保證事務；
以上述鍊路為例，分别測試如下幾種情況
首先是正常情況下，全部送出；可以看下幾個關鍵日志的地方。
全局事務
場景1 下遊服務挂了
直接上遊可以拿到ribbon異常并復原
把order-api停掉。上遊服務feign用戶端能馬上感覺到服務不可用的異常。
這裡我們停order-api還不夠明顯，account-api還沒執行。我們換下，就能發現有一個挂了，其他都能復原。
場景2 下遊服務逾時了
直接上有可以拿到ribbon異常并復原，通知下遊的事務也一起復原
同理，我們都對account-api下手，給他加個sleep6秒的操作，因為我們ribbon逾時設定的5秒。制作逾時的場景。
顯然也拿到了逾時異常，可以直接復原。
場景3 下遊服務熔斷了
直接上遊可以拿到sentinel異常并復原，在場景2的基礎上，我們多試幾次來達到sentinel的門檻值模拟熔斷。
進入我們的feign降級熔斷。值得一提，這裡我們不管對本地還是feign的sentinel都是不直接捕獲異常的。是以seata是能感覺到
與場景2不同的是，下遊熔斷以後是直接傳回拿到異常而不去嘗試請求的，是以seata根本就不需要管理熔斷的服務，隻要把其他的服務復原即可。
場景4 下遊服務遇到業務異常了
此時如果我們配置了全局異常捕獲@ControllerAdvice 對seata服務來說就感覺不到異常。我們需要在@ControllerAdvice手動擷取xid并復原，seata通知所有相同的xid事務復原。
我們給account-api随便給一個異常，觀察。
這裡實際上seata是沒有感覺到異常的。隻是我們在全局異常捕獲的地方手動擷取目前xid并手動復原，seata通知其他一樣的xid事務復原；
這裡有個小細節，如果account-api的地方加了本地@Transactional，則本地自動復原，seata不去重複操作了。
元件gitee https://gitee.com/xuetieqi/component-alibaba
項目gitee https://gitee.com/xuetieqi/base-server-alibaba