本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
REL04-BP01 識別您依賴的分散式系統種類
分散式系統可以是同步、非同步或批次處理。同步系統必須盡快處理要求，並透過使用 HTTP/S、REST 或遠端程序呼叫 (RPC) 通訊協定進行同步請求和回應呼叫，以便相互通訊。非同步系統透過中間服務以非同步方式交換資料來相互通訊，而不需要耦合個別系統。批處理系統接收大量輸入資料，無需人工介入即可執行自動化資料處理，並產生輸出資料。
預期成果：設計與同步、非同步和批次相依性有效互動的工作負載。
常見的反模式：
-
工作負載會無限期地等待來自其相依性的回應，這可能會導致工作負載用戶端逾時，而不知道是否已收到其請求。
-
工作負載使用可同步呼叫彼此的一系列相依系統。這需要每個系統都可供使用，並在整個系列成功之前成功處理請求，從而導致潛在的脆弱行為和整體可用性。
-
工作負載會以非同步方式與其相依性進行通訊，並依賴於僅保證傳遞訊息一次的概念，而且通常仍然可以接收重複的訊息。
-
工作負載不使用適當的批次排程工具，並允許同時執行相同的批次工作。
建立此最佳實務的優勢：對於特定的工作負載來說，在同步、非同步和批次之間實作一種或多種通訊方式很常見。此最佳實務可協助您識別與每種通訊方式相關的不同權衡，讓您的工作負載能夠容忍其任何相依性中斷。
未建立此最佳實務時的風險暴露等級：高
實作指引
下列各節包含每種相依性的一般和特定實作指引。
一般指引
-
請確定相依性所提供的效能與可靠性服務水準目標 (SLO) 符合工作負載的效能和可靠性需求。
-
使用 AWS 可觀測性服務
來監控回應時間和錯誤率 ，以確保您的相依性在工作負載所需的層級提供服務。 -
識別工作負載在與其相依性通訊時可能面臨的潛在挑戰。分散式系統面臨各種挑戰
，可能會增加架構複雜性、營運負擔和成本。常見的挑戰包括延遲、網路中斷、資料遺失、擴展和資料複寫延遲。 -
實作強大的錯誤處理和日誌記錄，以協助您在相依性遇到問題時對問題進行疑難排解。
同步相依性
在同步通訊中，工作負載會將請求傳送至其相依性，並封鎖等待回應的操作。當其相依性收到請求時，它會嘗試盡快處理它，並將回應傳送回您的工作負載。同步通訊的一個重大挑戰是它會導致時間耦合，這需要您的工作負載及其相依性同時可用。當您的工作負載需要與其相依性同步通訊時，請考慮下列指引：
-
您的工作負載不應該依賴多個同步相依性來執行單一函數。此相依性系列增加了整體的脆弱性，因為路徑中的所有相依性都必須可用，才能順利完成請求。
-
當相依性狀態不良或無法使用時，請確定處理錯誤並重試策略。避免使用雙模態行為。雙模態行為是指工作負載在正常和故障模式下呈現不同行為的情況。如需雙模態行為的詳細資訊，請參閱 REL11-BP05 使用靜態穩定性來防止雙模態行為。
-
請記住，快速檢錯好於讓工作負載等待。例如，AWS Lambda 開發人員指南說明如何在呼叫 Lambda 函數時處理重試和失敗。
-
當工作負載呼叫其相依性時設定逾時。此技術可避免等待太長時間或無限期等待回應。如需此問題的有用討論，請參閱 Tuning AWS Java SDK HTTP request settings for latency-aware Amazon DynamoDB applications
。 -
盡可能減少從工作負載到其相依性的呼叫次數，以滿足單一請求。在兩者之間進行聊天呼叫會增加耦合和延遲。
異步相依性
若要暫時將工作負載與其相依性分離，它們應該以非同步方式進行通訊。使用非同步方法，您的工作負載可以繼續執行任何其他處理，而不必等待其相依性或相依性系列來傳送回應。
當您的工作負載需要與其相依性異步通訊時，請考慮下列指引：
-
訊息傳遞和事件串流處理訊息的方式不同，因此您需要根據下列內容做出權衡決策：
-
訊息優先級：訊息代理程式可以在正常訊息之前處理高優先級訊息。在事件串流中，所有訊息都有相同的優先級。
-
訊息消耗：訊息代理程式確保消費者收到消息。事件串流消費者必須追蹤他們讀取的最後一則訊息。
-
訊息排序：使用訊息傳遞時，不能保證以傳送的確切順序接收訊息，除非您使用先進先出 (FIFO) 方法。事件串流永遠會保留產生資料的順序。
-
訊息刪除：使用訊息傳遞時，消費者必須在處理訊息後刪除它。事件串流服務會將訊息附加至串流，並保留在其中，直到訊息的保留期過期為止。此刪除政策使得事件串流適合重播訊息。
-
-
定義工作負載如何知道其相依性何時完成其工作。例如，當工作負載以非同步方式調用 Lambda 函數時，Lambda 會將事件放在佇列中，並傳回成功回應，但沒有額外資訊。處理完成後，Lambda 函數可以將結果傳送至目的地，並根據成功或失敗進行設定。
-
透過利用冪等性來構建工作負載以處理重複訊息。冪等性意味著即使為相同訊息產生多次工作負載，工作負載的結果也不會變更。重要的是要指出，如果發生網路故障或尚未收到確認，訊息傳遞
或串流服務將重新傳遞訊息。 -
如果您的工作負載未從其相依性中取得回應，則需要重新提交請求。請考慮限制重試次數，以保留工作負載的 CPU、記憶體和網路資源來處理其他請求。AWS Lambda 文件說明了如何處理非同步調用的錯誤。
-
運用適當的可觀測性、偵錯和追蹤工具，管理和操作工作負載的非同步通訊及其相依性。可以使用 Amazon CloudWatch
來監控訊息傳遞和事件串流服務。還可以使用 AWS X-Ray 檢測工作負載，以快速獲得疑難排解問題的洞見。
批處理相依性
批處理系統會取得輸入資料，啟動一系列作業來處理它，並產生一些輸出資料，無需人工介入。視資料大小而定，工作可能會執行幾分鐘，在某些情況下執行數天。當您的工作負載需要與其批處理相依性通訊時，請考慮下列指引：
-
定義工作負載執行批次工作的時間範圍。工作負載可以設定週期性模式來調用批次系統，例如，每小時或每月結束時。
-
確定資料輸入和已處理的資料輸出的位置。選擇可讓您的工作負載大規模讀取和寫入檔案的儲存服務，例如 Amazon Simple Storage Services (Amazon S3)
、Amazon Elastic File System (Amazon EFS) 和 Amazon FSx for Lustre。 -
如果您的工作負載需要調用多個批次工作，可以利用 AWS Step Functions
簡化在 AWS 或內部部署中執行的批次工作的協同運作。此範例專案 示範使用 Step Functions、AWS Batch 和 Lambda 協同運作批次任務。 -
監控批次任務以尋找異常情況，例如任務所花費的時間超過應該完成的時間。可以使用 CloudWatch Container Insights 等工具來監控 AWS Batch 環境和任務。在這種情況下，工作負載將從一開始就停止下一個任務，並通知相關人員有關例外情況。
資源
相關文件：
相關影片：
相關工具：
