administration

وبلاگ برنامه‌نویس: چه اتفاقی در زیر کاپوت gamer.ru می‌افتد

content auto translated from {from}

یک مروری تاریخی کوتاه

وب‌سایت gamer.ru در حال حاضر در حال تجربه سومین (و شاید حتی چهارمین) بازنویسی کامل کد است. این پروژه در ابتدا با Ruby-on-Rails در دهه 2000 نوشته شده بود. معماری این سیستم مونوگرافیک بود، بنابراین هر درخواست کاربر «عملیات» بسیار زیادی را به همراه داشت که شامل درخواست‌های اضافی به پایگاه داده و بارگذاری تمام کتابخانه‌های ممکن بود. برای تأمین نیازهای 100 هزار بازدیدکننده روزانه، مجبور شدیم از پنج سرور قدرتمند استفاده کنیم، از memcache، 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.