administration

Blog dello sviluppatore: cosa succede dietro le quinte di gamer.ru

content auto translated from {from}

Piccola nota storica

Il sito gamer.ru sta attraversando già la terza (e forse anche la quarta) completa riscrittura del codice. Inizialmente, il progetto è stato scritto in Ruby-on-Rails nei lontani anni 2000. L'architettura era monolitica, quindi ogni richiesta degli utenti comportava un'enorme quantità di richieste aggiuntive al database e il caricamento di tutte le possibili librerie. Per garantire il funzionamento del sito con 100.000 visitatori al giorno, è stato necessario impiegare ben cinque server potenti, utilizzare memcached, Redis e replicare i database su più server. Questo ha permesso di resistere fino al 2018, quando l'azienda ha iniziato ad avere problemi finanziari e il team di sviluppatori si è disperso.

Circa nel 2020 il sito ha perso il certificato SSL. Aggiornarlo si è rivelato impossibile, poiché la vecchia versione di Ruby-on-Rails dipendeva dalla vecchia versione di openssl, mentre i nuovi certificati richiedevano una versione più recente. Nessuno si è particolarmente preoccupato: il sito è continuato a funzionare, più o meno. Nel periodo dal 2015 al 2025, il traffico è gradualmente diminuito da 100.000 a 1.000 visitatori al giorno. Nei blog e nei commenti nascosti è iniziato a comparire un'enorme quantità di spam, compreso quello di contenuto non proprio decoroso. Yandex ha completamente perso interesse per noi e nella console webmaster c'era un mare di errori critici rossi.

Cosa abbiamo fatto per sistemare tutto

Il sito aveva bisogno di una seria ottimizzazione, poiché la vecchia architettura non era più in linea con la realtà. Si erano accumulati circa 100.000 post e 1,6 milioni di commenti, che dovevano essere trasferiti con attenzione sul nuovo motore. Abbiamo deciso di passare a un'architettura a microservizi sia per il backend che per il frontend, utilizzando tecnologie moderne, comprese le popolari HTMLElement.

Il progetto è stato completamente riscritto da zero in NodeJS senza l'uso di librerie di terze parti, il che ci garantisce una vita tranquilla nei prossimi 10-20 anni. Ora non c'è bisogno di temere che un aggiornamento di qualche libreria alla moda come ExpressJS o React rompa l'intero sito e richieda un'altra massiccia ristrutturazione. Anche l'editor visivo dei post è stato scritto da noi, poiché non siamo riusciti a trovare nulla di pronto che soddisfacesse le nostre modeste richieste. Ora il motore renderizza pagine HTML per vecchi dispositivi e motori di ricerca, mentre agli utenti offre contenuti tramite AJAX.

Attualmente, il sito gestisce con successo un carico medio di circa 150 richieste al secondo, e la maggior parte del traffico è costituita da bot di ricerca e altri crawler. I bot di semrush e openai, in particolare, si comportano come se cercassero di scaricare l'intero sito in un giorno. Se Yandex ci indicizza lentamente, con una velocità di 1-2 richieste al secondo, questi soggetti possono effettuare fino a 50 richieste.

Tuttavia, il motore è risultato così ottimizzato che tutta questa armata di bot può essere facilmente gestita da una sola macchina virtuale economica, che costa circa 500 rubli al mese.

Naturalmente, di tanto in tanto il sito ci ricorda la sua presenza con errori 502 e 504, che vengono man mano identificati e risolti. A volte si scopre che qualcuno ha dimenticato di aggiungere un indice al database, a volte una query troppo complessa deve essere suddivisa in più semplici, e a volte semplicemente lo spazio sul server finisce. Ma non ci arrendiamo: il lavoro continua e il processo, come si suol dire, è "sotto controllo".

post more button

1081

post actions

Commenti

Yeah, dynamic import is definitely a cool feature of JS.
I hadn't worked with such a stack before and I was used to a pretty strict separation between back-end and front-end, so a more flexible approach is not obvious to me.
I had encountered this more as a theoretical concept and had not seen such solutions in real projects. It was especially interesting to see this in action on a real website. Thank you!

Yes, something like that ) This approach also allows using modules with the same exports on both the front and back ends.

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

This allows you to use the same code in both the browser and the server. It is especially useful for templates and defining public routes.

Cool! It somewhat reminds me of Dapr from .NET, a very interesting and elegant solution. Am I correct in understanding that the business logic does not know where the module is physically located, and the transport is chosen at the abstraction level? If so, it turns out a custom RPC abstraction has been implemented with switching between local calls and http?

a self-written gateway, made in such a way that microservices can either be part of a monolith or can be run as standalone microservices. That is, any API method can either remain within the monolith or be extracted separately with a couple of lines of code. This helps save memory (since it is limited, and one process requires about 200-500 MB of RAM), but at the same time, allows for distributing the load across additional servers. There is a universal function ajax(method, path,...), which calls functions from neighboring modules; if the neighboring module is in the same domain, the function is called directly, and if in another, it is done through a network request with the user's session identifier being passed through... Everything turned out very well, and, just to be safe, for now, everything is still hanging in the monolith.)

Thank you for the detailed analysis. It is especially valuable that not only the solutions are described, but also the real limitations that had to be faced. Such things usually remain behind the scenes.

I am curious, if it's not a secret, what are you currently using as an API Gateway? What has proven convenient for routing, auth, and rate-limit in a microservices architecture?

We simplified the mechanics a bit, and it was decided to update the engine as soon as possible, albeit with minimal functionality, since the old engine had a lot of bugs that got us banned from search engines, causing our traffic to drop to zero. The correspondence has been saved, the governance will appear a bit later, and we will further develop gamification elements. Energy and experience were transferred from the old database. We have not yet decided what to do with the medals and statuses, and we will try to implement the friends/subscriptions functionality in the near future.

The course towards the revival of Gamer, of course, cannot fail to please, but where, may I ask, have the remaining little bonuses from the old times gone: the VIP status that allowed editing posts without spending energy, the medals that brought such pleasant nostalgia, messaging with friends, and the overall friends list? Where is my stewardship on the blog "The Witcher 3: Wild Hunt"? And where is my personal Wiedzminka status, once earned by reaching level 60? Oh right, and where are the levels themselves? I am not asking for the light bulb back, but it is very disappointing to lose the elements of gamification that the old Gamer was famous for.

Thank you.