I servizi dovrebbero dialogare direttamente tra loro in un'architettura a microservizi?

Ho un numero di servizi web che formano un'applicazione web. I clienti possono accedere a questi servizi tramite chiamate API REST.

Questi servizi dovrebbero essere in grado di parlare direttamente tra loro? Se è così, ciò non li renderebbe una coppia che va contro il concetto di microservizi?

Il client dovrebbe chiamarli direttamente uno dopo l'altro per ottenere i dati necessari per caricare una pagina Web sul client?

O dovrei avere un altro livello in cima ai miei servizi, che gestisce una richiesta dal client, recupera i dati per quella richiesta e poi li restituisce al client?

Se vuoi che i tuoi servizi appaiano come in questa immagine, allora sì: non è che non puoi farlo, ma il più delle volte avrà conseguenze negative. La comunicazione tramite REST non disaccoppierà significativamente i tuoi servizi. Quando alcune interfacce di servizio cambiano, molto probabilmente tutti i servizi dipendenti devono essere cambiati e ridistribuiti. Inoltre, durante la ridistribuzione del servizio, è necessario disattivare tutti i servizi dipendenti, che non è considerato un buon progetto per gli standard di elevata disponibilità.

Alla fine, avrai un'applicazione di microservizi che è più lenta di un'applicazione monolite alternativa, ma con quasi tutti gli stessi problemi!

Non sono d'accordo con @Robert Harvey

In pratica, tuttavia, uno o più microservizi (forse tutti) parleranno con un archivio dati centrale come un database SQL.

Il database di integrazione è noto antipattern

Una soluzione molto migliore consiste nell'utilizzare il modello di pubblicazione e sottoscrizione per rendere asincrone la comunicazione tra i servizi:

Dai un'occhiata al modo CQRS / ES di implementare questo metodo di comunicazione, Greg Young e altri ragazzi offrono tonnellate di bei video sull'argomento. Basta google per la parola chiave "CQRS / ES". In questo approccio, ogni servizio diventerà editore e abbonato allo stesso tempo, consentendo ai servizi di essere molto meno accoppiati.

Ecco una buona serie di articoli sui microservizi che fanno luce sulla controversia sull'argomento. Spiegazione molto dettagliata con belle illustrazioni.

Otterrai molte ottime idee dalla lettura di ciò che Udi Dahan ha da dire sulla SOA .

Un servizio è l'autorità tecnica per una specifica capacità aziendale. Qualsiasi dato o regola deve essere di proprietà di un solo servizio.

Ciò significa che anche quando i servizi pubblicano e si iscrivono a vicenda, sappiamo sempre qual è la fonte autorevole di verità per ogni dato e regola.

Inoltre, quando si guardano i servizi dall'obiettivo delle capacità aziendali, ciò che vediamo è che molte interfacce utente presentano informazioni appartenenti a capacità diverse - il prezzo di un prodotto insieme al fatto che sia disponibile o meno. Per consentirci di rispettare la suddetta definizione di servizi, questo ci porta a capire che tali interfacce utente sono in realtà un mashup - con ogni servizio che ha il frammento dell'interfaccia utente che si occupa dei suoi dati particolari.

In particolare per quanto riguarda la composizione dell'interfaccia utente, l'articolo di Mauro Servienti sulla composizione dell'interfaccia utente è un buon punto di partenza. Vedi anche il video di Udi, disponibile qui .

Questi servizi dovrebbero essere in grado di parlare direttamente tra loro? Se è così, ciò non li renderebbe una coppia che va contro il concetto di microservizi?

Se due servizi si scambiano messaggi tra loro, otterrai un accoppiamento. La risposta principale è che si accoppiano all'API dell'altro servizio: il contratto che il servizio promette di mantenere stabile anche quando i suoi interni cambiano.

Oltre a ciò, tecniche come la scoperta di servizi possono facilitare la dipendenza da un determinato fornitore di servizi e i broker di messaggi possono disaccoppiare produttori e consumatori (devono ancora capire i messaggi degli altri e come interagire con l'API del broker di messaggi - non c'è magia ).

Dipende da cosa intendi per "direttamente".

È perfettamente corretto, secondo l'architettura dei microservizi, disporre di microservizi che invocano altri microservizi, sul proprio server o anche su server esterni, tramite un'interfaccia come REST.

