administration

Blog lập trình viên: Những gì diễn ra bên trong gamer.ru

content auto translated from {from}

Một chút lịch sử

Trang web gamer.ru đã trải qua đến lần viết lại mã thứ ba (hoặc có thể thậm chí lần thứ tư). Dự án ban đầu được viết trên Ruby-on-Rails từ những năm 2000 xa xôi. Kiến trúc là monolithic, vì vậy mỗi yêu cầu của người dùng 'kéo theo' một số lượng lớn yêu cầu bổ sung tới cơ sở dữ liệu và tải tất cả các thư viện có thể có. Để đảm bảo hoạt động của tài nguyên với 100.000 lượt truy cập mỗi ngày, chúng tôi phải sử dụng đến năm máy chủ mạnh mẽ, sử dụng memcache, Redis và nhân bản cơ sở dữ liệu trên nhiều máy chủ. Điều này đã giúp trang web chống đỡ đến năm 2018, cho đến khi công ty gặp vấn đề tài chính và đội ngũ phát triển phải tan rã.

Khoảng năm 2020, trang web đã bị mất chứng chỉ SSL. Việc cập nhật nó trở nên không thể, vì phiên bản Ruby-on-Rails cũ phụ thuộc vào phiên bản openssl cũ, trong khi các chứng chỉ mới yêu cầu phiên bản mới hơn. Không ai thực sự lo lắng — trang web vẫn hoạt động một cách tạm chấp nhận. Trong khoảng thời gian từ 2015 đến 2025, lưu lượng truy cập đã giảm dần từ 100.000 xuống còn 1.000 người mỗi ngày. Trong các blog và bình luận ẩn hiện một lượng lớn spam, kể cả những nội dung không đứng đắn. Yandex hoàn toàn mất hứng thú với chúng tôi, trong khi trên webmaster chỉ toàn là một bức tranh đỏ rực của các lỗi nghiêm trọng.

Những gì chúng tôi đã làm để khắc phục

Trang web cần được tối ưu hóa nghiêm túc, vì kiến trúc cũ không còn phù hợp với thực tế. Trong cơ sở dữ liệu đã tích lũy khoảng 100.000 bài viết và 1,6 triệu bình luận cần được chuyển giao một cách cẩn thận sang động cơ mới. Chúng tôi quyết định chuyển sang kiến trúc microservices cả ở backend và frontend, đồng thời sử dụng các công nghệ hiện đại, bao gồm cả HTMLElement 'mốt'.

Dự án đã được viết lại hoàn toàn từ đầu trên NodeJS mà không sử dụng thư viện bên thứ ba, điều này đảm bảo cho chúng tôi có một cuộc sống bình yên trong khoảng 10-20 năm tới. Bây giờ không sợ rằng việc cập nhật một thư viện 'mốt' như ExpressJS hoặc React sẽ làm hỏng toàn bộ trang web và yêu cầu phải tiến hành một cuộc tái cấu trúc quy mô lớn khác. Thậm chí, chính chúng tôi đã phải viết một trình biên soạn bài viết, vì không có sản phẩm nào có sẵn đáp ứng được các yêu cầu khiêm tốn của chúng tôi. Giờ đây, động cơ có thể render các trang HTML cho các thiết bị cũ và các công cụ tìm kiếm, trong khi cung cấp nội dung cho người dùng thông qua AJAX.

Hiện tại, trang web có thể duy trì hoạt động dưới tải trung bình khoảng 150 yêu cầu mỗi giây, trong đó phần lớn lưu lượng là từ các bot tìm kiếm và các crawler khác. Đặc biệt, bots như semrush và openai hoạt động rất tích cực, giống như chúng đang cố gắng tải về toàn bộ trang web trong một ngày. Nếu Yandex lập chỉ mục chúng tôi một cách chậm chạp, với tốc độ 1-2 yêu cầu mỗi giây, thì những người bạn này hoàn toàn có thể gửi đến 50 yêu cầu.

Tuy nhiên, động cơ được tối ưu hóa đến mức một máy chủ ảo không đắt giá khoảng 500 rúp mỗi tháng có thể xử lý hết lượng bot này một cách dễ dàng.

Tất nhiên, đôi khi trang web nhắc nhở chúng tôi về sự hiện hữu của nó bằng các lỗi 502 và 504, những lỗi này được phát hiện và xử lý dần dần. Đôi khi phát hiện ra rằng ai đó đã quên thêm chỉ mục vào cơ sở dữ liệu, đôi khi một truy vấn quá phức tạp phải được chia thành nhiều truy vấn đơn giản, và đôi khi đơn giản là chỗ trống trên máy chủ đã hết. Nhưng chúng tôi không bỏ cuộc — công việc vẫn tiếp tục, và như người ta nói, 'mọi thứ vẫn nằm trong tầm kiểm soát.'

post more button

1081

post actions

Bình luận

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.