administration

Blog programisty: co się dzieje pod maską gamer.ru

content auto translated from {from}

Mała historyczna wzmianka

Strona gamer.ru przechodzi już trzecią (a może nawet czwartą) całkowitą przepisanie kodu. Początkowo projekt został napisany w Ruby-on-Rails jeszcze w odległych zerach. Architektura była monolityczna, dlatego każde zapytanie użytkownika „ciągnęło” za sobą ogromną liczbę dodatkowych zapytań do bazy danych i ładowanie wszystkich możliwych bibliotek. Aby zapewnić działanie serwisu przy 100 tysiącach odwiedzających dziennie, trzeba było użyć aż pięciu potężnych serwerów, wykorzystać memcache, Redis oraz replikować bazy danych na kilku serwerach. Dzięki temu udało się jakoś przetrwać do 2018 roku, aż w firmie zaczęły się problemy finansowe i zespół programistów się rozpadł.

Około 2020 roku strona straciła certyfikat SSL. Odnowienie go okazało się niemożliwe, ponieważ stara wersja Ruby-on-Rails była uzależniona od starej wersji openssl, a nowe certyfikaty wymagały nowszej wersji. Nikt szczególnie się tym nie martwił — strona w miarę jakoś działała. W okresie od 2015 do 2025 roku oglądalność stopniowo spadła ze 100 tysięcy do 1 tysiąca osób dziennie. W ukrytych blogach i komentarzach zaczęło pojawiać się ogromne ilości spamu, w tym o nie najlepszej treści. Yandex całkowicie stracił zainteresowanie nami, a w webmasterze pojawiło się mnóstwo krytycznych błędów.

Co zrobiliśmy, aby wszystko naprawić

Strona potrzebowała poważnej optymalizacji, ponieważ stara architektura nie odpowiadała już rzeczywistości. W bazie nagromadziło się około 100 tysięcy postów i 1,6 miliona komentarzy, które trzeba było starannie przenieść na nowy silnik. Podjęliśmy decyzję o przejściu na architekturę mikroserwisową zarówno w backendzie, jak i frontendzie, przy okazji korzystając z nowoczesnych technologii, w tym modnych HTMLElement'ów.

Projekt został całkowicie przepisany od podstaw na NodeJS bez użycia zewnętrznych bibliotek, co gwarantuje nam spokojne życie na najbliższe 10–20 lat. Teraz nie trzeba się bać, że aktualizacja jakiejkolwiek modnej biblioteki jak ExpressJS czy React złamie całą stronę i będzie wymagana kolejna duża refaktoryzacja. Nawet wizualny edytor postów musieliśmy napisać sami, ponieważ nie udało się znaleźć nic gotowego, co odpowiadałoby naszym skromnym wymaganiom. Teraz silnik renderuje strony HTML dla starszych urządzeń i wyszukiwarek, a użytkownikom dostarcza treść przez AJAX.

Obecnie strona skutecznie wytrzymuje średnie obciążenie około 150 zapytań na sekundę, przy czym znaczna część ruchu to boty wyszukiwarek i inne crawler. Szczególnie aktywne są boty semrush i openai, które zachowują się tak, jakby próbowały pobrać całą stronę w jeden dzień. Jeśli Yandex indeksuje nas powoli, w tempie 1-2 zapytań na sekundę, to ci koledzy mogą wysłać nawet 50.

Jednak silnik okazał się tak zoptymalizowany, że całą tę armię botów łatwo obsługuje jedna niedroga wirtualka kosztująca około 500 rubli miesięcznie.

Oczywiście od czasu do czasu strona przypomina nam o sobie błędami 502 i 504, które są stopniowo wykrywane i usuwane. Czasami okazuje się, że ktoś zapomniał dodać indeks do bazy danych, czasami zbyt złożone zapytanie trzeba rozbić na kilka prostych, a czasem po prostu kończy się miejsce na serwerze. Ale nie poddajemy się — praca trwa, a proces, jak to się mówi, „jest pod kontrolą”.

post more button

1081

post actions

Komentarze

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.