Orchestration de microservices
Quel est le modèle standard d’orchestration de microservices?
Si un microservice ne connaît que son propre domaine, mais qu'il existe un flux de données qui nécessite que plusieurs services interagissent de manière quelconque, quelle est la meilleure façon de procéder?
Disons que nous avons quelque chose comme ça:
- Facturation
- Expédition
Et pour les besoins de l’argumentation, supposons qu’une fois la commande expédiée, la facture doit être créée.
Quelque part, quelqu'un appuie sur un bouton d'une interface graphique: "J'ai terminé, faisons ceci!" Dans une architecture de service monolithique classique, je dirais qu'il existe soit un ESB qui gère cela, soit le service Expédition a des connaissances. du service de facturation et appelle simplement cela.
Mais comment les gens réagissent-ils dans ce nouveau monde de microservices?
Je comprends que cela pourrait être considéré comme hautement basé sur les opinions. mais il y a un côté concret à cela, car les microservices ne sont pas censés faire ce qui précède ... Il faut donc qu'il y ait un "que devrait-il plutôt faire par définition", qui n'est pas fondé sur une opinion?.
Tirer.
Essayer de regrouper les différentes approches ici.
Événements de domaine
L’approche dominante semble consister à utiliser des événements de domaine, chaque service publiant des événements sur ce qui s’est passé et d’autres services pouvant souscrire à ces événements ..__ Cela semble aller de pair avec le concept de points finaux intelligents, muet. les tuyaux décrits par Martin Fowler ici: http://martinfowler.com/articles/microservices.html#SmartEndpointsAndDumbPipes
Procuration
Une autre approche qui semble courante consiste à envelopper le flux d’activité dans son propre service . Où le proxy orchestre l’interaction entre les microservices, comme indiqué dans l’image ci-dessous:
.
Alors, en quoi l'orchestration de microservices est-elle différente de l'orchestration d'anciens services SOA qui ne sont pas “micro”? Pas grand chose du tout.
Les microservices communiquent généralement par http (REST) ou par messagerie/événements. L'orchestration est souvent associée à des plates-formes d'orchestration qui vous permettent de créer une interaction scriptée entre services pour automatiser les flux de travail. A l'époque SOA, ces plates-formes utilisaient WS-BPEL. Les outils actuels n'utilisent pas BPEL. Exemples de produits d’orchestration modernes: chef d’entreprise Netflix, Camunda, Zeebe, applications Azure Logic, Baker.
N'oubliez pas que l'orchestration est un modèle composé qui offre plusieurs fonctionnalités pour créer des compositions de services complexes. Les microservices sont plus souvent considérés comme des services qui ne devraient pas participer à des compositions complexes mais plutôt être plus autonomes.
Je peux voir un microservice appelé dans un flux de travail orchestré pour effectuer un traitement simple, mais je ne vois pas de microservice en tant que service d'orchestrateur, qui utilise souvent des mécanismes tels que la compensation des transactions et le référentiel d'état (déshydratation).
Donc, vous avez deux services:
- Micro service de facturation
- Service micro expédition
Dans la vraie vie, vous auriez quelque chose où vous maintenez l'état d'ordre. Appelons cela le service de commande. Vous avez ensuite des cas d’utilisation pour le traitement des commandes, qui savent quoi faire lorsque la commande passe d’un état à un autre. Tous ces services contiennent un certain ensemble de données, et maintenant vous avez besoin de quelque chose d'autre, qui assure toute la coordination. Cela pourrait être:
- Une interface graphique simple connaissant tous vos services et implémentant les cas d'utilisation ("J'ai terminé" appelle le service d'envoi)
- Un moteur de processus métier qui attend un événement "J'ai terminé". Ce moteur implémente les cas d'utilisation et le flux.
- Un micro-service d'orchestration, disons le service de traitement des commandes lui-même qui connaît le flux/les cas d'utilisation de votre domaine
- Tout ce que je n'ai pas encore pensé
Le point principal avec ceci est que le contrôle est externe. En effet, tous les composants de votre application sont des blocs de construction individuels, faiblement couplés. Si vos cas d'utilisation changent, vous devez modifier un composant à un endroit, qui est le composant d'orchestration. Si vous ajoutez un flux de commande différent, vous pouvez facilement ajouter un autre orchestrateur qui n’interfère pas avec le premier. La conception de micro-services ne concerne pas seulement l'évolutivité et la création d'API REST sophistiquées, mais également une structure claire, des dépendances réduites, ainsi que la réutilisation de données communes et de fonctionnalités partagées au sein de votre entreprise.
HTH, Mark
Si le State doit être géré, le Event Sourcing avec CQRS est le moyen de communication idéal. Sinon, un système de messagerie asynchrone (AMQP) peut être utilisé pour la communication entre microservices.
D'après votre question, il est clair que l'ES avec CQRS devrait être la bonne combinaison. Si vous utilisez Java, jetez un coup d'œil au framework Axon. Ou construisez une solution personnalisée en utilisant Kafka ou RabbitMQ.
la réponse à la question initiale est le modèle SAGA.