L’article a paru à l’origine sur le Blog de formation et de certification de la Linux Foundation. L’auteur est Marco Fioretti. Si vous souhaitez en savoir plus sur les microservices, pensez à certains de nos cours de formation gratuits, notamment Introduction aux technologies d’infrastructure cloud, Construire des plateformes de microservices avec TARSet Acteurs WebAssembly : du cloud à la périphérie.

Microservices permettent aux développeurs de logiciels de concevoir des applications Internet hautement évolutives et hautement tolérantes aux pannes. Mais comment les microservices d’une plateforme communiquent-ils réellement ? Comment coordonnent-ils leurs activités ou savent-ils avec qui travailler en premier lieu ? Nous présentons ici les principales réponses à ces questions, ainsi que leurs caractéristiques et inconvénients les plus importants. Avant d’approfondir ce sujet, vous voudrez peut-être d’abord lire les articles précédents de cette série, Microservices : définition et principales applications, API dans les microserviceset Introduction à la sécurité des microservices.

Couplage serré, orchestration et chorégraphie

Lorsque chaque microservice peut et doit dialoguer directement avec tous ses microservices partenaires, sans intermédiaires, on a ce qu’on appelle un couplage étroit. Le résultat peut être très efficace, mais rend tous les microservices plus complexes et plus difficiles à modifier ou à faire évoluer. De plus, si l’un des microservices tombe en panne, tout tombe en panne.

La première façon de surmonter ces inconvénients du couplage étroit est d’avoir un contrôleur central de tous, ou au moins certains des microservices d’une plate-forme, qui les fait fonctionner de manière synchrone, tout comme le chef d’orchestre. Dans cette orchestration – également appelée modèle demande/réponse – c’est le chef d’orchestre qui émet les demandes, reçoit leurs réponses et décide ensuite quoi faire ensuite ; c’est-à-dire s’il faut envoyer d’autres demandes à d’autres microservices ou transmettre les résultats de ce travail à des utilisateurs externes ou à des applications clientes.

L’approche complémentaire de l’orchestration est l’architecture décentralisée appelée chorégraphie. Il s’agit de plusieurs microservices qui fonctionnent indépendamment, chacun avec ses propres responsabilités, mais comme des danseurs dans le même ballet. Dans la chorégraphie, la coordination se fait sans supervision centrale, via des messages circulant entre plusieurs microservices selon des règles communes prédéfinies.

Cet échange de messages, ainsi que la découverte des microservices disponibles et de la manière de communiquer avec eux, se font via des bus d’événements. Ce sont des composants logiciels avec des API bien définies pour s’abonner et se désabonner à des événements et pour publier des événements. Ces bus d’événements peuvent être implémentés de plusieurs manières, pour échanger des messages en utilisant des standards tels que XML, SOAP ou Langage de description de services Web (WSDL).

Lorsqu’un microservice émet un message sur un bus, tous les microservices qui se sont abonnés pour écouter sur le bus d’événement correspondant le voient, et savent si et comment y répondre de manière asynchrone, chacun de son côté, sans ordre particulier. Dans cette architecture événementielle, tout ce qu’un développeur doit coder dans un microservice pour le faire interagir avec le reste de la plateforme, ce sont les commandes d’abonnement aux bus d’événements sur lesquels il doit générer des événements, ou les attendre.

Orchestration ou chorégraphie ? Ça dépend

Les deux choix de coordination les plus populaires pour les microservices sont la chorégraphie et l’orchestration, dont la différence fondamentale réside dans l’endroit où ils placent le contrôle : l’un le distribue entre des microservices homologues qui communiquent de manière asynchrone, l’autre dans un conducteur central, qui maintient tous les autres toujours en ligne.

Ce qui est le mieux dépend des caractéristiques, des besoins et des modèles d’utilisation réelle de chaque plate-forme, avec peut-être seulement deux règles qui s’appliquent dans tous les cas. La première est que le couplage étroit réel doit presque toujours être évité, car il va à l’encontre de l’idée même des microservices. Le couplage lâche avec la communication asynchrone correspond bien mieux aux avantages fondamentaux des microservices, à savoir un déploiement indépendant et une évolutivité maximale. Le monde réel, cependant, est un peu plus complexe, alors parlons un peu plus des avantages et des inconvénients de chaque approche.

