背景說明
@ExceptionHandler是springboot中的通用異常處理，通過與配合@RestControllerAdvice，達(dá)到處理全局異常的目的。
seata是springcloud alibaba的分布式事務(wù)組件
sentinel是springcloud alibaba的服務(wù)降級、熔斷組件
當(dāng)這三個(gè)組件在一起出現(xiàn)時(shí)，會(huì)產(chǎn)生什么結(jié)果呢？
模擬情況
testService作為服務(wù)消費(fèi)者，userService作為服務(wù)提供者，當(dāng)userService出現(xiàn)異常時(shí)，大致分為以下幾種情況：
情況1：ExceptionHandler+seata
服務(wù)提供者的ExceptionHandler將異常處理成了ResponseResultUtil.error這種返回值，而服務(wù)消費(fèi)者的feign將其識別為了無異常的返回值，導(dǎo)致調(diào)用方不回滾事務(wù)。
情況2：sentinel+seata
服務(wù)提供者返回異常，服務(wù)消費(fèi)者的sentinel將其降級處理，進(jìn)入fallback后，服務(wù)消費(fèi)者視作無異常，導(dǎo)致其不回滾事務(wù)。
情況3：ExceptionHandler+seata+sentinel
類似情況1，服務(wù)消費(fèi)者無異常，也不會(huì)降級，導(dǎo)致其不回滾事務(wù)。
解決方案
1.sentinel作為服務(wù)降級組件、存在的意義就在于能夠讓業(yè)務(wù)正常走下去，所以在邏輯要求嚴(yán)格的業(yè)務(wù)中不應(yīng)引入。
不應(yīng)引入的模塊，如轉(zhuǎn)銷售：先改單據(jù)狀態(tài)、再占庫、最后做賬，這一系列流程的結(jié)果必須保證一致，需要同時(shí)完成，不可降級。（其他思考：功能痛點(diǎn)：邏輯嚴(yán)格的系統(tǒng)中，如果一個(gè)微小的系統(tǒng)異常，導(dǎo)致用戶表單無法提交，很影響體驗(yàn)。這種嚴(yán)格流程是否應(yīng)該？是否也可以增加狀態(tài)來控制流程？比如訂單狀態(tài)改了，但占庫失敗，增加未占庫狀態(tài)，之后再手動(dòng)、或者自動(dòng)去占庫、做賬，提高系統(tǒng)的容錯(cuò)率及可用性。）
可以考慮引入的模塊，如新建用戶：先創(chuàng)建用戶，再關(guān)聯(lián)角色，如果用戶表單的項(xiàng)目很多，角色是其中一個(gè)select，而恰好關(guān)聯(lián)角色時(shí)，又有問題，則可以考慮先保存用戶信息，關(guān)聯(lián)角色降級處理，這樣的好處是可以讓使用者先將要?jiǎng)?chuàng)建的大部分?jǐn)?shù)據(jù)創(chuàng)建進(jìn)去，回頭再處理有問題的部分。當(dāng)然前提必須是對業(yè)務(wù)影響較小的情況。
而且，目前fallback只能針對對于整個(gè)interface，而不支持針對于interface中的某一個(gè)方法。所以如果有某一個(gè)方法需要特殊處理，還需要再額外增加接口。所以對于sentinel，應(yīng)持保守態(tài)度。
2.@ExceptionHandler配合@RestControllerAdvice意味著綁定了所有的@RequestMapping，即所有的接口都會(huì)進(jìn)行異常處理，結(jié)合目前只有記錄錯(cuò)誤日志、和處理返回體2種功能的這種情況，而影響到全局事務(wù)的功能只有處理通用返回體，所以應(yīng)明確：
2.1.終端的所有請求，皆通過主服務(wù)，即服務(wù)消費(fèi)者。所以在此獨(dú)立jar包中，采用通用的異常處理，去處理返回體是沒問題的。
2.2.而其他的服務(wù)提供者，如庫存、賬款、訂單、基礎(chǔ)服務(wù)提供者，一定不能將異常處理為正常返回體（日志保留），只有這樣，才能不影響seata全局事務(wù)。
