Reaktive Anwendung für die große US-Luft- und Raumfahrtindustrie.

Industrie

Technologie

Akka Akka-http Elasticsearch Kafka Postgres Scala Titan (mit Kassandra)

Einführung

Die Anwendung war bestens für Reaktivität geeignet, und der gesamte Lightbend Reactive Technology Stack half dabei, dies zu erreichen. Da die Anwendung auf Microservices basiert, ist das Design in hohem Maße erweiterbar und skalierbar. Außerdem würde die Anwendung niemals ausfallen, wenn ein Teil davon nicht mehr funktioniert.

Über Freebird

Freebird bietet eine mobile Plattform für die Umbuchung von Flügen, mit der Reisende im Falle einer Flugannullierung, einer vierstündigen Verspätung oder eines verpassten Anschlusses die Warteschlange überspringen und sofort ein neues Ticket bei einer beliebigen Fluggesellschaft buchen können. Über diese Plattform werden Reisende bei Flugunterbrechungen sofort benachrichtigt und haben die Möglichkeit, über ihre mobilen Geräte umzubuchen. Das Projekt “thePlatform” soll die B2B-Prozesse erleichtern. Sie ermöglicht es Partnern, mit der Plattform zu interagieren. Der Ablauf für die Plattform sieht in etwa so aus: Ein Partner kauft einen Freebird, indem er die Preisgestaltung und den Kauf vornimmt; wenn der Flug irgendwie gestört wird, erhält der Reisende eine SMS sowie eine E-Mail mit verschiedenen Umbuchungsoptionen. Der Reisende kann dann eine Option auswählen, und freebird bucht ein neues Ticket für ihn.

Die Herausforderung

Obwohl der grundlegende Ablauf der Anwendung sehr einfach ist, besteht die Herausforderung darin, dass die Anwendung die gesamte US-amerikanische Luft- und Raumfahrt abdecken muss, um Störungen zu erkennen. Da man einer einzigen Quelle nicht trauen kann, werden mehrere Quellen verwendet, um den Status der Flüge zu verfolgen. Der Status muss häufig abgefragt und in die Datenbank eingegeben werden, damit die Umbuchungsoptionen sofort an die Reisenden gesendet werden können. Jedes Mal, wenn die Statusdaten aus den Quellen abgerufen werden, kommt es zu zahlreichen Statusänderungen, so dass häufig große Datenmengen verarbeitet werden müssen. Dies ist nur eine Herausforderung für die Plattform, die auch die Verfügbarkeit der Flüge berücksichtigen muss, und zwar unter Berücksichtigung der Präferenzen der Partner.

Eine weitere Herausforderung besteht darin, Ersatzflüge für die Reise zu finden, falls diese unterbrochen wird. Die verfügbaren Flüge müssen wiederum aus verschiedenen Quellen abgerufen werden. Für jede Reise gibt es verschiedene Szenarien mit unterschiedlichen Präferenzen, die alle erfolgreich erstellt werden müssen, bevor die alternativen Flugquellen aufgerufen werden. Sobald die Alternativflüge generiert sind, senden Sie diese als Optionen an den Reisenden, und stellen Sie genügend Informationen für den Kundendienst bereit, damit dieser die Situationen klar und deutlich bearbeiten kann.

Obwohl die API die einfachste aller Herausforderungen zu sein scheint, muss sie viele Vorgänge verarbeiten, um genügend Informationen zu generieren, so dass die Überwachung von Störungen einfach durchgeführt werden kann. Es musste nicht nur die vom Kunden erzeugten Daten durchsuchen, sondern auch die Fluginformationen, die in das Backend eingespeist werden.

Unsere Lösung

NashTech begann mit der Entwicklung der Anwendung nach dem DDD-Ansatz. Es wurden begrenzte Kontexte identifiziert und die Anwendung wurde mit der Microservices-Architektur erstellt. Bis auf die API für die Preisgestaltung und den Einkauf war alles andere asynchron. Die Architektur wurde choreografisch aufgebaut, und wir verwendeten Kafka als Nachrichtenvermittler zwischen den Diensten. Es bot eine einheitliche Plattform mit hohem Durchsatz und geringer Latenz für die Echtzeitverarbeitung von Datenfeeds, deren Speicherebene im Wesentlichen eine “massiv skalierbare Pub/Sub-Message-Queue in Form eines verteilten Transaktionsprotokolls” ist. Innerhalb jedes Dienstes haben wir die funktionale Programmierung von Scala, Futures und bei Bedarf Akka ausgiebig genutzt, da alles nicht-blockierend und asynchron sein musste. Der Dateningestionsprozess war sehr umfangreich, und um den Rückstau zu bewältigen, wurde an vielen Stellen Kafka eingesetzt.

Da wir eine riesige Datenmenge in die Datenbanken einspeisen, musste die Suche sorgfältig gehandhabt werden, weshalb Elastic Search eingesetzt wurde. Sie enthält den Teil der Daten, auf dem die Suche basieren könnte, und gibt den Indexpunkt zurück, durch den die aktualisierten Daten aus der Datenbank geholt werden können.

Die Entwicklungsmethode von NashTech mit Scrum und XP wurde verwendet, um das Projekt in Sprints aufzubauen. Die Vorteile des agilen Ansatzes haben sich im Laufe der Entwicklung des Projekts immer wieder gezeigt. Der Schwerpunkt lag auf TDD unter Berücksichtigung der pyramidalen Testfallstrategie, bei der wir die geringste Anzahl von e2e-Testfällen, mehr Integrationstestfälle als e2e und hauptsächlich Unit-Testfälle haben. Als Verzweigungsstrategie wurde GitFlow verwendet, so dass die Codeverwaltung keine Herausforderung darstellte.

Das Ergebnis

Der Technologie-Stack und die Architektur erfüllten die SLAs, die für die Plattform erforderlich waren. Die Anwendung war bestens für Reaktivität geeignet, und der gesamte Lightbend Reactive Technology Stack half dabei, dies zu erreichen. Da die Anwendung auf Microservices basiert, ist das Design in hohem Maße erweiterbar und skalierbar. Außerdem würde die Anwendung niemals ausfallen, wenn ein Teil davon nicht mehr funktioniert.