1. “模式採用量”絕不是好的質量指標

1.1. 應該形成一種“面向恢復”的思維模式

1.2. 良好的模式能為開發工程師提供架構和設計方面的指導，從而減少、消除或緩解系統中的裂紋產生的影響

1.2.1. 在新發佈軟體後，它們能讓你睡個安穩覺

2. 超時

2.1. 超時是一種簡單的機制，只要認為響應不會到來，就可以停止等待

2.2. 代碼不能永遠等待響應，它遲早需要放棄等待

2.3. 早些年

2.3.1. 網路問題隻影響那些從事操作系統、網路協議、遠程文件系統等低層級軟體開發的程式員

2.4. 今天

2.4.1. 每個系統都是分散式系統

2.4.2. 每個應用程式都必須應對網路的基本特點：網路會出故障

2.4.2.1. 電纜可能會斷開

2.4.2.2. 傳輸線路上的交換機或路由器可能會壞掉

2.4.2.3. 正在定址的電腦可能會崩潰

2.4.3. 即使已經建立了通信，參與其中的任何部件都可能隨時中斷

3. 超時機制/模式

3.1. 良好的超時機制可以提供失誤隔離功能

3.1.1. 其他服務或設備中出現的問題不一定會成為你的問題

3.2. 在遠離複雜硬體層的抽象層，良好的超時設置越來越罕見

3.2.1. 一些高級API只有很少的超時設置，有些幾乎沒有明確的設置

3.2.2. 許多API只提供了一個帶有超時時間的調用和一個更簡單、更容易但永久阻塞的調用

3.2.3. 商業軟體客戶端程式庫缺乏超時設置

3.2.3.1. 這些庫通常代表系統直接進行套接字調用

3.3. 超時可以用於單個服務

3.3.1. 任何資源池都可能枯竭

3.3.2. 在向資源池檢入一個資源之前，調用線程會被阻塞

3.3.3. 無論資源是否可用，所有引起線程阻塞的資源池都必須有一個超時時間，以確保調用線程最終會解除阻塞

3.4. 處理所有潛在的超時會給代碼帶來不必要的複雜性

3.4.1. 網路連接代碼完全充斥著針對各類超時的錯誤處理邏輯

3.4.2. 有一半的代碼是進行錯誤處理，而不是提供特性

3.5. 以生產環境（而不是QA環境）為目標，其本質就是處理“是生存還是毀滅”這樣的終極問題

3.5.1. 用於錯誤處理的代碼會增強系統的韌性

3.5.2. 系統的用戶可能不會因此而感激你，系統不發生停機就沒人會留意你，但你晚上能睡得更好

3.6. 超時模式和快速失敗模式都解決了延遲問題

3.6.1. 快速失敗模式適用於傳入系統的請求

3.6.2. 超時模式則主要適用於系統發出的出站請求

3.7. 超時模式還可以通過阻止客戶端處理整個結果集，緩解“無限長結果集”的問題

3.8. 超時模式適用於一般類型的問題，它能幫助系統從意料之外的事件中恢復過來

4. 方案

4.1. 使用通用網關為連接處理、錯誤處理、查詢執行和結果處理提供模板

4.1.1. 將這種通用的交互模式收集到一個類中，採用斷路器模式時就會變得更加容易

4.1.2. 斷路器可以記錄一段時間內的超時情況，如果超時過於頻繁，斷路器就會跳閘

4.2. 那些使用回調函數或響應式編程風格的編程語言運行時，也能更輕鬆地設定超時時間

4.3. 將超時模式應用於集成點、阻塞線程和緩慢響應

4.4. 當操作時間過長，有時無須明確其原因時，只需要放棄操作並繼續做其他事

4.5. 超時通常與重試一同出現

4.5.1. 在“儘力而為”的設計理念下，軟體會試圖重覆執行一次超時操作

4.5.2. 在系統失效後立即重試，會產生一系列結果，其中只有一些是有益的

4.5.3. 如果由於重大問題而導致操作失敗，那麼立即重試的結果可能是再次失敗

4.5.4. 在數據中心的內部，系統失效可能是因為連接的另一端出現問題

4.5.4.1. 快速重試很有可能再次失敗

4.6. 慢慢地重試排隊等待的任務，能使系統更加穩健

4.6.1. 延遲重試

4.6.2. 大多數情況下，應該把操作任務放入隊列，稍後再重試

4.7. 務必給客戶一個答案

4.7.1. 由於某種超時而無法完成操作，最好返回一個結果

4.7.1.1. 失敗了

4.7.1.2. 成功了

4.7.1.3. 其他提示信息