I servizi devono comunicare direttamente tra loro in un'architettura di microservizio?

Se vuoi che i tuoi servizi siano come in questa immagine, allora sì: Nonèchenonpuoifarlo,malamaggiorpartedellevolteavràconseguenzenegative.LacomunicazionetramiteRESTnondisaccoppiasignificativamenteituoiservizi.Quandoalcuneinterfaccediserviziocambiano,èprobabilechetuttiiservizidipendentidebbanoesseremodificatieridistribuiti.Inoltre,duranteilridistribuzionedelservizio,dovraidisattivaretuttiiservizidipendenti,ilchenonèconsideratounbuonprogettoperglistandarddidisponibilitàelevata.

Allafine,avremol'applicazionemicroservizicheèpiùlentadiun'appmonolitealternativa,maconquasituttiglistessiproblemi!

Nonsonod'accordocon@RobertHarvey

Inpractice,however,oneormoreofyourmicroservices(perhapsallofthem)willtalktosomecentraldatastorelikeaSQLdatabase.

Ildatabasediintegrazioneè antipattern noto

Una soluzione molto migliore è utilizzare il modello di iscrizione-sottoscrizione per rendere la comunicazione tra i servizi asincroni:

Daiun'occhiataalmodoCQRS/ESdiimplementarequestometododicomunicazione,GregYoungealtriragazzi offre tantissimi video sull'argomento. Basta google per la parola chiave "CQRS / ES". Con questo approccio, ciascun servizio diventerà editore e abbonato allo stesso tempo, consentendo ai servizi di essere molto meno accoppiati.

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

Riceverai molte ottime idee leggendo ciò che Udi Dahan ha da dire su SOA .

A service is the technical authority for a specific business capability. Any piece of data or rule must be owned by only one service.

What this means is that even when services are publishing and subscribing to each other’s events, we always know what the authoritative source of truth is for every piece of data and rule.

Also, when looking at services from the lens of business capabilities, what we see is that many user interfaces present information belonging to different capabilities – a product’s price alongside whether or not it’s in stock. In order for us to comply with the above definition of services, this leads us to an understanding that such user interfaces are actually a mashup – with each service having the fragment of the UI dealing with its particular data.

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

Should these services be able to talk directly to each other? If so wouldn't that make them couple which goes against the concept on microservices?

Se due servizi si scambiano messaggi tra loro, allora si otterrà un accoppiamento. La risposta principale è che si associano all'API dell'altro servizio - il contratto che il servizio promette di mantenere stabile anche quando i suoi interni stanno cambiando.

Inoltre, tecniche come discovery dei servizi possono alleviare la dipendenza da un fornitore di servizi specifico e i broker di messaggi possono scindere i produttori e i consumatori (devono ancora capire i reciproci messaggi e come interagire con l'API del broker di messaggi - non c'è magia)

Dipende da cosa intendi per "direttamente".

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

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

Should these services be able to talk directly to each other? If so wouldn't that make them couple which goes against the concept on microservices?

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

Quello che stai veramente cercando con i microservizi è accoppiamento lento ; puoi ottenere ciò semplicemente disponendo di un microservizio che interroga l'altro tramite la sua API pubblica o utilizzando un bus eventi.

In pratica, comunque 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 avere un microservizio che altera i dati del database in qualche modo, che l'altro microservice interrogherà per raccogliere la modifica.

Sembra che quando si parla di SOA e architettura in generale, le persone vengano coinvolte in semantica e gergo. Cosa rende un servizio "micro"? In definitiva, è un insieme di caratteristiche che, in qualunque "sistema di punteggio" si sta utilizzando, chiaramente non rendono il servizio "non micro". Che cosa ha detto la giustizia suprema della corte sull'indecenza? "Lo saprò quando lo vedrò."

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

Should the client call them directly one after another to get the data it needs to load up a web page on the client?

Dipende; tuttavia, suggerirei di fornire funzionalità direttamente utilizzabili al client e di nascondere (incapsulare) i dettagli di come i risultati vengono assemblati (ad esempio tramite più servizi micro).

Se troppa logica è coinvolta nel combinare i risultati dei singoli servizi di micro-cliente da parte del cliente, ciò potrebbe inavvertitamente causare l'intrusione di alcune logiche di business nel client. Può anche esporre più client dell'architettura interna al client di quanto si desideri, impedendo in seguito il refactoring dei microservizi.

Quindi, questo significa con i microservizi, a volte è utile avere un microservizio wrapper che fornisce al client 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 verso il cliente sono probabilmente più costosi che dai tuoi microservizi l'uno all'altro).

Se osservi la direzione che sta prendendo GraphQL, ad esempio, troverai i client che inviano query direttamente rilevanti a un endpoint, che può o meno essere implementato come una raccolta di micrservices. Poiché l'architettura dei microservizi è nascosta dietro GraphQL, ciò rende l'architettura più facile da ridefinire e anche più amichevole con il cliente. Vedi, ad esempio, link .

Lo scopo principale dei micro-servizi è quello di rendere l'applicazione liberamente accoppiata. Pertanto, i servizi non possono chiamarsi l'un l'altro. Altrimenti, sarà accoppiato in modo congiunto. Ma cosa faremo se abbiamo due servizi che devono essere condivisi? La risposta è Message Broker. Pertanto, il servizio che ottiene i dati dal client può condividere i dati con il broker di messaggi centrale, quindi i servizi devono utilizzare tali dati per consumarlo, trasformarlo e inserirlo nella propria memoria di dati. Raccomando Kafka perché puoi unire i dati di diversi argomenti al volo con Kafka Stream. PS. meglio separare i tuoi micro-servizi per caratteristica.