Wie wir Sportmaster machen

Hallo allerseits! Ich bin sicher, dass viele von Ihnen jemals ein T-Shirt, einen Ball, Turnschuhe oder andere Sportgeräte in unseren Läden gekauft haben, aber nur wenige wissen, was Sportmaster aus technischer Sicht ist.


Ein bisschen Sportmaster 2003 von web.archive.org

Mein Name ist Dmitry, ich bin ein leitender Java-Entwickler bei Sportmaster, und heute möchte ich über unseren Online-Shop sprechen, darüber, welchen Weg er gegangen ist, wie Sie ihn jetzt kennen: wie wir angefangen haben, wie wir uns entwickelt haben Was ist passiert und was nicht, über die Probleme heute und über Pläne für die Zukunft. Interessant? Willkommen bei Katze!

Die Geschichte der Präsenz unseres Unternehmens im Internet begann bereits 1999 mit der ersten Website des Sportmaster, bei der es sich lediglich um eine Visitenkarte und einen Warenkatalog für Großhandelskäufer handelte. Eigentlich hat der Online-Shop des Unternehmens seine Geschichte seit 2001. Damals hatte das Unternehmen kein eigenes Team für die Entwicklung von Online-Projekten, und der Online-Shop konnte mehrere selbst erstellte Plattformen ändern (jetzt können wir uns nicht einmal mehr daran erinnern, wie viele). Die erste für uns relativ stabile Lösung wurde 2011 vom nächsten Integrator in PHP auf Basis von CMS 1C Bitrix erstellt. Die Website erwies sich als einfach. Tatsächlich wurde die Bitrix-Box-Funktionalität verwendet, mit kleinen Anpassungen, um eine Bestellung aufzugeben. Für die Hardware umfasste die Startkonfiguration 2 Anwendungsserver und einen Datenbankserver.

In der Zwischenzeit begann das Unternehmen, seine eigenen Kompetenzen im Bereich des Online-Vertriebs aktiv aufzubauen, vor allem auf der Seite des Geschäfts, was sich, wie ich sagen muss, ziemlich schnell entwickelte, und das Entwicklungsteam war gezwungen, in jeder Hinsicht schnell zu wachsen, um seine Bedürfnisse zu erfüllen. In weniger als einem Jahr begannen drei Teams sofort, sich für die Entwicklung und Unterstützung der Site zu verantworten - der Integrator selbst, das interne Team des Sportmasters, das zu dieser Zeit nur aus wenigen Personen bestand, und ein anderer Auftragnehmer - sein Erscheinungsbild war in der Tat auf die Tatsache zurückzuführen, dass der Integrator In diesem Moment konnte ich nicht die Kapazitäten bereitstellen, die wir für die Menschen brauchten.

Welche Probleme hatten wir damals? Es gab viele Probleme, aber das wichtigste ist der instabile Betrieb unseres Online-Shops.

Wir könnten sogar von der Tatsache abfallen, dass das Unternehmen eine Art Newsletter herausbrachte, nach dem ~ 2000-2500 Menschen auf die Website kamen, oder, wie ich mich jetzt erinnere, ein Werbebanner auf Yandex uns in einen tiefen Niederschlag versetzte. Natürlich sind solche Dinge nicht akzeptabel, da dies nicht nur entgangene Gewinne sind, sondern auch das Image des Unternehmens - im Allgemeinen haben wir verstanden, dass etwas geändert werden muss. Zunächst wurde erkannt, dass Standardlösungen mit unseren Workloads (zu dieser Zeit nicht sehr groß, aber immer noch nicht klein) nicht funktionieren würden. Dann hatten wir normalerweise ~ 1000 Besucher online, ~ 2500 zu Spitzenzeiten, plus Entwicklungspläne x2 pro Jahr.

