„Walking in my shoes“ – halt, sind die gekennzeichnet?

Seit 2019 gilt in Russland das Gesetz zur obligatorischen Kennzeichnung. Das Gesetz erstreckt sich nicht auf alle Warengruppen, und die Fristen für das Inkrafttreten der obligatorischen Kennzeichnung variieren je nach Warengruppe. Zunächst fallen Tabak, Schuhe, Arzneimittel unter die obligatorische Kennzeichnung, später werden weitere Waren wie Parfums, Textilien und Milch hinzukommen. Diese gesetzliche Neuerung hat zur Entwicklung neuer IT-Lösungen geführt, die es ermöglichen, die gesamte Lebensdauer eines Produkts vom Herstellungsprozess bis zum Kauf durch den Endverbraucher für alle Beteiligten im Prozess zu verfolgen: sowohl für den Staat als auch für alle Organisationen, die Produkte mit obligatorischer Kennzeichnung vertreiben.

Im H5-System wurde die Lösung, die die gekennzeichneten Produkte verfolgt und Daten mit dem Staat und den Lieferanten austauscht, "Markus" genannt. Lassen Sie uns Schritt für Schritt erklären, wie und von wem sie entwickelt wurde, welcher Technologiestack verwendet wird und warum wir darauf stolz sein können.

Echtzeit-HighLoad

"Markus" löst eine Vielzahl von Aufgaben, die wichtigste ist die Integrationsinteraktion zwischen den Informationssystemen von H5 und dem staatlichen Informationssystem der gekennzeichneten Produkte (GIS MP) zur Nachverfolgung der Lieferung der gekennzeichneten Produkte. Die Plattform speichert alle Codes der Kennzeichnung, die bei uns eingegangen sind, sowie die gesamte Historie der Bewegung dieser Codes zwischen den Objekten und hilft, Missverständnisse bei gekennzeichneten Produkten zu vermeiden. Beispielsweise enthält bereits ein Lkw mit Zigaretten etwa 600.000 Packungen, von denen jede ihren eigenen einzigartigen Code hat. Die Aufgabe unseres Systems besteht darin, die legalen Bewegungen jeder einzelnen Packung zwischen Lagern und Geschäften nachzuvollziehen und letztlich die Zulässigkeit ihres Verkaufs an den Endverbraucher zu überprüfen. Dabei erfassen wir etwa 125.000 Kassentransaktionen pro Stunde und müssen zudem dokumentieren, wie jede dieser Packungen ins Geschäft gelangt ist. Somit erwarten wir, unter Berücksichtigung aller Bewegungen zwischen den Objekten, jährlich Milliarden von Datensätzen.

Das Team M

Obwohl „Markus“ im Rahmen von X5 als Projekt gilt, wird es nach einem produktorientierten Ansatz umgesetzt. Das Team arbeitet nach Scrum. Der Projektstart war im Sommer des letzten Jahres, aber die ersten Ergebnisse kamen erst im Oktober – es wurde ein eigenes Team vollständig zusammengestellt, die Systemarchitektur entworfen und die Hardware gekauft. Momentan besteht das Team aus 16 Personen, von denen sechs die Backend- und Frontend-Entwicklung übernehmen, während drei sich mit der Systemanalyse beschäftigen. Sechs weitere Personen kümmern sich um manuelle, Last- und automatisierte Tests sowie um die Produktbetreuung. Darüber hinaus haben wir einen SRE-Spezialisten.

In unserem Team schreiben nicht nur die Entwickler Code, praktisch alle Kollegen können programmieren und erstellen automatisierte Tests, Lastscripts und Automatisierungsskripte. Wir legen besonderen Wert darauf, da selbst die Produktunterstützung ein hohes Maß an Automatisierung erfordert. Wir bemühen uns, Kollegen, die vorher nicht programmiert haben, zu unterstützen und ihnen kleine Aufgaben zu geben.

Im Zusammenhang mit der Coronavirus-Pandemie haben wir das gesamte Team auf Remote-Arbeit umgestellt. Das Vorhandensein aller Werkzeuge für das Management der Entwicklung sowie der Workflow in Jira und GitLab haben es ermöglicht, diesen Schritt problemlos zu bewältigen. Die Monate im Homeoffice haben gezeigt, dass die Produktivität des Teams nicht darunter gelitten hat, für viele hat sich der Arbeitskomfort erhöht, das Einzige, was fehlt, ist persönliche Kommunikation.

