Pourquoi faisons-nous Enterprise Service Mesh?

Service Mesh est un modèle architectural bien connu pour intégrer des microservices et passer à l'infrastructure cloud. Aujourd'hui, dans le monde des conteneurs cloud, il est assez difficile de s'en passer. Plusieurs implémentations de maillage de services open source sont déjà disponibles sur le marché, mais leur fonctionnalité, leur fiabilité et leur sécurité sont loin d'être toujours suffisantes, en particulier en ce qui concerne les exigences des grandes sociétés financières à travers le pays. Par conséquent, chez Sbertech, nous avons décidé de personnaliser Service Mesh et voulons parler de ce qui est cool dans Service Mesh, de ce qui n'est pas très et de ce que nous allons en faire.



La popularité du modèle Service Mesh augmente avec la popularité de la technologie 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 se composent de centaines, voire de milliers de ces services, chacun pouvant avoir des milliers de copies.



L'interaction entre ces services et leur gestion est une tâche clé de Service Mesh. En fait, il s'agit d'un modèle de réseau à partir d'une variété de procurations, géré de manière centralisée et exécutant 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, formation 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
  
• Gestion des relances et des timeouts, définition des nœuds «morts» (coupure de circuits), gestion des situations défaillantes (injection de défauts) et maintien de la résilience des services à travers d'autres mécanismes
  
• Authentification / autorisation d'appel
  
• Jeter les métriques (observabilité)
  

Le cercle des 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.

À quoi sert Service Mesh dans le secteur des entreprises?

L'utilisation de Service Mesh présente de nombreux avantages évidents. Tout d'abord, c'est juste pratique pour les développeurs: une plate-forme technologique apparaît pour écrire du code 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 d'application.

De plus, Service Mesh simplifie la relation entre fournisseurs et consommateurs. Aujourd'hui, il est beaucoup plus facile pour les fournisseurs et les consommateurs de l'API de se mettre d'accord sur des interfaces et des contrats par eux-mêmes, sans impliquer un intermédiaire d'intégration spécial et un arbitre pour cela - un bus de services d'entreprise. Cette approche affecte de manière significative deux indicateurs. La vitesse 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, car l'intégration doit se faire de manière indépendante. L'utilisation de Service Mesh par les équipes de développement commercial permet de maintenir l'équilibre ici. En conséquence, les fournisseurs d'API peuvent se concentrer exclusivement sur le composant d'application de leur service et le publier simplement dans le maillage de service - l'API deviendra immédiatement disponible pour tous les clients, et la qualité d'intégration sera prête pour la production et ne nécessitera pas une seule ligne de code supplémentaire.

Un autre avantage est que le développeur, en utilisant le Service Mesh, se concentre uniquement sur les fonctionnalités de l'entreprise - sur le produit, et non sur la composante technologique de son service. Par exemple, vous n'avez pas à penser au fait que dans une situation où le service sera appelé sur le réseau, quelque part la connexion peut se rompre. En outre, Service Mesh permet d'équilibrer le trafic entre les copies du même service: si l'une des copies «meurt», le système bascule tout le trafic vers les copies actives restantes.

Service Mesh est une bonne base pour créer des applications distribuées , qui cache au client les détails de la fourniture d'appels à ses services à la fois en interne et en externe. Toutes les applications qui utilisent Service Mesh sont isolées sur la couche transport à la fois du réseau et les unes des autres: il n'y a pas de connexion entre elles. Dans ce cas, le développeur obtient un contrôle total sur leurs services.

Il convient de noter que la mise à jour des applications distribuées dans un environnement où Service Mesh est utilisé devient de plus en plus facile. Par exemple, le déploiement bleu / vert, dans lequel deux environnements d'application sont disponibles pour l'installation, dont l'un n'est pas mis à jour et est en mode veille. La restauration de la version précédente en cas d'échec de la libération est effectuée par un routeur spécial, dont le rôle est parfaitement pris en charge par Service Mesh . Vous pouvez utiliser la version Canary pour exécuter dans la nouvelle version - basculez seulement 10% du trafic ou des demandes du groupe de clients pilotes vers la nouvelle version. Le trafic principal passe à l'ancienne version, rien ne casse.

Service Mesh nous donne également un contrôle SLA en temps réel . Le système de procurations distribuées ne permettra pas d'inonder le service lorsqu'un des clients dépasse le quota qui lui est attribué. Si la bande passante de l'API est limitée, personne ne pourra l'étrangler avec un grand nombre de transactions: le Service Mesh est en face du service et ne permet pas de trafic supplémentaire. Il va tout simplement battre dans la couche d'intégration, et les services eux-mêmes continueront de fonctionner sans s'en rendre compte.

Si l'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 est la disponibilité d'un ensemble complet de services d'intégration . Étant donné que toute intégration est construite à travers cette couche intermédiaire, nous pouvons gérer tout le trafic d'intégration et les connexions entre les applications qui forment le cœur de métier de l'entreprise. C'est très pratique.

Enfin, Service Mesh conduit l'entreprise à passer à une infrastructure dynamique. Maintenant, beaucoup se tournent vers la conteneurisation. Scier un monolithe en microservices, c'est beau de tout mettre en œuvre - le sujet est à la hausse. Mais lorsque vous essayez de transférer sur une nouvelle piste un système qui est en production depuis de nombreuses années, vous rencontrez immédiatement un certain nombre de problèmes: tout mettre dans des conteneurs et le déployer sur la plate-forme n'est pas facile. Et l'implémentation, la synchronisation et l'interaction de ces composants distribués est un autre sujet difficile. 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 de l'échange réseau.