Sofort in Bezug auf Hardware intensiviert: Wir haben 2 weitere Anwendungsserver hinzugefügt und einen Cluster aus 2 Datenbankservern erstellt. Unser Stack war zu dieser Zeit Nginx, MySQL, PHP. Parallel dazu haben wir versucht, die aktuelle Lösung zu optimieren - wir haben nach Engpässen gesucht und versucht, alles Mögliche neu zu schreiben. Da unser Engpass die Basis war, war es immer der erste, der „starb“, und wir beschlossen, ihn maximal zu entladen. Implementierte Sphinx für die Volltextsuche und Ausgabe von Warenkacheln mit Facetten durch die ausgewählten Filter und verbundenen Caches. Und voila - diese Lasten, die sich gestern für uns als tödlich herausstellten, begannen wir mit Leichtigkeit zu halten.

Parallel dazu wurde ein Pilotprojekt gestartet, in dessen Rahmen eine technologische Aktualisierung der Website durchgeführt werden sollte - die Übertragung auf eine grundlegend andere Plattform. Es gab viele Ideen und Ideen - zu dieser Zeit wurde die Personalisierung von allem und jedem, persönliche Empfehlungen, Mailings, Rabatte und andere nützliche Dinge immer beliebter, und wir wollten natürlich auch all dies nutzen. Wir haben uns angesehen, was auf dem Markt erhältlich ist, und die teuerste Plattform nach dem Prinzip „Einmal teurer, dann kühler“ gekauft. Die Implementierung wurde mit Hilfe eines Integrators geplant, und wir hatten noch Unterstützung und Weiterentwicklung des bedingt alten IM, bis das neue auf der neuen Plattform in Betrieb genommen wurde.

Da die Geschwindigkeit der funktionalen Entwicklung der aktuellen Website jedoch sehr hoch war, beschlossen wir, die Implementierung der neuen E-Commerce-Plattform über den damals kleineren und einfacheren Online-Shop der Einzelhandelskette in Austin zu beginnen, der auch vom IT Sportmaster-Team bedient wurde. Dabei stellten wir fest, dass das Ding kräftig und funktional anspruchsvoll, aber technologisch veraltet war, und es stellte sich als großes Problem heraus, Leute zu finden, die es vollständig umsetzen konnten. Darüber hinaus führte die vor Projektbeginn vorgenommene Dimensionierung zu erheblich geringeren Anforderungen an die Hardware und die Anzahl der Lizenzen - die Lebensdauer erwies sich als wesentlich grausamer. Im Allgemeinen haben wir eines verstanden: Wir werden keinen Sportmaster darauf machen. Und da sich das Team für die Migration auf die Plattform bereits im Rekrutierungsprozess befand, beschlossen die Jungs, mit dem Prototyping ihrer eigenen Lösung zu beginnen, basierend auf den Anforderungen, die das Unternehmen an die neue Plattform stellt.

Der Technologie-Stack wurde wie folgt ausgewählt: Java, Spring, Tomcat, ElasticSearch, Hazelcast.

Infolgedessen hatten wir Ende 2014 eine neue Version von IM fertig, vollständig selbst geschrieben, auf die wir erfolgreich umgestellt haben. Sie ist die erste Version der Website, die Sie heute sehen. Natürlich ist die aktuelle Version viel funktionaler und technologischer, aber die Basisplattform ist dieselbe.

Hauptaufgaben

Wenn wir über einen großen Online-Shop sprechen, sprechen wir natürlich über die Bereitschaft, nicht nur mit täglichen, sondern auch mit Spitzenlasten fertig zu werden - um für Unternehmen und Endbenutzer stabil zu sein.

Die Hauptansätze hierbei sind die Fähigkeit zur horizontalen Skalierung und die Anwendung von Daten-Caching-Ansätzen auf verschiedenen Ebenen. Und jetzt, wie vor einiger Zeit, haben wir beschlossen, den Zugriff auf unsere Daten zu optimieren. Wir können jedoch kein reguläres Seiten-Caching verwenden. Im Allgemeinen. Dies ist eine geschäftliche Anforderung, und die Anforderung ist durchaus vernünftig. Wenn Sie dem Benutzer der Website zu einem bestimmten Zeitpunkt den falschen Preis oder die falsche Verfügbarkeit von Waren anzeigen, führt dies höchstwahrscheinlich zu einer Ablehnung des Kaufs und einer Verringerung der Kundenbindung.

