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

　　當務之急是架構師需要考慮清楚定義系統故障響應后帶來的全部影響。在我們的例子中，當商品目錄服務響應時間較高時，商品將在緩存的版本中搜索。使用該特定的緩存后可能最終將導致用戶的得到的商品目錄是略微過時的版本。不管怎樣，這總比簡單的拋出一種異常然后終止用戶的搜索來的更好。
　　如上面的例子所見，系統行為的決策帶來的影響對業務來說意義深遠。因此，強烈建議與關鍵的業務利益相關者共同鑒定和確認系統響應來獲得針對業務目標的更好的優化。
　　一種用來加速決策過程的方法是將所有可行的系統故障響應作為選項列舉出來，根據業務風險評出相應的等級，并輔以簡短的解釋作為說明。一些業務風險的例子比如：運營成本，開發時間或花費，簡化的功能。
　　在下一節中，我們將看看解決方案架構師如何主動設計解決方案來實現在系統故障模型中指定的所需行為，并測試該實現。
　　定義系統故障響應的可用工具和模式
　　在本文的上一節中，我們討論了一些不同的步驟來幫助定義故障模型以及在應對解決方案依賴的第三方服務/系統出現故障時，如何選擇需要的系統響應。 在這一節中我們將著眼于不同的模式和方法論，這些內容可以幫助我們在設計階段和運行階段確保指定解決方案的故障響應被實現了，同時還可以正確的被測試。
　　通過依賴注入模擬故障
　　盡管這聽起來并不需要架構師高度關注，但是使用依賴注入模式對于設計一種能在服務中斷的情況下，系統依然可用的解決方案來說是極其重要的。 依賴注入使得解決方案的各種服務的不同實現可以以插件的形式插拔。這對在模擬依賴系統的行為作為測試保護措施時特別有用。
　　通過依賴注入，開發者可以在不重新編譯代碼的情況下注入那些精心設計用以觸發已知場景的服務?？梢酝ㄟ^簡單的改變配置來模擬不同的服務故障組合。該模式對于在單元測試和集成測試(我們將簡短的涉及到)時測試我們要求的系統行為極其有幫助。
　　不管怎樣，該模式應該在整個項目中被強制執行。個別違規的開發可能會破壞依賴注入的一些前提條件。通用的措施是解決方案架構師可以通過代碼復查來確保該模式被正確的實施了。這是一種工具并僅當在整個項目中被統一使用時才會有效：明智的做法是將它整合到開發團隊可以使用的應用開發框架中去。
　　從單元測試和持續集成中獲益
　　反復的測試和確認，當某一故障場景發生時，解決方案的行為是否會以規定的方式執行是非常重要的。達到這一點最有效的方式就是自動化執行這些測試。 一種可以達到該目的的方式是通過將故障模型和獨立的測試進行映射，并創建一整套用于模擬所依賴服務特定行為的測試套件。因為錯誤的不同組合可以并且應該在測試套件中被測試，所以測試套件執行的總時間可能比單元測試套件更長。 作為解決方案架構師，我們需要確認這些受益于依賴注入的長時間運行的集成測試并沒有跑在開發者的工作站上。
　　上述工作最合適的候選人就是構建服務器。不幸的是，當今大多數的開發小組僅僅通過利用構建服務器的構建能力，是不能將持續集成的全部潛力發揮出來的。當今很多的構建服務器具備了很多功能來執行上述測試套件。但是如果你的構建服務器不能提供這些能力或者你根本就沒有構建服務器，那么目前已有很多的開源解決方案供你選擇。
　　除了在構建服務器上執行常規單元測試之外，執行上述的測試套件，將給予架構師平和的心態，并在特定場景中的某些情況發生時確保系統行為。
　　盡管架構師的“兵工廠”(arsenal)里有如此偉大的一件工具，但持續集成測試并不能確保系統可以一直以期望的行為工作。他們只提供了在面對單一故障場景時的一種特定行為。如果要關注系統的長期行為，我們將在下一節中討論測試裝置(test harnesses)的用途。
　　創建測試裝置
　　在某些情況下，僅僅建立個別用于返回預定義異常的回執(stubs)可能就足夠了。然而大多數時候，能夠逐漸改變系統對依賴的響應以及觀察解決方案在環境變化時的行為是非常重要的。尤其是在測試到包含斷路器(circuit breaker)實現的場景時。
　　為了測試在變化的故障模式中的系統行為，有必要花較少的精力建立一個可以模擬獨立或組合服務故障的可控環境。一些時候，這還需要創建可以輸入腳本的應用，并可以在一段時間內按控制返回一系列錄制的響應。
　　通過當今操作系統提供的虛擬化能力和第三方的解決方案，通過創建虛擬化來達成這項任務是可行的。這些環境可以在每次迭代中的某一段時間內被使用，并可以在不使用時撤下。
　　需要注意的一件事是，創建測試裝置并不是一次性的活動，它需要在解決方案的每個迭代中重新考慮。一旦引入了更多的依賴，那么就需要更多的精力去保持測試裝置與當前代碼基礎的相關性。
　　結束語
　　作為解決方案架構師，我們日益面臨交付解決方案的挑戰。這些解決方案需要集成已存在的那些部署在云中，在不同的客戶端數據中心或相同的數據中心中的其他解決方案。不管這些服務在哪里，集成系統的行為將會以很多種方式影響到我們的解決方案。
　　我們作為架構師的一部分責任是識別，設計和測試如何應對這些系統中的故障和異?，F象。在本文中，我們討論了如何能更好的為集成其他服務做好計劃。我們著眼于識別出我們的SLAs去理解目標系統的性能。然后我們又通過創建故障模型來識別出系統會如何故障并且針對不同的故障組合解決方案該如何響應。最后，我們討論了一些可以整合到解決方案中的通用實踐，使得實現和測試期望系統的行為更將簡單。
　　我們在本文中涉及到工具和技術只是我們作為解決方案架構師用于確保交付高質量軟件可選工具的冰山一角。除了技術方面，在項目團隊組織方面多花精力也是不容忽視的。對于所有服務團隊中的人力與團隊工作動力方面的內容值得在另一篇獨立的文章中來講述。

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