系統中的故障場景建模(4)

　　在這一節中，我們討論了SLAs中的一些在達成前需要被徹底分析的內容。我們同樣也討論了一些工具來幫助我們評估解決方案中哪些SLAs是符合實際并可以達成的。一旦這些被確定，我們將開始關注設計和計劃如何使我們的系統達到這些SLAs，并主動地設計好系統如何在規定的約束條件內可以正常的運作。
　　第三步. 測量關鍵數據點
　　通過著眼于依賴關系，我們確定了期望的SLAs。在此之后，我們需要去搜集那些用于檢測期望運作模型的必要數據點。在這一節中，我們將討論在系統運行時可以搜集到的不同的數據點。 雖然每個項目需要搜集不同的關鍵指標，但實際上花90%的時間收集以下最小的指標集就足以用于適當的調整系統行為。
　　響應時間: 該值記錄了請求方向所依賴的服務發起請求至請求方接收到服務響應之間的總時間。這個響應時間考慮了所有網絡延遲以及系統所依賴的服務真正的處理時間。
　　數據負載規模: 服務調用返回響應的總規模。尤其是在處理粗粒度服務的時候，大數據量會影響整個處理管道。所以，掌握數據負載規模是非常有幫助的。
　　吞吐量: 該值可以是每秒服務處理的請求數或每秒服務處理返回的數據規模。該關鍵數據點可以被用來控制服務的請求流。
　　異常的類型/數量: 該值是一個固定的時間周期內根據類型分組的異?？倲?。該數據點可以被用來基于集成的服務的狀態臨時關閉系統的部分功能。 在下一節中，我們將使用前面提到的數據點創建一種可以適應生存的架構。換句話說，我們將討論請求流的控制(有時稱為限流)和斷路器(circuit breaker)的實現
　　第四步. 創建系統故障模型
　　目前我們已經理解了所有解決方案集成的服務以及解決方案可以滿足的合理SLAs，并且識別出了那些需要被測量(以用于檢測系統的實時運作質量是否符合了已達成的SLAs)的數據點。解決方案架構師還需要確認方案是否可以經受的起依賴系統的故障并且以一種可預見的方式響應故障。
　　每個被依賴的服務都可能因為不同的原因或以完全不同的方式發生故障。不幸的是，這些故障場景并沒有在系統所要求的這些功能的需求文檔里被良好的描述。 因此，需要為所有的依賴故障制定計劃并提出可行的恢復或限制功能的手段以供系統繼續以最優的方式運作，而這個重任就落在了架構師的肩上。
　　盡管不同的圖表技術都可以用來表述系統的故障模型，我們將會在后續描述一種特殊的信息記錄方式。然而，只要你交流的對象(開發團隊、業務分析師和項目利益相關者)能夠在沒有你特別解釋的情況下閱讀懂該圖，那么圖表工具或方法的選擇將不會像內容本身那樣重要。
　　對于解決方案集成的每一個系統來說，都有一系列的組件可能發生故障。本文到目前為止，我們已經創建了可用性，響應時間和吞吐量等模型。因此，我們將在咱的所有故障模型中僅僅考慮以下類型：
　　響應時間變長
　　重復的應用錯誤
　　系統不可用
　　一個系統的故障模型創建如下，其中搜集了在我們的電子商務解決方案中的不同類型的故障。請記住，這個表格需要簡潔但并不要求很全面。

場景/服務	訂單執行服務	庫存服務	客戶數據庫	商品目錄	客戶評論服務	系統行為
搜索商品				響應時間變長		提供緩存的版本
閱讀客戶評論					系統不可用	關閉功能
添加商品到購物車		X		響應時間變長
結賬	重復的應用錯誤	響應時間變長	X			對請求限流

　　在上面的例子中，每個場景都會依賴一些列的集成服務。在每一行中，我們提供了一種在集成服務可能失敗時可用的應對方法。簡單的“X”符號用來表示這些服務可以正確的工作。
　　在對本模型更加詳盡的實現中，我們需要考慮不同故障的組合情況。因此，這將是一個更加復雜的模型，它針對每個場景將擁有多行來展示不同的故障組合。 最后，我們期望的針對每個場景或功能的系統故障響應將以列表的形式展示在右手邊。令人遺憾的是，在表格中定義的每個系統故障響應都是有利有弊的。

原文轉自：http://www.anti-gravitydesign.com