it-swarm.com.de

E-Mail-Service in Microservice-Architektur

Wer sollte das Senden von E-Mails in der Microservice-Architektur als E-Mail-Versand mit APIs wie Sendgrid, Mandrill usw. behandeln?

  • jeder Microservice sollte für sich gesendet werden, da es sich nur um eine HTTP-API handelt (einige Nachteile: Jeder Microservice sollte die E-Mails jedes Benutzers im System kennen, Vorteile: einfach zu implementieren)
  • ein anderer Microservice sollte E-Mails basierend auf Ereignissen senden (einige Nachteile: Single Point of Failure, Pro: E-Mails wären nur diesem Microservice bekannt, und das Ändern von E-Mails im Profil würde sich nur an einer Stelle ändern).
8
user1318496

Wie Laiv in den Kommentaren hervorhob, ist dies keine eindeutige Antwort. Viel hängt davon ab, wo Ihre Prioritäten liegen.

Ein einzelner zentraler Mailingdienst ist möglicherweise der sauberste und "ordnungsgemäßste" in einer Microservice-Umgebung. Es ist sicherlich etwas, über das ich ernsthaft nachdenken würde.

Das Erstellen einer konfigurierbaren E-Mail-Bibliothek, um die Details des verwendeten E-Mail-Dienstes zu abstrahieren, und das Verknüpfen jedes Mikrodienstes, an den E-Mails gesendet werden müssen, ist eine weitere Option, die durchaus sinnvoll sein kann (und natürlich seit Jahrzehnten).

Der Vorteil der ersten Option (über ihre architektonische Reinheit hinaus) besteht darin, dass Sie nur eine einzige Änderung vornehmen müssen, wenn sich in der E-Mail-Umgebung etwas ändert. Nachteil ist, dass Sie jetzt einen einzigen Fehlerpunkt eingeführt haben. Wenn der von Ihnen erstellte Mail-Dienst aus irgendeinem Grund ausfällt, können Sie von überall aus überhaupt keine E-Mails mehr senden. Das Ausführen mehrerer Instanzen und Load Balancer, um den Datenverkehr zwischen ihnen zu leiten, kann dieses Risiko auf Kosten einer höheren Komplexität teilweise verringern.

Die zweite Option hat den entscheidenden Nachteil, dass Sie jeden einzelnen Microservice neu erstellen und erneut bereitstellen müssen, wenn sich Ihre E-Mail-Bibliothek ändert.

8
jwenting

Es ist am besten, externe APIs in einen internen Service mit einer herstellerneutralen API einzuschließen. Auf diese Weise können Sie den externen API-Anbieter mit nur einer einzigen Serviceänderung wechseln.

Jeder Service, den Sie haben, ist möglicherweise ein einzelner Fehlerpunkt (vorausgesetzt, alle erledigen wesentliche Dinge). Wenn Sie diesbezüglich Bedenken haben, sollten Sie sich mit Hochverfügbarkeits-Setups befassen, die redundante zustandslose Dienste hinter Load Balancern mit automatischem Failover verwenden, oder sich mit Nachrichtenbrokerlösungen befassen, bei denen die Kommunikation zwischen Diensten über einen zuverlässigen Nachrichtenbroker erfolgt, der eine moderate Ausfallzeit eines Dienstes bis dahin ermöglicht ist bereit, erneut Nachrichten zu empfangen.

3
Joeri Sebrechts