Wie Messaging erfolgreich in Microservices eingesetzt werden kann – Teil 1

20.10.2020

Besonders im Kontext von Microservices, aber auch in anderen Architekturen spielt die lose Kopplung der Services eine wichtige Rolle, um damit beispielsweise Erweiterbarkeit, Skalierbarkeit und Verfügbarkeit einer Softwarelösung zu steigern.

Damit diese Services miteinander kommunizieren – also ihren Status oder wichtige Ereignisse miteinander teilen können – gibt es verschiedene Möglichkeiten. Einige dieser Möglichkeiten, wie zum Beispiel die On-Premise Lösung mit Kafka benötigt viel Personal und Know-how. Cloud-Plattformen – wie z.B. Azure von Microsoft oder AWS von Amazon – bieten hier Services an, welche direkt gemanagt werden. So können sich Entwickler ganz auf die Umsetzung ihrer Lösung konzentrieren. Wir werfen einen Blick auf die entsprechenden Technologien und deren Umsetzung.

Event vs. Message

Um den passenden Event-/Messaging Service auswählen zu können, ist es zunächst wichtig, zu analysieren, um welche Art von Mitteilung es sich handelt. Hierbei können Mitteilungen grundsätzlich in zwei Typen unterteilt werden: Event und Message. Die Grenzen sind jedoch sehr fließend. Aber was genau sind die Unterschiede zwischen diesen beiden Typen?

Event

Ein Event ist meistens von der Größe her eine eher kleine Nachricht, welche dazu dient, einen anderen Service darüber zu informieren, dass etwas passiert ist. Dabei enthalten die Events nicht die Änderung selbst, sondern lediglich die Information, dass sich etwas geändert hat und optional, wo das Objekt zu finden ist. Generell gibt es bei Events auch keine Erwartungshaltung, was mit der Information beim Empfänger getan wird.

Ein mögliches Event über eine neu erstellte Datei könnte als JSON Objekt beispielsweise so aussehen:

{
    eventType:"File_Created",
    url: "www.myfilestorage.com/files/a_new_file.txt"
}

Events können zudem noch feiner in die zwei weiteren Kategorien „diskrete Events“ und „Series Events“ unterteilt werden.

Discrete Events

Bei diskreten Events handelt es sich um Events mit dem primären Fokus, einen Interessenten über ein Ereignis anstatt über die tatsächliche Änderung zu informieren. Deshalb enthält diese Gattung von Events entweder keine oder nur wenig Daten. Dies Art von Events werden daher oft als Trigger für andere Services verwendet, welche über eine Statusänderung wie beispielsweise die Erstellung eines neuen Blob auf dem Blob Storage informiert werden möchten.

Series Events

Series Events sind Events, welche über eine Bedingung/Stand informieren wollen, der analysierbar ist. Diese Events bestehen aus mehreren Events, die zueinander in einer gewissen Beziehung stehen und in regelmäßigen Zeitabständen erfasst werden. Beispiele für diese Art von Events sind Telemetriedaten eines IoT Geräts oder Logging Events.

Message

Eine Message hat ebenfalls die Aufgabe, einen Service über etwas zu informieren – jedoch liefert eine Message die Daten, welche für die weitere Verarbeitung wichtig sind, gleich mit. Dadurch sind sie meist deutlich größer als Events. Deshalb werden Messages vorrangig dafür verwendet, Daten zwischen Services auszutauschen, welche benötigt werden, um einen definierten Workflow abzubilden. Messages enthalten also für einen Prozess wichtige und eventuell auch sensible Daten. In diesem Fall ist eine Verschlüsselung zu verwenden.
Außerdem kann es für Nachrichten besondere Anforderungen geben:

  • Herausfiltern von Duplikaten
  • Fehlerhafte Daten
  • Einhaltung einer bestimmten Reihenfolge
  • Speicherung der Nachricht, bis ein konsumierender Service wieder online ist
  • Sicherstellung des Datenflusses

Ein Beispiel für eine Message könnte ein Service sein, der einen anderen Service über die bestellten Artikel eines Kunden informieren möchte. Als JSON Objekt könnte das in etwa so aussehen:

{
    messageId:"42",
    orderId: 1434522,
    articles[
        {
            articleNo: 32444,
            amount: 3,
            price: 4.99€
        },
        {
            articleNo: 54346,
            amount: 1,
            price: 9.99€
        }
    ]
}

Beispielszenarien für Messages könnten sein:

  • Information über bestellte Artikel
  • Nachricht an das Billing System zur Erstellung einer Rechnung

Wann nutze ich welchen Typ in Microservices?

Diese Entscheidung ist wichtig, aber nicht immer leicht zu fällen deshalb soll die nachfolgende Tabelle dabei helfen, diese Entscheidung zu vereinfachen.

Event Message
Austausch von Daten zwischen Services
Trigger für Services (Statusänderung)
Telemetrie Daten und Logging

 

Im Teil 2 des Beitrags gehen wir genauer auf Azure Messaging Services ein und vergleichen diese.

Hier geht’s zum Teil 2

Hier geht’s zum Teil 3

Zu unserem Leistungsangebot

 

Quellen

https://docs.microsoft.com/en-us/azure/event-grid/compare-messaging-services
https://docs.microsoft.com/en-us/azure/messaging-services/

Zurück zur Übersicht

Kommentar verfassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

*Pflichtfelder

*