Les services doivent-ils communiquer directement entre eux dans une architecture de microservices?
J'ai un certain nombre de services Web qui forment une application Web. Les clients peuvent accéder à ces services via les appels aux API REST.
Ces services devraient-ils pouvoir communiquer directement entre eux? Si oui, cela ne les rendrait-il pas contraires au concept des microservices?
Le client doit-il les appeler directement les uns après les autres pour obtenir les données dont il a besoin pour charger une page Web sur le client?
Ou devrais-je avoir une autre couche au-dessus de mes services, qui gère une demande du client, récupère les données de cette demande, puis les renvoie au client?
Si vous voulez que vos services ressemblent à cette photo, alors oui: 
Ce n'est pas comme si vous ne pouviez pas le faire, mais la plupart du temps cela aura de mauvaises conséquences. La communication via REST ne dissociera pas vos services de manière significative. Lorsque certaines interfaces de service changent, tous les services dépendants devront probablement être modifiés et redéployés. De plus, lors du redéploiement du service, vous devrez mettre tous les services dépendants vers le bas, ce qui n'est pas considéré comme une bonne conception pour les normes de haute disponibilité.
En fin de compte, vous aurez une application de microservices qui est plus lente que l'application monolithique alternative, mais ayant presque tous les mêmes problèmes!
Je dois être en désaccord avec @Robert Harvey
En pratique, cependant, un ou plusieurs de vos microservices (peut-être tous) parleront à un magasin de données central comme une base de données SQL.
La base de données d'intégration est contre-modèle bien conn
Une bien meilleure solution consiste à utiliser un modèle de publication-abonnement afin de rendre la communication entre vos services asynchrone:
Veuillez jeter un œil à la manière CQRS/ES de mettre en œuvre cette méthode de communication, Greg Young et d'autres gars offrez des tonnes de vidéos Nice sur le sujet. Il suffit de google pour le mot clé "CQRS/ES". Dans cette approche, chaque service deviendra à la fois éditeur et abonné, permettant aux services d'être beaucoup moins couplés.
Voici une bonne série d'articles sur les microservices qui éclaire la controverse autour du sujet. Explication très détaillée avec de belles illustrations.
Vous aurez beaucoup de très bonnes idées en lisant ce que Udi Dahan a à dire sur SOA .
Un service est l'autorité technique pour une capacité commerciale spécifique. Toute donnée ou règle doit appartenir à un seul service.
Cela signifie que, même lorsque les services publient et s’abonnent aux événements de chacun, nous savons toujours quelle est la source de vérité faisant autorité pour chaque élément de données et règle.
De plus, lorsque nous examinons les services du point de vue des capacités commerciales, nous constatons que de nombreuses interfaces utilisateur présentent des informations appartenant à différentes capacités - le prix d'un produit et son stock ou non. Afin de nous conformer à la définition ci-dessus des services, cela nous amène à comprendre que de telles interfaces utilisateur sont en fait un mashup - chaque service ayant le fragment de l'interface utilisateur traitant de ses données particulières.
En ce qui concerne spécifiquement la composition de l'interface utilisateur, l'article de Mauro Servienti sur Composition de l'interface utilisateur est un bon point de départ. Voir aussi la vidéo d'Udi, disponible ici .
Ces services devraient-ils pouvoir communiquer directement entre eux? Si oui, cela ne les rendrait-il pas contraires au concept des microservices?
Si deux services échangent des messages, vous obtiendrez un couplage. La principale réponse est qu'ils se couplent à l'API de l'autre service - le contrat que le service promet de maintenir stable même lorsque ses internes changent.
Au-delà de cela, des techniques telles que découverte de service peuvent atténuer la dépendance vis-à-vis d'un fournisseur de services spécifique, et les courtiers de messages peuvent dissocier les producteurs et les consommateurs (ils ont encore besoin de comprendre les messages des uns et des autres, et comment interagir avec le message API du courtier - il n'y a pas de magie).
Cela dépend de ce que vous entendez par "directement".
Selon l'architecture des microservices, il est parfaitement correct d'avoir des microservices qui invoquent d'autres microservices, soit sur votre propre serveur, soit même sur des serveurs externes, via une interface comme REST.
Ce qui ne va pas, c'est qu'un microservice en appelle un autre en utilisant des invocations directes de méthode; cela ferait des deux microservices une partie du même monolithe.
Ces services devraient-ils pouvoir communiquer directement entre eux? Si oui, cela ne les rendrait-il pas contraires au concept des microservices?
Le couplage n'est pas un mauvais mot. Chaque application a déjà un certain degré de couplage; les applications qui parlent à vos microservices sont déjà couplées aux microservices, sinon elles ne fonctionneraient pas.
Ce que vous recherchez vraiment avec les microservices, c'est couplage lâche ; vous pouvez y parvenir en demandant simplement à un microservice d'interroger l'autre via son API publique ou en utilisant un bus d'événements.
En pratique, cependant, un ou plusieurs de vos microservices (peut-être tous) parleront à un magasin de données central comme une base de données SQL. Selon la façon dont vous souhaitez atteindre votre objectif, vous pouvez simplement demander à un microservice de modifier les données de la base de données d'une manière ou d'une autre, que l'autre microservice interrogera pour détecter la modification.
Il semble qu'en parlant de SOA et d'architecture en général, les gens se retrouvent pris dans la sémantique et le jargon. Qu'est-ce qui rend un service "micro"? En fin de compte, c'est un ensemble de caractéristiques qui, quel que soit le "système de notation" que vous utilisez, ne rendent pas le service "non micro". Qu'est-ce que la justice de la Cour suprême a dit au sujet de l'indécence? "Je le saurai quand je le verrai."
Je suis sûr que certaines personnes diront que c'est une non-réponse, mais elles manquent de raison. Les architectures de micro-services visent à éviter plusieurs problèmes, parmi lesquels la question du "couplage étroit". Donc, si vous finissez par créer un enchevêtrement de micro-services qui dépendent de trop de détails les uns des autres, vous avez créé un couplage étroit qui - que vous utilisiez un bus de messages pub/sub ou des appels directs - détruit votre capacité à composer de nouvelles solutions à partir des pièces, à reconfigurer des pièces individuelles sans faire tomber l'ensemble du système, etc., etc.
Le but principal des micro-services est de rendre votre application faiblement couplée. Par conséquent, les services ne peuvent pas s’appeler. Sinon, il sera couplé étroitement. Mais qu'allons-nous faire si nous avons deux services qui doivent partager des données? La réponse est Message Broker. Ainsi, le service qui obtient les données du client peut partager les données avec le courtier de messages central, puis les services doivent utiliser ces données peuvent les consommer, les transformer et les placer dans son propre stockage de données. Je recommande Kafka parce que vous pouvez joindre des données de différents sujets à la volée avec Kafka Stream. PS. Mieux pour séparer vos micro-services par fonctionnalité.
Le client doit-il les appeler directement les uns après les autres pour obtenir les données dont il a besoin pour charger une page Web sur le client?
Ça dépend; Cependant, je suggère de fournir des capacités directement utilisables au client et de masquer (encapsuler) les détails de la façon dont les résultats sont assemblés (par exemple via plusieurs micro-services).
Si trop de logique est impliquée dans la combinaison des résultats individuels des micro-services par le client, cela peut provoquer par inadvertance une logique métier de se glisser dans le client. Il peut également exposer plus de votre architecture interne au client que vous ne le souhaiteriez, gênant la refactorisation ultérieure des microservices.
Donc, cela signifie qu'avec les microservices, il est parfois utile d'avoir un microservice wrapper qui fournit au client un point de terminaison ayant des abstractions utiles et qui effectue une coordination de niveau supérieur d'autres microservices (peut-être maintenant plus internes).
(De plus, les allers-retours vers le client sont probablement plus chers que vos microservices entre eux.)
Si vous regardez la direction prise par GraphQL, par exemple, vous trouverez des clients émettant des requêtes directement pertinentes à un point de terminaison, qui peuvent ou non être implémentées comme une collection de micrservices. Comme l'architecture des microservices est cachée derrière GraphQL, cela rend l'architecture plus facile à refactoriser et aussi plus conviviale pour le client. Voir, par exemple, https://stackoverflow.com/a/38079681/471129 .