administration

Blog van de programmeur: wat er onder de motorkap van gamer.ru gebeurt

content auto translated from {from}

Kleine historische achtergrond

De site gamer.ru heeft inmiddels al een derde (en misschien zelfs vierde) volledige herschrijving van de code ondergaan. Het project was oorspronkelijk geschreven in Ruby-on-Rails in de verre noughties. De architectuur was monolithisch, waardoor elk gebruikersverzoek een enorme hoeveelheid extra verzoeken naar de database met zich meebracht en alle mogelijke bibliotheken laadde. Om de werking van de site bij 100.000 bezoekers per dag te waarborgen, moesten er maar liefst vijf krachtige servers worden ingezet, memcached en Redis worden gebruikt, en databases over verschillende servers worden gerepliceerd. Dit hielp ons om het vol te houden tot 2018, toen financiële problemen in het bedrijf begonnen en het team van ontwikkelaars uit elkaar ging.

Ongeveer in 2020 viel het SSL-certificaat van de site weg. Het bleek onmogelijk om dit te vernieuwen, omdat de oude versie van Ruby-on-Rails afhankelijk was van een oude versie van OpenSSL, terwijl nieuwe certificaten een nieuwere versie vereisten. Niemand was echt bezorgd - de site bleef min of meer functioneren. In de periode van 2015 tot 2025 daalde het aantal bezoekers geleidelijk van 100.000 tot 1.000 mensen per dag. In verborgen blogs en opmerkingen appeared een enorme hoeveelheid spam, waaronder minder nette inhoud. Yandex verloor volledig zijn interesse in ons, en in de webmaster-interface was er een en al rode muur van kritieke fouten.

Wat we deden om alles te repareren

De site had een serieuze optimalisatie nodig, omdat de oude architectuur niet meer overeenkwam met de realiteit. In de database waren er ongeveer 100.000 berichten en 1,6 miljoen opmerkingen verzameld die voorzichtig naar de nieuwe engine moesten worden overgezet. We besloten om over te stappen op een microservices-architectuur, zowel voor de backend als de frontend, terwijl we moderne technologieën implementeerden, inclusief trendy HTMLElement's.

Het project is volledig vanaf nul herschreven in NodeJS zonder het gebruik van externe bibliotheken, wat ons een rustige levensduur van de komende 10-20 jaar garandeert. Nu hoeven we niet bang te zijn dat de update van een trendy bibliotheek zoals ExpressJS of React de hele site kapotmaakt en een nieuwe grootschalige refactoring vereist. Zelfs de visuele editor voor berichten moesten we zelf schrijven, omdat we niets kant-en-klaars konden vinden dat aan onze bescheiden eisen voldeed. Nu genereert de engine HTML-pagina's voor oude apparaten en zoekmachines, terwijl het gebruikers inhoud via AJAX biedt.

Tegenwoordig kan de site met succes een gemiddelde belasting van ongeveer 150 verzoeken per seconde aan, waarbij het merendeel van het verkeer bestaat uit zoekbots en andere crawlers. Vooral de bots van Semrush en OpenAI gedragen zich actief, alsof ze de hele site in één dag willen downloaden. Terwijl Yandex ons traag indexeert, met een snelheid van 1-2 verzoeken per seconde, kunnen deze gasten gemakkelijk 50 aanvragen doen.

Echter, de engine is zo geoptimaliseerd dat dit hele botleger gemakkelijk wordt bediend door slechts één goedkope virtuele machine die ongeveer 500 roebel per maand kost.

Natuurlijk herinnert de site ons af en toe aan zichzelf met foutmeldingen 502 en 504, die geleidelijk worden ontdekt en opgelost. Soms blijkt dat iemand vergeten is een index in de database toe te voegen, soms moet een te complexe aanvraag worden opgesplitst in verschillende eenvoudige, en soms is er simpelweg geen ruimte meer op de server. Maar we geven niet op - het werk gaat door, en het proces, zoals ze zeggen, ‘is onder controle’.

post more button

1081

post actions

Reacties

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.