Und es ist in Ordnung, wenn der Kunde 15 Paar Socken für 299 Rubel bestellt hat und im Laden festgestellt hat, dass es tatsächlich nur 14 Paar und 300 Rubel gibt - man kann irgendwie damit leben. Akzeptiere, kaufe was ist und lebe mit dieser Narbe in deiner Seele weiter. Aber wenn die Abweichungen in der Anzahl gravierend sind oder Sie nach einer bestimmten Größe gesucht haben - und diese gekauft wurde, während Sie die Bewertungen der glücklichen Besitzer karierter Shorts gelesen haben, ist hier bereits alles trauriger. Das heißt, sofort der Verlust eines zufriedenen (bis zu diesem Zeitpunkt) Kunden und der Verlust von Zeit und Geld für die Arbeit des Call Centers, wo dieser Kunde anruft, um herauszufinden, was passiert ist und warum.

Daher sollte der Benutzer immer den neuesten Preis und die aktuellsten Daten zu Warenbilanzen sehen. Daher sind unsere Caches intelligent und wissen, wann sich die Daten in der Datenbank ändern. Für das Caching verwenden wir Hazelcast.

Übrigens über die Reste

Hierbei ist zu beachten, dass die Tiefe der Warenrückstände sehr gering ist. Und eine sehr große Anzahl von Bestellungen wird (sehr) abgeholt. Daher sollte der Kunde normalerweise die Waren im richtigen Geschäft reservieren und die Salden verfolgen. Zu einer Zeit wurde bei Bitrix das Problem der Rückstände durch die Tatsache aufgegriffen, dass Rückstände von mehr als 10 Einheiten einfach als unendlich angesehen wurden. Das heißt, alles, was mehr als 10 ist, ist immer gleich 10, aber die niedrigeren Werte sind für uns bereits interessant zu berechnen und wir berücksichtigen sie und laden sie auf die Site hoch.

Dies ist jetzt nicht mehr möglich. Daher laden wir die Reste alle 15 Minuten aus allen Geschäften herunter. Und wir haben ungefähr 500 Geschäfte sowie eine Reihe regionaler Lagerhäuser und mehrere Einzelhandelsketten. Und das alles muss umgehend aktualisiert werden. Die Kirsche hier ist die Tatsache, dass sich die Arbeitsbedingungen von Kurierunternehmen sehr oft im Maßstab der Russischen Föderation ändern, daher müssen auch Lieferparameter geladen werden. Darüber hinaus wird ein kontinuierlicher Warenfluss an die Lager des Unternehmens geliefert, weshalb sich die Warenmenge in den Lagern voraussichtlich ändern wird. Also muss es auch wieder gezogen werden.

Und so werden Commodity Item Identifiers (SKUs) gebildet. Wir haben ungefähr 40.000 sogenannte Farbmodelle von Waren. Wenn wir weiter zur Größe der Waren gehen, erhalten wir ungefähr 200.000 SKU. Und für all dies müssen 200.000 in der Größenordnung von 500 Filialen aktualisiert werden.

Wir haben auch Zehntausende von Städten und Dörfern, in die wir Waren aus Geschäften oder Lagern liefern. Daher stellt sich heraus, dass die Cache-Variabilität für nur eine Produktseite (Stadt * SKU) ein Millionstel eines Werts beträgt. Unser Ansatz lautet: Die Berechnung der Verfügbarkeit einer bestimmten Wareneinheit erfolgt im laufenden Betrieb, wenn der Benutzer die Produktkarte eingibt. Wir betrachten die Arbeit der Kuriere in der Region des Benutzers, wir betrachten ihren Arbeitsplan, wir berechnen die Lieferkette und berücksichtigen deren Dauer. Parallel dazu werden die Überreste in nahe gelegenen Geschäften analysiert, von denen aus der Transport arrangiert werden kann.

