Giusto per deviare un po’ il discorso, il day1 senza downtime etc e’ probabilmente dovuto piu’ al fatto che Diablo 4 sia palesemente scritto con un approccio a microservices piuttosto che un enorme monolite di codice come e’ WoW.
Il motivo per cui WoW (almeno fino a che ricordo io) tende a collassare e’ che zone grosse come continenti interi sono tutte caricate assieme e sono molto piu’ ampie delle mappe di diablo.
Se avete giocato la beta avrete fatto caso al fatto che quando appariva il nome della nuova zona, avevi un rubber-banding o lag nei primi secondi ed era perche’ in quel momento sei ancora nella zona precedente, camminando sul una parte di mappa che triggera il caricamento della nuova zona e ti sposta in una nuova istanza.
Cosa vuol dire?
Ognuno di queste e’ gestita da un singolo service (“server” per chi non sa):
Estern Kingdom
Kalimdor
Classic Dungeons
Pandaria
E cosi via. Vuol dire seamless transition quando passi da una regione all’altra e un caricamento quando cambi continente (pensate alle barche o lo zeppelin).
Per gestire tutta quell’area tra giocatori che si muovono, npc/mob che aggrano, si spostano, etc servono dei server abbastanza corazzati. E ci sta, WoW e’ stato pensato quando il concetto di Cluster e Docker non era ancora presente.
Diablo 4 ha un’approccio piu’ atomico nella gestione, ad esempio:
Citta’ XYZ
Zona A
Zona B
Zona C
Citta’ XWK
Dungeon 1
Dungeon 2
Dungeon 3
World Boss Area I
World Boss Area II
E cosi via. Sono unita’ decisamente piu’ piccole e, a giudicare dalla beta, anche con molta meno concentrazione di nemici / giocatori. Se ci fate caso, dove c’e’ un world boss non ci sono nemici “minori”, per minimazzare il carico di lavoro e dove gestire solo i giocatori e una unita’ in sostanza.
Questo permette di creare un mesh di servizi piu’ piccoli e quindi facilmente scalabili e economicamente MOLTO piu’ leggeri da gestire.
Ad oggi con tecnologie come Kubernetes si puo’ scalare sia orizzontalmente (crea duplicati di un processo) che verticalmente (incrementa le risorse di un processo) sia in incremento che decremento, in base al traffico.
Non l’ha inventato Blizzard kubernetes (l’ha fatto google) ma pare che finalmente abbiano capito che developers e platform engineers devono lavorare assieme per fare un prodotto decente a livello tecnico sulla scalabilita’, ridondanza e affidabilita’. Per darvi un’idea, un Cluster di Kubernetes puo’ supportare fino a 150.000 unita’ di servizi (non sto a dirvi i termini tecnici che senno’ non finiamo piu’) e un totale di massimo 300.000 servizi.
Va da se’ che e’ meglio non raggiungere quel limite ma sopratutto che un cluster e’ praticamente un’unita’ logica (per farla semplice) e puoi avere quanti cluster vuoi, quindi se una regione geografica ha molti player, tirar su un cluster nuovo e’ questione di 24h volendo, quello magari richiede piu’ lavoro per essere automatizzato e magari non ne vale la pena, basta avere un monitoring decente.
Per cose come cross-cluster communication o jumping, niente vieta che ogni cluster abbia un servizio che accoglie richieste di un giocatore X di spostarsi nella zona/instance di giocatore Y. Basta un service bus che fa da passaggio dei dati e comunica il necessario. Ti becchi un loading screen e bam, sei nell’altro cluster. E’ una questione prettamente di software, neanche di platform.
