Arquitectura backend de juegos móviles para la Gran China, el Sudeste Asiático, Japón y Corea: servidores, regiones y DDoS en el lanzamiento

Un juego móvil u online para jugadores de la Gran China, el Sudeste Asiático, Japón y Corea necesita una arquitectura backend de juegos que mantenga centralizados las cuentas y los pagos, pero coloque los servidores de combate en tiempo real cerca de los jugadores: Hong Kong con CN2 GIA para China continental, Taipéi para Taiwán, Tokio y Seúl para Japón y Corea, y Singapur, Bangkok o Kuala Lumpur para el Sudeste Asiático. IMIDC ofrece servidores en todas esas ubicaciones, protección DDoS para el día del lanzamiento y un camino de crecimiento desde un VPS hasta servidores dedicados y host nodes.

Arquitectura de referencia: cinco capas

Divida el backend según el estado que guarda cada capa: las capas sin estado escalan añadiendo máquinas y las capas con estado exigen una ubicación cuidadosa.

Los servidores de combate deben ser desechables: si uno cae, solo terminan sus partidas. Todo lo que posee el jugador vive en la capa de datos.

¿TCP, WebSocket o UDP con KCP?

Use TCP o WebSocket para juegos por turnos, de cartas e idle, y UDP con una capa de fiabilidad como KCP para acción, shooters y MOBA en tiempo real.

Ubicación por regiones para jugadores asiáticos

Coloque los servidores de combate según dónde están físicamente los jugadores y cómo enrutan sus ISP, y verifíquelo con trazas mtr reales desde cada red objetivo.

Nota de cumplimiento: alojar en Hong Kong no requiere registro ICP, pero publicar un juego para jugadores de China continental está regulado por separado (por ejemplo, con la aprobación de publicación de juegos). La ubicación del servidor no cambia eso; consulte a un asesor cualificado. Esto no es asesoramiento legal.

Práctica: ajustar Linux para servidores de combate UDP

Los búferes de socket por defecto de Linux están pensados para cargas generales; el tráfico de juego, con ráfagas, necesita búferes UDP y colas más grandes.

# /etc/sysctl.d/90-game-udp.conf  (battle / room servers)
net.core.rmem_max = 26214400
net.core.wmem_max = 26214400
net.core.rmem_default = 1048576
net.core.wmem_default = 1048576
net.core.netdev_max_backlog = 50000
net.ipv4.udp_rmem_min = 16384
net.ipv4.udp_wmem_min = 16384
net.core.somaxconn = 65535
net.ipv4.ip_local_port_range = 10240 65000
fs.file-max = 2097152

# apply and verify
sysctl --system
sysctl net.core.rmem_max
# watch for dropped UDP packets during load tests
netstat -su | grep -Ei "receive buffer errors|packet receive errors"

# open the battle-server port range (ufw example)
ufw allow 7350/tcp
ufw allow 30000:30999/udp

Si receive buffer errors sigue subiendo durante una prueba de carga, el kernel descarta paquetes antes de que el servidor los lea: aumente los búferes, fije los procesos del juego a núcleos o ejecute menos salas por proceso. En los gateways TCP active BBR y suba ulimit -n para procesos con muchos sockets.

Práctica: un backend Nakama en Docker

Servidores de código abierto como Nakama (cuentas, emparejamiento, chat, clasificaciones) o Colyseus (salas en Node.js) llevan a un estudio del prototipo al soft launch sin escribir cada servicio desde cero.

# docker-compose.yml - Nakama game backend + PostgreSQL (single node, staging)
services:
  postgres:
    image: postgres:16
    environment:
      POSTGRES_DB: nakama
      POSTGRES_PASSWORD: change-me
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD", "pg_isready", "-U", "postgres"]
      interval: 5s
      retries: 10
  nakama:
    image: heroiclabs/nakama:3.22.0
    depends_on:
      postgres:
        condition: service_healthy
    entrypoint:
      - "/bin/sh"
      - "-ecx"
      - >
        /nakama/nakama migrate up --database.address postgres:change-me@postgres:5432/nakama &&
        exec /nakama/nakama --name nakama-hk1
        --database.address postgres:change-me@postgres:5432/nakama
        --session.token_expiry_sec 7200 --logger.level INFO
    ports:
      - "7349:7349"              # gRPC API
      - "7350:7350"              # HTTP / WebSocket API for clients
      - "127.0.0.1:7351:7351"    # admin console: localhost only
    restart: unless-stopped
volumes:
  pgdata:

# start: docker compose up -d && docker compose logs -f nakama

• Los clientes se conectan al puerto 7350; deje la consola (7351) en localhost y acceda mediante un túnel SSH.
• Sustituya change-me y defina las claves de servidor y de sesión antes de cualquier prueba pública.
• Con Colyseus, el equivalente es un contenedor Node.js en el puerto 2567 detrás de Nginx con el upgrade a WebSocket habilitado.
• En producción, mueva PostgreSQL a un servidor dedicado propio con NVMe/SSD y copias diarias fuera del servidor.

