Service Mesh est un modèle architectural bien connu pour l'intégration de microservices et la migration vers une infrastructure cloud. Aujourd’hui, dans le monde des conteneurs cloud, il est assez difficile de s’en passer. Plusieurs implémentations de services mesh open source sont déjà disponibles sur le marché, mais leur fonctionnalité, leur fiabilité et leur sécurité ne sont pas toujours suffisantes, notamment lorsqu'il s'agit des exigences des grandes sociétés financières du pays. C'est pourquoi chez Sbertech, nous avons décidé de personnaliser Service Mesh et souhaitons parler de ce qui est cool avec Service Mesh, de ce qui ne l'est pas si cool et de ce que nous allons faire à ce sujet.
La popularité du modèle Service Mesh augmente avec la popularité des technologies cloud. Il s'agit d'une couche d'infrastructure dédiée qui simplifie l'interaction entre les différents services réseau. Les applications cloud modernes comprennent des centaines, voire des milliers de services de ce type, chacun pouvant avoir des milliers de copies.
L’interaction entre ces services et leur gestion est une tâche clé du Service Mesh. En fait, il s’agit d’un modèle de réseau composé de nombreux proxys, gérés de manière centralisée et remplissant un ensemble de fonctions très utiles.
Au niveau du proxy (plan de données) :
- Attribuer et distribuer des politiques de routage et d’équilibrage du trafic
- Distribution de clés, certificats, jetons
- Collecte de télémétrie, génération de métriques de surveillance
- Intégration avec l'infrastructure de sécurité et de surveillance
Au niveau du plan de contrôle :
- Appliquer des politiques de routage et d’équilibrage du trafic
- Gérer les tentatives et les timeouts, détecter les nœuds « morts » (coupure de circuit), gérer l'injection de fautes et assurer la résilience du service via d'autres mécanismes
- Authentification/autorisation d'appel
- Suppression des métriques (observabilité)
L'éventail d'utilisateurs intéressés par le développement de cette technologie est très large - des petites startups aux grandes sociétés Internet, par exemple PayPal.
Pourquoi Service Mesh est-il nécessaire dans le secteur des entreprises ?
L’utilisation d’un Service Mesh présente de nombreux avantages évidents. Tout d'abord, c'est tout simplement pratique pour les développeurs : pour écrire du code une plateforme technologique apparaît, ce qui simplifie considérablement l'intégration dans l'infrastructure cloud du fait que la couche de transport est complètement isolée de la logique applicative.
En outre, Service Mesh simplifie la relation entre les fournisseurs et les consommateurs. Aujourd'hui, il est beaucoup plus facile pour les fournisseurs d'API et les consommateurs de s'entendre eux-mêmes sur les interfaces et les contrats, sans faire appel à un intermédiaire d'intégration et à un arbitre spécial : le bus de services d'entreprise. Cette approche affecte de manière significative deux indicateurs. La rapidité de mise sur le marché de nouvelles fonctionnalités (time-to-market) augmente, mais en même temps le coût de la solution augmente, puisque l'intégration doit se faire de manière indépendante. L’utilisation de Service Mesh par les équipes de développement de fonctionnalités métier permet de maintenir un équilibre ici. En conséquence, les fournisseurs d'API peuvent se concentrer exclusivement sur le composant applicatif de leur service et le publier simplement dans Service Mesh - l'API sera immédiatement disponible pour tous les clients et la qualité de l'intégration sera prête pour la production et ne nécessitera pas un seul ligne de code supplémentaire.
Le prochain avantage est que le développeur, utilisant Service Mesh, se concentre uniquement sur les fonctionnalités métier — sur le produit plutôt que sur la composante technologique de son service. Par exemple, vous n'avez plus à penser au fait que dans une situation où un service est appelé sur le réseau, une panne de connexion peut survenir quelque part. De plus, Service Mesh aide à équilibrer le trafic entre les copies du même service : si l'une des copies « meurt », le système basculera tout le trafic vers les copies en direct restantes.
Maillage de services - c'est une bonne base pour créer des applications distribuées, qui cache au client les détails de la fourniture des appels à ses services tant en interne qu'en externe. Toutes les applications utilisant Service Mesh sont isolées au niveau du transport aussi bien du réseau que les unes des autres : il n'y a aucune communication entre elles. Dans ce cas, le développeur a le contrôle total sur ses services.
Il faut noter que La mise à jour des applications distribuées dans un environnement maillé de services devient plus facile. Par exemple, un déploiement bleu/vert, dans lequel deux environnements applicatifs sont disponibles pour l'installation, dont l'un n'est pas mis à jour et est en mode veille. Le retour à la version précédente en cas d'échec de la publication est effectué par un routeur spécial, dont Service Mesh remplit bien le rôle. Pour tester la nouvelle version, vous pouvez utiliser version canari — passer à la nouvelle version seulement 10 % du trafic ou des demandes d'un groupe pilote de clients. Le trafic principal va vers l'ancienne version, rien ne casse.
aussi Service Mesh nous offre un contrôle SLA en temps réel. Le système proxy distribué ne permettra pas au service d'échouer lorsqu'un des clients dépasse le quota qui lui est attribué. Si le débit de l'API est limité, personne ne pourra la submerger avec un grand nombre de transactions : le Service Mesh se tient devant le service et ne permet pas de trafic inutile. Il ripostera simplement au niveau de la couche d'intégration et les services eux-mêmes continueront à fonctionner sans s'en apercevoir.
Si une entreprise souhaite réduire les coûts de développement de solutions d'intégration, Service Mesh aide également : Vous pouvez passer à sa version open source à partir de produits commerciaux. Notre Enterprise Service Mesh est basé sur la version open source de Service Mesh.
Un autre avantage - disponibilité d'un ensemble unique et complet de services d'intégration. Étant donné que toute l'intégration s'effectue via ce middleware, nous pouvons gérer tout le trafic d'intégration et les connexions entre les applications qui constituent le cœur de métier de l'entreprise. C'est très confortable.
Et enfin Service Mesh encourage une entreprise à évoluer vers une infrastructure dynamique. Aujourd’hui, nombreux sont ceux qui se tournent vers la conteneurisation. Découper un monolithe en microservices, mettre en œuvre tout cela magnifiquement - le sujet est en plein essor. Mais lorsque vous essayez de transférer un système en production depuis de nombreuses années vers une nouvelle plateforme, vous rencontrez immédiatement un certain nombre de problèmes : tout mettre dans des conteneurs et le déployer sur la plateforme n'est pas facile. Et la mise en œuvre, la synchronisation et l’interaction de ces composants distribués constituent un autre sujet très complexe. Comment vont-ils communiquer entre eux ? Y aura-t-il des échecs en cascade ? Service Mesh vous permet de résoudre certains de ces problèmes et de faciliter la migration de l'ancienne architecture vers la nouvelle car vous pouvez oublier la logique d'échange réseau.
Pourquoi avez-vous besoin d’une personnalisation de Service Mesh ?
Dans notre entreprise, des centaines de systèmes et de modules cohabitent, et le runtime est très chargé. Ainsi, un simple schéma selon lequel un système en appelle un autre et reçoit une réponse ne suffit pas, car en production, nous en voulons plus. De quoi d’autre avez-vous besoin d’un maillage de services d’entreprise ?
Service de traitement d'événements
Imaginons que nous ayons besoin de réaliser un traitement d'événements en temps réel - un système qui analyse les actions du client en temps réel et peut lui faire immédiatement une offre pertinente. Pour implémenter une fonctionnalité similaire, utilisez modèle architectural appelé architecture événementielle (EDA). Aucun des Service Meshes actuels ne prend en charge nativement de tels modèles, mais c'est très important, surtout pour une banque !
Il est assez étrange que l'appel de procédure à distance (RPC) soit pris en charge par toutes les versions de Service Mesh, mais ils ne sont pas compatibles avec EDA. Parce que Service Mesh est une sorte d'intégration distribuée moderne et EDA est un modèle architectural très pertinent qui vous permet de faire des choses uniques en termes d'expérience client.
Notre Enterprise Service Mesh devrait résoudre ce problème. De plus, nous souhaitons y voir la mise en œuvre d'une livraison garantie, d'un streaming et d'un traitement d'événements complexes utilisant une variété de filtres et de modèles.
Service de transfert de fichiers
En plus de l'EDA, ce serait bien de pouvoir transférer des fichiers : à l'échelle de l'Entreprise, très souvent seule l'intégration de fichiers est possible. En particulier, le modèle architectural ETL (Extract, Transform, Load) est utilisé. En règle générale, tout le monde y échange exclusivement des fichiers : le Big Data est utilisé, ce qui n'est pas pratique pour envoyer des requêtes séparées. La possibilité de prendre en charge de manière native les transferts de fichiers dans Enterprise Service Mesh vous offre la flexibilité dont votre entreprise a besoin.
Service d'orchestration
Les grandes organisations ont presque toujours des équipes différentes qui fabriquent des produits différents. Par exemple, dans une banque, certaines équipes travaillent avec des dépôts, tandis que d'autres travaillent avec des produits de prêt, et les cas de ce type sont assez nombreux. Ce sont différentes personnes, différentes équipes qui fabriquent leurs produits, développent leurs API et les fournissent à d'autres. Et très souvent, il est nécessaire de composer ces services, ainsi que de mettre en œuvre une logique complexe pour appeler séquentiellement un ensemble d'API. Pour résoudre ce problème, il faut une solution dans la couche d'intégration qui simplifiera toute cette logique composite (appel de plusieurs API, description du parcours des requêtes, etc.). Il s’agit du service d’orchestration d’Enterprise Service Mesh.
IA et ML
Lorsque les microservices communiquent via une seule couche d'intégration, le Service Mesh sait naturellement tout sur les appels de chaque service. Nous collectons des données télémétriques : qui a appelé qui, quand, pendant combien de temps, combien de fois, etc. Lorsqu’il existe des centaines de milliers de ces services et des milliards d’appels, alors tout cela s’accumule et forme du Big Data. Ces données peuvent être analysées à l'aide de l'IA, de l'apprentissage automatique, etc., puis certaines choses utiles peuvent être réalisées sur la base des résultats de l'analyse. Il conviendrait de confier au moins partiellement le contrôle de tout ce trafic réseau et des appels applicatifs intégrés dans le Service Mesh à l’intelligence artificielle.
Service de passerelle API
En règle générale, un Service Mesh comporte des proxys et des services qui communiquent entre eux au sein d’un périmètre de confiance. Mais il existe aussi des contreparties externes. Les exigences relatives aux API exposées à ce groupe de consommateurs sont beaucoup plus strictes. Nous divisons cette tâche en deux parties principales.
- sécurité. Problèmes liés aux ddos, à la vulnérabilité des protocoles, des applications, des systèmes d'exploitation, etc.
- Portée. Lorsque le nombre d’API qui doivent être servies aux clients atteint des milliers, voire des centaines de milliers, il est nécessaire de disposer d’une sorte d’outil de gestion pour cet ensemble d’API. Vous devez surveiller en permanence l'API : si elle fonctionne ou non, quel est son statut, quel trafic circule, quelles statistiques, etc. Une passerelle API doit gérer cette tâche tout en rendant l'ensemble du processus gérable et sécurisé. Grâce à ce composant, Enterprise Service Mesh apprend à publier facilement des API internes et externes.
Service de support pour protocoles et formats de données spécifiques (AS gateway)
Actuellement, la plupart des solutions Service Mesh peuvent fonctionner nativement uniquement avec le trafic HTTP et HTTP2 ou en mode réduit au niveau TCP/IP. L’Enterprise Service Mesh fait son apparition avec de nombreux autres protocoles de transfert de données très spécifiques. Certains systèmes peuvent utiliser des courtiers de messages, d'autres sont intégrés au niveau de la base de données. Si l'entreprise dispose de SAP, elle peut également utiliser son propre système d'intégration. De plus, tout cela fonctionne et constitue une partie importante de l’entreprise.
Vous ne pouvez pas simplement dire : « Abandonnons l’héritage et créons de nouveaux systèmes capables d’utiliser Service Mesh. » Pour connecter tous les anciens systèmes aux nouveaux (sur une architecture de microservices), les systèmes pouvant utiliser Service Mesh auront besoin d'une sorte d'adaptateur, d'intermédiaire, de passerelle. D'accord, ce serait bien s'il était livré dans une boîte avec le service. La passerelle AC peut prendre en charge n'importe quelle option d'intégration. Imaginez, vous venez d'installer Enterprise Service Mesh et il est prêt à interagir avec tous les protocoles dont vous avez besoin. Cette approche est très importante pour nous.
C’est à peu près ainsi que l’on imagine la version entreprise de Service Mesh (Enterprise Service Mesh). La personnalisation décrite résout la plupart des problèmes qui surviennent lors de la tentative d'utilisation de versions open source prêtes à l'emploi de la plate-forme d'intégration. Introduite il y a seulement quelques années, l'architecture Service Mesh continue d'évoluer et nous sommes ravis de pouvoir contribuer à son développement. Nous espérons que notre expérience vous sera utile.
Source: habr.com