Ciò che non va bene è che un microservizio invochi un altro usando invocazioni di metodo diretto; ciò renderebbe entrambi i microservizi parte dello stesso monolite.

Questi servizi dovrebbero essere in grado di parlare direttamente tra loro? Se è così, ciò non li renderebbe una coppia che va contro il concetto di microservizi?

L'accoppiamento non è una parolaccia. Ogni applicazione ha già un certo grado di accoppiamento; le applicazioni che parlano ai tuoi microservizi sono già associate ai microservizi, altrimenti non funzionerebbero.

Quello che stai veramente cercando con i microservizi è l' accoppiamento lento ; puoi ottenerlo semplicemente facendo interrogare un microservizio all'altro attraverso la sua API pubblica o usando un bus eventi.

In pratica, tuttavia, uno o più dei tuoi microservizi (forse tutti) parleranno con un archivio dati centrale come un database SQL. A seconda di come vuoi raggiungere il tuo obiettivo, potresti semplicemente fare in modo che un microservizio modifichi i dati del database in qualche modo, che l'altro microservizio interrogherà per raccogliere la modifica.

Sembra che quando si parla di SOA e dell'architettura in generale, le persone rimangono intrappolate nella semantica e nel gergo. Cosa rende un servizio "micro"? In definitiva, è un insieme di caratteristiche che, in qualunque "sistema di punteggio" che stai utilizzando, chiaramente non rendono il servizio "non micro". Cosa disse la giustizia della corte suprema sull'indecenza? "Lo saprò quando lo vedrò."

Sono sicuro che alcune persone diranno che questa è una non-risposta, ma poi manca il punto. Le architetture di micro-servizi hanno lo scopo di evitare diversi problemi, tra cui il problema dell '"accoppiamento stretto". Quindi, se finisci per creare un groviglio di micro-servizi che dipendono da troppi dettagli fini l'uno dell'altro, hai creato un accoppiamento stretto che, sia che tu stia utilizzando un bus pub / messaggio secondario o chiamate dirette, distrugge la tua capacità di comporre nuove soluzioni dai pezzi, riconfigurare i singoli pezzi senza far crollare l'intero sistema, ecc. ecc

Il client dovrebbe chiamarli direttamente uno dopo l'altro per ottenere i dati necessari per caricare una pagina Web sul client?

Dipende; tuttavia, suggerirei di fornire al cliente funzionalità direttamente utilizzabili e di nascondere (incapsulando) i dettagli del modo in cui i risultati vengono assemblati (ad esempio tramite più micro-servizi).

Se viene coinvolta troppa logica nel combinare i risultati dei singoli micro-servizi da parte del cliente, ciò potrebbe causare inavvertitamente una certa logica aziendale a insinuarsi nel client. Può inoltre esporre al client più architettura interna di quanto si desideri, ostacolando in seguito il refactoring dei microservizi.

Quindi, ciò significa che con i microservizi, a volte è utile disporre di un microservizio wrapper che fornisce al cliente un endpoint con astrazioni utili e che esegue un coordinamento di livello superiore di altri microservizi (forse ora più interni).

(Inoltre, i viaggi di andata e ritorno per il cliente sono probabilmente più costosi rispetto ai microservizi reciproci.)

Se osservi la direzione presa da GraphQL, ad esempio, troverai i clienti che inviano query direttamente pertinenti a un endpoint, che possono essere implementate o meno come raccolta di microservizi. Poiché l'architettura dei microservizi è nascosta dietro GraphQL, ciò rende l'architettura più semplice da riformattare e anche più amichevole per il cliente. Vedi, ad esempio, https://stackoverflow.com/a/38079681/471129 .

Lo scopo principale dei micro-servizi è quello di rendere la tua applicazione liberamente accoppiata. Pertanto, i servizi non possono chiamarsi. Altrimenti, sarà accoppiato in modo legato. Ma cosa faremo se avremo due servizi che devono essere dati condivisi? La risposta è Message Broker. Quindi il servizio che ottiene i dati dal client può condividere i dati con il broker di messaggi centrale, quindi i servizi devono utilizzare quei dati per consumarli, trasformarli e metterli nella propria memoria dati. Consiglio Kafka perché puoi unire al volo dati di diversi argomenti con Kafka Stream. PS. meglio separare i microservizi per funzionalità.