administration

Blog du programmeur : que se passe-t-il sous le capot de gamer.ru

content auto translated from {from}

Petit aperçu historique

Le site gamer.ru subit déjà sa troisième (voire même quatrième) réécriture complète de son code. À l'origine, le projet a été écrit en Ruby-on-Rails dans les lointains années 2000. L'architecture était monolithique, donc chaque requête utilisateur entraînait un énorme nombre de requêtes supplémentaires à la base de données et le chargement de toutes les bibliothèques possibles. Pour assurer le bon fonctionnement de la ressource avec 100 000 visiteurs par jour, il a fallu mobiliser pas moins de cinq serveurs puissants, utiliser des memcaches, Redis et répliquer les bases de données sur plusieurs serveurs. Cela a permis de tenir tant bien que mal jusqu'en 2018, jusqu'à ce que l'entreprise connaisse des problèmes financiers et que l'équipe de développeurs se disperse.

Vers 2020, le site a perdu son certificat SSL. Il s'est avéré impossible de le mettre à jour car l'ancienne version de Ruby-on-Rails dépendait d'une ancienne version d'openssl, tandis que les nouveaux certificats nécessitaient une version plus récente. Personne ne s'inquiétait vraiment - le site continuait à fonctionner tant bien que mal. Entre 2015 et 2025, l'affluence a progressivement chuté de 100 000 à 1 000 visiteurs par jour. De nombreux messages de spam, y compris de contenu peu approprié, ont commencé à apparaître dans des blogs cachés et des commentaires. Yandex a complètement perdu tout intérêt pour nous, et dans la Search Console, il y avait un océan rouge d'erreurs critiques.

Ce que nous avons fait pour tout corriger

Le site avait besoin d'une optimisation sérieuse, car l'ancienne architecture ne correspondait plus à la réalité. Dans la base, environ 100 000 publications et 1,6 million de commentaires s'étaient accumulés, qu'il fallait soigneusement transférer vers le nouveau moteur. Nous avons décidé de passer à une architecture microservices tant pour le backend que pour le frontend, en utilisant des technologies modernes, y compris les fameux HTMLElement.

Le projet a été entièrement réécrit à partir de zéro en NodeJS sans utiliser de bibliothèques tierces, ce qui nous garantit une tranquillité d'esprit pour les 10 à 20 prochaines années. Maintenant, nous n'avons plus à craindre qu'une mise à jour d'une bibliothèque tendance comme ExpressJS ou React casse tout le site et nécessite un autre important refactoring. Même l'éditeur visuel des publications a dû être écrit par nos soins, car nous n'avons trouvé rien de prêt qui correspondait à nos modestes demandes. Maintenant, le moteur génère des pages HTML pour les anciens appareils et les moteurs de recherche, et fournit le contenu aux utilisateurs via AJAX.

À ce jour, le site gère avec succès une charge moyenne d'environ 150 requêtes par seconde, dont la majeure partie du trafic est constituée de robots d'indexation et d'autres crawlers. Les robots semrush et openai se comportent particulièrement activement, agissant comme s'ils essayaient de télécharger tout le site en une journée. Si Yandex nous indexe lentement, à raison de 1 à 2 requêtes par seconde, ces compagnons peuvent parfaitement demander 50.

Cependant, le moteur est devenu si optimisé que tout cet armée de bots est facilement gérée par une seule machine virtuelle peu coûteuse, coûtant environ 500 roubles par mois.

Bien entendu, de temps en temps, le site nous rappelle à lui avec des erreurs 502 et 504, qui sont progressivement identifiées et corrigées. Parfois, il s'avère que quelqu'un a oublié d'ajouter un index à la base de données, parfois une requête trop complexe doit être répartie en plusieurs requêtes simples, et parfois il y a tout simplement plus d'espace sur le serveur. Mais nous ne renonçons pas - le travail continue, et le processus, comme on dit, est « sous contrôle ».

post more button

1081

post actions

Commentaires

