[[413636]]

對于一個系統(tǒng)，尤其是一個復雜的系統(tǒng)，重要的不是故障會不會發(fā)生，而是什么時候發(fā)生。故障處理對于開發(fā)人員和測試人員來說都特別耗費時間和精力：對于開發(fā)人員來說，他們在開發(fā)代碼時需要用20%的時間寫80%的主要邏輯，然后留出80%的時間處理各種非正常場景;對于測試人員來說，除了需要用80%的時間寫20%的異常測試項，更要用超過80%的時間執(zhí)行這些異常測試項，并構造各種故障場景，尤其是那種理論上才出現(xiàn)的故障，讓人苦不堪言。

故障注入是一種評估系統(tǒng)可靠性的有效方法，例如異常處理、故障恢復等。只有當系統(tǒng)的所有服務都經(jīng)過故障測試且具備容錯能力時，整個應用才健壯可靠。故障注入從方法上來說有編譯期故障注入和運行期故障注入，前者要通過修改代碼來模擬故障，后者在運行階段觸發(fā)故障。Istio 的故障注入就是在網(wǎng)格中對特定的應用層協(xié)議進行故障注入，這樣，基于 Istio 的故障注入就可以模擬出應用的故障場景了。

接下來我們就來說明如何注入故障并測試應用程序的彈性。

延遲故障注入

為了測試微服務應用程序 Bookinfo 的彈性，我們將為用戶 jason 在 reviews:v2 和 ratings 服務之間注入一個 7 秒的延遲，這個測試將會發(fā)現(xiàn)一個故意引入 Bookinfo 應用程序中的 bug。

首先移除之前創(chuàng)建的 VirtualService:

➜  ~ kubectl delete virtualservice reviews 
virtualservice.networking.istio.io "reviews" deleted 
➜  ~ kubectl get virtualservice 
NAME       GATEWAYS             HOSTS   AGE 
bookinfo   [bookinfo-gateway]   [*]     16d 

為了能夠讓請求穩(wěn)定，這里我們對 Reviews 服務配置請求路由，對應的資源清單文件 samples/bookinfo/networking/virtual-service-reviews-test-v2.yaml：

apiVersion: networking.istio.io/v1alpha3 
kind: VirtualService 
metadata: 
  name: reviews 
spec: 
  hosts: 
    - reviews 
  http: 
  - match: 
    - headers: 
        end-user: 
          exact: jason 
    route: 
    - destination: 
        host: reviews 
        subset: v2 
  - route: 
    - destination: 
        host: reviews 
        subset: v1 

上面的配置應用過后 jason 用戶會被路由到 reviews:v2 版本服務，其他用戶路由到 reviews:v1 版本服務。創(chuàng)建故障注入規(guī)則以延遲來自測試用戶 jason 的流量，對應的資源清單為 samples/bookinfo/networking/virtual-service-ratings-test-delay.yaml：

apiVersion: networking.istio.io/v1alpha3 
kind: VirtualService 
metadata: 
  name: ratings 
spec: 
  hosts: 
  - ratings 
  http: 
  - match: 
    - headers: 
        end-user: 
          exact: jason 
    fault: 
      delay: 
        percentage: 
          value: 100.0 
        fixedDelay: 7s 
    route: 
    - destination: 
        host: ratings 
        subset: v1 
  - route: 
    - destination: 
        host: ratings 
        subset: v1 

這個 VirtualService 定義了一個在 jason 登錄的情況下，訪問 ratings 服務的 100% 的 7s 訪問延遲。前面我們知道，Bookinfo 這個示例 productpage 服務調用 reviews，reviews 的不同版本會對 ratings 進行不同的調用，其中 reviews-v1 不調用 ratings，reviews-v2 和 reviews-v3 會調用 ratings，并做不同樣式的渲染。注意 reviews:v2 服務對 ratings 服務的調用具有 10 秒的硬編碼連接超時。因此，盡管引入了 7 秒的延遲，我們仍然期望端到端的流程是沒有任何錯誤的。

了解這一點后，我們現(xiàn)在來創(chuàng)建上面的 VirtualService 資源對象：

