Bonjour à tous!
Aujourd'hui, nous sommes heureux de vous proposer la traduction d'un article qui évoque brièvement une nouvelle tendance technologique appelée «Service mesh». La solution la plus intéressante dans ce domaine (à notre avis) est
Istio , mais l'article proposé est intéressant, tout d'abord, par une comparaison explicite des technologies existantes de ce type et un aperçu de haut niveau de l'ensemble du paradigme. L'auteur, Tobias Kunze, a également écrit un deuxième article plus pratique sur le maillage des services - une demande pour savoir s'il vaut la peine de publier sa traduction.
Cet article est le premier de deux à parler des avantages des réseaux de services. Cet article décrit ce qu'est un réseau de services, comment il fonctionne et quelle est son utilisation. La
deuxième partie explore pourquoi, où et quand utiliser ces réseaux, et ce qui nous attend.
Lors de la décomposition d'une application en microservices, il devient rapidement clair que l'appel d'un service sur un réseau est un processus beaucoup plus complexe et moins fiable qu'on ne le pensait initialement. Ce qui était censé «fonctionner correctement» dès la conception doit maintenant être clairement articulé pour chaque client et chaque service. Les clients doivent découvrir les terminaux de service, s'assurer qu'ils sont cohérents entre les versions d'API, et empaqueter et décompresser les messages. Les clients doivent également suivre l'exécution des appels et gérer ces opérations, détecter les erreurs, répéter les appels ayant échoué et conserver un délai d'attente si nécessaire. Les clients peuvent également avoir besoin de vérifier l'authenticité des services, les appels de journal et les transactions d'instruments. Enfin, il arrive que l'application entière soit conforme aux règles
IAM , aux exigences de chiffrement ou de contrôle d'accès.
Bien sûr, la plupart de ces problèmes ne sont pas nouveaux, et pendant longtemps nous avons à notre disposition des technologies qui aident à organiser les mécanismes de messagerie, par exemple SOAP, Apache Thrift et gRPC. Mais ce qui a été observé récemment: la distribution rapide des conteneurs et la croissance explosive des appels de service qui l'accompagne, le degré de mise à l'échelle horizontale et la courte durée des terminaux de service qui lui sont associés. Lorsque la complexité et la fragilité atteignent un nouveau niveau, il existe un désir d'encapsuler la communication réseau et de la porter à un nouveau niveau d'infrastructure. L'approche la plus populaire pour fournir ce niveau, appliquée aujourd'hui, est appelée le «réseau de services».
Qu'est-ce qu'un «réseau de service» exactement?
Un réseau de services n'est pas une «grille de services». Il s'agit d'un réseau d'intermédiaires API (proxies) auquel les (micro) services peuvent se connecter pour abstraire complètement le réseau. Comme le dit William Morgan, il s'agit «d'une couche d'infrastructure dédiée qui fournit une communication sécurisée, rapide et fiable entre les services». Les réseaux de services aident à faire face aux nombreux défis auxquels les développeurs sont confrontés lorsqu'ils doivent échanger des informations avec des terminaux distants. Cependant, il convient de noter que les problèmes opérationnels majeurs à l'aide des réseaux de services ne sont pas résolus.
Comment fonctionnent les réseaux de services?
Architecture de réseau de service typique. Les proxys dans le plan de données sont déployés en tant que compagnons (side-car) et le plan de contrôle est situé séparément.Dans un réseau de services typique, les services déployés sont modifiés de sorte que chacun d'eux soit accompagné de son propre
«compagnon» proxy . Les services n'appellent pas directement d'autres services sur le réseau, mais se tournent plutôt vers leurs compagnons de proxy locaux, qui, à leur tour, résument la complexité de l'échange d'informations entre les services. Un tel ensemble de proxys interconnectés implémente le soi-disant plan de données.
Au contraire, l'ensemble des API et des outils utilisés pour contrôler le comportement du proxy dans l'ensemble du réseau de services est appelé son «plan de contrôle». C'est dans le plan de contrôle que les utilisateurs définissent des stratégies et configurent le plan de données dans son ensemble.
Pour implémenter un réseau de services, un plan de données et un plan de contrôle sont nécessaires.
Acteurs majeurs: Envoyé, Linkerd, Istio et Consul
Envoy est un serveur proxy open source développé par Lyft. Aujourd'hui, il forme un plan de données dans de nombreux réseaux de services, dont Istio. Envoy a rapidement remplacé les autres proxys grâce à son API de configuration pratique, qui permet aux avions de contrôle d'ajuster son comportement en temps réel.
Linkerd est un projet open source soutenu par Buoyant et, en même temps, le tout premier réseau de services. Il a été initialement écrit en Scala, comme
Finagle , de Twitter, dont il est issu, puis a fusionné avec le projet léger Conduit et a été redémarré sous le nom de
Linkerd 2.0 .
Istio est peut-être le réseau de services le plus populaire de notre époque. Il a été lancé conjointement par Google, IBM et Lyft; elle devrait éventuellement intégrer le projet
Cloud-Native Computing Foundation (CNCF). À proprement parler, Istio est un plan de contrôle et, pour former un réseau de services, il doit être combiné avec le plan de données. Istio est généralement utilisé avec Envoy et fonctionne mieux sur Kubernetes.
Le consul est un phénomène relativement nouveau dans l'écosystème des avions de contrôle. Il fonctionne mieux avec des topologies couvrant de nombreux centres de données et est spécialisé dans la découverte de services. Consul fonctionne avec de nombreux plans de données et peut être utilisé sans impliquer d'autres plans de contrôle, par exemple sans Istio. Son soutien est HashiCorp.
Principaux avantages et différences de priorités
Bien que l'espace des réseaux de services continue d'évoluer, la plupart des projets, apparemment, sont déjà venus à l'idée de l'ensemble principal de fonctionnalités qui devraient être prises en charge dans un tel réseau:
- Découverte de services : découvrir des services et maintenir leur registre
- Routage : équilibrage intelligent de la charge et routage réseau, meilleurs tests de performances, modèles de déploiement automatique, par exemple, configurations bleu-vert et canari
- Stabilité : tentatives, délais d'attente et disjoncteurs
- Sécurité : cryptage basé sur TLS, y compris la gestion des clés
- Télémétrie : collecte de métriques et suivi des identifiants
En plus de ces capacités (et parfois basées sur celles-ci), il existe également un niveau plus riche de fonctions où de sérieuses différences commencent entre les différents réseaux de services sur ce qui peut être précieux pour les architectes, les développeurs et les administrateurs de systèmes de microservices. Par exemple, Envoy prend en charge WebSockets, mais Linkerd 2.0 (pas encore). Alors qu'Istio et Consul prennent en charge différents plans de données, Linkerd ne fonctionne qu'avec le sien. Consul a son propre plan de données intégré, qui peut être remplacé par un plus puissant lorsque la question des performances devient une priorité. Istio est conçu comme un plan de contrôle centralisé séparé, tandis que Consul et Linkerd sont entièrement distribués. Enfin, parmi tous les réseaux de services discutés ci-dessus, seul Istio prend en charge l'injection de pannes. Ce ne sont que quelques-unes des principales différences à considérer si vous envisagez d'introduire un tel réseau.
Critique du réseau de service
Malgré la popularité évidente et les fonctionnalités attrayantes prometteuses, les réseaux de services ne sont pas aussi largement utilisés qu'on pourrait s'y attendre. Sans aucun doute, cela est dû en partie à leur nouveauté et au fait que toute cette industrie continue de prendre forme. Mais, en parlant de réseaux de services, vous ne pouvez pas vous passer de quelques critiques.
Le scepticisme associé aux réseaux de services est principalement lié à la complexité supplémentaire qu'ils apportent, à leur productivité relativement faible et à certaines lacunes qui apparaissent lors de l'utilisation de topologies provenant de plusieurs clusters.
Les réseaux de services sont des plates-formes ambiguës, au stade initial de mise en œuvre, qui nécessitent de sérieux investissements dans l'assemblage du système lui-même et de ses équipements instrumentaux. Il peut sembler que l'ajout d'un compagnon au conteneur est assez facile, cependant, une gestion des pannes et une nouvelle tentative compétentes nécessitent de sérieux efforts d'ingénierie. Il peut être difficile de justifier de tels investissements lorsque vous travaillez avec des applications existantes avec un cycle de vie court ou avec des applications en développement rapide.
De plus, les réseaux de service peuvent dégrader sérieusement les performances des applications par rapport à l'utilisation d'appels réseau directs. Les problèmes qui se posent dans ce cas sont parfois difficiles à diagnostiquer, et plus encore à éliminer. Étant donné que la plupart des réseaux de services visent à travailler avec des applications de microservices autonomes, et non à des paysages entiers d'applications connexes, ces réseaux ont généralement un support mal implémenté pour des solutions pour de nombreux clusters et différentes régions.
En bref, les réseaux de services ne sont pas une panacée pour les architectes et les opérateurs qui cherchent à s'adapter avec souplesse à l'exploitation d'une flotte croissante de services numériques. Un tel réseau est une solution tactique, il représente une amélioration technique «fondamentale» conçue pour résoudre des problèmes pertinents, principalement pour les développeurs. Au niveau des entreprises, ils n'inverseront pas la situation.
Technologie connexe
Les réseaux de services se croisent avec d'autres composants architecturaux, mais, bien sûr, ne leur sont pas réductibles. Ces éléments incluent les API, les passerelles d'application, les équilibreurs de charge, les contrôleurs de trafic entrant et sortant (entrée et sortie) ou les passerelles de livraison d'application. L'objectif principal de la passerelle API est de fournir des services avec accès au monde extérieur, tout en agissant comme une API unique pour fournir des fonctions d'équilibrage de charge, de sécurité et de gestion de base. Les contrôleurs de trafic entrant et sortant transmettent des informations entre des adresses non routables dans l'orchestre de conteneurs et des adresses routées à l'extérieur. Enfin, les contrôleurs de livraison d'applications sont similaires aux passerelles API, mais leur spécialisation consiste à accélérer la livraison des applications Web, pas seulement l'API.