Comment nous faisons Sportmaster

Bonjour à tous! Je suis sûr que beaucoup d'entre vous ont déjà acheté un T-shirt, un ballon, des baskets, ou tout autre équipement de sport dans nos magasins, mais peu savent ce qu'est le Sportmaster d'un point de vue technique.


Un peu de Sportmaster 2003 de web.archive.org

Je m'appelle Dmitry, je suis un développeur Java senior chez Sportmaster, et aujourd'hui je voudrais parler de notre boutique en ligne, de la voie qu'il est devenue pour devenir votre façon de le connaître maintenant: comment nous avons commencé, comment nous avons développé ce qui s'est passé et ce qui ne s'est pas passé, des problèmes d'aujourd'hui et des plans pour l'avenir. Intéressant? Bienvenue au chat!

L'histoire de la présence de notre entreprise sur le web a déjà commencé en 1999 avec le premier site du Sportmaster, qui n'était qu'une carte de visite et un catalogue de marchandises pour les acheteurs en gros. En fait, la boutique en ligne de l'entreprise a son histoire depuis 2001. À cette époque, la société ne disposait pas de sa propre équipe pour développer des projets en ligne, et la boutique en ligne a réussi à changer plusieurs plates-formes self-made (maintenant, nous ne nous souvenons même pas du nombre). La première solution relativement stable pour nous a été créée par le prochain intégrateur en 2011 en PHP, basée sur CMS 1C Bitrix. Le site s'est avéré être simple, en fait, la fonctionnalité en boîte Bitrix a été utilisée, avec de petites personnalisations pour passer une commande. Pour le matériel, la configuration de démarrage comprenait 2 serveurs d'applications et un serveur de base de données.

Entre-temps, la société a commencé à développer activement ses propres compétences dans le domaine de la vente en ligne, principalement du côté de l'entreprise, qui, je dois le dire, a progressé assez rapidement, et l'équipe de développement a été contrainte de se développer rapidement dans tous les sens afin de répondre à ses besoins. En moins d'un an, trois équipes ont immédiatement commencé à répondre du développement et du support du site - l'intégrateur lui-même, l'équipe interne du Sportmaster, qui n'était alors composée que de quelques personnes, et d'un autre entrepreneur - son apparition, en fait, était due au fait que l'intégrateur à ce moment, je ne pouvais pas fournir les capacités dont nous avions besoin pour les gens.

Quels problèmes avions-nous à ce moment-là? Il y avait de nombreux problèmes, mais le plus important est le fonctionnement instable de notre boutique en ligne.

Nous pourrions même tomber du fait que l'entreprise a réalisé une sorte de newsletter, après quoi ~ 2000-2500 personnes sont venues sur le site, ou, si je me souviens bien, une bannière publicitaire sur Yandex nous a plongés. Bien sûr, de telles choses sont inacceptables, car ce n'est pas seulement une perte de profits, mais aussi l'image de l'entreprise - en général, nous avons compris que quelque chose devait être changé. Tout d'abord, il a été réalisé que les solutions standard avec nos charges de travail (à l'époque pas très grandes, mais toujours pas petites) ne fonctionneraient pas. Nous avons ensuite eu environ 1000 visiteurs en ligne normalement, environ 2500 au plus fort, plus des plans de développement x2 par an.

Intensification immédiate en termes de matériel: nous avons ajouté 2 serveurs d'applications supplémentaires et créé un cluster de 2 serveurs de bases de données. Notre pile à cette époque était nginx, MySQL, PHP. En parallèle, nous avons essayé d'optimiser la solution actuelle - nous avons cherché des goulots d'étranglement, essayé de réécrire tout ce qui était possible. Notre goulot d'étranglement étant la base, il a toujours été le premier à «mourir», nous avons décidé de le décharger au maximum. Sphinx implémenté pour la recherche en plein texte et la sortie de tuiles de produits avec des facettes par les filtres sélectionnés et les caches connectés. Et voila - ces charges qui se sont avérées fatales pour nous hier, nous avons commencé à tenir avec facilité.

Parallèlement, un pilote a été lancé en parallèle, dans le cadre duquel ils souhaitaient réaliser une mise à jour technologique du site - un transfert vers une plateforme fondamentalement différente. Il y avait beaucoup d'idées et d'idées - à cette époque, la personnalisation de tout et de tout, des recommandations personnelles, des envois postaux, des remises et d'autres choses utiles gagnait en popularité, et nous voulions bien sûr également utiliser tout cela. Nous avons regardé ce qui était disponible sur le marché à partir de cela, eh bien, et avons acheté la plate-forme la plus chère sur le principe "Une fois de plus cher, puis plus cool." La mise en œuvre a été planifiée avec l'aide d'un intégrateur, et nous avions toujours le support et le développement de l'ancienne IM conditionnelle jusqu'à ce que la nouvelle soit mise en service sur la nouvelle plate-forme.

