Der Übergang zu Mikroservices für ein Logistikunternehmen

Entdecken Sie unseren Ansatz zur Steigerung der Leistung und Skalierbarkeit von Software für ein Logistikunternehmen durch den Übergang von einer monolithischen Architektur zu Microservices.

  • Industrie

    Logistik

  • Land

    USA

  • Größe des Teams

    6

  • Implementierung

    7 Monate

Über den Auftraggeber

Unser Kunde ist ein großer US-amerikanischer Logistikkonzern, der den Transport und die Lagerhaltung im ganzen Land abwickelt. 

Geschäft Kontext

Aufgrund der schnellen Expansion des Unternehmens konnte ihre monolithische Software für das Lager- und Transportmanagement nicht entsprechend dem Wachstum des Unternehmens richtig funktionieren und skalieren. Die Software war jedoch zu groß und komplex, um sie in kurzer Zeit richtig zu aktualisieren. Um diese Herausforderung anzugehen, bot Yalantis einen Wechsel von einer monolithischen Architektur zu Mikroservices an. Hier sind einige der Herausforderungen, die wir durch diesen Übergang bewältigen mussten: 

  • Es war enorm viel Zeit erforderlich, um Änderungen am Produkt vorzunehmen.
  • Eine hohe Software-Latenz führte zu einem Verlust von Nutzern
  • Unser Kunde musste eine zunehmende Anzahl von Mikroservices verwalten.
  • Das Speicherlecken gefährdete die ordnungsgemäße Funktion der App.

Lösung Übersicht

  • Reduzierung der Zeit, die für Änderungen am Produkt benötigt wird

    Die Anbindung neuer Funktionen und die Änderungen an der App erforderten für die Testphase und die Überprüfung jeweils einen bis drei Monate. Wir haben diese Zeit verkürzt: 

    • Die Identifizierung logischer Komponenten des Systems, die in Mikroservices umgewandelt werden können
    • Die Separation von Microservices nach technischer Ausrichtung      
    • Die Entscheidung über die Reihenfolge, in der Teile zu Mikroservices weiterentwickelt werden sollen
    • Die Integration von WARs mit Mikroservices in Jetty, die für die Verbindung der Server zu den einzelnen Mikroservices verantwortlich ist

  • Reduzierung der Software-Latenz 

    Um die Verzögerung zwischen der Eingabe und der gewünschten Ausgabe zu reduzieren, replikierte unser Team die gesamte Datenbank über mehrere Rechenzentren hinweg. Dadurch kann das System, falls ein Rechenzentrum nicht richtig funktioniert, auf ein anderes umschalten und dessen Kopie der Datenbank verwenden. 

  • Verwalten einer zunehmenden Anzahl von Mikroservices     

    Nach der Implementierung von mehr als 20 Microservices standen wir vor der Herausforderung, die Kompatibilität und die Versionsverwaltung der Service-Daten zu gewährleisten. Außerdem hatten wir Schwierigkeiten, viele WAR-Dateien in Jetty zu bereitstellen. Es dauerte bis zu zwei Stunden, bis alle Microservices aktualisiert waren; dies war zu lange, um den Anforderungen unserer Kunden gerecht zu werden. Um diese Probleme zu lösen, führten wir folgende Maßnahmen:

    • Erstellung von Client-Bibliotheken (Modul-APIs) für Service-Controller, die die Kompatibilität der Datenarten sicherstellten und die gleiche Anruf-Schnittstelle für Client-Bibliotheken und Controller verwendeten
    • Es wurde zu einer horizontalen Architektur umgestellt, die Datenzentren unterteilt und einen separaten Server für das Elastic Stack mit der Kibana-Benutzeroberfläche für die Datenerfassung anhand von Indizes und die Verringerung der Serverressourcen hinzugefügt.
    • Redis wurde als Zwischenprotokoll zwischen der Datenbank und dem Server für Ereignisse und Benutzeraktionen eingesetzt, sodass grundlegende Geschäftsfunktionen und deren Transaktionen nicht gleichzeitig auf mehrere Server auswirken.
    • Ein geschlossener Kubernetes-Container um die Software um eine einfache Skalierung und die Möglichkeit zu gewährleisten, bei Bedarf von einem Cloud-Dienstanbieter zu einem anderen zu wechseln
    • Das Unternehmen hat die App so umgestaltet, dass sie eine stateless-Architektur verwendet und somit einfache Anfragen senden und mehrere Datenbankinstanzen erstellen kann.

  • Die Erkennung und Behebung von Speicherlecks

    Unser Team hatte ein Problem mit dem Speicherverbrauch, da Subsysteme die Ressourcen übernommen haben, die die Software nicht mehr benötigte. Um ein fatales OutOfMemoryError zu vermeiden, haben wir:

    • Verwendete native Mechanismen der Subsysteme, um eine Auslagerung der Speicherressourcen zu vermeiden
    • Das System wurde unter Verwendung eines benutzerdefinierten JAR-Dienstprogramms mit einem Szenario zur Erkennung von Speicherlecks ausgeführt.
    • Verhinderte Speicherlecks durch die Verwendung eines Out-of-Memory-Killers, einer etablierten Methode zur Wiederherstellung der Systemspeicherressourcen.

Wert geliefert

Unsere Zusammenarbeit mit dem Kunden führte zu dem Folgenden:

  • Das hochvolumige und fehlerverzeihende System unseres Kunden verfügt über 40.000 registrierte Nutzer in verschiedenen Zeitzonen und verarbeitet täglich 200.000 Transaktionen.

  • Systemaktualisierungen dauern statt von zwei Stunden auf weniger als fünf Minuten, und die Anbindung neuer Dienste hat keine Auswirkungen auf andere Systemmodule.

  • Das System ermöglicht es Entwicklern, die App horizontal skalieren zu können, indem sie unterschiedliche Technologien, Programmiersprachen, Frameworks und Bibliotheken verwenden.

  • Die Mikroservice-Architektur von Docker ermöglicht die Schaffung verteilt arbeitender Entwicklungsteams, die unabhängig von einander auf verschiedenen Teilen der Software arbeiten können.

OPTIMALIERT IHRE APP-LEISTUNG MIT EINER VERFÜGBAREN ARCHITECTURE

Yalantis gewährleistet mit skalierbaren und wartungsarmen Technologie-Lösungen hohe Stabilität und Fehlertoleranz Ihres Systems.

Beratung buchen

Weitere Projekte