➜  ~ kubectl apply -f samples/bookinfo/networking/virtual-service-reviews-test-v2.yaml 
➜  ~ kubectl apply -f samples/bookinfo/networking/virtual-service-ratings-test-delay.yaml 
virtualservice.networking.istio.io/ratings created 
➜  ~ kubectl get virtualservice 
NAME       GATEWAYS               HOSTS         AGE 
bookinfo   ["bookinfo-gateway"]   ["*"]         6d23h 
ratings                           ["ratings"]   23m 
reviews                           ["reviews"]   4s 

通過瀏覽器打開 Bookinfo 應用，使用用戶 jason 登錄到 /productpage 頁面。我們期望的是 Bookinfo 主頁在大約 7 秒鐘加載完成并且沒有錯誤，但是 Reviews 部分顯示了一個錯誤消息：Sorry, product reviews are currently unavailable for this book.

reviews unavailable

而且我們可以看到頁面加載實際上用了大約6s，按照預期，我們引入的 7s 延遲不會影響到 reviews 服務，因為 reviews 和 ratings 服務間的超時被硬編碼為 10 秒，但實際上在 productpage 和 reviews 服務之間也有一個 3s 的硬編碼的超時，再加 1 次重試，一共 6s，所以 productpage 對 reviews 的調用在 6s 后提前超時并拋出錯誤了。

這種類型的錯誤在不同的團隊獨立開發(fā)不同的微服務的企業(yè)應用程序中是可能會出現(xiàn)的，Istio 的故障注入規(guī)則可以幫助我們識別此類異常，而不會影響最終用戶。

請注意，此次故障注入限制為僅影響用戶 jason，如果你以任何其他用戶身份登錄，則不會遇到任何延遲。

我們可以增加 productpage 與 reviews 服務之間的超時或降低 reviews 與 ratings 的超時來解決這個問題，在 reviews 服務的 v3 版本中已經(jīng)修復了這個問題，reviews:v3 服務已將 reviews 與 ratings 的超時時間從 10s 降低為 2.5s，因此它可以兼容(小于)下游的 productpage 的請求。

如果我們將上面 Reviews 的流量轉移到 reviews:v3 服務，然后可以嘗試修改延遲規(guī)則為任何低于 2.5s 的數(shù)值，例如 2s，然后可以確認端到端的流程沒有任何錯誤。

通過這種超時故障注入，可以幫助我們方便地發(fā)現(xiàn)服務間相互訪問中存在的潛在問題。

中斷訪問故障注入

測試微服務彈性的另一種方法是引入 HTTP abort 故障，接下來我們將給 ratings 微服務為測試用戶 jason 引入一個 HTTP abort。在這種情況下，我們希望頁面能夠立即加載，同時顯示 Ratings service is currently unavailable 這樣的消息。

這里我們需要使用到的資源清單文件為 samples/bookinfo/networking/virtual-service-ratings-test-abort.yaml：

apiVersion: networking.istio.io/v1alpha3 
kind: VirtualService 
metadata: 
  name: ratings 
spec: 
  hosts: 
  - ratings 
  http: 
  - match: 
    - headers: 
        end-user: 
          exact: jason 
    fault: 
      abort: 
        percentage: 
          value: 100.0 
        httpStatus: 500 
    route: 
    - destination: 
        host: ratings 
        subset: v1 
  - route: 
    - destination: 
        host: ratings 
        subset: v1 

上面這個 VirtualService 資源對象配置了在 jason 登錄時，reviews 對 ratings 訪問時 100% 的返回一個500錯誤響應。然后創(chuàng)建這個資源對象：

➜  ~ kubectl apply -f samples/bookinfo/networking/virtual-service-ratings-test-abort.yaml 
virtualservice.networking.istio.io/ratings created 
➜  ~ kubectl get virtualservice 
NAME       GATEWAYS               HOSTS         AGE 
bookinfo   ["bookinfo-gateway"]   ["*"]         7d 
ratings                           ["ratings"]   68m 
reviews                           ["reviews"]   44m 

現(xiàn)在我們回到 BookInfo 應用，登錄 jason，刷新頁面，有時候可以很快就看到 Rating 服務不可用的提示信息：

bookinfo error

如果注銷用戶 jason，我們將看到 /productpage 為除 jason 以外的其他用戶調用了 reviews:v1(完全不調用 ratings)，因此，不會看到任何錯誤消息，不會顯示星標的圖形。