Teammeeting vor dem Remote-Arbeiten

Meetings während des Remote-Arbeitens

Technologischer Stack der Lösung

Das standardmäßige Repository und das CI/CD-Tool für X5 ist GitLab. Wir verwenden es zur Speicherung des Codes, für kontinuierliches Testen sowie für die Bereitstellung auf Test- und Produktionsservern. Zudem nutzen wir die Praxis des Code-Reviews, bei dem mindestens zwei Kollegen die vom Entwickler vorgenommenen Änderungen im Code genehmigen müssen. Die statischen Code-Analysetools SonarQube und JaCoCo helfen uns, den Code sauber zu halten und den erforderlichen Grad der Abdeckung durch Unit-Tests sicherzustellen. Alle Änderungen im Code müssen unbedingt diese Prüfungen bestehen. Alle Testfälle, die manuell durchgeführt werden, werden anschließend automatisiert.

Um die Geschäftsprozesse von „Markus“ erfolgreich umzusetzen, mussten wir eine Reihe technologischer Aufgaben lösen, von denen wir jede einzeln betrachten.

Aufgabe 1. Die Notwendigkeit der horizontalen Skalierbarkeit des Systems

Um diese Aufgabe zu lösen, haben wir einen mikroskopischen Ansatz für die Architektur gewählt. Dabei war es wichtig, die Verantwortungsbereiche der Dienste zu verstehen. Wir haben versucht, diese nach Geschäftsoperationen zu unterteilen, wobei wir die spezifischen Abläufe berücksichtigt haben. Zum Beispiel ist die Wareneingangskontrolle im Lager keine sehr häufige, aber eine sehr umfangreiche Operation, bei der man so schnell wie möglich Informationen über die angenommenen Produkte vom staatlichen Regulierungsbehörde einholen muss, wobei die Menge in einer Lieferung bis zu 600.000 Einheiten erreichen kann, sowie die Zulässigkeit der Annahme dieser Waren im Lager überprüft und alle notwendigen Informationen dem Lagerautomatisierungssystem übermittelt werden müssen. Im Gegensatz dazu hat die Auslieferung aus den Lagern eine deutlich höhere Intensität, jedoch bearbeitet sie kleinere Datenmengen.

Alle unsere Dienste implementieren wir nach dem stateless Prinzip, und selbst interne Abläufe versuchen wir in Schritte zu unterteilen, indem wir, wie wir sie nennen, self-Topics in Kafka verwenden. Das bedeutet, dass ein Mikrodienst eine Nachricht an sich selbst sendet, was es ermöglicht, die Last bei ressourcenintensiveren Operationen zu verteilen und die Wartung des Produkts zu vereinfachen, aber dazu später mehr.

Wir haben beschlossen, Module, die mit externen Systemen interagieren, in separate Dienste auszulagern. Das hat es uns ermöglicht, das Problem häufig wechselnder APIs externer Systeme nahezu ohne Einfluss auf Dienste mit Geschäfts-Funktionalität zu lösen.

Alle Mikrodienste werden im OpenShift-Cluster bereitgestellt, das sowohl das Problem der Skalierung jedes Mikrodienstes löst als auch die Verwendung von Drittanbieter-Tools zur Service-Entdeckung unnötig macht.

Aufgabe 2. Die Notwendigkeit, hohe Last und sehr intensiven Datenaustausch zwischen den Diensten der Plattform aufrechtzuerhalten: nur in der Startphase des Projekts werden etwa 600 Operationen pro Sekunde durchgeführt. Wir erwarten, dass dieser Wert auf 5000 Op/Sek ansteigt, wenn Handelsobjekte mit unserer Plattform verbunden werden.

