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

場景/服務	訂單執行服務	庫存服務	客戶數據庫	商品目錄	客戶評論服務	系統響應時間
搜索商品				2		1000	毫秒
閱讀客戶評論					1	1000	毫秒
添加商品到購物車		2		2		1300	毫秒
結賬	1	2	2			1500	毫秒

　　通過使用該模型，我們可以識別出指定的場景/功能中期望的響應時間。一旦監控的響應時間開始惡化，解決方案將可以努力采取類似如下主動架構措施：借助于多層緩存，用并行的解決方案處理調用結果以及使用重疊IO(overlapped I/O)。我們將在本文的后續部分探索這些方法中的部分方案。
　　系統吞吐量模型
　　我們在本文中討論的最后一項SLA是解決方案的吞吐能力。該能力大致可以理解為每秒鐘可以處理的請求數。簡單起見，我們將不考慮數據有效負載的規?；蛉魏斡嬎阒械钠渌囊蛩?。解決方案的吞吐量依賴于調用鏈中每個依賴系統每秒的事務處理量(TPS)。我們可以將事務理解為任何在調用鏈中的指定系統的一次操作執行。
　　如何得出依賴系統的TPS往往被證明是一件非常有挑戰的事，因為系統相關的文檔往往很缺乏。在這種情況下，我們就有必要編寫簡單的驅動應用去監控每個系統獨立的TPS。
　　如果這些個依賴系統被多個其他應用所共享，就像一個數據庫會為三個不同的應用提供服務一樣，該系統的TPS只有部分對該開發中的解決方案來說是有效的。整體依賴的利用百分比需要在計算中作為因素被考慮進去。以下是系統容量模型的例子，一個簡化的在線零售商，通過整合跨越訂單執行，庫存，商品目錄，客戶評價和客戶數據庫等多個服務的調用提供相關功能。

服務	吞吐量（TPS）	當前解決方案的專用容量	整體可用性吞吐量（TPS）
訂單執行服務	350	100%	350
庫存服務	500	75%	375
客戶數據庫	2000	50%	1000
商品目錄	2000	100%	2000
客戶評論服務	150	55%	82.5

　　通過這些數字，直觀的就能看到的是：對于指定的服務調用鏈，該解決方案的最大吞吐量僅僅是該調用鏈中TPS最低的服務的吞吐量。在解決方案中，這條關鍵信息可以被用來識別潛在的擴展計劃，并可以采取主動措施以確定沒有超過吞吐量的閾值。我們將會在本文的后續部分就如何可以做到這一點來探討一些相關的技術。

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