administration

Blog de programador: qué sucede bajo el capó de gamer.ru

content auto translated from {from}

Breve referencia histórica

El sitio gamer.ru está atravesando ya la tercera (o incluso cuarta) reescritura completa de su código. Inicialmente, el proyecto fue escrito en Ruby-on-Rails hace ya más de una década. La arquitectura era monolítica, por lo que cada solicitud del usuario generaba una enorme cantidad de solicitudes adicionales a la base de datos y cargaba todas las bibliotecas posibles. Para asegurar el funcionamiento del recurso con 100,000 visitantes al día, se tuvieron que utilizar cinco servidores potentes, implementar memcached, Redis y replicar bases de datos en varios servidores. Esto permitió sobrevivir de alguna manera hasta 2018, cuando comenzaron los problemas financieros en la empresa y el equipo de desarrolladores se dispersó.

Aproximadamente en 2020, el sitio perdió su certificado SSL. Resultó imposible actualizarlo, ya que la versión antigua de Ruby-on-Rails dependía de una versión obsoleta de openssl, mientras que los nuevos certificados requerían una versión más reciente. Nadie se preocupaba mucho; el sitio continuaba funcionando de forma mediocre. Entre 2015 y 2025, la asistencia cayó gradualmente de 100,000 a 1,000 personas al día. En los blogs y comentarios ocultos apareció una gran cantidad de spam, incluyendo contenido poco decoroso. Yandex perdió completamente el interés en nosotros, y en la herramienta para webmasters solo había un lienzo rojo de errores críticos.

Qué hicimos para corregir todo

El sitio necesitaba una seria optimización, ya que la antigua arquitectura ya no respondía a las realidades. Se habían acumulado alrededor de 100,000 publicaciones y 1.6 millones de comentarios que debían ser trasladados cuidadosa y cuidadosamente al nuevo motor. Decidimos migrar a una arquitectura de microservicios tanto en el backend como en el frontend, aprovechando al mismo tiempo tecnologías modernas, incluidos los modernos HTMLElement's.

El proyecto fue completamente reescrito desde cero en NodeJS sin el uso de bibliotecas de terceros, lo que garantiza una vida tranquila durante los próximos 10 a 20 años. Ahora no hay que temer que la actualización de alguna biblioteca popular como ExpressJS o React rompa todo el sitio y requiera otro gran refactor. Incluso tuvimos que escribir nosotros mismos el editor visual de publicaciones, ya que no pudimos encontrar nada listo que cumpliera con nuestras modestas solicitudes. Ahora, el motor genera páginas HTML para dispositivos y motores de búsqueda antiguos, y proporciona contenido a los usuarios a través de AJAX.

Hoy en día, el sitio soporta con éxito una carga media de aproximadamente 150 solicitudes por segundo, siendo la mayoría del tráfico generada por bots de búsqueda y otros crawlers. Los bots de semrush y openai, en particular, se comportan de manera muy activa, como si intentaran descargar todo el sitio en un día. Si Yandex nos indexa lentamente, a una velocidad de 1-2 solicitudes por segundo, estos compañeros pueden hacer hasta 50 solicitudes.

Sin embargo, el motor resultó tan optimizado que toda esta armada de bots es fácilmente atendida por una única máquina virtual económica que cuesta alrededor de 500 rublos al mes.

Por supuesto, de vez en cuando, el sitio nos recuerda su presencia con errores 502 y 504, que se van identificando y corrigiendo poco a poco. A veces, resulta que alguien olvidó añadir un índice en la base de datos, otras veces, una consulta demasiado compleja tiene que ser dividida en varias más simples, y a veces simplemente se agota el espacio en el servidor. Pero no nos rendimos: el trabajo continúa, y el proceso, como se dice, está "bajo control".

post more button

1081

post actions

Comentarios

Sí, la importación dinámica es definitivamente una característica genial de JS.
No había trabajado con tal stack antes y estaba acostumbrado a una separación bastante estricta entre el back-end y el front-end, así que un enfoque más flexible no me resulta obvio.
Me había encontrado con esto más como un concepto teórico y no había visto soluciones así en proyectos reales. Fue especialmente interesante ver esto en acción en un sitio web real. ¡Gracias!

Sí, algo así ) Este enfoque también permite utilizar módulos con las mismas exportaciones tanto en el front como en el back.

Así:
let { session, ajax, addViewRoute } = typeof window !== 'undefined'
? await import("../../shared/frontend.js")
: await import("../../shared/backend-server.js")

Esto permite utilizar el mismo código en el navegador y en el servidor. Es especialmente útil para plantillas y definición de rutas públicas.

¡Genial! Me recuerda un poco a Dapr de .NET, una solución muy interesante y elegante. ¿Estoy en lo correcto al entender que la lógica de negocio no sabe dónde se encuentra físicamente el módulo, y que el transporte se elige a nivel de abstracción? Si es así, se ha implementado una abstracción RPC personalizada con un cambio entre llamadas locales y http?

un gateway autocompuesto, realizado de tal manera que los microservicios pueden ser parte de un monolito o pueden ejecutarse como microservicios independientes. Es decir, cualquier método de la API puede permanecer dentro del monolito o ser extraído por separado con un par de líneas de código. Esto ayuda a ahorrar memoria (ya que es limitada y un proceso requiere alrededor de 200-500 MB de RAM), pero al mismo tiempo permite distribuir la carga en servidores adicionales. Hay una función universal ajax(método, ruta,...), que llama a funciones de los módulos vecinos; si el módulo vecino está en el mismo dominio, la función se llama directamente, y si está en otro, se realiza a través de una solicitud de red con el identificador de sesión del usuario pasando... Todo salió muy bien, y, por si acaso, por ahora, todo sigue colgando en el monolito.)

Gracias por el análisis detallado. Es especialmente valioso que se describan no solo las soluciones, sino también las verdaderas limitaciones con las que se tuvo que enfrentar. Estas cosas suelen quedarse fuera de cámara.

Tengo curiosidad, si no es un secreto, ¿qué estás utilizando actualmente como API Gateway? ¿Qué ha resultado conveniente para la ruta, la autenticación y el límite de tasa en un esquema de microservicios?

Hemos simplificado un poco las mecánicas y se decidió actualizar el motor lo antes posible, aunque con funcionalidad mínima, ya que el antiguo motor tenía muchos errores que nos hizo ser baneados de los motores de búsqueda, provocando que nuestro tráfico cayera a cero. La correspondencia se ha guardado, el gobierno aparecerá un poco más tarde, y seguiremos desarrollando elementos de gamificación. Se transfirieron energía y experiencia de la antigua base de datos. Aún no hemos decidido qué hacer con las medallas y los estados, y trataremos de implementar la funcionalidad de amigos/suscripciones en un futuro cercano.

El curso hacia el renacimiento de Gamer, por supuesto, no puede dejar de agradar, pero ¿a dónde, permítame preguntar, se han ido los pequeños bonificadores que quedaron de los tiempos antiguos: el estado VIP que permitía editar publicaciones sin gastar energía, las medallas que traían una agradable nostalgia, el mensajería con amigos y, en general, la lista de amigos? ¿Dónde está mi administración en el blog "The Witcher 3: Wild Hunt"? ¿Y dónde está mi estado personal de Wiedzminka, obtenido alguna vez al alcanzar el nivel 60? Oh, cierto, ¿y dónde están los niveles mismos? No estoy pidiendo que me devuelvan la bombilla, pero es muy decepcionante perder los elementos de la gamificación por los que era famoso el antiguo Gamer.

Gracias.