Tengo este concepto de reescribir un motor de juego como una colección escalable de microservicios.
Actualmente es una prueba de concepto, pero el principio principal radica en que cada jugador tenga su sesión/conexión mantenida y administrada por un solo contenedor, por lo que los contenedores aumentarán o disminuirán según la cantidad de usuarios conectados.
Cada contenedor de reproductor se comunicará con muchos otros microservicios para recopilar datos y realizar acciones, estos servicios serán réplicas estáticas de 2 o 3.
Hay un microservicio que tengo en mente que siento que es un cuello de botella y actualmente estoy buscando formas de hacerlo más 'escalable' y 'robusto'.
Este microservicio en cuestión es el servicio GameMap. Habrá varios servicios de GameMap (al menos un servicio para cada mapa de juego único o instanciado). Cada mapa contendrá un número N de celdas y cada celda puede contener objetos con diferentes tipos/estados, por ejemplo (es decir, otros objetos de jugador, Objetos de artículo)
Me gustaría poder tener una réplica de al menos 2 para cada GameMap para voltear instantáneamente si uno fallara y se apagara por alguna razón. Para lograr eso, necesito tener un estado consistente/actualizado compartido entre ellos.
La necesidad de poder equilibrar la carga del tráfico entre las dos réplicas es agradable pero no esencial.
Hasta ahora, la única solución potencial que he encontrado es Hazelcast. Esto me permitirá mantener el estado de cada celda del mapa en una cuadrícula de datos de memoria escalable (nuevamente por solidez y escalabilidad).
Espero que pueda haber hasta 100 cambios de estado dentro de un mapa de juego cada segundo y mi preocupación es que puede ser demasiado lento y causar una gran latencia entre los usuarios.
¿Alguien tiene algún consejo, sugerencia o comentario basado en ambos escenarios o, lo que es más importante, en el caso de uso de Hazelcast aquí?
PD: puedo cargar mi diagrama de arquitectura/conectividad muy crudo de mi motor de juego como microservicios en algún momento si ayuda o si alguien está interesado.
Realmente depende de sus requisitos, entorno, etc.
Especialmente si quiere ser HA, probablemente quiera replicar en diferentes zonas de disponibilidad o regiones potencialmente diferentes y estará limitado por la velocidad de la luz (o tendrá que aceptar que existe la posibilidad de pérdida de datos). Así que en otras palabras; el rendimiento está determinado principalmente por la infraestructura.
Pero solo para darle algunos números aproximados; para una lectura simple en instancias c5.9xlarge en EC entre máquinas en el mismo grupo de baja latencia, está buscando 100/200 us. Y ejecutar cientos de miles de segundos por instancia normalmente no es un problema.
En otras palabras; es muy difícil decir si este es el enfoque correcto. Dependiendo de su situación y cuán importante sea esto, tomaría una sola porción de todo su sistema y haría algunos puntos de referencia para tener una impresión de qué tan bien funciona y qué tan bien escala.
Pero me suenan las alarmas cuando veo la combinación de microservicio con 'tiempo real' y 'motor de juego'.