GAMEREL03-BP02 Implementa un accoppiamento libero delle funzionalità di gioco per gestire i fallimenti con un impatto minimo sull'esperienza del giocatore

Il disaccoppiamento dei componenti si riferisce al concetto di progettazione dei componenti del server in modo che possano funzionare nel modo più indipendente possibile. Alcuni aspetti del gioco sono difficili da separare poiché i dati devono essere il più aggiornati possibile per offrire ai giocatori una buona esperienza di gioco. Tuttavia, molti componenti e attività di gioco possono essere disaccoppiati. Ad esempio, le classiifiche e i servizi di statistiche non sono fondamentali per l'esperienza di gioco e le letture e le scritture su questi servizi possono essere eseguite in modo asincrono dal gioco.

Livello di rischio associato se questa best practice non fosse adottata: elevato

Guida all’implementazione

Implementa una riduzione graduale delle funzionalità del gioco, che possono essere disattivate automaticamente o da un amministratore se vengono rilevati problemi, oltre a configurare i servizi upstream che dipendono dalla funzionalità per poter gestire l'errore in modo corretto. Ad esempio, se i dati di un giocatore specifico non vengono caricati correttamente nel client di gioco, dovresti valutare se questi dati sono fondamentali per l'esperienza di gioco. In caso contrario, configura il client di gioco in modo da gestire correttamente questo errore senza interrompere l'esperienza del giocatore, scegliendo di riprovare a recuperare questi dati in un secondo momento, quando il giocatore rivisita lo schermo.

Utilizza logiche come timeout, nuovi tentativi e backoff per gestire errori e fallimenti. I timeout impediscono ai sistemi di bloccarsi per periodi irragionevolmente lunghi. I nuovi tentativi possono garantire un'elevata disponibilità di errori transitori e casuali.

Definite i componenti non critici che possono essere associati liberamente ai componenti critici. L'accoppiamento flessibile consente ai sistemi di essere più resilienti poiché il guasto di un componente non si ripercuote a cascata sugli altri. Quando le funzionalità di gioco non richiedono connessioni stateful ai server di gioco o al backend, dovresti implementare protocolli stateless per scalare dinamicamente e ripristinare guasti transitori. Sviluppa i componenti non critici laddove possano essere associati liberamente a protocolli stateless utilizzando un'API. HTTP/JSON Implementa le chiamate di rete dal client di gioco in modo che siano asincrone e non bloccanti per ridurre al minimo l'impatto sui giocatori delle funzionalità di gioco a prestazioni lente o di altri servizi dipendenti.

Per migliorare ulteriormente la resilienza tramite l'accoppiamento libero, utilizza un servizio di messaggistica come un sistema di accodamento, streaming o un sistema basato su argomenti tra componenti che possono essere gestiti in modo asincrono. Questo modello è adatto per un'interazione che non richiede una risposta immediata o in cui è sufficiente confermare che una richiesta è stata registrata. Questa soluzione prevede un componente che genera eventi e un altro che li consuma. I due componenti non si integreranno tramite un' point-to-pointinterazione diretta ma attraverso un elemento intermedio, ad esempio uno storage durevole o uno strato di coda. Questo aiuta anche a migliorare l'affidabilità del sistema preservando i messaggi quando l'elaborazione fallisce.

Ricerca e seleziona un meccanismo di messaggistica appropriato, poiché vari servizi di messaggistica hanno caratteristiche diverse, come i meccanismi di ordinazione e consegna. Progetta le operazioni in modo che siano idempotenti in modo che il sistema di messaggi scelto recapiti i messaggi almeno una volta. Ad esempio, prendiamo in considerazione un tipico caso d'uso di un gioco in cui il gioco deve tenere traccia del tempo di gioco dei giocatori, delle statistiche o di altri dati pertinenti, il che può portare a un elevato throughput di scrittura nei momenti di picco della concorrenza tra i giocatori.

Per implementare un'architettura affidabile, valuta se il caso d'uso richieda la read-after-write coerenza percepita dal giocatore. In genere, scenari come questi sono adatti all'elaborazione asincrona e possono essere realizzati implementando un modello di coda di scrittura in cui le richieste vengono inserite in una coda di messaggi scalabile e durevole come Amazon SQS e possono essere inserite nel database di backend in batch utilizzando un servizio consumer, come una funzione Lambda. Questo approccio è più affidabile della comunicazione sincrona tra più componenti distribuiti, tra cui il client di gioco del giocatore, i server web e applicativi di backend e il sistema di database interno. Inoltre, riduce i costi perché non è necessario scalare il database di backend per soddisfare i picchi di velocità di scrittura, poiché l'elaborazione da parte dei consumatori dalla coda di scrittura può essere utilizzata per rallentare questa velocità di acquisizione in base alle esigenze.

Passaggi dell’implementazione

Resources