REL 4: 如何在分散式系統中設計防止失敗的互動？
分散式系統倚賴通訊網路來互連元件，例如伺服器或服務。即使這些網路上的資料遺失或延遲，您的工作負載仍必須可靠運作。分散式系統的元件必須以不會對其他元件或工作負載造成負面影響的方式運作。這些最佳實務可防止失敗，並延長平均失敗間隔時間 (MTBF)。
資源
AWS re:Invent 2019: Moving to event-driven architectures (SVS308)
AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems,
Big and Small ARC337 (includes loose coupling, constant work, static stability)
AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge
(MAD205)
What Is Amazon EventBridge?
What Is Amazon Simple Queue Service?
Amazon EC2: Ensuring Idempotency
The Amazon Builders' Library: Challenges with distributed systems
最佳實務:
-
確定需要哪種分散式系統: 硬式即時分散式系統需要同步、快速給予回應，而軟式即時系統則可以在更長的時段 (分鐘) 內來回應。離線系統會透過批次或非同步處理來處理回應。硬式即時分散式系統具有最嚴格的可靠性要求。
-
實作鬆散耦合相依性: 佇列系統、串流系統、工作流程和負載平衡器之間具有鬆散耦合的相依性。鬆耦合有助於將某個元件的行為與依賴它的其他元件隔離，進而提高彈性和靈活性
-
將所有回應設為等冪: 等冪服務承諾每個請求只完成一次，使得發出多個相同請求與發出單一請求具有相同的效果。等冪服務可讓用戶端更輕鬆地實作重試，而不用擔心錯誤地多次處理請求。為此，用戶端可以使用等冪權杖發出 API 請求，即每次重複請求時，都會使用相同的權杖。等冪服務 API 會使用權杖來傳回與第一次完成請求時傳回之回應相同的回應。
-
持續執行工作: 負載大幅快速變更時，系統可能會發生故障。例如，監控數千部伺服器運作狀態的運作狀態檢查系統，應該每次傳送相同大小的承載 (目前狀態的完整快照)。無論伺服器全無故障或全部出現故障，運作狀態檢查系統都會持續執行工作，而無大幅快速變更。
改進方案
確定需要哪種分散式系統
The Amazon Builders' Library: Challenges with distributed systems
- 硬式即時分散式系統需要同步、快速給予回應。
- 軟式即時系統則可以在更長的時段 (分鐘) 內來回應
- 離線系統會透過批次或非同步處理來處理回應。
- 硬式即時分散式系統具有最嚴格的可靠性要求。
實作鬆散耦合相依性
AWS re:Invent 2019: Moving to event-driven architectures (SVS308)
What Is Amazon EventBridge?
What Is Amazon Simple Queue Service?
- Amazon EventBridge 可讓您建立鬆散耦合和分散式的事件驅動型架構
AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (MAD205) - 如果一個元件的變更迫使依賴它的其他元件也變更，則屬於緊密耦合。鬆耦合會破壞此相依性，因此相依元件只需要知道受版本控制的和已發佈的界面。
- 盡可能讓元件採用非同步互動。此模型適用於不需要立即回應的任何互動，以及確認已註冊請求便以足夠的狀況。
AWS re:Invent 2019: Scalable serverless event-driven applications using Amazon SQS and Lambda (API304)
將所有回應設為等冪
- 用戶端可以使用等冪權杖發出 API 請求，即每次重複請求時，都會使用相同的權杖。等冪服務 API 會使用權杖來傳回與第一次完成請求時傳回之回應相同的回應。
Amazon EC2: Ensuring Idempotency
持續執行工作
AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (includes constant work)
- 將工作負載設計為無論成功或失敗的數量為何，承載大小都保持不變。
- 例如，如果運作狀態檢查系統正在監控 100,000 部伺服器，則在一般輕型伺服器失敗率下，其負載為額定值。不過，如果重大事件讓一半的伺服器運作狀況不良，則運作狀態檢查系統會因嘗試更新通知系統並向其用戶端溝通狀態，而承受不住負載。因此，運作狀態檢查系統應每次都傳送目前狀態的完整快照。100,000 個伺服器運作狀態 (每個以一位元表示) 只是 12.5 KB 的承載。無論伺服器全無故障或全部出現故障，運作狀態檢查系統都會持續執行工作，而大幅快速變更也不會對系統穩定性造成威脅。這實際上是控制平面針對 Amazon Route 53 運作狀態檢查設計的宗旨。