En ce qui concerne l’orchestration, son principal inconvénient peut être que le contrôle centralisé est souvent, sinon un synonyme, du moins un raccourci vers un point de défaillance unique. Un inconvénient beaucoup plus fréquent de l’orchestration est que, puisque les microservices et un chef d’orchestre peuvent être sur des serveurs ou des nuages ​​différents, connectés uniquement via l’Internet public, les performances peuvent en souffrir, de manière plus ou moins imprévisible, à moins que la connectivité ne soit vraiment excellente. À un autre niveau, avec l’orchestration, pratiquement tout ajout de microservices ou modification de leurs flux de travail peut nécessiter des modifications de nombreuses parties de la plate-forme, pas seulement du chef d’orchestre. Il en va de même pour les échecs : lorsqu’un microservice orchestré échoue, il y aura généralement des effets en cascade : comme d’autres microservices attendant de recevoir des commandes, uniquement parce que le conducteur est temporairement bloqué en attendant des réponses de celui qui a échoué. Du côté positif, précisément parce que la « chaîne de commandement » et la communication sont bien définies et pas vraiment flexibles, il sera relativement facile de savoir ce qui s’est cassé et où. Pour la même raison, l’orchestration facilite le test indépendant de fonctions distinctes. Par conséquent, l’orchestration peut être la voie à suivre chaque fois que les flux de communication à l’intérieur d’une plate-forme basée sur des microservices sont bien définis et relativement stables.

Dans de nombreux autres cas, la chorégraphie peut fournir le meilleur équilibre entre l’indépendance des microservices individuels, l’efficacité globale et la simplicité de développement.

Avec la chorégraphie, un service ne doit émettre que des événements, c’est-à-dire des communications indiquant que quelque chose s’est passé (par exemple, une demande de connexion a été reçue), et tous ses microservices en aval doivent uniquement y réagir, de manière autonome. Par conséquent, changer un microservice n’aura aucun impact sur ceux en amont. Même l’ajout ou la suppression de microservices est plus simple qu’avec l’orchestration. Le revers de la médaille est que, du moins si l’on y va sans prendre de précautions, cela crée plus de chances que les choses tournent mal, dans plus d’endroits et de manière plus difficile à prévoir, tester ou déboguer. Lancer des messages sur Internet en comptant sur tout pour aller bien, mais sans aucun moyen de savoir si tous leurs destinataires les ont reçus et ont tous été capables de réagir de la bonne manière peut rendre la vie très difficile aux intégrateurs système.

Conclusion

Certains workflows sont par nature hautement synchrones et prévisibles. D’autres ne le sont pas. Cela signifie que de nombreuses plates-formes de microservices du monde réel pourraient et devraient probablement combiner les deux approches pour obtenir la meilleure combinaison de performances et de résistance aux pannes ou aux pics de charge. En effet, les pointes de charge temporaires – qui peuvent être mieux gérées avec une chorégraphie – peuvent ne se produire que dans certaines parties d’une plate-forme, et les pannes aux conséquences les plus graves, pour lesquelles une orchestration plus serrée pourrait être plus sûre, uniquement dans d’autres (par exemple, les achats de single produits par les clients finaux, vs commandes d’achat des mêmes produits en gros, pour réapprovisionner l’entrepôt) . Pour les architectes système, peut-être que le pire qui puisse arriver serait de concevoir une architecture qui est soit une orchestration, soit une chorégraphie, mais sans être vraiment conscient (peut-être parce qu’ils ne font que porter sur des microservices une plate-forme monolithique préexistante) de laquelle il s’agit, obtenant ainsi de mauvaises surprises lorsque quelque chose ne va pas, ou lorsque de nouvelles exigences s’avèrent beaucoup plus difficiles que prévu à concevoir ou à tester. Ce qui conduit à la deuxième des deux règles générales mentionnées ci-dessus : ne commencez même pas à choisir entre l’orchestration ou la chorégraphie pour vos microservices, avant d’avoir la meilleure estimation possible de ce que seront leurs charges réelles et leurs besoins en communication.