Laden...

Communicationsprotokoll für Microservices, Asynchron oder/und Synchron?

Erstellt von malignate vor 7 Jahren Letzter Beitrag vor 7 Jahren 3.442 Views
malignate Themenstarter:in
742 Beiträge seit 2005
vor 7 Jahren
Communicationsprotokoll für Microservices, Asynchron oder/und Synchron?

Hallo,

wir planen testweise ein neues Buchungssystem auf der Basis von Microservices. Das wird erstmal ein Spiel und Testprojekt und es ist unklar, ob es jemals zum Einsatz kommen wird. Unser System muss Hotelbuchungen, Flüge, Mietwagen und Zusatzprodukte bedienen können. Außerdem natürlich noch mehrere Payment Provider usw.

Ein großes Problem unseres aktuellen Systems ist, dass es synchron arbeitet, d.h. der Benutzer klickt "Jetzt buchen" und dann kommt ein Spinner und wir haben 1 Minute alles abzuschließen. Das ist erstmal relativ wenig Zeit, wenn viele Produkte im Warenkorb sind. Außerdem gibt es immer mal wieder Fehler und Produkte können auch ausverkauft sein. Deshalb soll es in Zukunft asynchron arbeiten. Das heißt der Benutzer bekommt sofort eine Antwort "Buchung wird bearbeitet" und dann später eine Email, wenn alles abgeschlossen wird. Dadurch können wir auch manuell eingreifen und Alternativen anbieten, z.B. ein besseres Zimmer, falls das die Provision erlaubt.

Ein Teil der Kommunikation zwischen Services ist synchron (= Request/Response), z.B:

* Zahlung beginnen (generiert vll. nur einen Deeplink zu Paypal etc.)
* Produkt validieren (sind die Eingaben gültig etc.)

Ein Teil der Kommunikation auch asynchron (= Messaging):

* Bezahlung durchführen
* Produkt buchen
* Produkt stornieren

Für beide Probleme gibt es viele tolle Lösungen:

Synchron

* REST mit JSON
* gRPC
...

Asynchron

* Kafka
* RabbitMq
...

Jetzt wäre es super, wenn man das Kommunikationsprotokoll relativ kompakt halten könnte. Habt ihr Erfahrung mit irgendwelchen Alternativen die im Prinzip beide Kommunikationsmuster abdecken? z.B. Akka.NET, Orleans. Was sind da eure Erfahrungen?

W
872 Beiträge seit 2005
vor 7 Jahren

Ich benutze in meinem Umfeld gRPC - das bietet beide Kommunikationsmuster an.
Mir persönlich gefällt daran, daß gRPC sehr kompakt ist und dass man damit viele Sprachen anbietet. Die Struktur mit den proto Files als plattformunabhängige Schnittstellen-Beschreibung finde ich sehr gut.

malignate Themenstarter:in
742 Beiträge seit 2005
vor 7 Jahren

Ich finde gRpc auch super und die Proto Files sind klasse, aber wie kann damit asynchrone Kommunikation machen? Ich meinte nicht Async I/O (Async Task usw.) sondern im Prinzip Messaging mit Queues / MessageBus usw.

W
872 Beiträge seit 2005
vor 7 Jahren

Für einen Message Bus würdest Du Server streaming RPC benutzen.
Aber ein Message Bus ist im Sinne von Microservices ein Antipattern.

malignate Themenstarter:in
742 Beiträge seit 2005
vor 7 Jahren

Ich liebe Aussagen ohne Begründung, das erinnert mich immer an Religionen 😄

W
872 Beiträge seit 2005
vor 7 Jahren

Willst Du Punkt zu Punkt Verbindung über den Message Bus machen oder sollen alle lauschen? Bei Dir hört sich das nach letzterem an....

malignate Themenstarter:in
742 Beiträge seit 2005
vor 7 Jahren

Ich ziehe den Begriff MessageBus zurück 😉.

Ich brauche in manchen Fällen eine Entkopplung und asynchrone Kommunikation. z.B. mit RabbitMq oder Kafka oder Azure Service Bus. In dieser asynchronen Kommunikation können auch Menschen beteiligt sein, weil sich manche Buchungsschritte und Fehlerbehandlungen (noch) nicht automatisieren lassen.

Das heißt im Kern habe ich eine Art ProcessManager der auf Events reagiert und daraufhin Events auslöst. Diese Events müssen jetzt von verschiedenen Services behandelt werden.

Ein Teil der Events sind im Prinzip an einem bestimmten Empfänger gerichtet, der auch mal Offline sein kann, z.B. Amadeus-Flug-Buchungssystem, andere Events werden z.B. von mehreren Services konsumiert. Beispielsweise wird wenn eine Buchung abeschlossen wird, eine Email versendet, eine Rechnung verschickt, ein Report aktualisiert und die Information an das Accounting System geschickt.

Ich könnte z.B. einfach Kafka oder EventStore für die asynchrone Kommunikation verwenden, müsste dann aber für die synchrone Kommunikation auch noch mit gRPC arbeiten. Die Frage ist, ob ich das auch irgendwie abstrahieren kann, bspw.

  1. Ich kann natürlich ein Art Adapter schreiben, der beide Kommunikationsprotokolle für die Microservices kapselt. Wenn alle Services mit der gleichen Sprache arbeiten, kann ich das ja einfach als NuGet zur Verfügung stellen.

  2. Ich könnte auch nur auf asynchrone Kommunikation setzen. Request / Reply ist aber nicht so einfach. Evtl. muss ich dann mit temporären Queues arbeiten, Timeouts werden schwieriger usw.

16.806 Beiträge seit 2008
vor 7 Jahren

Mich interessiert das selbst, da ich bislang auch keine Lösung dafür gefunden hab.

Wir machen das weiterhin aktuell mit Reactive Extensions und eigenen CQS-angelehnten Implementierungen.
AKKA haben wir wegen der extrem hohen Abhängigkeiten nicht gewollt.

Wenn Du was hast: lass es mich wissen 😃

W
872 Beiträge seit 2005
vor 7 Jahren

Es gibt übrigens ein neues Projekt protoactor, das quasi gRPC für ein Actor-Framework benutzt. Bisher habe ich mich damit noch nicht beschäftigt, da für mich gRPC ausreicht - aber es scheint einige Aspekte von Dir abzubilden. (Supervision/Lifecycle events/State machines).
Dazu gab es bei dotnetrocks vor kurzem eine sehr interessante Episode.

P
1.090 Beiträge seit 2011
vor 7 Jahren

Ein Arbeitskollege von mir hatte sich vor kurzen mit den Thema befasst für uns mal zu validieren was für Möglichkeiten es da für uns so gibt. Und auch mal zum Test ein paar Beispiele implementiert.

Das Grundlegende Ergebnis war, das wir wohl unsere Anforderungen nicht mit einer Technologie umsetzen können. Sondern eher mehrere in Kombination nutzen werden.
Mit einer seiner favorisierten Technologien, war in dem Rahmen auch gRPC.

Da es aber bei uns nicht dringend ist und ich denke das sich grade wegen IOT sich einiges tut kann. Haben wir es erst mal zurück gestellt.

Also falls du da was vernünftiges findest, wäre ich auch sehr interessiert.

Sollte man mal gelesen haben:

Clean Code Developer
Entwurfsmuster
Anti-Pattern