通過之前spring cloud系列教程中的《spring cloud構建微服務架構：服務容錯保護（hystrix服務降級）》一文，我們已經知道如何通過hystrix來保護自己的服務不被外部依賴方拖垮的情況。但是實際使用過程中經常碰到開發反應「莫名」觸發了降級邏輯的情況。為了更精準的定位觸發原因，或是在降級邏輯中需要根據不同的異常做不同的處理時，在降級方法中，我們希望可以獲取到主邏輯中丟擲的異常資訊。接下來就來介紹一下hystrix兩種不同實現方式中如何在降級邏輯中獲取異常資訊的方法。
先介紹一下用註解方式定義的hystrix命令是如何在降級邏輯中獲取異常的，實現非常簡單，先看下面的例子：
@hystrixcommand(fallbackmethod = "fallback")
user getuserbyid(string id)
user fallback(string id, throwable throwable)
getuserbyid，主邏輯中會主動丟擲乙個異常，從而觸發該主邏輯的降級函式fallback。重點看fallback函式中的最後乙個傳參throwable throwable。通過這樣的簡單定義，開發人員就可以很方便的獲取觸發降級邏輯的異常資訊，用作日誌記錄或者其它複雜的業務邏輯了。
在繼承方式中要獲取觸發異常也非常簡單，具體如下：
public
static
class
usercommand
extends
hystrixcommand
@override
protected user run() throws exception
@override
protected user getfallback()
}
getfailedexecutionexception方法就可以獲取到觸發降級的異常資訊了。
我們在實際使用hystrix的時候，有時候一些業務異常或者內部rpc由服務提供方丟擲的異常在消費方沒能考慮周到，會觸發一些意料之外的降級。所以在降級邏輯中，建議每一段都加入觸發異常的日誌記錄，以方便定位問題原因。
以下專題教程也許您會有興趣
Hystrix降級邏輯中如何獲取觸發的異常
通過之前spring cloud系列教程中的 服務容錯保護 hystrix服務降級 一文，我們已經知道如何通過hystrix來保護自己的服務不被外部依賴方拖垮的情況。但是實際使用過程中經常碰到開發反應 莫名 觸發了降級邏輯的情況。為了更精準的定位觸發原因，或是在降級邏輯中需要根據不同的異常做不同的處...
hystrix的區域性降級邏輯的處理方式
一般服務降級放在消費端，即 消費者端 但是提供者端一樣能使用。首先提供者，即8001 先從自身找問題，設定自身呼叫超時的峰值，峰值內正常執行，超出峰值需要有兜底的方法處理，作服務降級fallback 1 在8001服務提供方引入hystrix依賴 org.springframework.cloud ...
debian中如何為軟體包降級
引言 準備安裝g 卻被告知有衝突，一看原來是因為先使用了unstable，後來又轉回testing的緣故，libc6的版本太新了，提示說要麼別安裝g 要麼就降級libc6。以前知道debian的包管理支援將軟體包降級，但是一直沒弄明白怎麼搞。這次找了一下，發現以前的文件沒了，取而代之的是debian...