Hi...
ich spiel mich grade mit (Micro)services und Message-Queues (im speziellen Azure Service Bus) und hätte eine Architekturfrage weil ich mir nicht ganz sicher bin was die "sauberste" Lösung ist.
Beispiel:
Ticket-Service (zuständig für CRUD-Operationen bei Tickets)
Notification-Service (zuständig für Senden von Email-Benachrichtigungen)
Über Ticket-Service wird nun eine neues Ticket erstellt und einem Benutzer zugewiesen. Das Ticket-Service sendet eine "neues-Ticket"-Message in den Notification-Queue.
Notification-Service empfängt die Message und soll an den Benutzer eine Email senden.
Nun gibt es meiner Meinung nach 2 Möglichkeiten:
Alle für das Senden der Nachricht notwendigen Daten (Benutzer und Ticket-Infos) werden direkt in der Message übergeben.
In der Message wird nur die Ticket-Id übergeben und das Notification-Service holt sich die notwendigen Daten vor dem Senden über z.B. eine Web-API die das Ticket-Service zur Verfügung stellt.
Welche Variante wäre die bessere?
lg
Hallo,
pauschal lässt sich das nicht sagen, obwohl ich zu Variante 1 tendiere.
Ein Faktor könnte z.B. die maximale Größe einer Nachricht der Messagequeue sein. Falls deine Payload größer als ein paar KB sein sollte, gibt es möglicherweise Einschränkungen seitens Azure Service Bus.
Variante 2 könnte problematisch sein falls du replizierte und nicht (bzw. letztendlich) konsistente Datenspeicher verwendest. Wenn beim Einfügen deiner Nachricht in die Queue beispielsweise noch nicht alle Replikate aktualisiert wurden und sich deine Queue die Daten aus einem nicht aktualisierten Replikat holt, dann wäre das ein Problem.
Zudem vermeidet Variante 1 eine Abhängigkeit zum Ticket-Service.
Das kommt jetzt ziemlich drauf an, was das für ein Notificationsystem sein soll.
Gründe, die dies beeinflussen:
Notifications sind übrigens nen schlechtes Beispiel für Microservices; denn Notifications sind ein Service-übergreifendes Element, für das man dann doch i.d.R. wieder auf einen Enterprise-Bus zurück greift.
Enterprisebus Elemente können generische Informationen kennen; müssen sie aber nicht.
Dahingehend tendiere ich bei diesen beiden Auswahlmöglichkeiten auch zu 1.
Sollte das Ticket aber ein zentraler Bestandteil des Enterprise-Elements / des Kernbusiness sein, dann könnte es auch Variante 2 sein.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code