Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 | Suche | FAQ

Hauptmenü
myCSharp.de
» Startseite
» Forum
» Suche
» Regeln
» Wie poste ich richtig?

Mitglieder
» Liste / Suche
» Wer ist online?

Ressourcen
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Microsoft Docs

Team
» Kontakt
» Cookies
» Spenden
» Datenschutz
» Impressum

  • »
  • Community
  • |
  • Diskussionsforum
Architektur: Disconnected Services mit Message-Queue
[email protected]
myCSharp.de - Member



Dabei seit:
Beiträge: 407

Themenstarter:

Architektur: Disconnected Services mit Message-Queue

beantworten | zitieren | melden

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
private Nachricht | Beiträge des Benutzers
Sarc
myCSharp.de - Member



Dabei seit:
Beiträge: 426

beantworten | zitieren | melden

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.
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von Sarc am .
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 16112

beantworten | zitieren | melden

Das kommt jetzt ziemlich drauf an, was das für ein Notificationsystem sein soll.

Gründe, die dies beeinflussen:
- Wenn der Benutzer aktuell aktiv in der Anwendung ist, dann reicht evtl. nur eine Nachricht via WebSocket, die im Browser aufpoppt. Kein Grund ihm da eine (zusätzliche) E-Mail zu senden.
- Wenn er nicht in Aktiv in der Anwendung ist, oder die Websocket-Nachricht nicht nach x Minuten liest, dann greift eine Eskalationsstufe, die ihm dann doch die E-Mail senden
- Ist der Benutzer überhaupt nicht aktiv, ist es nacht oder hat die Notification eine gewisse Priorität, dann kannst Du das entsprechend nach Eskalationsstufe erweitern und dann zusätzlich oder direkt eine SMS oder einen automatischen Anruf absetzen.

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 - @blog - @AzureStuttgart - github.com/BenjaminAbt
private Nachricht | Beiträge des Benutzers