Microservices: Que sont les terminaux intelligents et les tubes muets?
J'ai lu un article " Microservices " de Martin Fowler et j'ai du mal à comprendre smart endpoint s et dumb pipes. S'il vous plaît expliquer ces termes, les exemples sont les bienvenus.
Je n’ai pas lu l’article, je ne peux donc que spéculer sur ce qu’il peut signifier exactement, mais comme il donne ESB comme exemple contre microservices et ZeroMQ comme exemple pour les micro-services, j’espère que mes hypothèses seront assez précises:
L'une des idées d'Unix (et de Linux) est de créer de petites applications indépendantes et de les connecter via des canaux. L’ensemble probablement le plus courant de deux commandes que j’utilise est ps et grep comme ceci: ps aux | grep PROCESS_NAME - vous pouvez voir ici un tuyau muet qui ne fait que transmettre la sortie de ps à stdin de grep.
D'autres systèmes de messagerie, tels que ZeroMQ, fonctionnent de la même manière, bien qu'ils puissent présenter un peu plus de complexité, comme une distribution alternée et une distribution fiable. Erlang en tant que langage est construit sur de petits terminaux intelligents qui envoient des messages entre eux. Les avantages ici sont évidents et également mentionnés dans l'article, les petites applications sont plus faciles à gérer, le découplage facilite la mise à l'échelle.
Par ailleurs, les microservices sont généralement des applications de grandes entreprises, comme le bus de service d'entreprise mentionné. Je n’ai pas vraiment travaillé avec ceux-ci pour vous donner un exemple spécifique, mais en général, ces bus contiennent de nombreuses fonctionnalités qui sont incluses via des scripts ou par la configuration. De telles fonctionnalités incluent généralement un flux de travail configurable avec un routage avancé et peuvent même transformer les messages afin que différents ordinateurs d'extrémité puissent les gérer.
Un exemple pourrait être - si vous souhaitez effectuer une action avancée dans un système, par exemple modifier les exigences d'un projet en cours d'exécution, cela pourrait démarrer un flux de travail, dans lequel ESB enverrait automatiquement des notifications différentes à différents acteurs autour des exigences modifiées. et attendez qu'un ou plusieurs de ces acteurs soient confirmés avant que ce changement ne soit appliqué. Ce qui serait fondamentalement l'opposé - des points d'extrémité stupides (qui envoient/reçoivent simplement les données vers/depuis le bus) et un canal très intelligent (le bus, qui peut être configuré ou scripté pour gérer tous les scénarios d'entreprise possibles).
Je suis persuadé qu’il existe des bus de service d’entreprise qui gèrent des scénarios similaires et qui sont à l’opposé des simples cadres «de transmission de messages de type« stupide »de type ZeroMQ.
Fondamentalement, la logique doit être implémentée quelque part - soit dans le grand ESB, soit dans les terminaux. L'idée des microservices est de l'insérer dans les terminaux plutôt que dans le bus et d'adopter une philosophie similaire à celle des applications Unix.
Je pense que l’article de Martin Fowlers manque cruellement en décrivant mal le concept de «ESB». Cette mauvaise caractérisation est répandue. Combien de fois avez-vous vu un diagramme représentant le "bus" comme un canal vers lequel les messages circulent? J'ai certainement perdu le compte et ça me fait grimacer à chaque fois. Un «bus» n’est pas un tuyau. C’est un mécanisme permettant de rendre facilement accessibles des «services habilitants» dans un environnement distribué, orienté services. L'analogie classique est celle d'un bus dans une usine. Bien que l’électricité passe par le bus, ce n’est pas pour cela qu’il s’agit d’un «bus». C’est un «bus» parce qu’il couvre toute la longueur de l’atelier de fabrication. Toute machine (implémentation de service) peut facilement puiser dans la barre pour obtenir de l’énergie (à partir d’un service de production), où qu’elle se trouve. Le bus est un outil omniprésent qui favorise la flexibilité et les changements dans le temps.
Les seules choses qui vivent sur un bus de service sont les services et, en principe, mieux vaut les implémenter sous forme de microservices chaque fois que cela est possible ou souhaitable. Le mantra des «points de terminaison intelligents, tuyaux muets» remonte bien avant l’avènement des microservices. Je l'ai entendu pour la première fois par un membre de l'équipe Microsoft BizTalk il y a de nombreuses années lors d'un débat public avec un défenseur de premier plan d'ESB. Le responsable ESB a préconisé l’utilité de services de transformation autonomes très fins (microservices) plutôt que l’approche BizTalk typique dans laquelle les transformations sont appliquées aux points finaux (points finaux intelligents). Le responsable de l’ESB critiquait BizTalk, affirmant qu’il était «monolithique» et qu’il ne pouvait donc pas être utilisé pour mettre en œuvre des services aussi détaillés, pouvant être déployés indépendamment. Le gars de BizTalk a fait remarquer qu'il avait tort (comme démontré par la suite dans la trousse à outils BizTalk ESB), mais que l'essentiel était l'intérêt général de transformer les points de terminaison du message (du point de vue de l'intégration) plutôt qu'en aval dans un service intermédiaire invoqué dans l’échange (conceptuellement, plus bas dans le "tuyau").
C'était un débat adulte entre des pratiquants sérieux. Je suis d'accord avec le gars de BizTalk sur ce point - points finaux intelligents, tuyaux muets. Ironiquement, le responsable ESB promouvait efficacement une approche de microservice dans un contexte ESB. Pour moi, c’est un excellent exemple de la manière dont le mantra du microservice, comme toute autre philosophie, peut aller trop loin.
Les composants d'un système utilisent des "canaux" (HTTP/S, files d'attente, etc.) pour communiquer entre eux. Habituellement, ces canaux transitent par un ESB (Enterprise Service Bus) qui effectue un certain nombre de choses pour les messages échangés entre les composants.
Cela pourrait faire:
- Contrôles de sécurité
- Routage
- Flux d'activité/validation
- Transformation
Une fois ces tâches terminées, le message sera transféré sur le composant "endpoint". Ceci est un exemple de "tubes intelligents" dans la mesure où beaucoup de logique et de traitement résident dans l'ESB (partie du système de "tubes"). Les points de terminaison peuvent alors être "stupides" car le BSE a effectué tout le travail.
"Smart endpoints and dumb pipes" préconise le scénario opposé. Que les voies de communication soient dépourvues de traitement métier et de logique et ne distribuent littéralement que des messages entre composants. Ce sont ensuite les composants eux-mêmes qui traitent/logique/validation etc. sur ces messages.
Ce sont des questions très générales. Je vais essayer de le garder comme ça
Points finaux intelligents
Les points de terminaison intelligents désignent uniquement les règles commerciales réelles et toutes les autres validations effectuées derrière ces points de terminaison qui ne sont visibles par personne, que les consommateurs de ces points de terminaison considèrent comme un lieu où la magie se produit.
Pipelines muets
Les pipelines muets désignent tout moyen de communication où aucune autre action, par exemple une validation, n’a eu lieu, il transporte simplement les données sur ce canal particulier et peut également être remplacé si nécessaire.
Selon Martin Fowler: "La deuxième approche couramment utilisée est la messagerie sur un bus de messagerie léger. L’infrastructure choisie est généralement muette (stupide car elle sert uniquement de routeur de messagerie)".
La logique d'utilisation de points finaux intelligents est implicite: "La propriété clé d'un composant est la notion de remplacement indépendant et de possibilité d'évolution - ce qui implique que nous recherchions des points permettant d'imaginer la réécriture d'un composant sans affecter ses collaborateurs.".
Pour soutenir ce dernier, un micro-service doit être tolérant envers son consommateur. Par exemple. ajouter un argument d'entrée obligatoire plus tard casserait l'interface et devrait donc être évité. Au lieu de cela, vous devez utiliser des stratégies de compensation, telles que les valeurs par défaut, ou prendre en charge une sorte de "routage" interne afin que le microservice puisse toujours donner une réponse valide. C'est une sorte de "point final" intelligent.
Les tuyaux muets signifient simplement des connexions point à point. Les points finaux font tout le travail et toute complexité est éliminée du mécanisme qui les relie. Je pense que les gens parlent d’ESB dans cette conversation parce que les tuyaux muets (connexions point à point) sont une idée terrible dans un contexte d’entreprise (et dans beaucoup d’autres). Les ESB ne sont pas des «tuyaux muets». Les ESB sont une bonne définition des tuyaux très intelligents. Et ils aident à maîtriser le désordre incroyablement poilu que les connexions point à point créent chaque fois que vous avez plusieurs services qui doivent se parler.
WSO2 vient de créer un ensemble de bons webinaires sur les microservices, et ils parlent de ce concept. Mais même ils hésitent à utiliser le concept de pipes muettes.
Désormais, les tuyaux muets peuvent avoir un sens si les services sont utilisés uniquement de manière ad hoc, mais pas lorsque vous essayez de gérer des systèmes d'entreprise complexes. La configuration de plusieurs connexions réseau pour chaque service est la moindre des choses.