administration

Ohjelmoijan blogi: mitä gamer.ru:n koneen alla tapahtuu

content auto translated from {from}

Pieni historiallinen katsaus

Sivusto gamer.ru on kokenut jo kolmannen (ja mahdollisesti jopa neljännen) täydellisen koodin uudelleen kirjoittamisen. Alun perin projekti oli kirjoitettu Ruby-on-Rails -alustalla jo kaukaisella 2000-luvulla. Arkkitehtuuri oli monoliittinen, joten jokainen käyttäjätason pyyntö "veti" mukaansa valtavan määrän lisäpyyntöjä tietokantaan ja kaikkien mahdollisten kirjastojen lataamisen. Jotta resurssin toiminta voitaisiin taata 100 000 päivittäisellä kävijämäärällä, oli käytettävä peräti viittä tehokasta palvelinta, käytettävä memcachea, Redis-tekniikkaa ja replikoitava tietokantoja useille palvelimille. Tämä mahdollisti jotenkin selviytymisen vuoteen 2018 asti, jolloin yrityksessä alkoi esiintyä taloudellisia ongelmia ja kehittäjätiimi hajaantui.

Noin vuonna 2020 sivuston SSL-sertifikaatti oli lakkautettu. Sen päivittäminen osoittautui mahdottomaksi, koska vanha Ruby-on-Rails -versio riippui vanhasta openssl-versiosta, kun taas uudet sertifikaatit vaativat uudemman version. Kukaan ei erityisesti välittänyt – sivusto jatkoi huonosti toimimista. Vuosina 2015–2025 kävijämäärä laski vähitellen 100 000:sta 1 000:een henkilöön päivässä. Piiloblogeissa ja kommenteissa alkoi esiintyä valtavia määriä roskapostia, mukaan lukien ei niin kunniallista sisältöä. Yandex menetti täysin kiinnostuksensa meitä kohtaan, ja webmaster-alueella oli pelkkää punaista kriittisten virheiden peittoa.

Mitä teimme kaiken korjaamiseksi

Sivusto tarvitsi vakavaa optimointia, sillä vanha arkkitehtuuri ei enää vastannut todellisuutta. Tietokannassa oli kertynyt noin 100 000 kirjoitusta ja 1,6 miljoonaa kommenttia, jotka oli siirrettävä huolellisesti uuteen moottoriin. Päätimme siirtyä mikro palveluarkkitehtuuriin sekä backendillä että frontendillä, samalla hyödyntäen moderneja teknologioita, mukaan lukien muodikkaat HTMLElementit.

Projekti kirjoitettiin täysin alusta alkaen NodeJS:llä ilman kolmannen osapuolen kirjastoja, mikä takaa meille rauhallisen elämän seuraavat 10–20 vuotta. Nyt ei tarvitse pelätä, että jonkin muodikkaan kirjaston, kuten ExpressJS:n tai Reactin päivitys rikkoo koko sivustoa ja vaatii jälleen laajamittaista refaktorointia. Jopa kirjoitusten visuaalinen editori oli pakko kirjoittaa itse, koska mitään valmista, joka vastaisi vaatimuksiamme, ei löytynyt. Nyt moottori renderoi HTML-sivuja vanhemmille laitteille ja hakukoneille, kun taas käyttäjille toimitetaan sisältö AJAXin kautta.

Tällä hetkellä sivustolla on menestyksekkäästi kestänyt keskimääräinen kuormitus noin 150 pyyntöä sekunnissa, ja suurin osa liikenteestä koostuu hakukrobotsista ja muista crawlereista. Erityisesti boti semrush ja openai käyttäytyvät aktiivisesti, ikään kuin yrittäisivät ladata koko sivuston päivässä. Jos Yandex indeksoi meitä hitaasti, 1-2 pyyntöä sekunnissa, niin nämä kaverit voivat aivan hyvin pyytää jopa 50 pyyntöä.

Kuitenkin moottori on niin optimoitu, että koko tämä bot-armeija pystyy palvelemaan helposti yksi edullinen virtuaalikone, jonka kustannus on noin 500 ruplaa kuukaudessa.

Tietenkin sivusto muistuttaa ajoittain itseään 502- ja 504-virheillä, jotka paljastuvat ja korjataan vähitellen. Joskus tapahtuu, että joku unohti lisätä indeksin tietokantaan, joskus liian monimutkainen pyyntö on pakko jakaa useaksi yksinkertaisemmaksi, ja joskus palvelimella loppuu yksinkertaisesti tila. Mutta emme luovuta – työ jatkuu, ja prosessi, kuten sanotaan, on "kontrollissa".

post more button

1081

post actions

Kommentit

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.