Servizio di posta elettronica nell'architettura dei microservizi

1

Chi dovrebbe gestire l'invio di e-mail nell'architettura dei microservizi se come e-mail che invia utilizzando API come Sendgrid, Mandrill e così via?

  • ogni microservizio dovrebbe inviare da solo, perché è solo l'API HTTP (alcuni dei contro: ogni microservizio dovrebbe conoscere l'e-mail di ciascun utente nel sistema, vantaggi: facile da implementare)
  • un altro microservizio dovrebbe inviare e-mail in base agli eventi (alcuni dei contro: single point of failure, pro: le e-mail sarebbero conosciute solo da questo microservice e la modifica delle e-mail nel profilo cambierebbe solo in un punto)
posta user1318496 20.06.2018 - 08:42
fonte

2 risposte

5

Come sottolineato da Laiv nei commenti, non è una risposta chiara. Molto dipende da dove sono le tue priorità.

Un singolo servizio di posta centrale può essere il più pulito e il più "appropriato" in un ambiente di microservizi. È certamente qualcosa che prenderei seriamente in considerazione.

Ma costruire una libreria email configurabile per astrarre i dettagli del servizio di posta utilizzato e collegare ogni microservizio che deve inviare email a questa è un'altra opzione che potrebbe essere praticabile (ed è ovviamente come sono state fatte le cose per decenni) .

Il vantaggio della prima opzione (oltre alla sua purezza architettonica) è che hai solo una cosa da cambiare se qualcosa cambia nell'ambiente di posta elettronica. Lo svantaggio è che ora hai introdotto un singolo punto di errore, se il servizio di posta che hai creato non funziona per nessuna ragione, non puoi più inviare email da nessuna parte. Naturalmente, l'esecuzione di più istanze e il bilanciamento del carico per indirizzare il traffico tra di loro può in parte alleviare tale rischio, a costo di una maggiore complessità.

La seconda opzione ha il chiaro svantaggio di dover ricostruire e ridistribuire ogni singolo microservizio se la tua libreria di email cambia.

    
risposta data 21.06.2018 - 07:40
fonte
2

È meglio racchiudere le API esterne in un servizio interno con un'API indipendente dal fornitore. In questo modo puoi cambiare fornitore di API esterne con un solo cambio di servizio.

Ogni servizio che hai è potenzialmente un singolo punto di errore (presupponendo che tutti facciano cose essenziali). Se questo è un problema per te, controlla le configurazioni di alta disponibilità utilizzando i servizi stateless ridondanti dietro load balancer con failover automatico oppure guarda le soluzioni dei broker di messaggi in cui la comunicazione tra i servizi avviene tramite un affidabile broker di messaggi che consente un moderato tempo di inattività di qualsiasi servizio fino a quando è pronto a ricevere nuovamente i messaggi.

    
risposta data 20.06.2018 - 09:09
fonte

Leggi altre domande sui tag