Pourquoi personnaliser le maillage de service

Dans notre entreprise, des centaines de systèmes et de modules coexistent et le temps d'exécution est très chargé. Ainsi, un schéma simple, lorsqu'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 avez-vous besoin de plus d'un maillage de service d'entreprise?

Service de traitement d'événements

Imaginez que nous devons faire un traitement d'événement en temps réel - un système qui analyse en temps réel les actions du client et peut immédiatement lui faire une offre pertinente. Pour implémenter cette fonctionnalité, un modèle architectural appelé architecture événementielle (EDA) est utilisé . Aucun des services Mesh concernés ne prend en charge de tels modèles de manière native, mais cela est très important, en particulier pour la banque!

Il est étrange que l'appel de procédure distante (RPC) prenne en charge toutes les versions du Service Mesh, et ils ne sont pas amis avec EDA. Parce que Service Mesh est un semblant 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 voulons y voir la mise en œuvre de la livraison garantie, du streaming et du traitement d'événements intégré à l'aide d'une variété de filtres et de modèles.

Service de transfert de fichiers

En plus d'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 est utilisé (Extraire, Transformer, Charger - «extraire, transformer, charger»). Dans ce document, en règle générale, tout le monde échange des fichiers exclusivement: ils utilisent des données volumineuses, ce qui n'est pas pratique pour insérer des demandes distinctes. La possibilité de prendre en charge nativement les transferts de fichiers dans l'Enterprise Service Mesh offre la flexibilité dont les besoins métier.

Service d'orchestration

Dans les grandes organisations, il y a 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 crédit, et il y a beaucoup de tels cas. Ce sont des personnes différentes, des équipes différentes qui fabriquent leurs produits, développent leurs API et les fournissent à d'autres. Et très souvent il y a un besoin pour la composition de ces services, ainsi que la mise en œuvre de la logique complexe de l'appel séquentiel de l'ensemble d'API. Pour résoudre ce problème, une solution est nécessaire dans la couche d'intégration, ce qui simplifiera toute cette logique composite (appel de plusieurs API, décrivant le chemin des requêtes, etc.). Il s'agit du service d'orchestration dans l'Enterprise Service Mesh.

AI et ML

Lorsque les microservices communiquent via une seule couche d'intégration, Service Mesh, bien sûr, sait tout sur les appels de chaque service. Nous collectons la télémétrie: qui a appelé qui, quand, combien de temps, combien de fois, etc. Lorsqu'il existe des centaines de milliers de ces services et des milliards d'appels, tout cela s'accumule et forme des Big Data. Ces données peuvent être analysées à l'aide de l'IA, de l'apprentissage automatique, etc., puis effectuer des tâches utiles en fonction des résultats de l'analyse. Il conviendrait de transférer au moins partiellement à l'intelligence artificielle la gestion de tout ce trafic réseau et appels applicatifs intégrés au Service Mesh.

Service de passerelle API

En règle générale, Service Mesh dispose de serveurs proxy et de services qui s’accèdent mutuellement à l’intérieur du périmètre de confiance. Mais il existe également des contreparties externes. Les exigences API pour ce groupe de consommateurs sont beaucoup plus sérieuses. Nous divisons cette tâche en deux parties principales.

• La sécurité Problèmes liés aux ddos, vulnérabilité des protocoles, applications, systèmes d'exploitation, etc.
  
• L'échelle . Lorsque la facture d'API qui doit être remise aux clients atteint des milliers voire des centaines de milliers, il existe un besoin pour certains moyens de gérer cet ensemble d'API. Vous devez surveiller en permanence l'API: fonctionnent-elles ou non, dans quel état, quel trafic est en cours, quelles statistiques, etc. La passerelle API doit gérer cette tâche, ce qui rend l'ensemble du processus gérable et sécurisé. Grâce à ce composant, l'Enterprise Service Mesh apprend à publier les API internes et externes sans trop de difficulté.
  

Service d'assistance pour des protocoles et formats de données spécifiques (passerelle AS)

Actuellement, la plupart des solutions Service Mesh ne peuvent fonctionner en mode natif qu'avec le trafic HTTP et HTTP2 ou en mode tronqué au niveau TCP / IP. Enterprise Service Mesh possède 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 possède SAP, elle peut également utiliser son propre système d'intégration. Et 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 qui peuvent utiliser le maillage de service." Pour se faire des amis de tous les anciens systèmes avec de nouveaux (sur l'architecture de microservice), les systèmes qui peuvent utiliser Service Mesh auront besoin d'une sorte d'adaptateur, d'intermédiaire et de passerelle. D'accord, ce serait bien s'il était livré dans une boîte avec le service. La passerelle AS peut prendre en charge n'importe quelle option d'intégration. Imaginez, vous installez simplement l'Enterprise Service Mesh, et il est prêt à interagir avec tous les protocoles dont vous avez besoin. Pour nous, cette approche est très importante.

C'est ainsi que nous présentons la version d'entreprise de Service Mesh (Enterprise Service Mesh). La personnalisation décrite résout la plupart des problèmes qui se posent lorsque vous essayez d'utiliser des versions open source prêtes à l'emploi de la plate-forme d'intégration. Apparue il y a quelques années à peine, 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.