2016-05-29 16 views
1

Wie behandelt man korrelierte Ereignisse in einer ereignisgesteuerten Architektur? Konkret, was passiert, wenn mehrere Ereignisse ausgelöst werden müssen, damit eine Aktion ausgeführt werden kann. Zum Beispiel habe ich einen Microservice, der die beiden Ereignisse foo und bar abhört und nur eine Aktion ausführt, wenn beide Ereignisse eintreffen und die gleiche Korrelations-ID haben.Auf mehrere Ereignisse warten

Ein Weg wäre, eine interne Datenstruktur innerhalb des Microservices zu behalten, die die Buchhaltung durchführt, und wenn alles erfüllt ist, wird eine entsprechende Aktion ausgelöst. Das Problem bei diesem Ansatz ist jedoch, dass der Microservice nicht mehr unveränderbar ist.

Gibt es einen besseren Ansatz?

+0

Suchen Sie nach einer Zustandsmaschine ähnlich dem [SAGA-Konzept in NServiceBus] (http://docs.particular.net/nservicebus/sagas/)? –

+0

Das klingt wie ein Job für das [Aggregator] (http://www.enterpriseintegrationpatterns.com/patterns/messaging/Aggregator.html) Muster! –

Antwort

2

Wenn ich richtig verstehe, sieht es so aus, als ob Sie einen CEP (komplexen Ereignisprozessor) benötigen, wie ws02 cep oder andere, die genau das tun. ceps kann Ereignisse zusammenfassen und Aktionen ausführen, wenn bestimmte Bedingungen erfüllt sind.

3

Ein klassisches Beispiel ist, wo eine Bestellung im Verkauf kommt und eine Veranstaltung veröffentlicht wird. Sowohl Finance als auch Shipping sind an der Veranstaltung beteiligt, aber der Versand ist auch für die Veranstaltung aus dem Finanzbereich abonniert.

waiting for all events to come in

Das Komische ist, dass Sie keine Ahnung, auf den Auftrag haben, in dem die Nachrichten ankommen. Das Ereignis aus dem Verkauf kann einen technischen Fehler verursachen, da die Datenbank offline ist. Es wird möglicherweise erneut in die Warteschlange eingereiht oder in einer Fehlerwarteschlange für Vorgänge, die es erneut versuchen, enden. In der Zwischenzeit könnte die Veranstaltung aus dem Finanzbereich eintreffen. Also theoretisch das Ereignis aus dem Verkauf sollte zuerst und dann das Finanzereignis ankommen, aber in der Praxis kann es umgekehrt sein.

Es gibt eine Reihe von Lösungen hier, aber ich habe die grafischen nie gemocht. Als .NET-Entwickler habe ich in der Vergangenheit K2 und Windows Workflow Foundation verwendet, aber die flexibelsten Lösungen werden im Code erstellt, nicht über eine grafische Benutzeroberfläche.

Ich würde derzeit NServiceBus oder MassTransit dafür verwenden. Nebenbei arbeite ich derzeit bei Particular Software und wir machen NServiceBus. NServiceBus hat Sagas für diese Art von Arbeit (documentation) und Sie können auch in meinem Weblog über eine presentation lesen, inkl. Code auf GitHub.

Der Begriff saga ist eine Art geladen, aber es behandelt im Grunde lange laufende (Geschäfts-) Prozesse. Gregor Hohpe nennt es eine Process Manager (link).

Zusammenfassend, was Sagas tun: Sie werden von eingehenden Nachrichten instanziiert und haben Status. Eingehende Nachrichten werden basierend auf einer Korrelations-ID an eine bestimmte Saga-Instanz gebunden/versandt, z. B. customer id oder order id. Sobald die Nachricht (das Ereignis) verarbeitet wurde, wird der Status gespeichert, bis eine neue Nachricht eintrifft oder bis der Code die Saga als abgeschlossen kennzeichnet und der Status aus dem Speicher entfernt wird.

Wie gesagt, in der .NET-Welt unterstützen MassTransit und NServiceBus dies, aber es gibt höchstwahrscheinlich Alternativen in anderen Umgebungen.