Réponse.

L'architecture avec un service mesh est conçue pour gérer les interactions complexes entre les microservices à l'aide d'une couche d'infrastructure distincte. Le service mesh fournit automatiquement des fonctions telles que le routage, l'équilibrage de charge, la découverte de services, la sécurité (par exemple, mTLS), la journalisation, le suivi et la réessai des requêtes sans avoir besoin de les implémenter dans chaque service. Tout cela est réalisé grâce à des proxys spéciaux (sidecar) qui s'exécutent à côté de chaque microservice et interceptent tout le trafic réseau.

Une architecture microservices traditionnelle nécessite que la plupart de ces fonctionnalités soient mises en œuvre à l'intérieur des services eux-mêmes ou au niveau de la plateforme, ce qui complique le développement et la maintenance d'un projet avec un grand nombre de services.

Exemple de code pour configurer un service mesh Istio pour Kubernetes :

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: my-service
spec:
  hosts:
    - my-service
  http:
    - route:
        - destination:
            host: my-service
            subset: v1

Caractéristiques clés :

• Routage centralisé et gestion des politiques d'interaction réseau.

• Minimisation de la duplication du code de logique d'interaction dans chaque service.

• Sécurité et surveillance améliorées sans modifier la logique métier des applications.

Questions piégées.

Le service mesh remplace-t-il complètement le passerelle API ?

Non, le service mesh et la passerelle API se complètent : la passerelle API assure le contrôle d'entrée, tandis que le service mesh gère la communication est-ouest entre les services.

Faut-il modifier le code des services lors de l'implémentation d'un service mesh ?

Généralement non. Dans la plupart des cas, le proxy de service s'exécute en mode sidecar, et le code de la logique métier n'a pas besoin d'être modifié.

Le service mesh dégrade-t-il les performances des microservices ?

Le service mesh introduit en effet un léger retard en raison du traitement du trafic par le proxy, mais pour la plupart des scénarios, cela est négligeable par rapport aux avantages en termes de gestion et de fiabilité.