Mais comme la vitesse de développement fonctionnel du site actuel était très élevée, nous avons décidé de commencer la mise en œuvre de la nouvelle plate-forme de commerce électronique à partir de la boutique en ligne plus petite et plus simple de l'époque de la chaîne de magasins Austin, qui était également desservie par l'équipe IT Sportmaster. Au cours du processus, nous avons réalisé que la chose était lourde et fonctionnellement sophistiquée, mais technologiquement obsolète, et trouver des personnes pour la mettre en œuvre pleinement s'est avéré être un énorme problème. De plus, le dimensionnement effectué avant le début du projet a réduit considérablement les besoins en matériel et le nombre de licences - la durée de vie s'est avérée beaucoup plus cruelle. En général, nous avons compris une chose: nous ne ferons pas de Sportmaster dessus. Et comme l'équipe de migration vers la plateforme était déjà en cours de recrutement, les gars ont décidé de commencer à prototyper leur propre solution, en fonction des exigences fixées par l'entreprise pour la nouvelle plateforme.

La pile technologique a été sélectionnée comme suit: Java, Spring, Tomcat, ElasticSearch, Hazelcast.

Par conséquent, à la fin de 2014, nous avions une nouvelle version de la messagerie instantanée prête, entièrement auto-écrite, vers laquelle nous sommes passés avec succès. C'est la première version du site que vous voyez aujourd'hui. Naturellement, la version actuelle est beaucoup plus fonctionnelle et technologique, mais la plate-forme de base est la même.

Tâches principales

Bien sûr, lorsque nous parlons d'une grande boutique en ligne, nous parlons de la volonté de faire face non seulement aux charges quotidiennes, mais également aux pics de charge - pour être stable pour les entreprises et les utilisateurs finaux.

Les principales approches ici sont la capacité à évoluer horizontalement et l'application d'approches de mise en cache des données à différents niveaux. Et maintenant, comme il y a quelque temps, nous avons décidé d'optimiser l'accès à nos données. Mais nous ne pouvons pas utiliser la mise en cache de page régulière. Généralement. Il s'agit d'une exigence commerciale et l'exigence est tout à fait raisonnable - si vous montrez le mauvais prix ou la mauvaise disponibilité des marchandises à un moment donné à l'utilisateur du site, cela entraînera très probablement un rejet de l'achat et une diminution de la fidélité des clients.

