administration

Blogul programatorului: ce se întâmplă sub capota gamer.ru

content auto translated from {from}

O scurtă informație istorică

Site-ul gamer.ru a trecut deja prin a treia (sau poate chiar a patra) rescriere completă a codului. La început, proiectul a fost scris în Ruby-on-Rails încă din anii 2000. Arhitectura era monolitică, așa că fiecare solicitare a utilizatorului „trăgea” după ea un număr uriaș de solicitări suplimentare către baza de date și încărca toate bibliotecile posibile. Pentru a asigura funcționarea resursei cu 100 de mii de vizitatori pe zi, a fost necesar să se folosească cinci servere puternice, să se utilizeze memcached, Redis și să se replici baze de date pe mai multe servere. Aceasta a permis cumva să ne menținem până în 2018, când compania a început să aibă probleme financiare și echipa de dezvoltatori s-a dispersat.

Aproximativ în 2020, site-ul a pierdut certificatul SSL. A fost imposibil să-l actualizăm, deoarece vechea versiune de Ruby-on-Rails depindea de o versiune veche de openssl, iar noile certificate necesitau o versiune mai nouă. Nimeni nu s-a îngrijorat prea mult - site-ul a continuat să funcționeze oarecum. În perioada 2015-2025, vizitările au scăzut treptat de la 100 de mii la 1 mie de oameni pe zi. În blogurile și comentariile ascunse au început să apară o mulțime de spam, inclusiv de conținut nu tocmai decent. Yandex a pierdut complet interesul față de noi, iar în webmastern a fost un întreg panou roșu de erori critice.

Ce am făcut pentru a remedia totul

Site-ul avea nevoie urgentă de optimizare, deoarece vechea arhitectură nu mai corespundea realităților. În bază s-au acumulat aproximativ 100 de mii de postări și 1,6 milioane de comentarii, care trebuiau transferate cu atenție pe un nou motor. Am decis să trecem la o arhitectură microservicii atât pe backend, cât și pe frontend, implicând tehnologii moderne, inclusiv popularele HTMLElement-uri.

Proiectul a fost rescris complet de la zero pe NodeJS fără utilizarea bibliotecilor externe, ceea ce ne garantează o viață liniștită pentru următorii 10-20 de ani. Acum nu ne mai este teamă că actualizarea unei biblioteci populare, cum ar fi ExpressJS sau React, va strica întregul site și va necesita o refactorizare masivă. Chiar și editorul vizual pentru postări a trebuit să fie scris de la zero, deoarece nu am găsit nimic gata care să corespundă cerințelor noastre modeste. Acum motorul generează pagini HTML pentru dispozitivele vechi și motoarele de căutare, iar utilizatorilor le livrează conținut prin AJAX.

În prezent, site-ul suportă cu succes o încărcătură medie de aproximativ 150 de solicitări pe secundă, din care o mare parte din trafic provine din roboți de căutare și alte crawler-e. Roboții semrush și openai se comportă deosebit de activ, comportându-se ca și cum ar încerca să descarce întregul site într-o singură zi. Dacă Yandex ne indexează lent, cu o viteză de 1-2 solicitări pe secundă, acești colegi pot solicita și 50.

Cu toate acestea, motorul a fost atât de optimizat încât întreaga această armată de roboți este ușor gestionată de un singur server virtual ieftin, costând aproximativ 500 de ruble pe lună.

Desigur, periodic site-ul ne amintește de existența sa prin erori 502 și 504, care sunt identificate și corectate treptat. Uneori se dovedește că cineva a uitat să adauge un index în baza de date, alteori o solicitare prea complexă trebuie împărțită în mai multe solicitări simple, iar uneori, pur și simplu se termină spațiul pe server. Dar nu ne dăm bătuți - munca continuă, iar procesul, așa cum se spune, este „sub control”.

post more button

1081

post actions

Comentarii

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.