Oui, l'import dynamique est vraiment une fonctionnalité géniale de JS.
Je n'avais jamais travaillé avec une telle stack auparavant et j'étais habitué à une séparation assez stricte entre le back-end et le front-end, donc une approche plus flexible ne m'est pas évidente.
J'avais rencontré ce concept plutôt comme une notion théorique et je n'avais pas vu de telles solutions dans des projets réels. C'était particulièrement intéressant de le voir en action sur un site réel. Merci !

Oui, quelque chose comme ça ) De plus, cette approche permet d'utiliser des modules avec les mêmes exports à la fois sur le front et sur le back.

Voilà à peu près
let { session, ajax, addViewRoute } = typeof window !== 'undefined'
? await import("../../shared/frontend.js")
: await import("../../shared/backend-server.js")

Cela permet d'utiliser le même code dans le navigateur et sur le serveur. C'est particulièrement utile pour les templates et la définition des routes publiques.

Génial ! Ça me rappelle un peu Dapr de .NET, c'est une solution très intéressante et élégante. Si je comprends bien, la logique métier ne sait pas où se trouve physiquement le module, et le transport est choisi au niveau d'abstraction ? Si c'est le cas, cela signifie qu'une abstraction RPC propriétaire a été mise en place avec un changement entre l'appel local et http ?

un gateway personnalisé, conçu de manière à ce que les microservices puissent Faire partie d'un monolithe ou être exécutés séparément en tant que microservices. C'est-à-dire que n'importe quelle méthode d'API peut être soit laissée à l'intérieur du monolithe, soit extraite indépendamment par quelques lignes de code. Cela permet d'économiser de la mémoire (car elle est limitée, et un processus nécessite environ 200 à 500 Mo de RAM), mais en même temps permet de répartir la charge sur des serveurs supplémentaires. Il existe une fonction universelle ajax(method, path,...), qui appelle des fonctions des modules voisins, si le module voisin appartiennent au même domaine, l'appel de la fonction se fait directement, et s’il se trouve dans un autre - via une requête réseau en passant l'identifiant de session de l'utilisateur... Tout s'est très bien passé, et, par précaution, tout reste pour l'instant dans le monolithe)

Merci pour cette analyse détaillée. Il est particulièrement précieux que non seulement des solutions soient décrites, mais aussi les vraies limitations auxquelles vous avez dû faire face. De telles choses restent souvent dans l'ombre.

Je suis curieux, si ce n'est pas un secret, qu'utilisez-vous actuellement comme API Gateway ? Qu'est-ce qui s'est avéré pratique pour la routage, l'authentification et la limitation de débit dans un schéma microservices ?

Nous avons légèrement simplifié les mécaniques et avons décidé de mettre à jour le moteur dès que possible, même avec des fonctionnalités minimales, car l'ancien moteur avait de nombreux bugs qui nous ont fait bannir des moteurs de recherche et la fréquentation a chuté à zéro. La correspondance a été sauvegardée, la régence apparaîtra un peu plus tard, et nous allons continuer à développer les éléments de gamification. L'énergie et l'expérience ont été transférées de l'ancienne base. Nous n'avons pas encore décidé quoi faire avec les médailles et les statuts, et nous essaierons de mettre en place la fonctionnalité d'amis/abonnements dans un avenir proche.

Le retour du Gamer est bien sûr réjouissant, mais où sont donc passés les petits bonus des temps anciens : le statut VIP, qui permettait d'éditer des posts sans utiliser d'énergie, les médailles qui évoquaient une si agréable nostalgie, la correspondance avec des amis, et en général la liste d'amis ? Où est mon mandat dans le blog "The Witcher 3: Wild Hunt" ? Et où est mon statut personnel de Wiedzminka, obtenu autrefois pour avoir atteint le niveau 60 ? Ah oui, et les niveaux eux-mêmes, où sont-ils ? Je ne demande pas à retrouver l'ampoule, mais il est très frustrant de perdre les éléments de gamification qui faisaient la renommée du précédent Gamer.

Merci.