Microservizi e modello canonico

Quando stavo leggendo dei microservizi su questo sito , mi sono imbattuto nella seguente dichiarazione. Cosa si intende con uno schema canonico? Non è lo stesso del modello di dominio?

Il modello di architettura dei microservizi rifiuta anche altre parti della SOA, come il concetto di uno schema canonico.

— Punter Vicky
fonte

Ti capita di conoscere la fonte di tale affermazione? (ai fini del collegamento)

— Jack,

Certo Jack, è qui - nginx.com/blog/introduction-to-microservices/…

— Punter Vicky

Suppongo che questo articolo di Wikipedia sia quello che stai cercando. Tuttavia, non trovo l'articolo facile da capire.

— Arseni Mourzenko,

Grazie @ArseniMourzenko. Credo che anche nell'architettura dei microservizi, la richiesta e la risposta debbano essere conformi ad alcuni modelli di dati. Non è ancora in grado di capire perché sia indicato come rifiutato dall'architettura dei microservizi.

— Punter Vicky,

Alcuni modelli di dati sì, ma mi sembra che l'articolo si riferisca a modelli di dati "condivisi" o "comuni" tra 2 o più servizi. Lo schema canonico è un modello pensato per salvare i servizi dalle trasformazioni dei dati di runtime. Un "linguaggio" comune tra i servizi. Sembra quindi che l'articolo stia enfatizzando la totale indipendenza della SM dall' "ecosistema" in cui vive. Prendiamo ad esempio la menzione che fa a ESB. ESB richiede di solito un modello di dati aziendali (messaggi) che sarà comune a tutti gli utenti del bus. MS rifiuta di essere collegato a qualsiasi costrizione del sistema esterno.

— Laiv

Risposte:

Mi scuso in anticipo per aver fatto affidamento sul commento di @ArseniMourzenko, ma una volta che ho iniziato a leggere Wikipedia ho capito subito cosa significa Schema canonico .

Qui il commento di OP che si concentra sul vero dubbio

Credo che anche nell'architettura dei microservizi, la richiesta e la risposta debbano essere conformi ad alcuni modelli di dati.

Alcuni modelli di dati sì, ma sembra che l'articolo faccia riferimento a modelli di dati "condivisi" o "comuni" tra 2 o più servizi.

Lo schema canonico è un modello pensato per salvare i servizi dalle trasformazioni dei dati di runtime. Ti salva anche dalla duplicazione del codice. Ma poi stai accoppiando il tuo servizio anche a un modello di dati esterno. (Vedi i diagrammi alla pagina di Wikipedia collegata sopra)

È una sorta di "linguaggio" comune tra i servizi.

Sembra quindi che l'articolo stia enfatizzando la totale indipendenza della SM dall'ecosistema in cui vive.

Prendiamo ad esempio la menzione che fa a ESB.

Evitano inoltre di utilizzare ESB e implementano invece funzionalità simili a ESB nei microservizi stessi.

ESB di solito richiede un modello di dati aziendale (messaggi) che sarà comune per tutti coloro che sono collegati al bus.

Quindi, tornando all'articolo, sembra che l'autore stia indicando il fatto che MS rifiuta di essere collegato a qualsiasi sistema esterno (e ai loro vincoli) .

— LAIV
fonte

Grazie @Laiv. Assegnerò la taglia in 9 ore - quindi mi sta limitando :)

— Punter Vicky

I microservizi si basano sulla coesione stretta e sull'accoppiamento lento. All'interno di un microservizio, hai una stretta coesione, ma tra microservizi hai un accoppiamento lento e quindi vuoi evitare schemi condivisi o contratti di dati. Se scopri di avere microservizi che si scambiano chiamate sincrone in un modo che richiede che condividano uno schema comune, ciò può indicare che hai definito in modo errato i confini del tuo servizio.

I microservizi dovrebbero essere strettamente allineati ai contesti limitati, nel linguaggio Design guidato dal dominio.

— pnschofield
fonte

If you find that you have microservices making synchronous calls. Chiamate non necessariamente asincrone. Potrebbe accadere anche con i messaggi asincroni ESB. Penso che si concentri sul fatto di essere accoppiato a schemi condivisi o contratti di dati. Presumo che nell'architettura MS, dovrebbe essere evitata qualsiasi comunicazione p2p tra servizi. La comunicazione dovrebbe avvenire attraverso le applicazioni anziché qualsiasi livello interno (livello di servizio interno) o esterno (ESB, coda, ecc.)

— Laiv