administration

Блог программіста: що відбувається під капотом gamer.ru

content auto translated from {from}

Невеличка історична довідка

Сайт gamer.ru переживає вже третє (а можливо, навіть четверте) повне переписування коду. Спочатку проєкт був написаний на Ruby-on-Rails ще в далеких нульових. Архітектура була монолітною, тому кожен користувацький запит «тягнув» за собою величезну кількість додаткових запитів до бази даних і завантаження всіх можливих бібліотек. Щоб забезпечити роботу ресурсу при 100 тисячах відвідувачів на добу, довелося задіяти цілих п’ять потужних серверів, використовувати мемкеші, Redis і реплікувати бази даних по кількох серверах. Це дозволило хоч якось протриматися до 2018 року, поки в компанії не почалися фінансові проблеми і команда розробників не розбіглася.

Приблизно в 2020 році у сайту відвалився SSL-сертифікат. Оновити його виявилося неможливо, оскільки стара версія Ruby-on-Rails залежала від старої версії openssl, а нові сертифікати вимагали більш свіжої версії. Ніхто особливо не переживав — сайт продовжував погано-багато працювати. У період з 2015 по 2025 роки відвідуваність поступово впала зі 100 тисяч до 1 тисячі людей на добу. У прихованих блогах і коментарях з’явилася величезна кількість спаму, в тому числі не самого пристойного змісту. Яндекс повністю втратив до нас інтерес, а в вебмайстрі було суцільне червоне полотно критичних помилок.

Що ми зробили, щоб все виправити

Сайт потребував серйозної оптимізації, оскільки стара архітектура більше не відповідала реаліям. У базі накопичилося близько 100 тисяч постів і 1,6 млн коментарів, які потрібно було акуратно перенести на новий движок. Ми прийняли рішення перейти на мікросервісну архітектуру як на бекенді, так і на фронтенді, попутно задіявши сучасні технології, включаючи модні HTMLElement'и.

Проєкт було повністю переписано з нуля на NodeJS без використання сторонніх бібліотек, що гарантує нам спокійну життя на найближчі 10–20 років. Тепер можна не боятися, що оновлення якоїсь модної бібліотеки, як-от ExpressJS або React, зламає весь сайт і вимагатиме чергового масштабного рефакторингу. Навіть візуальний редактор постів довелося написати самостійно, оскільки нічого готового, що відповідало б нашим скромним запитам, знайти не вдалося. Тепер движок рендерить HTML-сторінки для старих пристроїв і пошуковиків, а користувачам віддає контент через AJAX.

На сьогоднішній день сайт успішно витримує середню навантаження приблизно 150 запитів на секунду, причому левову частку трафіку складають пошукові боти та інші краулери. Особливо активно ведуть себе боти semrush і openai, які ведуть себе так, ніби намагаються вивантажити собі весь сайт за день. Якщо Яндекс індексує нас неспішно, зі швидкістю 1-2 запити на секунду, то ці товари можуть запитати і 50.

Однак движок виявився настільки оптимізованим, що всю цю бот-армію легко обслуговує всього одна недорога віртуалка вартістю близько 500 рублів на місяць.

Звичайно, періодично сайт нагадує нам про себе помилками 502 і 504, які поступово виявляються і усуваються. Іноді виявляється, що хтось забув додати індекс у базу даних, іноді занадто складний запит доводиться розбивати на кілька простих, а іноді банально закінчується місце на сервері. Але ми не здаємось — робота триває, а процес, як кажуть, «під контролем».

post more button

1081

post actions

Коментарі

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.