Diese Aufgabe wurde durch den Einsatz eines Kafka-Clusters und nahezu vollständigen Verzicht auf synchrone Interaktion zwischen den Microservices der Plattform gelöst. Dies erfordert eine sehr sorgfältige Analyse der Systemanforderungen, da nicht alle Operationen asynchron sein können. Dabei übermitteln wir nicht nur Ereignisse über den Broker, sondern auch alle erforderlichen Geschäftsinformationen in der Nachricht. Somit kann die Nachrichtenlänge mehrere hundert Kilobyte erreichen. Die Einschränkung der Nachrichtenvolumina in Kafka erfordert von uns eine genaue Vorhersage der Nachrichtenlängen, und falls erforderlich, teilen wir sie auf, wobei diese Aufteilung logisch und mit den Geschäftsoperationen verbunden ist.
Zum Beispiel teilen wir die Ware, die mit dem Fahrzeug angekommen ist, nach Kisten. Für synchrone Vorgänge werden separate Microservices bereitgestellt und es wird umfassendes Lasttesting durchgeführt. Der Einsatz von Kafka hat uns vor eine neue Herausforderung gestellt: Die Funktionsprüfung unseres Dienstes in Bezug auf die Integration mit Kafka macht alle unsere Unit-Tests asynchron. Diese Aufgabe haben wir durch das Schreiben eigener Hilfsfunktionen unter Verwendung von Embedded Kafka Broker gelöst. Dies mindert nicht die Notwendigkeit, Unit-Tests für einzelne Methoden zu schreiben, aber komplexe Fälle testen wir lieber mit Kafka.

Wir haben sehr viel Wert auf die Protokollverfolgung gelegt, damit ihre TraceId bei Auftreten von Ausnahmen während des Betriebs der Dienste oder beim Arbeiten mit Kafka-Batch nicht verloren gehen. Während bei ersterem keine besonderen Fragen auftauchten, mussten wir im zweiten Fall alle TraceIds, mit denen das Batch kam, in das Protokoll schreiben und eine für die Fortsetzung der Verfolgung auswählen. So kann der Benutzer bei der Suche nach der ursprünglichen TraceId leicht herausfinden, mit welcher die Verfolgung fortgesetzt wurde.

Aufgabe 3. Die Notwendigkeit, eine große Menge an Daten zu speichern: Über 1 Milliarde Kennzeichnungen pro Jahr nur für Tabak gehen bei X5 ein. Diese erfordern einen ständigen und schnellen Zugriff. Insgesamt sollte das System etwa 10 Milliarden Datensätze zur Historie der Bewegungen der gekennzeichneten Waren verarbeiten.

Zur Lösung der dritten Aufgabe wurde die NoSQL-Datenbank MongoDB gewählt. Wir haben einen Shard aus 5 Knoten aufgebaut und in jedem Knoten ein Replica Set aus 3 Servern. Dies ermöglicht es, das System horizontal zu skalieren, indem man hinzufügt. neue Server in einem Cluster, und seine Ausfallsicherheit zu gewährleisten. Hierbei stehen wir vor einem weiteren Problem – die Gewährleistung der Transaktionsfähigkeit im Mongo-Cluster unter Berücksichtigung der Nutzung horizontal skalierbarer Mikrodienste. Zum Beispiel ist eine der Aufgaben unseres Systems, Versuche zum Wiederverkauf von Waren mit identischen Kennzeichnungscodes zu identifizieren. Hierbei treten Probleme mit fehlerhaften Scans oder fehlerhaften Kassenoperationen auf. Wir haben festgestellt, dass solche Duplikate sowohl innerhalb eines verarbeiteten Kafka-Batches als auch innerhalb von zwei parallel verarbeiteten Batches auftreten können. Somit brachte die Überprüfung auf Duplikate durch Anfragen an die Datenbank keine Ergebnisse. Für jeden der Mikrodienste haben wir das Problem individuell gemäß der Geschäftslogik dieses Dienstes gelöst. Beispielsweise haben wir für Belege eine Überprüfung innerhalb des Batches hinzugefügt und eine separate Verarbeitung zur Identifizierung von Duplikaten bei der Einfügung implementiert.

Damit die Nutzung der Transaktionshistorie durch die Benutzer keinen Einfluss auf das Wichtigste hat – die Funktionsfähigkeit unserer Geschäftsprozesse, haben wir alle historischen Daten in einen separaten Dienst mit einer eigenen Datenbank ausgelagert, der ebenfalls Informationen über Kafka erhält. So arbeiten die Nutzer mit einem isolierten Dienst, ohne Einfluss auf die Dienste, die die Daten zu aktuellen Operationen verarbeiten.

Aufgabe 4. Wiederverarbeitung von Warteschlangen und Monitoring:

