Le Book Building Microservices décrit en détail les styles mentionnés par @RogerAlsing dans sa réponse.
À la page 43, sous Orchestration vs Chorégraphie, le livre dit:
Alors que nous commençons à modéliser une logique de plus en plus complexe, nous devons faire face au problème de la gestion des processus métier qui s'étendent au-delà des frontières des services individuels. Et avec les microservices, nous atteindrons cette limite plus tôt que d'habitude. [...] En ce qui concerne la mise en œuvre effective de ce flux, nous pouvons suivre deux styles d'architecture. Avec l'orchestration, nous comptons sur un cerveau central pour guider et conduire le processus, un peu comme le chef d'orchestre. Avec la chorégraphie, nous informons chaque partie du système de son travail et la laissons travailler les détails, comme les danseurs qui trouvent leur chemin et réagissent aux autres autour d'eux dans un ballet.
Le livre explique ensuite les deux styles. Le style d'orchestration correspond davantage à l'idée SOA d' orchestration / services de tâches , tandis que le style de chorégraphie correspond aux canaux stupides et aux points de terminaison intelligents mentionnés dans l'article de Martin Fowler.
Style d'orchestration
Sous ce style, le livre ci-dessus mentionne:
Réfléchissons à quoi ressemblerait une solution d'orchestration pour ce flux. Ici, la chose la plus simple à faire serait probablement que notre service client agisse comme le cerveau central. Lors de sa création, il communique avec la banque de points de fidélité, le service de messagerie électronique et le service postal, [...] via une série d'appels de demande / réponse. Le service client lui-même peut alors suivre où se trouve un client dans ce processus. Il peut vérifier si le compte du client a été configuré, ou l'e-mail envoyé, ou le courrier livré. Nous pouvons prendre le diagramme [...] et le modéliser directement dans le code. Nous pourrions même utiliser des outils qui implémentent cela pour nous, peut-être en utilisant un moteur de règles approprié. Des outils commerciaux existent à cet effet sous la forme d'un logiciel de modélisation des processus métier. En supposant que nous utilisons une demande / réponse synchrone, nous pourrions même savoir si chaque étape a fonctionné [...] L'inconvénient de cette approche d'orchestration est que le service client peut devenir trop une autorité centrale. Il peut devenir le hub au milieu d'un web et un point central où la logique commence à vivre. J'ai vu cette approche aboutir à un petit nombre de services «divins» intelligents indiquant aux services anémiques basés sur CRUD quoi faire.
Remarque: Je suppose que lorsque l'auteur mentionne l'outillage, il fait référence à quelque chose comme BPM (par exemple, Activity , Apache ODE , Camunda ). En fait, le site Web Workflow Patterns propose un ensemble impressionnant de modèles pour effectuer ce type d'orchestration et il offre également des détails d'évaluation de différents outils de fournisseurs qui aident à l'implémenter de cette façon. Je ne pense pas que l'auteur laisse entendre qu'il est nécessaire d'utiliser l'un de ces outils pour implémenter ce style d'intégration, cependant, d'autres cadres d'orchestration légers pourraient être utilisés, par exemple Spring Integration , Apache Camel ou Mule ESB
Cependant, d' autres livres que j'ai lus sur le sujet des microservices et en général la majorité des articles que j'ai trouvés sur le Web semblent défavoriser cette approche de l'orchestration et suggèrent plutôt d'utiliser la suivante.
Style de chorégraphie
Sous un style chorégraphique, l'auteur dit:
Avec une approche chorégraphiée, nous pourrions plutôt demander au service client d'émettre un événement de manière asynchrone, selon le client créé. Le service de courrier électronique, le service postal et la banque de points de fidélité se contentent alors de souscrire à ces événements et réagissent en conséquence [...] Cette approche est nettement plus découplée. Si un autre service devait atteindre la création d'un client, il lui suffit de s'abonner aux événements et de faire son travail en cas de besoin. L'inconvénient est que la vue explicite du processus commercial que nous voyons dans [le flux de travail] n'est désormais implicitement reflétée dans notre système [...] Cela signifie qu'un travail supplémentaire est nécessaire pour vous assurer que vous pouvez surveiller et suivre que les bonnes choses ont arrivé. Par exemple, sauriez-vous si la banque de points de fidélité avait un bug et pour une raison quelconque n'a pas créé le bon compte? Une approche que j'aime pour traiter cela est de construire un système de surveillance qui correspond explicitement à la vue du processus métier dans [le flux de travail], mais suit ensuite ce que chacun des services fait en tant qu'entités indépendantes, vous permettant de voir des exceptions étranges mappées sur le flux de processus plus explicite. L'organigramme [...] n'est pas le moteur, mais juste une lentille à travers laquelle nous pouvons voir comment le système se comporte. En général, j'ai constaté que les systèmes qui tendent davantage vers l'approche chorégraphiée sont plus faiblement couplés, et sont plus flexibles et plus susceptibles de changer. Cependant, vous devez effectuer un travail supplémentaire pour surveiller et suivre les processus au-delà des limites du système. J'ai trouvé que les implémentations les plus fortement orchestrées étaient extrêmement fragiles, avec un coût de changement plus élevé. Dans cet esprit, je préfère fortement viser un système chorégraphié, où chaque service est suffisamment intelligent pour comprendre son rôle dans l'ensemble de la danse.
Remarque: À ce jour, je ne suis toujours pas sûr que la chorégraphie soit juste un autre nom pour l' architecture événementielle (EDA), mais si EDA n'est qu'une façon de le faire, quelles sont les autres façons? (Voir également Qu'entendez-vous par «piloté par les événements»? Et Les significations de l'architecture pilotée par les événements ). De plus, il semble que des choses comme CQRS et EventSourcing résonnent beaucoup avec ce style architectural, non?
Maintenant, après cela vient le plaisir. Le livre Microservices ne suppose pas que les microservices vont être implémentés avec REST. En fait, dans la section suivante du livre, ils examinent les solutions basées sur RPC et SOA et enfin REST. Un point important ici est que les microservices n'impliquent pas REST.
Alors, qu'en est-il de HATEOAS? (Hypermedia en tant que moteur de l'état d'application)
Maintenant, si nous voulons suivre l'approche RESTful, nous ne pouvons pas ignorer HATEOAS ou Roy Fielding sera très heureux de dire dans son blog que notre solution n'est pas vraiment REST. Voir son article de blog sur l' API REST Doit être piloté par hypertexte :
Je suis frustré par le nombre de personnes qui appellent une interface basée sur HTTP une API REST. Que faut-il faire pour clarifier le style architectural REST sur la notion que l'hypertexte est une contrainte? En d'autres termes, si le moteur de l'état de l'application (et donc de l'API) n'est pas piloté par l'hypertexte, il ne peut pas être RESTful et ne peut pas être une API REST. Période. Y a-t-il un manuel cassé quelque part qui doit être réparé?
Donc, comme vous pouvez le voir, Fielding pense que sans HATEOAS, vous ne construisez pas vraiment des applications RESTful. Pour Fielding, HATEOAS est la voie à suivre lorsqu'il s'agit d'orchestrer des services. J'apprends juste tout cela, mais pour moi, HATEOAS ne définit pas clairement qui ou quelle est la force motrice derrière réellement suivre les liens. Dans une interface utilisateur qui pourrait être l'utilisateur, mais dans les interactions d'ordinateur à ordinateur, je suppose que cela doit être fait par un service de niveau supérieur.
Selon HATEOAS, le seul lien que le consommateur d'API a vraiment besoin de connaître est celui qui initie la communication avec le serveur (par exemple, POST / order). À partir de ce moment, REST va conduire le flux, car, dans la réponse de ce point de terminaison, la ressource retournée contiendra les liens vers les prochains états possibles. Le consommateur d'API décide ensuite du lien à suivre et fait passer l'application à l'état suivant.
Malgré la fraîcheur que cela semble, le client doit toujours savoir si le lien doit être POST, PUTed, GETed, PATCHed, etc. Et le client doit toujours décider quelle charge utile passer. Le client doit toujours savoir quoi faire en cas d'échec (réessayer, compenser, annuler, etc.).
Je suis assez nouveau dans tout cela, mais pour moi, du point de vue HATEOAs, ce client ou consommateur d'API est un service de haut niveau. Si nous le pensons du point de vue d'un humain, vous pouvez imaginer un utilisateur final sur une page Web, décidant quels liens suivre, mais le programmeur de la page Web devait quand même décider de la méthode à utiliser pour appeler les liens, et quelle charge utile passer. Donc, à mon point, dans une interaction d'ordinateur à ordinateur, l'ordinateur joue le rôle de l'utilisateur final. Encore une fois, c'est ce que nous appelons un service d'orchestrations.
Je suppose que nous pouvons utiliser HATEOAS avec une orchestration ou une chorégraphie.
Le modèle de passerelle API
Un autre modèle intéressant est suggéré par Chris Richardson qui a également proposé ce qu'il a appelé un modèle de passerelle API .
Dans une architecture monolithique, les clients de l'application, tels que les navigateurs Web et les applications natives, effectuent des requêtes HTTP via un équilibreur de charge vers l'une des N instances identiques de l'application. Mais dans une architecture de microservices, le monolithe a été remplacé par une collection de services. Par conséquent, une question clé à laquelle nous devons répondre est de savoir avec quoi les clients interagissent-ils?
Un client d'application, comme une application mobile native, pourrait faire des requêtes HTTP RESTful aux services individuels [...] En apparence, cela pourrait sembler attrayant. Cependant, il est probable qu'il y ait un décalage important dans la granularité entre les API des services individuels et les données requises par les clients. Par exemple, l'affichage d'une page Web peut nécessiter des appels vers un grand nombre de services. Amazon.com, par exemple,
décrit comment certaines pages nécessitent des appels vers plus de 100 services. Faire autant de demandes, même sur une connexion Internet haut débit, sans parler d'un réseau mobile à bande passante plus faible et à latence plus élevée, serait très inefficace et entraînerait une mauvaise expérience utilisateur.
Une bien meilleure approche consiste à ce que les clients effectuent un petit nombre de demandes par page, peut-être aussi peu qu'une, sur Internet vers un serveur frontal appelé passerelle API.
La passerelle API se situe entre les clients de l'application et les microservices. Il fournit des API adaptées au client. La passerelle API fournit une API à granularité grossière aux clients mobiles et une API à granularité plus fine aux clients de bureau qui utilisent un réseau hautes performances. Dans cet exemple, les clients de bureau font plusieurs demandes pour récupérer des informations sur un produit, tandis qu'un client mobile fait une seule demande.
La passerelle API gère les demandes entrantes en adressant des demandes à un certain nombre de microservices sur le LAN hautes performances. Netflix, par exemple,
décrit
comment chaque demande déploie en moyenne six services backend. Dans cet exemple, les demandes à granularité fine d'un client de bureau sont simplement transmises par proxy au service correspondant, tandis que chaque demande à granularité grossière d'un client mobile est traitée en agrégeant les résultats de l'appel de plusieurs services.
Non seulement la passerelle API optimise la communication entre les clients et l'application, mais elle encapsule également les détails des microservices. Cela permet aux microservices d'évoluer sans impact sur les clients. Par exemple, deux microservices peuvent être fusionnés. Un autre microservice peut être partitionné en deux services ou plus. Seule la passerelle API doit être mise à jour pour refléter ces changements. Les clients ne sont pas affectés.
Maintenant que nous avons examiné comment la passerelle API sert d'intermédiaire entre l'application et ses clients, regardons maintenant comment implémenter la communication entre les microservices.
Cela semble assez similaire au style d'orchestration mentionné ci-dessus, juste avec une intention légèrement différente, dans ce cas, il semble s'agir de performances et de simplification des interactions.
.