Comunicazione microservizi: evitare singoli punti di errore

Come giustamente dici, avere un componente dedicato al trasferimento dei messaggi è sicuramente meglio che avere ogni servizio responsabile per sapere esattamente come raggiungere tutti i servizi di collaborazione. Pertanto, le code di messaggi, i bus di comunicazione, ecc. Sono una buona idea.

E se diventano un unico punto di errore? Bene, fai ciò che fai sempre per robustezza e scalabilità: distribuisci più istanze della coda dei messaggi. Se il tuo ambiente non è in grado di trattenere alcun di loro, è probabile che non avrai comunque alcun lavoro utile. Problema risolto.

Che una topologia o l'altra siano le migliori dipenderà in gran parte dalla forma della comunicazione.

Ad esempio, se invii principalmente messaggi autonomi che non richiedono una conversazione estesa tra i servizi, un bus dei messaggi con broker funziona bene. Ciò è particolarmente vero se i messaggi devono raggiungere più servizi o se sei agnostico a quale servizio preleva il messaggio. La resilienza può essere gestita con una configurazione di broker in cluster che la maggior parte dei broker di messaggi popolari può gestire.

Se le comunicazioni sono prevalentemente bidirezionali, tuttavia, il peer-to-peer potrebbe essere la soluzione giusta. Questo sarebbe particolarmente vero se stai trasmettendo dati tra i servizi. Esistono varie tecniche per mitigare l'accoppiamento, ad esempio l'utilizzo di un servizio di individuazione per identificare un partner appropriato. Esistono anche tecniche comuni per limitare l'accoppiamento di interfaccia. Ad esempio, avere un'API simile a REST e utilizzare un'interfaccia dichiarativa e estensibile per la comunicazione aziendale. JSON è un formato popolare, XML lo era prima ecc.

Questo non vuol dire che non si possa eseguire il peer-to-peer attraverso un bus dei messaggi, ma si finisce per gestire un sacco di stati della sessione che possono complicare le cose. Se le tue comunicazioni sono per lo più eventi con un peer-to-peer, potrebbe essere comunque preferibile farlo per mantenere solo un sistema di messaggistica.

Allo stesso modo, se si esegue principalmente lo streaming con un po 'di passaggio di messaggi, è possibile incorporare un protocollo di eventi nel protocollo di streaming per lo stesso motivo.

E queste non sono le tue uniche opzioni. Per configurazioni complesse, mi piace molto usare ZeroMQ per cui utilizzo un "tessuto" di comunicazione ma applichiamo topologie appropriate dove necessario.

In breve, la migliore topologia di messaggistica dipende dalla natura dei messaggi. Non c'è una risposta corretta ma, sul lato positivo, è un percorso ben battuto. Dovresti essere in grado di ottenere soluzioni valide e pronte all'uso con attenuazioni sensibili a meno che tu non stia facendo qualcosa di molto insolito.