Um die Verwaltung zu vereinfachen, verfügen wir über eine bestimmte Anzahl sehr schneller Caches in der Anwendung. Dank dieser Funktion können wir alle erforderlichen Daten schnell nach ID abrufen und im laufenden Betrieb sortieren. Das Gleiche gilt für Kuriere: Wir gruppieren sie in Cluster, und dann werden die Cluster bereits in der Datenbank gespeichert. Alle 15 Minuten wird dies alles aktualisiert. Für jede eingehende Anfrage berechnen wir eine bestimmte Gruppe von Kurieren mit den erforderlichen Parametern, aggregieren sie und geben sie schnell an den Käufer weiter - alles ist in Ordnung, wir haben definitiv solche grünen Shorts der Größe 50, Sie können es auch In diesen drei Geschäften in der Nähe können Sie mit Stiften abholen oder 3 Tage lang in einem Geschäft auf der anderen Straßenseite (oder sogar zu Hause) bestellen.

Für Moskau mag diese Situation unnötig erscheinen, aber für die Regionen ist dies eine ganz andere Sache. Sie bestellen sehr oft Waren in einigen Geschäften (die Sie vielleicht auch speziell erreichen müssen).

Zahlen

Jetzt empfängt die Site Tausende von Anforderungen pro Sekunde unter Berücksichtigung der statischen Daten und 500-1000 Anforderungen pro Sekunde an Anwendungsserver. Die Anzahl der Anwendungsserver hat sich nicht geändert, aber ihre Konfiguration hat erheblich zugenommen. Es werden durchschnittlich etwa 3.000.000 Aufrufe pro Tag erzielt.

DDoS werden manchmal auf der Site gefunden. Gleichzeitig klopfen sie mit Botnetzen, außerdem mit unseren Verwandten aus der Russischen Föderation. Vor langer Zeit gab es Fälle von Versuchen, auf Botnetze aus Mexiko und Taiwan zu klopfen, aber jetzt ist dies nicht mehr der Fall.

Es gibt eine Reihe von Lösungen für den Cloud-Schutz gegen DDoS auf dem Markt, ja, und recht gute. Für bestimmte Sicherheitsrichtlinien können wir diese Art von Cloud-Lösungen jedoch nicht verwenden.

Was jetzt?

Wir beginnen mit der Erstellung einer Plattformlösung, bei der die Teams nicht vertikal (einige von ihnen sahen einen Standort und der zweite einen anderen), sondern horizontal getrennt werden. Dabei wird die gemeinsame Plattformebene hervorgehoben, in Teile geteilt und ein Team um sie herum gebildet. Und auf ihnen schließen wir bereits die Site und nicht nur, einschließlich aller Kunden des Unternehmens, sowohl extern als auch intern. Daher haben wir viele komplexe und interessante Arbeiten.

Der Stapel an der Vorderseite hat sich aus offensichtlichen Gründen in dieser Zeit nicht wirklich geändert - Java, Spring, Tomcat, ElasticSearch und Hazelcast sind immer noch gut für unsere Anforderungen. Eine andere Sache ist, dass jetzt viele Back-Office-Systeme mit verschiedenen Technologien hinter der Site versteckt sind. Und natürlich ist ein Reengineering im Gange (da die Anforderungen an interne Systeme und die Arbeit mit ihnen insgesamt optimiert werden müssen und wir die Geschäftsanforderungen und neuen Geschäftsfunktionen nicht vergessen).

Und Sie können mir sicher persönliche (oder Kommentare) Vorschläge zur Verbesserung der Website geben - sowohl in Bezug auf neue Funktionen als auch auf die visuelle Komponente und die allgemeine Benutzererfahrung. Wir werden versuchen, schnell zu reagieren und alles zu berücksichtigen. Und wenn Sie Teil des Teams werden und alles von innen sehen möchten - willkommen .