亞馬遜認為在分散式系統中必須避免使用回退

在分散式系統領域，回退策略是最難應對的挑戰之一，對於時間敏感的服務來說尤其如此。更糟糕的是，不良的回退策略可能需要很長時間（甚至數年）才能產生影響，而優質策略與不良策略之間的差異並不明顯。本文將重點講述回退策略如何導致更多問題，且問題的出現速度比修復速度更快。我們將提供一些示例，說明回退策略給 Amazon 哪些方面造成了問題。最後，我們將討論我們在 Amazon 使用的回退備用方案。

• 回退邏輯還可能在系統上放置不可預測的負載。
• 回退策略不僅可能會使問題更加嚴重，而且可能會作為潛在錯誤發生。

分散式回退在涉及嚴重系統故障時會出現所有相同的問題，甚至更多的問題。

• 分散式回退策略更難測試。服務回退比單臺計算機應用程式更復雜，因為多臺計算機和下游服務在故障中起著重要作用。故障模式本身（如過載方案）很難在測試中複製，即使多臺計算機的測試編排隨時可用。組合還會增加要測試的案例的數量，因此您需要更多測試，而這些測試的設定會更加困難。
• 分散式回退策略本身可能會失敗。 雖然回退策略似乎可以保證成功，但根據我們的經驗，它們通常只能提高成功的機率。
• 分散式回退策略通常會使中斷情況更糟糕。根據我們的經驗，回退策略會擴大故障的影響範圍，並增加恢復時間。
• 分散式回退策略通常不值得冒險。與 malloc2 一樣，回退策略通常要做出某種權衡；否則，我們會一直使用它。為什麼在已經出現問題的情況下還要使用更糟糕的回退策略？
• 分散式回退策略通常具有潛在的錯誤，這些錯誤僅在發生了一組不太可能的巧合時才會出現，可能是在發生後的幾個月或幾年。Amazon 零售網站中的回退機制觸發的實際重大中斷說明了所有這些問題。中斷髮生在 2001 年左右，是由一項新功能導致的，這項新功能為網站上顯示的所有產品提供最新的配送速度。

Amazon 如何避免回退

• 提高非回退案例的可靠性

如上所述，回退策略只會降低完全失敗的可能性。如果主（非回退）程式碼的可靠性得到提高，服務的可用性就可能會更高。例如，團隊可以投資使用具有更高內在可用性的資料庫（例如 Amazon DynamoDB），而不是在兩個不同的資料儲存之間實施回退邏輯。此策略在 Amazon 中經常使用且屢屢奏效。

• 讓呼叫者處理錯誤

嚴重系統故障的一個解決方案不是回退，而是讓呼叫系統處理故障（例如，通過重試）。這是 AWS 服務的首選策略，我們的 CLI 和開發工具包已經具有內建的重試邏輯。在可能的情況下，我們更青睞這種策略，尤其是在已做出足夠努力來共擔命運並降低主案例失敗可能性（而且回退邏輯根本不可能改善可用性）的情況下。 

• 主動推送資料

我們用來避免回退的另一種方法是在響應請求時減少移動部件的數量。例如，如果服務需要資料來滿足請求，而這些資料已在本地存在（不需要提取），則不需要故障轉移策略。這種方法的一個成功示例是實施適用於 Amazon EC2 的 AWS Identity and Access Management (IAM) 角色。IAM 服務需要為 EC2 例項上執行的程式碼提供經過簽名和輪換的憑證。為了避免產生回退需要，系統會主動將憑證推送到每個例項，並在許多小時內保持有效。這意味著由於推送機制發生中斷的可能性較小，IAM 角色相關請求可持續工作。 

• 將回退轉換為故障轉移

關於回退，最糟糕的其中一件事情是，它不會定期執行，並且在故障期間觸發時，可能會失敗或擴大影響範圍。觸發回退的情況可能幾個月甚至幾年都不會自然發生！ 要解決回退策略的潛在失敗問題，需在生產環境中定期實施這一策略。服務必須連續執行回退和非回退邏輯。它不能僅執行回退案例，還必須將其視為同等有效的資料來源。例如，服務可能會在回退和非回退響應之間隨機選擇（當同時獲得兩個響應時），以確保二者都可正常執行。但此時，該策略不能再被視為回退策略，而是完全屬於故障轉移類別。

• 確保重試和超時不會成為回退

重試是一種強大的機制，可在出現瞬態和隨機錯誤時提供高可用性。換言之，重試和超時可為因虛假包丟失、不相關的單臺計算機故障等小問題而偶爾出現的故障提供保障。但是，重試和超時很容易用錯。服務通常持續數月或更長時間，無需多次重試，而在您的團隊從未測試過的場景中，這些重試最終可能會投入使用。出於此原因，我們需維護監控總體重試率以及在重試頻繁發生時用以提醒團隊的警報的指標。

避免讓重試變為回退的另一種方法是始終使用主動重試執行操作（也稱為對衝或並行請求）。這種技術固有地內建在執行法定讀取或寫入的系統中，在這種系統中，可能需要三臺伺服器中的兩臺伺服器提供應答才能響應。主動重試遵循持續工作的設計模式。由於總是發出冗餘請求，因此隨著對冗餘請求的需求增加，不會向系統新增重試產生的額外負載。