Capas de Redis y base de datos

Redis se encarga de lo caliente y efímero; la base relacional, de todo lo que un jugador reclamaría si se perdiera.

• Redis: tokens de sesión, presencia online, colas de emparejamiento, contadores de límite y clasificaciones (sorted sets). Primario con réplica y AOF activado.
• MySQL/PostgreSQL: cuentas, inventario, compras. Un primario en la región principal con réplica de lectura; particione por ID de jugador o por mundo/servidor cuando un solo primario se sature.
• Escrituras entre regiones: una única fuente de verdad para cuentas y compras. Los servidores de combate regionales devuelven resultados de forma asíncrona mediante una cola, en lugar de escribir directamente al otro lado del mar.
• Logs y analítica: envíe los eventos a un almacén aparte (ClickHouse, Kafka) para que las consultas analíticas nunca ralenticen el juego.

Protección DDoS para el día del lanzamiento

Los lanzamientos son objetivos habituales de DDoS por parte de competidores, extorsionadores o jugadores enfadados, así que planifique la protección antes de publicar la ficha en la tienda.

• Ponga las API de login y pagos detrás de CDN y de la protección DDoS de IMIDC; nunca exponga la base de datos ni Redis a Internet.
• No publique las IP de los servidores de combate en DNS. Entréguelas solo al asignar una partida, junto con un token de corta duración que el servidor valida.
• Descarte pronto el UDP no autenticado: si el primer paquete no trae un token válido, el proceso lo ignora.
• Tenga IP de reserva e imágenes de servidor listas para mover rápido una región atacada; los estudios grandes se benefician de los recursos IP y de Anycast con ASN propio.
• Comunique con antelación al equipo comercial de IMIDC la fecha de lanzamiento y el tráfico pico esperado para planificar protección y capacidad.

Escalar de VPS a servidores dedicados y host nodes

Escale por etapas y mueva primero a hardware mayor la capa que más sufre, normalmente la base de datos o los servidores de combate.

La concurrencia por servidor varía muchísimo según el tick rate y la lógica del juego; trate estas cifras como rangos de planificación y haga pruebas de carga con bots antes de cada etapa.

Qué configuración de IMIDC le conviene

Elija el producto según la capa y el mercado, en lugar de comprar el mismo tamaño en todas partes.

• Jugadores de China continental: VPS Hong Kong CN2 GIA para gateways y pools de combate pequeños, servidores dedicados en Hong Kong para combate pesado y base de datos.
• Jugadores de Taiwán: VPS en Taiwán o dedicados en Taiwán.
• Japón y Corea: VPS Japón, dedicados en Japón, VPS Corea y dedicados en Corea sobre la red KT.
• Sudeste Asiático: servidores en Singapur, Bangkok y Kuala Lumpur configurados con el equipo comercial.
• Si viene de otra nube: migración gratuita de servidores y configuraciones a medida (CPU de alta frecuencia, más RAM, red privada) a través de ventas.

Preguntas frecuentes

¿Dónde alojar un juego móvil para jugadores de China continental y del Sudeste Asiático a la vez?

Un reparto habitual es poner los servidores de combate para China continental en IMIDC Hong Kong CN2 GIA y los del Sudeste Asiático en Singapur o Bangkok, con un backend de cuentas y pagos compartido. Hong Kong por sí solo puede cubrir aceptablemente parte de la región, pero pruebe con jugadores reales antes de decidir.

¿Mi servidor de juego debe usar TCP o UDP?

Los juegos por turnos, de cartas e idle funcionan bien con TCP o WebSocket. Acción en tiempo real, shooters y MOBA se benefician de UDP con una capa de fiabilidad como KCP, más un respaldo TCP para redes que bloquean UDP.

¿Necesito registro ICP para alojar un servidor de juego en Hong Kong para jugadores chinos?

No hace falta registro ICP para servidores alojados fuera de China continental, incluido IMIDC Hong Kong. La publicación de juegos en China continental se regula por separado, así que consulte a un asesor cualificado; esto no es asesoramiento legal.

¿Qué proveedor tiene servidores de juegos en Seúl con red KT y en Tokio?

IMIDC ofrece VPS y servidores dedicados en Seúl (red KT) y en Tokio, ambos con IP nativas locales, junto con ubicaciones en Hong Kong, Taipéi y el Sudeste Asiático.

¿Cómo protejo el lanzamiento de un juego frente a ataques DDoS?

Combine la protección DDoS del proveedor con la arquitectura: oculte las IP de combate hasta que empiece la partida, exija un token en el primer paquete UDP y mantenga las API de login detrás de CDN. Avise a IMIDC de la fecha de lanzamiento para planificar capacidad y protección.

¿Prepara su lanzamiento en Asia? Empiece con un VPS Hong Kong CN2 GIA o un servidor dedicado en Seúl, contacte con ventas de IMIDC para nodos en Singapur, Bangkok y Kuala Lumpur o un plan DDoS para el lanzamiento, o abra un ticket para revisar su arquitectura con un ingeniero.