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. 其他提示資訊
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/555962.html
標籤：架構設計
上一篇：讀發布！設計與部署穩定的分布式系統（第2版）筆記11_無限長的結果集
下一篇：返回列表