故障註入測試顧名思義就是當被測試應用部分組件或功能出現潛在故障時其本身的容錯機制是否正常工作，以達到規避故障保證正常組件或功能的使用。Istio提供了HTTP故障註入功能，在http請求轉發的過程中，用戶可以設定一個或多個故障。故障註入的修改作用於Virtual Service，共有兩種不同的故障模式abort和delay。

為了方便大家理解本文內容，我們預先部署了bookinfo示例。

圖中是原來完整的 virtualservice，設置了當cookie滿足user=vip時，reviews的請求會流入v4版本，其余都會流入v1版本。

中斷故障

當用戶對某個負載註入了中斷故障時，對於訪問該負載的http請求，都會收到預先設定的錯誤狀態碼而不會收到正確內容的響應。圖中的yaml截取於reviews的virtualservice文件。

我們可以看到對於版本v1的路由規則裏多了一條fault對象。這個fault對象中，則包含了設定的故障屬性。可以解讀為，v1版本添加abort故障並且設定返回的http狀態碼為501，percent設定為100這意味著所有訪問v1的請求都會收到501的http響應，顯而易見如果這裏設成50則只有一半的請求會收到501響應，另一半則會收到正常的響應。

如果我們訪問productpage只能看到基本的報錯信息，並不能確定，這到底是我們預設的中斷故障起作用了，還是某種原因導致服務“崩了”。

為了確定是我們人工導致的服務中斷，而不是其他，我們必須直接訪問reviews。給Reviews組件配置外部ip，打開瀏覽器，並且按下F12，選擇network，在地址欄中輸入“地址/reviews/0”，network中會有一項紅色報錯信息，點開則可以看到我們預設的501報錯狀態碼。至此中斷故障已經成功註入。刪除則只需將fault對象直接清除掉即可。

如果這時候我們去訪問v4，將cookie設為user=vip

可以看到這時的reviews可以正常的顯示。

延時故障註入

除了剛才延時的中斷服務故障，延時故障也可以手動註入組件中。剛才使用的bookinfo示例中有兩個版本v1和v4。我們已經給v1版本註入了中斷故障，現在我們給v4版本註入延時故障，設定時間延遲為2秒，並且所有訪問v4的請求都會有2秒的延遲。

如上，我們打開product page 以及 reviews page 來驗證一下：

從這裏我們可以看到product page 響應2.39秒

Reviews page的響應2.27s

我們用例子介紹了兩種基本故障註入的方式

接下來我們看一些其他的故障註入例子

Virtual Service 例子1：

在這個例子中，當cookie滿足user=vip時會觸發延時故障，2秒延時後訪問v4版本，當user=svip的時候則會觸發中斷故障，當cookie不滿足以上兩個條件時，則可以正常訪問v1版本。

Virtual Service 例子2：

在這個例子中不論cookie符合vip還是svip，亦或是都不符合兩個條件，都可以正常的訪問到v1版本。這是由於route對象放在了第一個，沒有任何匹配條件，不管cookie值是什麽都“滿足條件”，所以所有的流量不加任何處理直接會流向版本v1，這裏要特殊提醒下，如若自己手動添加故障註入一定要註意相對順序，否則可能不會出現你想設定的結果。

Virtual Service 例子3：

這個virtual service中我們對同一個版本註入了兩個不同的故障，滿足任何一個條件都可以觸發相應的故障，如果所有條件都不滿足則會默認的正常訪問v1版本。那麽問題來了，如果我沒有配置最後一條route，出現了一條既不符合中斷故障匹配條件，也不符合延時故障匹配條件，請求會走向哪裏呢？對於這種yaml設置，結果異常的簡單直白，如果請求不符合任何條件，則會直接獲得404的響應，不會自動流入任何其他的版本。

故障註入測試為應用在上線前提供了完備的可靠性測試，istio為使用者進行故障註入提供了極大地便捷，在正確的地方添加3-4行配置而不用修改應用代碼即可進行故障註入測試。希望有更多的人可以利用istio故障註入功能提供的便捷來提高自己的研發和測試效率。

idou老師帶教你學Istio 03： istio故障註入功能的介紹和使用