Service Mesh pour microservices C# : comment survivre dans le zoo .NET

Vos microservices .NET ont échappé à tout contrôle ? Découvrez Service Mesh

Imaginez : vous avez cinq, dix, voire cinquante microservices C#. Ils communiquent entre eux via HTTP, gRPC ou RabbitMQ. Tout fonctionne... jusqu'à ce que ça ne fonctionne plus. Timeouts, retries, circuit breakers, équilibrage de charge, authentification entre services — chaque développeur réécrit la même chose à partir de zéro. Cela vous dit quelque chose ?

C'est ce qu'on appelle le « problème du zoo des microservices » — quand la logique métier se noie dans le code d'infrastructure. Et c'est là qu'intervient le Service Mesh — un modèle architectural qui externalise toute la partie réseau de votre code C#. Dans cet article, nous allons voir comment apprivoiser Service Mesh dans le monde .NET, écrire du code réel et comprendre si cela en vaut la peine.

Qu'est-ce que Service Mesh en termes simples (pour un développeur C#)

Service Mesh est une couche d'infrastructure dédiée à la gestion de la communication entre les services. Imaginez que chacun de vos microservices C# reçoive un « assistant invisible » — un proxy sidecar (généralement Envoy ou Linkerd-proxy). Ce proxy intercepte tout le trafic entrant et sortant du service et fait tout le sale boulot à votre place :

\n
• Découverte de services — plus d'URL codées en dur.
\n
• Équilibrage de charge — répartition intelligente des requêtes.
\n
• Retries et timeouts — tentatives automatiques en cas d'échec.
\n
• Circuit Breaker — protection contre les défaillances en cascade.
\n
• Chiffrement mTLS — sécurité « prête à l'emploi ».
\n
• Observabilité (Observability) — métriques, tracing, logs.
\n

Le principal avantage pour C# : votre code reste propre. Vous écrivez uniquement la logique métier, et toute la magie réseau est prise en charge par Service Mesh. Les implémentations les plus populaires : Istio (lourd mais puissant) et Linkerd (léger, rapide, écrit en Rust).

Écrire un microservice C# prêt pour Service Mesh

Pour comprendre la magie, créons un simple microservice .NET en C# et préparons-le à fonctionner avec Service Mesh. Nous utiliserons gRPC — le protocole idéal pour la communication interne des microservices.

Étape 1 : Créer un service gRPC en C#

Ouvrez un terminal et exécutez :

dotnet new grpc -n OrderService\ncd OrderService

Ajoutons un simple fichier proto Protos/orders.proto :

syntax = "proto3";\n\nservice OrderGrpc {\n  rpc GetOrder (OrderRequest) returns (OrderResponse);\n}\n\nmessage OrderRequest {\n  string order_id = 1;\n}\n\nmessage OrderResponse {\n  string order_id = 1;\n  string status = 2;\n  double total = 3;\n}

Implémentons le service dans Services/OrderService.cs :

public class OrderService : OrderGrpc.OrderGrpcBase\n{\n    private readonly ILogger<OrderService> _logger;\n\n    public OrderService(ILogger<OrderService> logger)\n    {\n        _logger = logger;\n    }\n\n    public override Task<OrderResponse> GetOrder(OrderRequest request, ServerCallContext context)\n    {\n        _logger.LogInformation("Requête de commande {OrderId}", request.OrderId);\n        // Ici pourrait se trouver votre logique métier\n        return Task.FromResult(new OrderResponse\n        {\n            OrderId = request.OrderId,\n            Status = "Confirmé",\n            Total = 99.99\n        });\n    }\n}

Lancez :

dotnet run

Le service fonctionne sur le port 5001 (par défaut pour gRPC). Imaginez maintenant que vous ayez 20 services de ce type. Comment gérer leur communication ? C'est là que Service Mesh entre en jeu.

Configuration d'Istio pour les microservices C# : étape par étape

Supposons que votre cluster Kubernetes soit déjà configuré. Installons Istio :

istioctl install --set profile=demo -y

Activons maintenant l'injection automatique du