L'uso di un broker di messaggi è in linea con i Microservizi di costruzione di Sam Newman?

Ok, ci proverò qui.

In primo luogo, l'opinione di Sam è considerata il modo normale di "fare" i micro-servizi, ma ci sono dei compromessi.

1. La coreografia significa che gli attori agiscono in modo indipendente ma secondo una serie di istruzioni condivise. Questo è in contrasto con l'orchestrazione dove c'è un conduttore centrale che dice ai giocatori cosa fare e quando farlo.

   L'orchestrazione è comunemente associata agli ESB che contengono molta logica aziendale (si pensi agli script e alle scelte) e distribuiscono il lavoro ai servizi.

   La coreografia è più comunemente associata a sistemi event-driven, in cui i servizi trasmettono eventi al mondo e le parti interessate agiscono indipendentemente su questi eventi.

2. Il middleware muto implica che il middleware non reagisce attivamente al contenuto dei messaggi che trasporta. Instrada "roba" da A a B in base all'indirizzo sulla busta. La maggior parte dei middleware di messaggistica è stupida sotto questo aspetto, sebbene spesso vi sia un grado di intelligenza aggiunto per fornire garanzie di consegna, ad es. esattamente una sola volta. Questo è, probabilmente, non l'intelligenza di per sé, ma è ancora, a mio parere, un po 'troppo intelligente a causa di problemi di transazione, e la semantica della gestione degli errori, ma non permette ancora di andare lì. Fidati di me quando dico che gli architetti discutono su questa roba tutto il tempo, e Sam cade dal lato della luce e della verità qui, se non la convenienza e la semplicità.

3. Se hai un middleware stupido, i micro-servizi devono essere assolutamente degli endpoint intelligenti, altrimenti hai un sistema fragile (tende a rompersi facilmente) del peggior tipo. Quanta intelligenza dipende da come vuoi affrontare il sovraccarico e il fallimento. Dai un'occhiata a tutti i gadget utilizzati da Netflix per aggiungere questi smart ai micro-servizi in modo riutilizzabile, ad es. Hystrix.

4. No. Per quanto il middleware non dovrebbe essere troppo intelligente, non dovrebbe essere stupido. Kafka, ZeroMQ e così via sono sottosistemi altamente sofisticati quando si desidera eseguire correttamente i sistemi basati sugli eventi. Ciò non significa che devi usarli, ma hanno alcune caratteristiche utili. La maggior parte dei sistemi su larga scala fa entrambe le cose. Le cose sincrone sono fatte usando la richiesta / risposta http. Roba asincrona utilizza la messaggistica. La messaggistica può essere centralizzata (Kafka) o distribuita (ZeroMQ locale), ma quelli centralizzati possono facilmente isolarti dall'errore / recupero del servizio.