administration

Blog eines Programmierers: Was passiert unter der Haube von gamer.ru

content auto translated from {from}

Ein kleiner historischer Überblick

Die Website gamer.ru hat bereits ihre dritte (und möglicherweise sogar vierte) vollständige Code-Neuschreibung erlebt. Ursprünglich wurde das Projekt in den frühen 2000er Jahren auf Ruby-on-Rails entwickelt. Die Architektur war monolithisch, sodass jede Benutzeranfrage eine enorme Menge zusätzlicher Datenbankanfragen und das Laden aller möglichen Bibliotheken nach sich zog. Um den Betrieb der Ressource bei 100.000 Besuchern pro Tag zu gewährleisten, mussten ganze fünf leistungsstarke Server eingesetzt, Memcached, Redis und die Datenbanken auf mehrere Server repliziert werden. Dies ermöglichte es, bis zum Jahr 2018 durchzuhalten, bis das Unternehmen in finanzielle Schwierigkeiten geriet und das Entwicklerteam auseinanderbrach.

Etwa im Jahr 2020 fiel das SSL-Zertifikat der Website aus. Es stellte sich als unmöglich heraus, es zu aktualisieren, da die alte Version von Ruby-on-Rails von einer alten Version von OpenSSL abhing, während neue Zertifikate eine neuere Version erforderten. Niemand machte sich große Sorgen — die Website funktionierte mehr schlecht als recht weiter. Im Zeitraum von 2015 bis 2025 sank die Besuchszahl allmählich von 100.000 auf 1.000 Personen pro Tag. In versteckten Blogs und Kommentaren tauchte eine enorme Menge Spam auf, darunter auch nicht sehr anständige Inhalte. Yandex verlor vollständig das Interesse an uns, und im Webmaster-Tool herrschte ein rotes Feld kritischer Fehler.

Was wir getan haben, um alles zu reparieren

Die Website benötigte eine ernsthafte Optimierung, da die alte Architektur nicht mehr den Realitäten entsprach. In der Datenbank hatten sich etwa 100.000 Posts und 1,6 Millionen Kommentare angesammelt, die sorgfältig auf die neue Engine übertragen werden mussten. Wir beschlossen, auf eine Mikroservice-Architektur sowohl im Backend als auch im Frontend umzusteigen und gleichzeitig moderne Technologien zu nutzen, einschließlich angesagter HTMLElemente.

Das Projekt wurde vollständig von Grund auf neu in NodeJS ohne Verwendung von Drittanbieterbibliotheken neu geschrieben, was uns ein ruhiges Leben für die nächsten 10 bis 20 Jahre garantiert. Jetzt können wir uns keine Sorgen mehr machen, dass ein Update einer trendigen Bibliothek wie ExpressJS oder React die gesamte Website kaputt macht und eine erneute umfassende Überarbeitung erfordert. Sogar der visuelle Editor für Posts musste selbst entwickelt werden, da es nichts Fertiges gab, das unseren bescheidenen Anforderungen entsprach. Jetzt rendert die Engine HTML-Seiten für alte Geräte und Suchmaschinen und liefert den Benutzern Inhalte über AJAX.

Heute hält die Website erfolgreich eine durchschnittliche Last von etwa 150 Anfragen pro Sekunde aus, wobei der Löwenanteil des Traffics von Suchrobotern und anderen Crawlern stammt. Besonders aktiv sind die Bots von semrush und openai, die sich so verhalten, als wollten sie die gesamte Website an einem Tag abrufen. Wenn Yandex uns gemächlich mit einer Geschwindigkeit von 1-2 Anfragen pro Sekunde indiziert, können diese Kollegen durchaus auch 50 Anfragen stellen.

Die Engine ist jedoch so optimiert, dass diese gesamte Bot-Armee problemlos von einer einzigen, kostengünstigen virtuellen Maschine mit Kosten von etwa 500 Rubel pro Monat bedient werden kann.

Natürlich erinnert uns die Website hin und wieder durch Fehler 502 und 504 an sich, die schrittweise identifiziert und behoben werden. Manchmal stellt sich heraus, dass jemand vergessen hat, einen Index in der Datenbank hinzuzufügen, manchmal muss eine zu komplexe Anfrage in mehrere einfache aufgeteilt werden, und manchmal ist einfach der Speicherplatz auf dem Server erschöpft. Aber wir geben nicht auf — die Arbeit geht weiter, und der Prozess steht, wie gesagt, "unter Kontrolle".

post more button

1081

post actions

Kommentare

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.