Et ce n'est pas grave si le client a commandé 15 paires de chaussettes pour 299 roubles, et dans le magasin, il a découvert qu'il n'y avait en fait que 14 paires et 300 roubles chacune - vous pouvez en quelque sorte vivre avec. Acceptez, achetez ce qui est et vivez avec cette cicatrice dans votre âme. Mais si les écarts de chiffres sont sérieux, ou si vous recherchiez une taille spécifique - et qu'elle a été achetée pendant que vous lisiez les avis des heureux propriétaires de shorts à carreaux, ici tout est déjà plus triste. C'est-à-dire immédiatement la perte d'un client satisfait (jusqu'à ce point) et la perte de temps et d'argent sur le travail du centre d'appels, où ce client appellera pour savoir ce qui s'est passé et pourquoi.

Par conséquent, l'utilisateur doit toujours voir le dernier prix et les données les plus récentes sur les soldes des matières premières, et donc nos caches sont intelligents et savent quand les données de la base de données changent. Pour la mise en cache, nous utilisons Hazelcast.

Au fait, à propos des restes

Il est important de noter ici que la profondeur des résidus de produits est très faible. Et un très grand nombre de commandes sont prises en charge (très). Par conséquent, le client doit normalement réserver les marchandises dans le bon magasin et suivre les soldes. À une époque, sur Bitrix, le problème des résidus a été résolu par le fait qu'ils considéraient simplement les restes de plus de 10 unités comme infinis. Autrement dit, tout ce qui est supérieur à 10 est toujours égal à 10, mais les valeurs inférieures sont déjà intéressantes pour nous à calculer et nous les prenons en compte, les téléchargeons sur le site.

Maintenant, il n'est plus possible de le faire, nous téléchargeons donc les restes de tous les magasins toutes les 15 minutes. Et nous avons environ 500 magasins, plus un certain nombre d'entrepôts régionaux, ainsi que plusieurs chaînes de magasins. Et tout cela doit être mis à jour rapidement. La cerise sur le gâteau est le fait que les conditions de travail des entreprises de messagerie changent très souvent à l'échelle de la Fédération de Russie, par conséquent, les paramètres de livraison doivent également être chargés. En outre, un flux continu de marchandises est livré aux entrepôts de l'entreprise, c'est pourquoi la quantité de marchandises dans les entrepôts devrait changer. Donc, il doit également être retiré à nouveau.

Et voici comment les identifiants des articles de base (SKU) sont formés. Nous avons environ 40 000 modèles de produits, appelés couleurs. Si nous allons plus loin dans la taille des marchandises, nous obtenons environ 200 000 SKU. Et pour tout cela, 200 000 doivent être mis à jour à l'échelle de 500 magasins.

Nous avons également des dizaines de milliers de villes et villages dans lesquels nous livrons des marchandises dans des magasins ou des entrepôts. Par conséquent, il s'avère que la variabilité du cache pour une seule page de produit (ville * SKU) est un millionième de valeur. Notre approche est la suivante: le calcul de la disponibilité d'une unité de marchandise particulière se fait à la volée lorsque l'utilisateur entre la carte du produit. Nous regardons le travail des coursiers dans la région de l'utilisateur, nous regardons leur horaire de travail, nous calculons la chaîne de livraison et considérons sa durée. Parallèlement à cela, les restes dans les magasins à proximité sont analysés en parallèle, à partir desquels le transport peut être organisé.

Pour faciliter la gestion de tout cela, nous avons un certain nombre de caches très rapides dans l'application - grâce à cela, nous pouvons rapidement obtenir toutes les données nécessaires par ID et les trier à la volée. La même chose avec les courriers - nous les regroupons en clusters, puis les clusters sont déjà enregistrés dans la base de données. Toutes les 15 minutes, tout cela est mis à jour, pour chaque demande entrante, nous calculons un certain groupe de courriers avec les paramètres nécessaires, les agrégons et les remettons rapidement à l'acheteur - tout va bien, nous avons définitivement de tels shorts verts de taille 50, vous pouvez soit ramasser avec des stylos dans ces trois magasins à proximité en ce moment, ou commander dans un magasin de l'autre côté de la route (ou même à la maison) pendant 3 jours, choisissez.

Pour Moscou, cette situation peut sembler inutile, mais pour les régions, c'est une question complètement différente, ils commandent très souvent des marchandises à certains magasins (auxquels vous devez peut-être également vous rendre spécialement).

Les chiffres

Désormais, le site reçoit des milliers de demandes par seconde, en tenant compte de la statique et de 500 à 1 000 demandes par seconde aux serveurs d'applications. Le nombre de serveurs d'applications n'a pas changé, mais leur configuration a considérablement augmenté. Une moyenne d'environ 3 000 000 de vues par jour est obtenue.

Des DDoS se trouvent parfois sur le site. En même temps, ils frappent avec des botnets, d'ailleurs, nos proches de la Fédération de Russie. Il y a longtemps, il y a eu des cas de tentatives de frapper des botnets du Mexique et de Taïwan, mais maintenant ce n'est plus le cas.

Il existe un certain nombre de solutions pour la protection du cloud contre les DDoS sur le marché, oui, et assez bonnes. Mais pour certaines politiques de sécurité, nous ne pouvons pas utiliser ce type de solutions cloud.

Et maintenant

Nous commençons à faire une solution de plate-forme, en séparant les équipes non pas verticalement (certains d'entre eux ont vu un site, et le second en a vu un autre), mais horizontalement, mettant en évidence la couche de plate-forme commune, la divisant en parties, formant une équipe autour d'elle. Et sur eux, nous fermons déjà le site et pas seulement, y compris les clients de l'entreprise, à la fois externes et internes. Par conséquent, nous avons beaucoup de travail complexe et intéressant.

La pile à l'avant, pour des raisons évidentes, n'a pas vraiment changé pendant cette période - Java, Spring, Tomcat, ElasticSearch, Hazelcast sont toujours bons pour nos besoins. Une autre chose est que maintenant beaucoup de systèmes de back-office sur diverses technologies sont cachés derrière le site. Et, bien sûr, la réingénierie est en cours (car les demandes de systèmes internes et de travail avec eux dans leur ensemble doivent être optimisées, sans oublier les exigences métier et les nouvelles fonctions métier).

Et vous pouvez en toute sécurité me faire part de vos suggestions personnelles (ou de commentaires) sur l'amélioration du site - à la fois en termes de nouvelles fonctionnalités, et du composant visuel et de l'expérience utilisateur globale. Nous allons essayer de répondre rapidement et de tout prendre en compte. Et si vous voulez faire partie de l'équipe et tout voir de l'intérieur - bienvenue .