Microservices et modèle canonique

9

Lorsque je lisais sur les microservices sur ce site , je suis tombé sur la déclaration ci-dessous. Qu'entend-on par schéma canonique? N'est-ce pas la même chose que le modèle de domaine?

Le modèle d'architecture de microservices rejette également d'autres parties de SOA, telles que le concept d'un schéma canonique.

web-services soa microservices nginx Punter Vicky
la source
Connaissez-vous la source de cette déclaration? (à des fins de liaison)
Jack
Bien sûr Jack, c'est ici - nginx.com/blog/introduction-to-microservices/…
Punter Vicky
Je suppose que cet article Wikipedia est ce que vous recherchez. Cependant, je ne trouve pas l'article facile à comprendre.
Arseni Mourzenko
Merci @ArseniMourzenko. Je crois que même dans l'architecture de microservices, la demande et la réponse doivent se conformer à certains modèles de données. Pas encore incapable de comprendre pourquoi il est considéré comme rejeté par l'architecture de microservices.
Punter Vicky
2
Certains modèles de données oui, mais il me semble que l'article fait référence à des modèles de données "partagés" ou "communs" entre 2 services ou plus. Le schéma canonique est un modèle destiné à enregistrer des services dans les transformations de données d'exécution. Une "langue" commune entre les services. Il semble donc que l'article insiste sur l'indépendance totale des États membres par rapport à l '«écosystème» où ils vivent. Prenons par exemple la mention qu'il fait à ESB. ESB exige généralement un modèle de données d'entreprise (messages) qui sera commun à tous dans le bus. MS refuse d'être attaché à toute restriction du système externe.
Laiv

Réponses:

5

Je m'excuse d'avance de m'être appuyé sur le commentaire @ArseniMourzenko, mais une fois que j'ai commencé à lire Wikipédia, j'ai immédiatement compris ce que signifie le schéma canonique .

Voici le commentaire d'OP qui se concentre sur le vrai doute

Je crois que même dans l'architecture de microservices, la demande et la réponse doivent se conformer à certains modèles de données.

Certains modèles de données oui, mais il semble que l'article se réfère à des modèles de données "partagés" ou "communs" entre 2 services ou plus.

Le schéma canonique est un modèle destiné à enregistrer des services dans les transformations de données d'exécution. Il vous évite également la duplication de code. Mais vous couplez également votre service à un modèle de données externe. (Voir les diagrammes sur la page de Wikipédia liée ci-dessus)

C'est une sorte de «langage» commun aux services.

Il semble donc que l'article insiste sur l'indépendance totale des États membres par rapport à l '«écosystème» où ils vivent.

Prenons par exemple la mention qu'il fait à ESB.

Ils évitent également d'utiliser des ESB et implémentent à la place des fonctionnalités de type ESB dans les microservices eux-mêmes.

ESB exige généralement un modèle de données d'entreprise (messages) qui sera commun à toutes les personnes connectées au bus.

Donc, revenons à l'article, semble que l'auteur pointe sur le fait que MS refuse d'être attaché à tout système externe (et leurs contraintes) .

Laiv
la source
Merci @Laiv. J'attribuerai la prime dans 9 heures - ainsi me restreint :)
Punter Vicky
1

Les microservices sont une question de cohésion étroite et de couplage lâche. Au sein d'un microservice, vous avez une cohésion étroite, mais entre les microservices, vous avez un couplage lâche et vous voulez donc éviter les schémas partagés ou les contrats de données. Si vous constatez que des microservices effectuent des appels synchrones entre eux d'une manière qui exige qu'ils partagent un schéma commun, cela peut indiquer que vous avez mal défini vos limites de service.

Les microservices doivent être étroitement alignés sur les contextes délimités, dans le langage de conception pilotée par domaine.

pnschofield
la source
If you find that you have microservices making synchronous calls. Pas nécessairement des appels asynchrones. Cela peut également arriver avec des messages asynchrones ESB. Je pense que cela se concentre sur le fait d'être couplé à des schémas partagés ou des contrats de données. Je suppose que dans l'architecture MS, il convient d'éviter toute communication p2p entre les services. La communication devrait se faire via des applications au lieu de toute couche interne (couche de service interne) ou externe (ESB, file d'attente, etc.)
Laiv