Noter. trad.: Le service mesh est un phénomène qui n'a pas encore de traduction stable en russe (il y a plus de 2 ans, nous proposions l'option "mesh for services", et un peu plus tard, certains collègues ont commencé à promouvoir activement la combinaison "service sieve") . Les discussions constantes sur cette technologie ont conduit à une situation dans laquelle les composants marketing et techniques sont trop étroitement liés. Ce merveilleux matériel de l'un des auteurs du terme original est destiné à apporter de la clarté aux ingénieurs et pas seulement.
Bande dessinée de
introduction
Si vous êtes un ingénieur logiciel travaillant quelque part dans le domaine des systèmes backend, le terme "service mesh" est probablement déjà bien ancré dans votre esprit au cours des deux dernières années. Grâce à une étrange coïncidence, cette phrase envahit de plus en plus l'industrie, et le battage médiatique et les offres promotionnelles connexes se développent comme une boule de neige, dévalant la colline et ne montrant aucun signe de ralentissement.
Le maillage de services est né dans les eaux troubles et tendancieuses de l'écosystème natif du cloud. Malheureusement, cela signifie qu'une grande partie de la controverse qui l'entoure va du "bavardage hypocalorique" à - pour utiliser le terme technique - des conneries flagrantes. Mais si vous filtrez tout le bruit, vous pouvez constater que le maillage de services a une fonction très réelle, définie et importante.
Dans cet article, je vais essayer de faire exactement cela : fournir un guide honnête, approfondi et orienté ingénieur sur le maillage de services. Je vais répondre plus qu'à la question : "Ce que c'est?", - mais aussi "Pourquoi?"et "Pourquoi maintenant?". Enfin, je vais essayer d'expliquer pourquoi (à mon avis) cette technologie particulière a provoqué un battage médiatique aussi fou, ce qui en soi est une histoire intéressante.
Qui suis-je?
Salut tout le monde! Mon nom est . Je suis l'un des créateurs - le tout premier projet de service mesh et le projet responsable de l'apparition du terme maillage de service en tant que tel (désolé les gars!). (Remarque trad.: Soit dit en passant, à l'aube de l'apparition de ce terme, il y a plus de 2,5 ans, nous avons déjà traduit le premier matériel du même auteur appelé "".) je dirige aussi est une startup qui construit des maillages de services sympas comme Linkerd et .
Vous pouvez probablement deviner que j'ai une opinion très biaisée et subjective sur cette question. Cependant, je vais essayer de réduire au minimum les préjugés (à l'exception d'une section : « Pourquoi parle-t-on tant du maillage de services ? », - dans lequel je partagerai néanmoins mes idées reçues). Je ferai également de mon mieux pour rendre ce guide aussi objectif que possible. Dans des exemples spécifiques, je m'appuierai principalement sur l'expérience de Linkerd, tout en soulignant les différences (le cas échéant) que je connais dans la mise en œuvre d'autres types de service mesh.
Bon, il est temps de passer aux friandises.
Qu'est-ce qu'un maillage de services ?
Malgré tout le battage médiatique, le maillage de services est structurellement assez simple. C'est juste un tas de proxys d'espace utilisateur situés "à côté" des services (nous parlerons un peu de "proche" plus tard), plus un ensemble de processus de contrôle. Les procurations sont appelées collectivement plan de données, et les processus de contrôle sont appelés plan de contrôle. Le plan de données intercepte les appels entre les services et fait "quelque chose de différent" avec eux ; le plan de contrôle, respectivement, coordonne le comportement du proxy et vous fournit un accès, c'est-à-dire opérateur, à l'API, permettant de manipuler et de mesurer le réseau dans son ensemble.
Quelle est cette procuration ? Il s'agit d'un proxy TCP de la catégorie "Layer 7-aware" (c'est-à-dire "en tenant compte" de la 7ème couche du modèle OSI) comme HAProxy et NGINX. Vous pouvez choisir un proxy à votre goût ; Linkerd utilise un proxy Rust, nommé simplement . Nous l'avons compilé spécifiquement pour le service mesh. D'autres maillages préfèrent d'autres proxies (Envoy est un choix courant). Cependant, le choix d'un proxy n'est qu'une question de mise en œuvre.
Que font ces serveurs proxy ? De toute évidence, ils proxy appellent vers et depuis les services (à proprement parler, ils agissent comme des proxys et des proxys inverses, gérant à la fois les appels entrants et sortants). Et ils implémentent un ensemble de fonctionnalités qui se concentre sur les appels между prestations de service. Cette concentration sur le trafic entre les services est ce qui distingue un proxy de maillage de services, par exemple, des passerelles API ou des proxys d'entrée (ces derniers se concentrant sur les appels entrant dans le cluster depuis le monde extérieur). (Noter. trad. : Pour une comparaison des contrôleurs d'entrée Kubernetes existants, dont beaucoup utilisent l'Envoy déjà mentionné, voir .)
Donc, nous avons compris le plan de données. Le plan de contrôle est plus simple : il s'agit d'un ensemble de composants qui fournissent tous les mécanismes dont le plan de données a besoin pour fonctionner de manière coordonnée, y compris la découverte de services, l'émission de certificats TLS, l'agrégation de métriques, etc. Le plan de données informe le plan de contrôle sur son comportement ; à son tour, le plan de contrôle fournit une API qui vous permet de modifier et de suivre le comportement du plan de données dans son ensemble.
Vous trouverez ci-dessous un schéma du plan de contrôle et du plan de données dans Linkerd. Comme vous pouvez le voir, le plan de contrôle comprend plusieurs composants différents, y compris une instance Prometheus qui collecte des métriques à partir de serveurs proxy, ainsi que d'autres composants tels que destination (découverte de services), identity (autorité de certification, CA) et public-api (points de terminaison pour le Web et CLI). En revanche, le plan de données est un simple linkerd-proxy à côté de l'instance d'application. Ceci n'est qu'un diagramme logique; dans un déploiement réel, vous pouvez avoir trois répliques de chaque composant du plan de contrôle et des centaines ou des milliers de proxys dans le plan de données.
(Les cases bleues de ce diagramme représentent les bordures des pods Kubernetes. Vous pouvez voir que les conteneurs avec le linkerd-proxy se trouvent dans le même pod que les conteneurs d'application. Ce schéma est connu sous le nom de conteneur side-car.)
L'architecture de maillage de services a plusieurs implications importantes. Premièrement, puisque le travail d'un proxy est d'intercepter les appels entre services, un maillage de services n'a de sens que si votre application a été conçue pour un ensemble de services. engrener on peut utiliser avec des monolithes, mais cela est clairement redondant pour un seul proxy, et il est peu probable que sa fonctionnalité soit demandée.
Une autre conséquence importante est que le maillage de services nécessite énorme nombre de procurations. En fait, Linkerd enchaîne un linkerd-proxy à chaque instance de chaque service (d'autres implémentations ajoutent un proxy à chaque nœud/hôte/VM. C'est beaucoup de toute façon). Une telle utilisation active d'un proxy entraîne en soi un certain nombre de complications supplémentaires :
- Les proxys dans le plan de données doivent être vite, car pour chaque appel, il y a deux appels au proxy : un côté client, un côté serveur.
- De plus, les procurations doivent être petit и poids léger. Chacun consommera de la mémoire et des ressources CPU, et cette consommation augmentera linéairement avec l'application.
- Vous aurez besoin d'un mécanisme pour déployer et mettre à jour un grand nombre de proxys. Le faire manuellement n'est pas une option.
En général, le maillage de services ressemble à ceci (du moins à vol d'oiseau) : vous déployez un ensemble de proxys d'espace utilisateur qui « font quelque chose » avec le trafic interne interservices, et utilisez le plan de contrôle pour les surveiller et les gérer.
Il est temps pour la question "Pourquoi?"
A quoi sert un service mesh ?
Pour ceux qui ont rencontré pour la première fois l'idée d'un maillage de services, il est pardonnable d'être un peu impressionné. La conception du maillage de services signifie non seulement qu'elle augmentera la latence des applications, mais qu'elle augmentera également consommer ressources et ajouterai un tas de nouveaux mécanismes dans l'infrastructure. Vous configurez d'abord un maillage de services, puis vous vous retrouvez soudainement à devoir servir des centaines (voire des milliers) de proxys. La question est, qui se portera volontaire pour cela ?
La réponse à cette question comporte deux parties. Premièrement, les coûts de transaction associés au déploiement de ces proxys peuvent être considérablement réduits en raison de certains changements en cours dans l'écosystème (nous en reparlerons plus tard).
Deuxièmement, un tel dispositif est en fait un excellent moyen d'introduire une logique supplémentaire dans le système. Et pas seulement parce que de nombreuses nouvelles fonctionnalités peuvent être ajoutées à l'aide du maillage de services, mais aussi parce que cela peut se faire sans interférer avec l'écosystème. En fait, tout le modèle du maillage de services repose sur ce postulat : dans un système multiservice, quoi qu'il arrive faire services individuels, trafic entre eux est le point idéal pour ajouter des fonctionnalités.
Par exemple, dans Linkerd (comme dans la plupart des maillages), la fonctionnalité se concentre principalement sur les appels HTTP, y compris HTTP/2 et gRPC*. La fonctionnalité est assez riche - elle peut être divisée en trois classes :
- Fonctionnalités associées la fiabilité. Demandes de nouvelles tentatives, délais d'attente, approche Canary (division/redirection du trafic), etc.
- Fonctionnalités associées surveillance. Agrégation des taux de réussite, des retards et des volumes de demandes pour chaque service ou destination individuelle ; construire des cartes topologiques des services, etc.
- Fonctionnalités associées la sécurité. TLS mutuel, contrôle d'accès, etc.
* Du point de vue de Linkerd, gRPC n'est pratiquement pas différent de HTTP/2 : il utilise simplement protobuf dans la charge utile. Du point de vue d'un développeur, ces deux choses sont, bien sûr, différentes.
Beaucoup de ces mécanismes fonctionnent au niveau de la demande (d'où le "proxy L7"). Par exemple, si le service Foo effectue un appel HTTP au service Bar, le linkerd-proxy du côté de Foo peut intelligemment équilibrer la charge et acheminer les appels des instances Foo vers Bar en fonction de la latence observée ; il peut répéter la requête si nécessaire (et si elle est idempotente) ; il peut enregistrer le code de réponse et le délai d'attente, etc. De même, le linkerd-proxy du côté Bar peut rejeter une demande si elle n'est pas autorisée ou si la limite de demande est dépassée ; peut réparer le retard de sa part, etc.
Les mandataires peuvent également "faire quelque chose" au niveau de la connexion. Par exemple, un linkerd-proxy du côté Foo peut initier une connexion TLS, et un linkerd-proxy du côté Bar peut y mettre fin, et les deux côtés peuvent vérifier les certificats TLS* de l'autre. Cela fournit non seulement un cryptage entre les services, mais également un moyen cryptographiquement sécurisé d'identifier les services : Foo et Bar peuvent "prouver" qu'ils sont bien ceux qu'ils prétendent être.
* "Ami d'un ami" signifie que le certificat du client est également vérifié (mutual TLS). Dans TLS "classique", par exemple, entre un navigateur et un serveur, le certificat d'un seul côté (le serveur) est généralement vérifié.
Qu'ils opèrent au niveau de la demande ou de la connexion, il est important de souligner que toutes les fonctionnalités du maillage de services sont opérationnel personnage. Linkerd est incapable de transformer la sémantique de la charge utile, comme l'ajout de champs à un fragment JSON ou la modification d'un protobuf. Nous parlerons de cette fonctionnalité importante plus tard lorsque nous parlerons d'ESB et de middleware.
Il s'agit de l'ensemble des fonctionnalités offertes par le maillage de services. La question se pose : pourquoi ne pas les implémenter directement dans l'application ? Et pourquoi jouer avec un proxy ?
Pourquoi un maillage de services est une bonne idée
Bien que les capacités du maillage de services soient captivantes, sa valeur principale ne réside pas vraiment dans les fonctionnalités. En fin de compte nous pouvez implémentez-les directement dans l'application (nous verrons plus loin que ce fut l'origine du service mesh). Pour résumer en une phrase, la valeur d'un maillage de services est : il fournit des fonctionnalités essentielles à l'exécution de logiciels de serveur modernes de manière cohérente, à l'échelle de la pile et indépendante du code d'application.
Analysons cette proposition.
«Fonctions essentielles à l'exécution d'un logiciel serveur moderne". Si vous créez une application de serveur transactionnel connectée à l'Internet public qui accepte les requêtes du monde extérieur et y répond en peu de temps - par exemple, une application Web, un serveur API et la grande majorité des autres applications modernes - et si vous l'implémentez comme un ensemble de services qui interagissent de manière synchrone les uns avec les autres, et si vous mettez constamment à jour ce logiciel, ajoutez de nouvelles fonctionnalités, et si vous êtes obligé de maintenir ce système en état de fonctionnement pendant la modification - dans ce cas, félicitations , vous créez un logiciel serveur moderne . Et toutes ces excellentes fonctionnalités énumérées ci-dessus s'avèrent en fait essentielles pour vous. L'application doit être fiable, sécurisée et vous devez pouvoir voir ce qu'elle fait. Ce sont ces questions que le service mesh aide à résoudre.
(D'accord, ma conviction que cette approche est la manière moderne de créer un logiciel serveur s'est glissée dans le paragraphe précédent. D'autres préfèrent développer des monolithes, des "microservices réactifs" et d'autres choses qui ne relèvent pas de la définition ci-dessus. Ces personnes ont probablement une opinion qui diffère du mien, et à mon tour, je crois qu'ils ont "tort" - bien que dans tous les cas, le service mesh ne leur soit pas très utile).
«Uniforme pour toute la pile". Les fonctionnalités fournies par le maillage de services ne sont pas seulement critiques. Ils s'appliquent à tous les services d'une application, quel que soit le langage dans lequel ils sont écrits, le framework qu'ils utilisent, qui les a écrits, comment ils ont été déployés et toutes les autres subtilités de leur développement et de leur utilisation.
«Indépendant du code d'application". Enfin, le maillage de services fournit non seulement des fonctionnalités cohérentes sur l'ensemble de la pile, mais il le fait d'une manière qui ne nécessite pas de modifier l'application. La base fondamentale de la fonctionnalité d'un maillage de services, y compris les tâches de configuration, de mise à jour, d'exploitation, de maintenance, etc., se situe uniquement au niveau de la plate-forme et est indépendante de l'application. L'application peut changer sans affecter le service mesh. À son tour, le maillage de services peut changer sans aucune intervention de l'application.
En bref, le maillage de services fournit non seulement des fonctionnalités vitales, mais il le fait de manière globale, uniforme et indépendante des applications. Ainsi, bien que la fonctionnalité d'un maillage de services puisse être implémentée dans le code d'un service (par exemple, sous la forme d'une bibliothèque incluse avec chaque service), cette approche ne fournira pas l'uniformité et l'indépendance si précieuses dans le cas d'un maillage de services.
Et tout ce que vous avez à faire est d'ajouter un tas de procurations ! Promis, nous examinerons très bientôt les coûts opérationnels associés à l'ajout de ces proxys. Mais d'abord, arrêtons-nous et regardons cette idée d'indépendance du point de vue de divers personnes.
À qui le maillage de services aide-t-il ?
Aussi gênant que cela puisse être, pour qu'une technologie devienne un élément important de l'écosystème, elle doit être acceptée par les gens. Alors, qui est intéressé par un maillage de services ? A qui profite son utilisation ?
Si vous développez un logiciel serveur moderne, vous pouvez grossièrement imaginer votre équipe comme un groupe propriétaires de servicesqui développent et implémentent ensemble la logique métier, et propriétaires de plate-formeimpliqué dans le développement de la plate-forme interne sur laquelle ces services fonctionnent. Dans les petites organisations, il peut s'agir des mêmes personnes, mais à mesure que l'entreprise grandit, ces rôles ont tendance à s'accentuer et même à se diviser en sous-rôles... (Il y a beaucoup à dire ici sur la nature changeante des devops, l'impact organisationnel des microservices, etc.). n. Mais pour l'instant, prenons ces descriptions pour acquises).
De ce point de vue, les bénéficiaires clairs du maillage de services sont les propriétaires de la plateforme. Après tout, l'objectif ultime de l'équipe de la plate-forme est de créer une plate-forme interne sur laquelle les propriétaires de services peuvent mettre en œuvre une logique métier et le faire d'une manière qui garantit leur indépendance maximale par rapport aux sombres détails de son fonctionnement. Le maillage de services offre non seulement les capacités essentielles à la réalisation de cet objectif, mais il le fait d'une manière qui, à son tour, n'impose aucune dépendance aux propriétaires de services.
Les propriétaires de services en bénéficient également, quoique de manière plus indirecte. L'objectif du propriétaire du service est d'être aussi productif que possible dans la mise en œuvre de la logique du processus métier, et moins il a à se soucier des problèmes opérationnels, mieux c'est. Au lieu d'appliquer, par exemple, des politiques de nouvelle tentative ou TLS, ils peuvent se concentrer uniquement sur l'entreprise et espérer que la plate-forme s'occupe du reste. Pour eux, c'est un gros avantage.
La valeur organisationnelle d'une telle division entre les propriétaires de plateformes et de services ne peut être surestimée. Je pense qu'elle contribue primaire contribution à la valeur du maillage de services.
Nous avons appris cette leçon lorsqu'un des premiers fans de Linkerd nous a expliqué pourquoi il avait choisi le maillage de services : parce qu'il leur permettait de "continuer à parler au minimum". Voici quelques détails : les gars d'une grande entreprise ont migré leur plateforme vers Kubernetes. Étant donné que l'application fonctionnait avec des informations sensibles, ils souhaitaient chiffrer toutes les communications dans les clusters. Cependant, la situation était compliquée par la présence de centaines de services et de centaines d'équipes de développement. La perspective de contacter tout le monde et de les convaincre d'inclure le support de TLS dans leurs plans ne leur a pas du tout plu. En installant Linkerd, ils ont migré responsabilité des développeurs (du point de vue desquels c'était un problème inutile) aux plateformers, pour qui c'était une priorité absolue. En d'autres termes, Linkerd résolvait pour eux moins un problème technique qu'un problème organisationnel.
Bref, le maillage de services n'est pas une solution technique, mais socio technique problèmes. (Merci pour introduire ce terme.
Le service mesh résoudra-t-il tous mes problèmes ?
Oui. Je veux dire non!
En regardant les trois classes de fonctionnalités décrites ci-dessus - fiabilité, sécurité et observabilité - il devient clair que le maillage de services n'est pas une solution complète à aucun de ces problèmes. Bien que Linkerd puisse envoyer des requêtes répétées (s'il sait qu'elles sont idempotentes), il n'est pas en mesure de prendre des décisions sur ce qu'il faut renvoyer à l'utilisateur si le service est finalement tombé en panne - ces décisions doivent être prises par l'application. Linkerd peut conserver des statistiques sur les requêtes réussies, mais il n'est pas en mesure d'examiner le service et de fournir ses métriques internes - une application devrait disposer d'une telle boîte à outils. Et bien que Linkerd soit capable d'héberger mTLS, les solutions de sécurité à part entière nécessitent bien plus.
Un sous-ensemble des fonctionnalités de ces zones offertes par le maillage de services est lié à fonctionnalités de la plateforme. J'entends par là les fonctions qui :
- Indépendant de la logique métier. La manière dont les histogrammes d'appels sont construits entre Foo et Bar est totalement indépendante du fait que pourquoi Foo appelle Bar.
- Difficile à mettre en œuvre correctement. Dans Linkerd, les tentatives sont paramétrées avec toutes sortes de choses fantaisistes comme les budgets de relance. (réessayer les budgets), car une approche simpliste de la mise en œuvre de telles choses conduira sûrement à l'émergence de la soi-disant "avalanche de demandes" (réessayer tempête) et d'autres problèmes spécifiques aux systèmes distribués.
- Plus efficace lorsqu'il est appliqué de manière cohérente. Le mécanisme TLS n'a de sens que s'il est appliqué partout.
Étant donné que ces fonctionnalités sont implémentées au niveau de la couche proxy (et non au niveau de la couche application), le maillage de services les expose au niveau plate-forme, pas les applications. Ainsi, peu importe la langue dans laquelle les services sont écrits, le cadre qu'ils utilisent, qui les a écrits et pourquoi. Les proxys fonctionnent au-delà de tous ces détails, et la base fondamentale de cette fonctionnalité, y compris les tâches de configuration, de mise à jour, d'exploitation, de maintenance, etc., se situe uniquement au niveau de la plate-forme.
Exemples de fonctionnalités de maillage de services
En résumé, un maillage de services n'est pas une solution complète pour la fiabilité, l'observabilité ou la sécurité. Le périmètre de ces domaines implique la participation obligatoire des propriétaires de services, des équipes Ops / SRE et des autres parties prenantes de l'entreprise. Le maillage de services ne fournit qu'une "tranche" au niveau de la plate-forme pour chacun de ces domaines.
Pourquoi le maillage de services est-il devenu populaire en ce moment ?
Vous vous demandez probablement en ce moment : OK, si le maillage de services est si bon, pourquoi n'avons-nous pas commencé à déployer des millions de proxys sur la pile il y a dix ans ?
Il y a une réponse banale à cette question : il y a dix ans, tout le monde construisait des monolithes, et personne n'avait besoin d'un service mesh. C'est vrai, mais à mon avis, cette réponse passe à côté de l'essentiel. Il y a encore dix ans, le concept de microservices comme moyen prometteur de créer des systèmes à grande échelle était largement discuté et appliqué dans des entreprises telles que Twitter, Facebook, Google et Netflix. La perception générale - du moins dans les secteurs de l'industrie avec lesquels j'ai été en contact - était que les microservices sont la "bonne façon" de construire de grands systèmes, même si c'était sacrément difficile.
Bien sûr, bien qu'il y ait dix ans, il y avait des entreprises qui exploitaient les microservices, elles ne plaçaient pas des proxies partout où elles le pouvaient pour former un maillage de services. Cependant, si vous regardez de plus près, ils ont fait quelque chose de similaire : nombre de ces entreprises ont mandaté l'utilisation d'une bibliothèque interne spéciale pour la mise en réseau (parfois appelée bibliothèque client lourd, bibliothèque client lourd).
Netflix avait Hysterix, Google avait Stubby, Twitter avait la bibliothèque Finagle. Finagle, par exemple, est devenu obligatoire pour chaque nouveau service sur Twitter. Il gérait à la fois le côté client et le côté serveur des connexions, autorisait les demandes répétées, prenait en charge le routage des demandes, l'équilibrage de charge et la mesure. Il a fourni une couche cohérente de fiabilité et d'observabilité sur l'ensemble de la pile Twitter, peu importe ce que faisait le service. Bien sûr, cela ne fonctionnait que pour les langages JVM et était basé sur un modèle de programmation qui devait être utilisé pour l'ensemble de l'application. Cependant, sa fonctionnalité était presque la même que celle du service mesh. (En fait, la première version de Linkerd n'était que Finagle sous forme de procuration.)
Ainsi, il y a dix ans, il n'y avait pas que des microservices, mais aussi des bibliothèques spéciales de proto-service-mesh qui résolvaient les mêmes problèmes que le service mesh résout aujourd'hui. Cependant, le maillage de services lui-même n'existait pas alors. Il devait y avoir un autre quart de travail avant qu'elle n'apparaisse.
Et c'est là que se trouve la réponse la plus profonde, cachée dans un autre changement qui s'est produit au cours des 10 dernières années : il y a eu une forte baisse du coût de déploiement des microservices. Les entreprises mentionnées ci-dessus qui utilisaient des microservices il y a dix ans (Twitter, Netflix, Facebook, Google) étaient des entreprises à grande échelle et dotées d'énormes ressources. Ils avaient non seulement le besoin, mais aussi la capacité de créer, déployer et exploiter de grandes applications basées sur des microservices. L'énergie et les efforts que les ingénieurs de Twitter ont déployés pour passer d'une approche monolithique à une approche de microservices sont incroyables. (Honnêtement, tout comme le fait que cela a fonctionné.) Ce type de manœuvre d'infrastructure était alors impossible pour les petites entreprises.
Passons au présent. Aujourd'hui, il existe des startups où le ratio de microservices aux développeurs est de 5:1 (ou même ), et de plus, ils y font face avec succès ! Si une startup de 5 personnes est capable d'exploiter 50 microservices sans forcer, alors quelque chose a clairement réduit le coût de leur mise en œuvre.
1500 microservices à Monzo ; chaque ligne est une règle de réseau prescrite qui autorise le trafic
La réduction spectaculaire du coût d'exploitation des microservices est le résultat d'un processus unique : popularité croissante des conteneurs и orchestrateurs. C'est précisément la réponse profonde à la question de savoir ce qui a contribué à l'émergence du maillage de services. La même technologie a rendu attractifs à la fois le service mesh et les microservices : Kubernetes et Docker.
Pourquoi? Eh bien, Docker résout un gros problème - le problème de l'emballage. En empaquetant une application et ses dépendances d'exécution (hors réseau) dans un conteneur, Docker transforme l'application en une unité fongible qui peut être hébergée et exécutée n'importe où. En même temps, cela simplifie grandement le fonctionnement. multilingue pile : puisqu'un conteneur est une unité atomique d'exécution, peu importe ce qu'il contient, qu'il s'agisse d'une application JVM, Node, Go, Python ou Ruby, à des fins de déploiement et d'exploitation. Vous venez de le lancer et c'est tout.
Kubernetes fait passer tout au niveau supérieur. Maintenant qu'il existe un tas de "choses exécutables" et de nombreuses machines sur lesquelles les exécuter, il est nécessaire de disposer d'un outil capable de les comparer les unes aux autres. Au sens large, vous donnez à Kubernetes de nombreux conteneurs et de nombreuses machines, et il les fait correspondre les uns aux autres (bien sûr, il s'agit d'un processus dynamique et en constante évolution : de nouveaux conteneurs se déplacent dans le système, les machines démarrent et s'arrêtent, etc. Cependant, Kubernetes prend tout cela en compte).
Une fois Kubernetes configuré, le temps nécessaire pour déployer et exploiter un service n'est pas très différent du coût de déploiement et d'exploitation de dix services (en fait, il est presque le même pour 100 services). Ajoutez à cela des conteneurs en tant que mécanisme d'emballage qui encourage la mise en œuvre multilingue, et vous avez une tonne de nouvelles applications implémentées en tant que microservices écrits en plusieurs langues, exactement le type d'environnement auquel le maillage de services est si bien adapté.
Nous arrivons donc à la réponse à la question de savoir pourquoi l'idée d'un maillage de services est devenue populaire en ce moment : l'uniformité que Kubernetes fournit pour les services est directement applicable aux tâches opérationnelles auxquelles le maillage de services est confronté. Vous emballez les proxys dans des conteneurs, donnez à Kubernetes la tâche de les coller partout où c'est possible, et le tour est joué ! En sortie, vous obtenez un service mesh, tandis que Kubernetes contrôle toute la mécanique de son déploiement. (Au moins à vol d'oiseau. Bien sûr, ce processus comporte de nombreuses nuances.)
Pour résumer : la raison pour laquelle le maillage de services est devenu populaire maintenant et pas il y a dix ans, c'est que Kubernetes et Docker n'ont pas seulement considérablement augmenté besoin en elle, simplifiant la mise en œuvre des applications en tant qu'ensembles de microservices multilingues, mais aussi considérablement réduit frais pour son fonctionnement en fournissant des mécanismes de déploiement et de maintenance de parcs proxy side-car.
Pourquoi parle-t-on tant du service mesh ?
avertissement: Dans cette section, j'ai recours à toutes sortes d'hypothèses, de conjectures, de fabrications et d'informations privilégiées.
La recherche de "service mesh" fera apparaître un tas de contenus recyclés et hypocaloriques, des projets étranges et un kaléidoscope de distorsion digne d'une chambre d'écho. Toute nouvelle technologie à la mode en est dotée, mais dans le cas du maillage de services, le problème est particulièrement aigu. Pourquoi?
Eh bien, c'est en partie ma faute. J'ai fait de mon mieux pour promouvoir Linkerd et le maillage de services à chaque occasion, à travers d'innombrables articles de blog et articles comme celui-ci. Mais je ne suis pas si puissant. Pour vraiment répondre à cette question, nous devons parler un peu de la situation générale. Et impossible d'en parler sans évoquer un projet : est un maillage de services open source développé conjointement par Google, IBM et Lyft.
(Ces trois sociétés ont des rôles très différents : l'implication de Lyft semble se limiter au seul nom ; elles créent Envoy mais n'utilisent pas ou ne sont pas impliquées dans le développement d'Istio. IBM est impliqué dans le développement d'Istio et l'utilise. Google est fortement impliqué dans le développement d' Istio , mais pour autant que je sache, ne l'utilise pas réellement.)
Le projet Istio est remarquable pour deux choses. Premièrement, c'est l'énorme effort de marketing que Google, en particulier, met dans sa promotion. J'estime que la plupart des personnes actuellement au courant du concept de maillage de services l'ont découvert grâce à Istio. La deuxième caractéristique est à quel point Istio a été mal reçu. Dans cette affaire, je suis évidemment une partie intéressée, mais en essayant de rester le plus objectif possible, je ne peux toujours pas m'empêcher de , pas très spécifique (mais pas unique : systemd me vient à l'esprit, ...) pour un projet Open Source.
(En pratique, Istio semble avoir des problèmes non seulement de complexité et d'expérience utilisateur, mais aussi de performances. Par exemple, pendant menée par un tiers, les experts ont trouvé des situations dans lesquelles la latence de queue d'Istio était 100 fois supérieure à celle de Linkerd, ainsi que des situations de manque de ressources, lorsque Linkerd continuait à fonctionner avec succès et qu'Istio a complètement cessé de fonctionner.)
Laissant de côté mes théories sur les raisons pour lesquelles cela s'est produit, je pense que le battage publicitaire hors échelle autour du maillage de services est dû à l'implication de Google. A savoir, une combinaison des trois facteurs suivants :
- promotion obsessionnelle d'Istio par Google ;
- attitude désapprobatrice et critique appropriée envers le projet ;
- la récente montée en flèche de la popularité de Kubernetes, dont le souvenir est encore frais.
Ensemble, ces facteurs fusionnent dans une sorte d'environnement enivrant et anoxique dans lequel la capacité de jugement rationnel diminue, ne laissant qu'une variété bizarre de .
Du point de vue de Linkerd, c'est… Je le décrirais comme une bénédiction mitigée. Je veux dire, c'est formidable que le maillage de services soit entré dans le courant dominant - ce qui n'était pas le cas en 2016 lorsque Linkerd est apparu pour la première fois et il était vraiment difficile d'attirer l'attention des gens sur le projet. Maintenant, il n'y a pas un tel problème! Mais la mauvaise nouvelle est que la situation du maillage de services est si confuse aujourd'hui qu'il est presque impossible de déterminer quels projets appartiennent réellement à la catégorie des maillages de services (et encore moins de déterminer lequel est le meilleur pour un cas d'utilisation particulier). Cela gêne certainement tout le monde (et dans certains cas, Istio ou un autre projet est meilleur que Linkerd, car ce dernier n'est pas une solution unique).
Du côté de Linkerd, notre stratégie a été d'ignorer le bruit, de continuer à nous concentrer sur la résolution des vrais problèmes de la communauté et d'attendre essentiellement que le battage médiatique se calme. Finalement, le battage médiatique s'apaisera et nous pourrons continuer à travailler en paix.
D'ici là, nous devrons tous être patients.
Le service mesh me sera-t-il utile à moi, modeste ingénieur logiciel ?
Le questionnaire suivant permettra de répondre à cette question :
Vous occupez-vous exclusivement de la mise en œuvre de la logique métier ? Dans ce cas, le service mesh ne vous sera d'aucune utilité. C'est-à-dire, bien sûr, cela peut vous intéresser, mais idéalement, le maillage de services ne devrait pas affecter directement quoi que ce soit dans votre environnement. Continuez à travailler sur ce pour quoi vous êtes payé.
Vous gérez une plateforme dans une entreprise qui utilise Kubernetes ? Oui, dans ce cas, vous avez besoin d'un maillage de service (bien sûr, si vous n'utilisez pas les K8 uniquement pour exécuter un traitement monolithique ou par lots - mais je voudrais alors vous demander pourquoi vous avez besoin des K8). Très probablement, vous vous retrouverez dans une situation avec de nombreux microservices écrits par différentes personnes. Ils interagissent tous les uns avec les autres et sont liés dans un enchevêtrement de dépendances d'exécution, et vous devez trouver un moyen de gérer tout cela. L'utilisation de Kubernetes permet de choisir un service mesh "pour soi". Pour ce faire, familiarisez-vous avec leurs capacités et fonctionnalités et répondez à la question de savoir si l'un des projets disponibles vous convient (je vous recommande de commencer vos recherches avec Linkerd).
Exécutez-vous une plate-forme pour une entreprise qui n'utilise PAS Kubernetes mais utilise des microservices ? Dans ce cas, le service mesh vous sera utile, mais son utilisation sera non triviale. Bien sûr vous pouvez imiter service mesh en hébergeant un tas de proxys, mais un avantage important de Kubernetes est précisément le modèle de déploiement : la maintenance manuelle de ces proxys demandera beaucoup plus de temps, d'efforts et de coûts.
Vous êtes en charge de la plateforme dans une entreprise qui travaille avec des monolithes ? Dans ce cas, vous n'avez probablement pas besoin d'un maillage de services. Si vous travaillez avec des monolithes (ou même des ensembles de monolithes) qui ont des modèles d'interaction bien définis et qui changent rarement, alors le service mesh a peu à vous offrir. Vous pouvez donc simplement l'ignorer et espérer qu'il disparaisse comme un mauvais rêve...
Conclusion
Probablement, le maillage de services ne devrait toujours pas être appelé "la technologie la plus médiatisée au monde" - cet honneur douteux appartient probablement au bitcoin ou à l'IA. Peut-être qu'elle est dans le top cinq. Mais si vous franchissez les couches de bruit et de vacarme, il devient clair que le maillage de services apporte de réels avantages à ceux qui créent des applications dans Kubernetes.
J'aimerais que vous essayiez Linkerd - en l'installant dans un cluster Kubernetes (ou même Minikube sur un ordinateur portable) et vous pouvez voir par vous-même de quoi je parle.
QFP
- Si j'ignore le service mesh, va-t-il disparaître ?
- Je dois vous décevoir : le maillage de service est avec nous depuis longtemps.
— Mais JE NE VEUX PAS utiliser un service mesh !
- Eh bien, ce n'est pas nécessaire! Lisez simplement mon questionnaire ci-dessus pour voir si vous devriez au moins vous familiariser avec ses bases.
— N'est-ce pas du bon vieux ESB/middleware avec une nouvelle sauce ?
- Le service mesh traite de la logique opérationnelle, pas de la sémantique. bus de services d'entreprise (). Le maintien de cette séparation permet au maillage de services d'éviter le même sort.
- En quoi un maillage de services est-il différent des passerelles API ?
Il y a un million d'articles sur ce sujet. Juste Google.
Envoy est-il un maillage de services ?
- Non, Envoy n'est pas un service mesh, c'est un serveur proxy. Il peut être utilisé pour organiser un maillage de services (et bien plus encore - c'est un proxy à usage général). Mais en soi, ce n'est pas un maillage de services.
- Network Service Mesh - est-ce un service mesh ?
- Non. Malgré son nom, ce n'est pas un maillage de services (comment aimez-vous les merveilles du marketing ?).
- Le maillage de service m'aidera-t-il avec mon système asynchrone réactif basé sur la file d'attente de messages ?
- Non, le maillage de service ne vous aidera pas.
- Quel maillage de service dois-je utiliser ?
- , pas de prise de tête.
- L'article est nul ! / L'auteur - sur le savon !
— Veuillez partager le lien avec tous vos amis afin qu'ils puissent en être convaincus !
Remerciements
Comme vous pouvez le deviner d'après le titre, cet article a été inspiré par le fantastique traité de Jay Kreps "". J'ai rencontré Jay il y a dix ans lors d'une interview sur Linked In et il est depuis une source d'inspiration pour moi.
Bien que j'aime m'appeler un "développeur Linkerd", la réalité est que je suis plutôt un mainteneur du fichier README.md dans un projet. Travailler sur Linkerd aujourd'hui , , personnes, et ce projet n'aurait pas été possible sans l'étonnante communauté de contributeurs et d'utilisateurs.
Et enfin, un merci spécial au créateur de Linkerd, (premier parmi les pairs), qui, avec moi il y a de nombreuses années, a plongé tête baissée dans tout ce remue-ménage avec le service mesh.
PS du traducteur
A lire aussi sur notre blog :
- «";
- «";
- «";
- «";
- «».
Source: habr.com