In verteilten Systemen treten unvermeidbar Probleme und Verfügbarkeitsfehler von Datenbanken, Warteschlangen und externen Datenquellen auf. Im Fall von 'Markus' ist eine Quelle solcher Fehler die Integration mit externen Systemen. Es war notwendig, eine Lösung zu finden, die es ermöglicht, fehlerhafte Antworten nach einer bestimmten Timeout-Zeit erneut anzufragen, ohne dabei die Verarbeitung erfolgreicher Anfragen in der Hauptwarteschlange zu unterbrechen. Daher wurde das sogenannte Konzept des 'topic based retry' gewählt. Für jedes Haupt-Topic wird ein oder mehrere Retry-Topics erstellt, in die fehlerhafte Nachrichten geleitet werden, wobei eine Verzögerung bei der Verarbeitung von Nachrichten aus dem Haupt-Topic ausgeschlossen wird. Das Interaktionsschema ist –

Um ein solches Schema umzusetzen, benötigten wir Folgendes – diese Lösung mit Spring zu integrieren und Code-Duplikate zu vermeiden. Im Internet stießen wir auf eine ähnliche Lösung, die auf Spring BeanPostProcessor basierte, aber sie schien uns zu umständlich. Unser Team entwickelte eine einfachere Lösung, die es ermöglicht, sich in den Spring-Zyklus zur Erstellung von Consumer einzufügen und zusätzlich Retry-Consumer hinzuzufügen. Ein Prototyp unserer Lösung wurde dem Spring-Team angeboten, den man sich ansehen kann. hier. Die Anzahl der Retry-Consumer und die Anzahl der Versuche jedes Consumers werden über Parameter konfiguriert, abhängig von den Anforderungen des Geschäftsprozesses, und damit alles funktioniert, bleibt nur noch die bekannte Annotation org.springframework.kafka.annotation.KafkaListener zu setzen.

Falls eine Nachricht nach allen Retry-Versuchen nicht verarbeitet werden konnte, gelangt sie mit Hilfe des Spring DeadLetterPublishingRecoverer in das DLT (Dead Letter Topic). Auf Wunsch des Supports haben wir diese Funktionalität erweitert und einen separaten Dienst erstellt, der es ermöglicht, Nachrichten, die im DLT gelandet sind, sowie Stacktraces, traceId und weitere nützliche Informationen einzusehen. Außerdem wurden Überwachungen und Alarme für alle DLT-Topics hinzugefügt, so dass das Auftreten einer Nachricht im DLT-Topic im Grunde Anlass zur Untersuchung und zur Erstellung eines Defekts ist. Das ist sehr praktisch – an der Bezeichnung des Topics erkennen wir sofort, an welcher Stelle im Prozess das Problem aufgetreten ist, was die Suche nach der zugrunde liegenden Ursache erheblich beschleunigt.

Neulich haben wir eine Schnittstelle umgesetzt, die es unserer Unterstützung ermöglicht, Nachrichten nach der Beseitigung ihrer Ursachen (zum Beispiel Wiederherstellung der Funktionsfähigkeit eines externen Systems) erneut zu senden und natürlich einen entsprechenden Defekt zur Analyse anzulegen. Hier kamen unsere Self-Topics ins Spiel: Um eine lange Verarbeitungskette nicht neu zu starten, kann man sie ab dem benötigten Schritt neu starten.

Betrieb der Plattform

Die Plattform ist bereits im produktiven Einsatz, täglich führen wir Lieferungen und Verladungen durch, binden neue Verteilzentren und Geschäfte an. Im Rahmen des Piloten arbeitet das System mit den Warengruppen 'Tabak' und 'Schuhe'.

Unser gesamtes Team ist an der Durchführung von Piloten beteiligt, analysiert aufkommende Probleme und macht Vorschläge zur Verbesserung unseres Produkts, von der Optimierung der Protokolle bis hin zu Änderungen der Prozesse.

Um meine Fehler nicht zu wiederholen, spiegeln sich alle im Rahmen des Piloten gefundenen Fälle in den automatisierten Tests wider. Eine Vielzahl von automatisierten Tests und Unit-Tests ermöglicht es, Regressionstests durchzuführen und Hotfixes buchstäblich innerhalb weniger Stunden bereitzustellen.

Derzeit entwickeln und verbessern wir unsere Plattform weiter und stehen ständig neuen Herausforderungen gegenüber. Wenn Sie interessiert sind, erzählen wir in den kommenden Artikeln von unseren Lösungen.

Quelle: habr.com