本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

GAMEREL03-BP02 實作遊戲功能的鬆散耦合，在對玩家體驗影響最小的情況下處理失敗

解耦元件是指設計伺服器元件的概念，以便它們可以盡可能獨立運作。遊戲的某些層面很難解耦，因為資料需要盡可能保持最新狀態，才能為玩家提供良好的遊戲體驗。不過，許多元件和遊戲任務都可以解耦。例如，排行榜和統計資料服務對遊戲體驗來說並不重要，而且對這些服務的讀取和寫入可以從遊戲中非同步執行。

未建立此最佳實務時的曝險等級：高

實作指引

針對遊戲中可自動停用的功能，或在偵測到問題時由管理員停用的功能實作正常降級，以及設定依賴該功能的上游服務，以正常處理失敗。例如，如果特定玩家資料未正確載入遊戲用戶端，您應該考慮此資料是否對遊戲體驗至關重要。如果沒有，請設定遊戲用戶端以正常方式處理此失敗，而不會中斷玩家的體驗，選擇稍後在玩家重新瀏覽畫面時重試擷取此資料。

使用逾時、重試和退避等邏輯來處理錯誤和失敗。逾時可防止系統長時間不合理地懸置。重試可提供高可用性的暫時性和隨機錯誤。

定義可鬆散耦合至關鍵元件的非關鍵元件。鬆耦合可讓系統更具彈性，因為一個元件中的故障不會層疊到其他元件。當遊戲功能不需要與遊戲伺服器或後端的狀態連線時，您應該實作無狀態通訊協定來動態擴展並從暫時性故障中復原。開發您的非關鍵元件，其中它可以使用 HTTP/JSON API 鬆散地與無狀態通訊協定耦合。從遊戲用戶端實作非同步和非封鎖的網路呼叫，將執行緩慢的遊戲功能或其他相依服務對玩家的影響降至最低。

若要透過鬆散耦合進一步改善彈性，請在可非同步處理的元件之間使用訊息服務，例如佇列、串流或主題型系統。此模型適用於不需要立即回應或確認已註冊請求的互動。此解決方案涉及一個產生事件的元件，以及另一個耗用它們的元件。這兩個元件不會透過直接point-to-point互動進行整合，而是透過耐用儲存或佇列層等中繼進行整合。這也有助於在處理失敗時保留訊息，以改善系統的可靠性。

研究並選擇適當的簡訊機制，因為各種簡訊服務具有不同的特性，例如訂購和交付機制。設計等冪操作，讓所選的訊息系統至少傳遞訊息一次。例如，假設您的遊戲需要追蹤玩家播放時間、統計資料或其他相關資料的典型遊戲使用案例，這可能會在玩家並行峰值時導致高寫入輸送量使用案例。

若要實作可靠的架構，請考慮使用案例是否需要玩家感知的read-after-write一致性。一般而言，這類案例適用於非同步處理，並且可以透過實作寫入佇列模式來實現，其中請求會擷取到可擴展且耐用的訊息佇列，例如 Amazon SQS，並且可以使用消費者服務，例如 Lambda 函數，分批插入您的後端資料庫。這種方法比多個分散式元件之間的同步通訊更可靠，包括玩家的遊戲用戶端、後端 Web 和應用程式伺服器，以及內部資料庫系統。它還降低成本，因為後端資料庫不需要擴展以滿足峰值寫入輸送量，因為來自寫入佇列的消費者處理可以根據需要用來減慢此擷取速率。

實作步驟

Resources