Le Service Mesh est un modèle architectural bien connu pour l'intégration des microservices et la transition vers une infrastructure cloud. Aujourd'hui, il est assez difficile de s'en passer dans le monde des conteneurs cloud. Plusieurs implémentations open-source de service mesh sont déjà disponibles sur le marché, mais leurs fonctionnalités, leur fiabilité et leur sécurité ne sont pas toujours suffisantes, notamment lorsque l'on parle des exigences des grandes entreprises financières à l'échelle nationale. C'est pourquoi chez Sbertech, nous avons décidé de personnaliser le Service Mesh et nous voulons vous parler de ce qui est génial dans le Service Mesh, de ce qui ne l'est pas, et de ce que nous avons l'intention d'en faire.
La popularité du modèle Service Mesh augmente avec celle des technologies cloud. Il représente une couche d'infrastructure dédiée qui simplifie l'interaction entre différents services réseau. Les applications cloud modernes se composent de centaines, voire de milliers de ces services, chacun pouvant avoir des milliers de copies.
L'interaction et la gestion de ces services constituent la tâche clé du Service Mesh. En réalité, il s'agit d'un modèle réseau composé de plusieurs proxys, géré de manière centralisée et exécutant un ensemble de fonctions très utiles.
Au niveau du proxy (data plane):
- Attribution et diffusion des politiques de routage et d'équilibrage de trafic
- Diffusion des clés, certificats, jetons
- Collecte de la télémétrie, création de métriques de surveillance
- Intégration avec l'infrastructure de sécurité et de surveillance
Au niveau du plan de contrôle (control plane):
- Application des politiques de routage et d'équilibrage de trafic
- Gestion des répétitions et des timeouts, identification des nœuds « morts » (circuit breaking), gestion des situations d'échec (injecting faults) et garantie de la résilience des services via d'autres mécanismes
- Authentification/autorisation des appels
- Élimination des métriques (observabilité)
Le cercle des utilisateurs intéressés par le développement de cette technologie est très large — allant des petites startups aux grandes entreprises Internet, comme PayPal.
À quoi sert le Service Mesh dans le secteur d'entreprise
L'utilisation du Service Mesh offre de nombreux avantages évidents. Tout d'abord, c'est tout simplement pratique pour les développeurs : pour écrire du code une plate-forme technologique émerge, qui simplifie considérablement l'intégration dans l'infrastructure cloud grâce à l'isolation complète de la couche de transport de la logique applicative.
De plus, Le Service Mesh facilite les relations entre fournisseurs et consommateurs. Aujourd'hui, il est beaucoup plus facile pour les fournisseurs et les consommateurs d'API de négocier eux-mêmes les interfaces et les contrats, sans avoir besoin d'un intermédiaire d'intégration spécial et d'un arbitre — la bus de service d'entreprise. Cette approche a un impact significatif sur deux indicateurs. La vitesse de mise sur le marché de nouvelles fonctionnalités (time-to-market) augmente, mais le coût de la solution augmente également, car l'intégration doit être réalisée de manière autonome. L'utilisation de Service Mesh par les équipes de développement des fonctionnalités métier permet de maintenir un équilibre ici. En fin de compte, les fournisseurs d'API peuvent se concentrer uniquement sur l'aspect applicatif de leur service et simplement le publier dans le Service Mesh — l'API sera immédiatement accessible à tous les clients, et la qualité de l'intégration sera prête pour la production sans nécessiter une seule ligne de code supplémentaire.
Un autre avantage est que le développeur, en utilisant le Service Mesh, se concentre exclusivement sur la fonctionnalité métier — sur l'aspect produit plutôt que sur l'aspect technologique de son service. Par exemple, il n'est plus nécessaire de se soucier de la possibilité d'une interruption de connexion lorsque le service est appelé sur un réseau. De plus, le Service Mesh aide à équilibrer le trafic entre les copies d'un même service : si l'une des copies « est morte », le système redirigera tout le trafic vers les copies encore actives.
Service Mesh — est une bonne base pour la création d'applications distribuées, qui masque du client les détails de l'appel de ses services, tant de l'intérieur que de l'extérieur. Toutes les applications utilisant le Service Mesh sont isolées au niveau du transport, à la fois du réseau et les unes des autres : il n'y a aucune connexion entre elles. Cela permet au développeur d'avoir un contrôle complet sur ses services.
Il ne faut pas oublier que la mise à jour des applications distribuées dans un environnement où le Service Mesh est utilisé devient plus simple. Par exemple, le déploiement blue/green, où deux environnements d'application sont disponibles pour l'installation, l'un n'étant pas mis à jour et étant en attente. Le retour à la version précédente en cas d'échec d'une version est effectué par un routeur spécial, un rôle que gère parfaitement le Service Mesh.. Pour tester la nouvelle version, on peut également utiliser le déploiement canari — basculer vers la nouvelle version pour seulement 10 % du trafic ou des requêtes d'un groupe pilote de clients. Le trafic principal va à l'ancienne version, rien ne casse.
Aussi Le Service Mesh nous donne un contrôle SLA en temps réel. Un système de proxies distribués ne permettra pas de faire échouer le service lorsque l'un des clients dépasse sa quota allouée. Si la bande passante par API est limitée, personne ne pourra le DDoSer avec un trop grand nombre de transactions : le Service Mesh se place devant le service et ne laisse pas passer le trafic excessif. Il sera simplement rejeté à la couche d'intégration, tandis que les services eux-mêmes continueront de fonctionner sans s'en apercevoir.
Si une entreprise souhaite réduire ses coûts de développement de solutions d'intégration, le Service Mesh est également utile : il est possible de passer à sa version open-source depuis des produits commerciaux.Notre Enterprise Service Mesh est basé sur la version open-source du Service Mesh.
Un autre avantage est la présence d'un ensemble complet de services d'intégration. Étant donné que toute l'intégration se fait via cette couche intermédiaire, nous pouvons gérer tout le trafic d'intégration et les relations entre les applications qui forment le cœur métier de l'entreprise. C'est très pratique.
Et enfin, Le Service Mesh incite l'entreprise à passer à une infrastructure dynamique. Actuellement, beaucoup se tournent vers la containerisation. Diviser le monolithe en microservices et tout intégrer de manière élégante - c'est un sujet en plein essor. Mais lorsque vous essayez de passer à un nouveau système qui est en production depuis des années, vous êtes immédiatement confronté à de nombreux problèmes : enfermer tout cela dans des conteneurs et le déployer sur la plateforme n'est pas simple. De plus, l'implémentation, la synchronisation et l'interaction de ces composants distribués sont encore un autre sujet compliqué. Comment vont-ils communiquer entre eux ? Y aura-t-il des pannes en cascade ? Le Service Mesh permet de résoudre certaines de ces problématiques et d'accélérer la migration de l'ancienne architecture vers la nouvelle en permettant d'oublier la logique des échanges réseau.
Pourquoi la personnalisation du Service Mesh est-elle nécessaire
Dans notre entreprise, des centaines de systèmes et de modules coexistent, et le runtime est très sollicité. Un simple modèle, où un système appelle un autre et obtient une réponse, ne suffit pas, car en production, nous voulons plus. Que faut-il encore attendre d'un Service Mesh d'entreprise ?
Service de traitement des événements
Imaginons que nous avons besoin de faire du traitement d'événements en temps réel — un système qui analyse en temps réel les actions du client et peut lui faire immédiatement une offre pertinente. Pour réaliser une telle fonctionnalité, on utilise un modèle architectural appelé architecture orientée événements (EDA). Aucun des Service Mesh actuels ne prend en charge ces modèles de manière native, ce qui est pourtant très important, notamment pour une banque !
Il est assez étrange que l'appel de procédure distante (RPC) soit pris en charge par toutes les versions du Service Mesh, alors qu'avec l'EDA, ils ne sont pas compatibles. Parce que le Service Mesh est semblable à une intégration distribuée moderne, alors que l'EDA est un modèle architectural très actuel qui permet de créer des expériences client uniques.
Notre Enterprise Service Mesh doit résoudre ce problème. De plus, nous voulons y voir la mise en œuvre de la livraison garantie, du traitement d'événements en continu et complexe en utilisant divers filtres et modèles.
Service de transfert de fichiers
En plus de l'EDA, il serait utile d'avoir la possibilité de transférer des fichiers : à l'échelle d'une entreprise, l'intégration se fait souvent uniquement par fichiers. En particulier, le modèle architectural ETL (Extract, Transform, Load — « extraire, transformer, charger ») est utilisé. Dans ce cadre, on échange généralement uniquement des fichiers : des données volumineuses qui ne sont pas judicieuses à envoyer par des requêtes individuelles. La prise en charge native du transfert de fichiers dans l'Enterprise Service Mesh offre la flexibilité nécessaire pour les entreprises.
Service d'orchestration
Dans les grandes entreprises, il y a presque toujours différentes équipes qui travaillent sur différents produits. Par exemple, dans une banque, certaines équipes s'occupent des dépôts, tandis que d'autres se concentrent sur les produits de crédit, et il existe de nombreux cas similaires. Ce sont des personnes différentes, des équipes différentes, qui créent leurs propres produits, conçoivent leurs propres API et les mettent à disposition des autres. Il y a souvent un besoin de composer ces services, ainsi que d'implémenter une logique complexe d'appels séquentiels d'un ensemble d'API. Pour résoudre ce problème, une solution au niveau d'intégration est nécessaire pour simplifier toute cette logique composite (appels de plusieurs API, description du chemin des requêtes, etc.). C'est précisément cela qu'est le service d'orchestration dans un Enterprise Service Mesh.
IA et ML
Lorsque les microservices communiquent à travers une couche d'intégration unique, le Service Mesh est bien entendu au courant de tous les appels de chaque service. Nous recueillons la télémétrie : qui a appelé qui, quand, combien de temps, combien de fois, et ainsi de suite. Quand ces services se comptent par centaines de milliers et que les appels se chiffrent en milliards, toutes ces données s'accumulent et forment des Big Data. Ces informations peuvent être analysées à l'aide d'IA, de machine learning, etc., et ensuite permettre de réaliser des choses utiles basées sur les résultats de l'analyse. Il serait judicieux de confier au moins partiellement à l'intelligence artificielle la gestion de tout ce trafic réseau et des appels d'applications, intégrés dans le Service Mesh.
Service API Gateway
En général, dans le Service Mesh, il y a des proxies et des services qui s'appellent mutuellement à l'intérieur d'un périmètre de confiance. Mais il existe également des parties externes. Les exigences pour les API fournies à ce groupe de consommateurs sont bien plus strictes. Nous divisons cette tâche en deux parties principales.
- Sécurité. Les questions liées aux ddos, à la vulnérabilité des protocoles, des applications, des systèmes d'exploitation, etc.
- Échelles. Lorsque le nombre d'API à fournir aux clients atteint des milliers, voire des centaines de milliers, il devient nécessaire de disposer d'un outil de gestion de cet ensemble d'API. Il est crucial de surveiller constamment les API : fonctionnent-elles ou non, quel est leur statut, quel trafic est en cours, quelles statistiques, etc. La passerelle API doit être capable de gérer cette tâche, rendant tout le processus maîtrisé et sécurisé. Grâce à ce composant, l'Enterprise Service Mesh apprend à publier sans complications inutiles les API internes et externes.
Service de prise en charge de protocoles et de formats de données spécifiques (passerelle AS)
À l'heure actuelle, la plupart des solutions Service Mesh ne peuvent fonctionner nativement qu'avec le trafic HTTP et HTTP2 ou en mode réduit au niveau TCP/IP. L'Enterprise Service Mesh fait face à beaucoup d'autres protocoles de transmission de données assez spécifiques. Certains systèmes peuvent utiliser des courtiers de messages, d'autres sont intégrés au niveau des bases de données. Si une entreprise utilise SAP, elle peut également avoir son propre système d'intégration. Et tout cela fonctionne et est une partie importante des affaires.
On ne peut pas simplement dire : « Abandonnons l'héritage et créons de nouveaux systèmes qui pourront utiliser Service Mesh ». Pour lier tous les anciens systèmes aux nouveaux (basés sur une architecture microservices), les systèmes capables d'utiliser Service Mesh auront besoin d'un adaptateur, d'un intermédiaire, d'une passerelle. Convenez qu'il serait agréable qu'il soit fourni en standard avec le service. La passerelle AS peut justement prendre en charge n'importe quelle option d'intégration. Imaginez, vous installez simplement l'Enterprise Service Mesh et il est déjà prêt à interagir avec tous les protocoles dont vous avez besoin. Cette approche est très importante pour nous.
Voici à peu près comment nous imaginons la version entreprise de Service Mesh (Enterprise Service Mesh). La personnalisation décrite résout la plupart des problèmes rencontrés lors de l'utilisation des versions open-source prêtes à l'emploi de la plateforme d'intégration. Apparue il y a seulement quelques années, l'architecture Service Mesh continue d'évoluer, et nous sommes heureux de pouvoir contribuer à son développement. Nous espérons que notre expérience vous sera utile.
Source : habr.com
