Développement Backend Robuste avec C# et .NET: De l'API REST aux Microservices
Développement Backend Robuste avec C# et .NET: De l'API REST aux Microservices

Observabilité et Résilience des Microservices avec .NET: Logging, Monitoring et Patterns Avancés

Contexte du cours : Développement Backend Robuste avec C# et .NET: De l'API REST aux Microservices

Introduction: Naviguer dans le Labyrinthe des Microservices

Bienvenue dans cette leçon consacrée à deux piliers fondamentaux de la réussite des architectures de microservices : l'Observabilité et la Résilience. Alors que le passage des applications monolithiques aux microservices apporte une agilité et une scalabilité indéniables, il introduit également une complexité significative. Au lieu d'une seule application "géante" facile à déboguer localement, nous nous retrouvons avec un réseau de services distribués, chacun ayant ses propres déploiements, bases de données, et logiques métier.

Imaginez une ville : dans un monolithe, toutes les fonctions vitales sont regroupées dans un seul bâtiment. Si ce bâtiment est affecté, toute la ville est à l'arrêt, mais la cause est généralement localisée. Dans une architecture de microservices, chaque fonction est un petit bâtiment autonome. Cela rend la ville plus robuste globalement (la défaillance d'un bâtiment n'arrête pas tout), mais la comprendre et la maintenir devient un défi. Comment savoir quel bâtiment est en difficulté ? Comment garantir que la défaillance d'un petit bâtiment ne provoque pas l'effondrement de tout un quartier ?

C'est précisément là qu'interviennent l'Observabilité et la Résilience.

  • L'Observabilité est la capacité de comprendre l'état interne d'un système à partir de ses sorties externes. En d'autres termes, elle nous permet de voir ce qui se passe dans notre système distribué, de diagnostiquer les problèmes et de comprendre les performances, souvent sans avoir à déployer de nouveau code. Elle est cruciale pour le débogage, l'optimisation des performances et la compréhension des interactions complexes.
  • La Résilience est la capacité d'un système à récupérer gracieusement des défaillances et à continuer de fonctionner, même en présence d'erreurs ou de perturbations. Elle consiste à concevoir nos services de manière à ce qu'ils puissent gérer l'imprévu, minimiser l'impact des pannes et maintenir un niveau de service acceptable.

Dans cette leçon, nous allons explorer en détail les concepts, les outils et les patterns essentiels pour rendre vos microservices .NET non seulement fonctionnels, mais aussi intelligents et robustes.

1. L'Observabilité: Voir ce qui se passe

L'observabilité est souvent décrite à travers ses trois piliers fondamentaux : la journalisation (Logging), les métriques (Metrics) et le traçage distribué (Distributed Tracing). Ensemble, ils fournissent une vue complète de la santé et du comportement de vos microservices.

1.1 Les Piliers de l'Observabilité

1.1.1 Logging (Journalisation)

Les logs sont les enregistrements textuels des événements qui se produisent au sein d'une application. Dans un monolithe, les logs peuvent être écrits dans un fichier local ou la console. Dans un environnement de microservices, cette approche est insuffisante. Les requêtes traversent plusieurs services, et corréler les logs devient un casse-tête sans une stratégie adéquate.

Concepts Clés :

  • Structured Logging (Journalisation structurée) : Plutôt que de simples chaînes de caractères, les logs structurés sont des objets JSON (ou un format similaire) avec des paires clé-valeur. Cela les rend facilement interrogeables, analysables et agrégables par des outils automatisés.
    • Exemple : {"Timestamp": "...", "Level": "Information", "Message": "Requête reçue", "Endpoint": "/api/users", "Method": "GET", "CorrelationId": "abc-123"}
  • Centralized Logging (Journalisation centralisée) : Tous les logs de tous les services sont collectés et envoyés à un système centralisé. Ce système permet de rechercher, de filtrer, d'agréger et de visualiser les logs de manière cohérente.
    • Outils courants : ELK Stack (Elasticsearch, Logstash, Kibana), Grafana Loki, Azure Log Analytics, Datadog, Splunk.
  • Niveaux de Log : Utiliser des niveaux (Debug, Information, Warning, Error, Critical) permet de contrôler la verbosité des logs et de filtrer les informations en fonction de leur importance.
  • Correlation IDs (IDs de corrélation) : Pour le traçage distribué, il est crucial d'inclure un identifiant unique (un "Correlation ID" ou "Trace ID") dans chaque log associé à une requête spécifique, et de le propager à travers tous les services impliqués.

Implémentation avec .NET :

.NET propose Microsoft.Extensions.Logging comme abstraction standard pour la journalisation. Vous pouvez ensuite brancher des fournisseurs de logs (Serilog, NLog, etc.) qui implémentent cette abstraction.

Serilog est un choix populaire pour la journalisation structurée grâce à sa syntaxe fluide et sa capacité à écrire dans divers "sinks" (destinations comme la console, des fichiers, ou des systèmes centralisés).

// 1. Installation des packages NuGet :
//    Install-Package Serilog
//    Install-Package Serilog.AspNetCore
//    Install-Package Serilog.Sinks.Console
//    Install-Package Serilog.Sinks.Seq (pour un serveur de log structuré local comme Seq)

// 2. Configuration dans Program.cs (ou Startup.cs pour les anciennes versions)
using Serilog;
using Serilog.Events;

public class Program
{
    public static void Main(string[] args)
    {
        Log.Logger = new LoggerConfiguration()
            .MinimumLevel.Debug() // Niveau minimum pour le log
            .MinimumLevel.Override("Microsoft", LogEventLevel.Warning) // Réduit le bruit de MS
            .Enrich.FromLogContext() // Permet d'ajouter des propriétés au contexte de log
            .WriteTo.Console() // Écrit les logs dans la console
            // .WriteTo.Seq("http://localhost:5341") // Exemple d'envoi à un serveur Seq
            .CreateLogger();

        try
        {
            Log.Information("Démarrage de l'application web...");
            CreateHostBuilder(args).Build().Run();
        }
        catch (Exception ex)
        {
            Log.Fatal(ex, "L'application a démarré de manière inattendue.");
        }
        finally
        {
            Log.CloseAndFlush();
        }
    }

    public static IHostBuilder CreateHostBuilder(string[] args) =>
        Host.CreateDefaultBuilder(args)
            .UseSerilog() // Intègre Serilog avec le système de logging .NET
            .ConfigureWebHostDefaults(webBuilder =>
            {
                webBuilder.UseStartup<Startup>();
            });
}

// 3. Utilisation dans un contrôleur ou un service
using Microsoft.Extensions.Logging;
using Microsoft.AspNetCore.Mvc;

[ApiController]
[Route("[controller]")]
public class WeatherForecastController : ControllerBase
{
    private readonly ILogger<WeatherForecastController> _logger;

    public WeatherForecastController(ILogger<WeatherForecastController> logger)
    {
        _logger = logger;
    }

    [HttpGet]
    public IEnumerable<WeatherForecast> Get()
    {
        // Exemple de log information
        _logger.LogInformation("Requête GET WeatherForecast reçue.");

        // Exemple de log avec des données structurées
        var location = "Paris";
        _logger.LogInformation("Prévisions météo demandées pour {Location}.", location);
        
        try
        {
            // Simuler une erreur
            if (DateTime.Now.Second % 2 == 0)
            {
                throw new InvalidOperationException("Erreur de simulation !");
            }
            return Enumerable.Range(1, 5).Select(index => new WeatherForecast
            {
                Date = DateTime.Now.AddDays(index),
                TemperatureC = Random.Shared.Next(-20, 55),
                Summary = Summaries[Random.Shared.Next(Summaries.Length)]
            })
            .ToArray();
        }
        catch (Exception ex)
        {
            // Exemple de log d'erreur avec exception
            _logger.LogError(ex, "Une erreur est survenue lors de la récupération des prévisions météo pour {Location}.", location);
            throw; // Re-jeter l'exception pour le gestionnaire d'erreurs global
        }
    }
}

Explication du code : Le premier bloc de code configure Serilog au démarrage de l'application, en spécifiant les niveaux de log et les destinations (console, ou un serveur comme Seq). UseSerilog() branche Serilog sur le système de logging intégré de .NET. Le second bloc montre comment injecter ILogger dans un contrôleur et l'utiliser pour enregistrer différents types de messages. L'utilisation de placeholders comme {Location} dans LogInformation et LogError permet à Serilog de capturer ces valeurs comme des propriétés structurées dans le log, facilitant ainsi les recherches ultérieures.

1.1.2 Metrics (Mesures)

Les métriques sont des données numériques représentant l'état d'un système à un moment donné ou sur une période. Contrairement aux logs qui sont des événements discrets, les métriques sont des valeurs agrégables qui permettent de suivre les tendances et de générer des alertes.

Concepts Clés :

  • Types de Métriques :
    • Counter (Compteur) : Une valeur qui ne fait qu'augmenter (ex: nombre de requêtes traitées, erreurs survenues).
    • Gauge (Jauge) : Une valeur qui peut augmenter ou diminuer (ex: nombre de connexions actives, utilisation CPU actuelle).
    • Histogram (Histogramme) : Mesure la distribution d'une série de valeurs sur une période (ex: temps de réponse des requêtes, tailles des messages). Fournit des informations sur les valeurs moyennes, min, max et les percentiles.
    • Summary (Résumé) : Similaire à l'histogramme, mais calcule des quantiles côté client.
  • Métriques Opérationnelles : CPU, mémoire, I/O disque, bande passante réseau, nombre de requêtes par seconde (RPS), latence, taux d'erreurs, taille des files d'attente.
  • Métriques Métier : Nombre d'inscriptions d'utilisateurs, de transactions réussies, de paniers abandonnés.
  • Outils de Collecte et Visualisation : Prometheus, Grafana, Azure Monitor, Datadog, New Relic.

Implémentation avec .NET :

Depuis .NET 6, System.Diagnostics.Metrics fournit des APIs intégrées pour la création et la consommation de métriques. OpenTelemetry est le standard de facto pour l'instrumentation.

// 1. Installation des packages NuGet pour OpenTelemetry (si vous souhaitez exporter les métriques) :
//    Install-Package OpenTelemetry.Extensions.Hosting
//    Install-Package OpenTelemetry.Instrumentation.AspNetCore
//    Install-Package OpenTelemetry.Exporter.Prometheus.AspNetCore (ou tout autre exporteur)

// 2. Configuration dans Program.cs
using System.Diagnostics.Metrics;
using OpenTelemetry.Metrics; // Nécessaire pour l'extension AddMeter

public class Program
{
    // Définition d'un Meter unique pour votre application/service
    // Le nom doit être unique et identifier l'origine des métriques
    private static readonly Meter MyServiceMeter = new("MyService.APIMetrics", "1.0.0");
    // Création d'un Counter pour suivre le nombre de requêtes entrantes
    private static readonly Counter<long> IncomingRequestsCounter = 
        MyServiceMeter.CreateCounter<long>("app-incoming-requests", "req", "Number of incoming requests");
    // Création d'un Histogram pour mesurer la durée des requêtes
    private static readonly Histogram<double> RequestDuration = 
        MyServiceMeter.CreateHistogram<double>("app-request-duration", "ms", "Duration of incoming requests");

    public static void Main(string[] args)
    {
        CreateHostBuilder(args).Build().Run();
    }

    public static IHostBuilder CreateHostBuilder(string[] args) =>
        Host.CreateDefaultBuilder(args)
            .ConfigureServices((hostContext, services) =>
            {
                services.AddOpenTelemetry()
                    .WithMetrics(builder =>
                    {
                        // Ajoute le Meter que nous avons défini
                        builder.AddMeter("MyService.APIMetrics"); 
                        
                        // Instrumentation automatique pour ASP.NET Core
                        builder.AddAspNetCoreInstrumentation(); 

                        // Autres compteurs .NET par défaut utiles
                        builder.AddRuntimeInstrumentation() // CPU, GC, Threads, etc.
                               .AddProcessInstrumentation(); // Infos sur le processus
                        
                        // Exporter les métriques. Ici, vers Prometheus pour scraping
                        builder.AddPrometheusHttpListener(options =>
                        {
                            options.UriPrefixes = new string[] { "http://localhost:9091/" };
                        });
                        // Ou vers un autre exporteur si vous utilisez un autre système (OTLP par exemple)
                        // builder.AddOtlpExporter(options => options.Endpoint = new Uri("http://localhost:4317/"));
                    });
            })
            .ConfigureWebHostDefaults(webBuilder =>
            {
                webBuilder.UseStartup<Startup>();
            });
}

// 3. Utilisation dans un contrôleur ou un service
using Microsoft.AspNetCore.Mvc;
using System.Diagnostics; // Important pour Stopwatch

[ApiController]
[Route("[controller]")]
public class ProductController : ControllerBase
{
    public ProductController()
    {
        // Le Meter est statique, donc pas besoin d'injection directe ici,
        // mais on peut le récupérer via DI si on veut plusieurs instances
    }

    [HttpGet("{id}")]
    public ActionResult<string> Get(int id)
    {
        IncomingRequestsCounter.Add(1, new KeyValuePair<string, object?>("endpoint", "/products/{id}"));
        
        var stopwatch = Stopwatch.StartNew();
        try
        {
            // Logique métier pour récupérer le produit
            Thread.Sleep(Random.Shared.Next(50, 200)); // Simule un travail
            return $"Produit {id}";
        }
        finally
        {
            stopwatch.Stop();
            // Enregistre la durée de la requête
            RequestDuration.Record(stopwatch.Elapsed.TotalMilliseconds, 
                                   new KeyValuePair<string, object?>("endpoint", "/products/{id}"));
        }
    }
}

Explication du code : Nous définissons un Meter statique pour l'ensemble du service, puis des compteurs (Counter) et des histogrammes (Histogram) à partir de ce Meter. Le Program.cs configure OpenTelemetry pour collecter les métriques de ce Meter (via AddMeter("MyService.APIMetrics")) et des instrumentations automatiques (.NET Runtime, ASP.NET Core). Il configure également un exportateur (ici, Prometheus) pour rendre les métriques disponibles. Dans le contrôleur, IncomingRequestsCounter.Add(1, ...) incrémente le compteur avec une "dimension" endpoint, tandis que RequestDuration.Record(...) enregistre la durée de la requête, également avec une dimension. Ces dimensions sont cruciales pour filtrer et agréger les métriques par la suite.

1.1.3 Tracing Distribué (Traces)

Le traçage distribué est la technique qui permet de suivre le chemin d'une seule requête utilisateur à travers tous les microservices qu'elle traverse. C'est essentiel pour comprendre les performances des systèmes distribués et diagnostiquer les problèmes de latence ou d'erreurs.

Concepts Clés :

  • Span : Représente une seule opération logique au sein d'une trace (ex: appel à une fonction, requête HTTP à un autre service, requête de base de données). Chaque Span a un nom, une durée, des attributs (clé-valeur) et peut avoir des événements.
  • Trace : Une collection de Spans qui représentent le chemin complet d'une requête à travers un système distribué. Les Spans d'une même trace sont liées entre elles (parent-enfant).
  • Contexte de Traçage : Informations qui sont propagées d'un service à l'autre (via des en-têtes HTTP par exemple) pour relier les Spans entre elles et former une Trace cohérente. Inclut le Trace ID et le Span ID du parent.
  • Visualisation : Les outils de traçage présentent les traces sous forme de diagrammes de Gantt, montrant la séquence et la durée de chaque opération.
  • Outils : OpenTelemetry (standard d'instrumentation), Jaeger, Zipkin, Azure Application Insights, Datadog.

Implémentation avec .NET :

OpenTelemetry est le choix recommandé pour le traçage distribué. Il fournit une API et un SDK neutres vis-à-vis du fournisseur.

// 1. Installation des packages NuGet OpenTelemetry pour le tracing :
//    Install-Package OpenTelemetry.Extensions.Hosting
//    Install-Package OpenTelemetry.Instrumentation.AspNetCore
//    Install-Package OpenTelemetry.Instrumentation.HttpClient
//    Install-Package OpenTelemetry.Exporter.Console (pour le débogage local)
//    Install-Package OpenTelemetry.Exporter.OpenTelemetryProtocol (pour exporter vers Jaeger/Zipkin/Collector)

// 2. Configuration dans Program.cs
using OpenTelemetry.Trace;

public class Program
{
    public static void Main(string[] args)
    {
        CreateHostBuilder(args).Build().Run();
    }

    public static IHostBuilder CreateHostBuilder(string[] args) =>
        Host.CreateDefaultBuilder(args)
            .ConfigureServices((hostContext, services) =>
            {
                services.AddOpenTelemetry()
                    .WithTracing(builder =>
                    {
                        // Instrumentation automatique pour ASP.NET Core (requêtes entrantes)
                        builder.AddAspNetCoreInstrumentation(); 
                        // Instrumentation automatique pour HttpClient (requêtes sortantes)
                        builder.AddHttpClientInstrumentation(); 
                        
                        // Exemple d'ajout d'un Span manuel si besoin (rare avec les instrumentations auto)
                        // builder.AddSource("MyService.ActivitySource"); 

                        // Exporter les traces
                        // Pour le débogage, imprime dans la console
                        builder.AddConsoleExporter(); 
                        // Pour l'intégration avec un système de traçage (ex: Jaeger, Zipkin via OTLP Collector)
                        // builder.AddOtlpExporter(options => options.Endpoint = new Uri("http://localhost:4317/"));
                    });
            })
            .ConfigureWebHostDefaults(webBuilder =>
            {
                webBuilder.UseStartup<Startup>();
            });
}

// 3. Utilisation dans un contrôleur ou un service (souvent pas de code explicite si instrumentations auto)
using System.Net.Http;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Mvc;

[ApiController]
[Route("[controller]")]
public class OrderController : ControllerBase
{
    private readonly IHttpClientFactory _httpClientFactory;

    public OrderController(IHttpClientFactory httpClientFactory)
    {
        _httpClientFactory = httpClientFactory;
    }

    [HttpPost]
    public async Task<IActionResult> CreateOrder()
    {
        // Lorsqu'une requête arrive ici, ASP.NET Core Instrumentation crée un Span
        // et propage automatiquement le contexte de traçage si la requête entrante en a un.

        // Simuler un appel à un autre microservice (ex: service de paiement)
        // HttpClientInstrumentation de OpenTelemetry détectera cet appel
        // et créera un nouveau Span enfant, propageant le contexte de traçage.
        var httpClient = _httpClientFactory.CreateClient();
        httpClient.BaseAddress = new Uri("http://localhost:5001/"); // Simuler un autre service

        await httpClient.PostAsync("/api/payment", new StringContent("..."));

        // Vous pouvez ajouter des Spans manuels si vous avez des opérations internes complexes
        // utilisant System.Diagnostics.Activity (l'API sous-jacente d'OpenTelemetry en .NET)
        using (var activity = System.Diagnostics.Activity.Current?.Source.StartActivity("ProcessOrderInternally"))
        {
            activity?.AddTag("orderId", Guid.NewGuid().ToString());
            // Logique métier complexe
            await Task.Delay(50);
        }

        return Ok("Commande créée.");
    }
}

Explication du code : La configuration dans Program.cs est la plus importante. AddAspNetCoreInstrumentation() et AddHttpClientInstrumentation() sont les clés. La première instrumente automatiquement les requêtes HTTP entrantes (API Gateways, contrôleurs), créant des Spans pour chaque requête. La seconde instrumente les appels HttpClient sortants, créant des Spans enfants et propageant le contexte de traçage via les en-têtes HTTP (comme traceparent). Dans le contrôleur OrderController, aucun code explicite d'OpenTelemetry n'est nécessaire pour le traçage de base, car les instrumentations automatiques gèrent la majeure partie du travail. Un exemple de System.Diagnostics.Activity est montré pour des scénarios plus granulaires.

1.2 Outils et Plateformes pour l'Observabilité

  • Prometheus & Grafana : Combinaison open source très populaire pour la collecte de métriques (Prometheus) et leur visualisation sous forme de tableaux de bord (Grafana).
  • Jaeger / Zipkin : Outils open source dédiés au traçage distribué, souvent utilisés avec OpenTelemetry.
  • ELK Stack (Elasticsearch, Logstash, Kibana) : Suite pour la journalisation centralisée, la recherche et l'analyse de logs.
  • Azure Monitor / Application Insights : Solutions complètes de Microsoft pour l'observabilité dans Azure, incluant logs, métriques, traçage et alertes.
  • Datadog, New Relic, Splunk : Solutions commerciales "tout-en-un" qui couvrent les trois piliers de l'observabilité et offrent des fonctionnalités avancées.

2. La Résilience: Gérer l'Imprévu

Dans un système distribué, la défaillance est une certitude, pas une possibilité. Un service peut être en panne, le réseau peut rencontrer des latences, une base de données peut être inaccessible. La résilience consiste à concevoir vos microservices pour qu'ils puissent gérer ces défaillances de manière élégante, minimisant l'impact sur l'utilisateur final et évitant les défaillances en cascade.

2.1 Pourquoi la Résilience est Cruciale ?

  • Interdépendances : Les microservices dépendent les uns des autres. La défaillance d'un service peut entraîner la défaillance de ses dépendances.
  • Latence Réseau : Les appels réseau sont intrinsèquement plus lents et moins fiables que les appels en mémoire.
  • Charge Variable : Les services peuvent être surchargés, entraînant des temps de réponse lents ou des erreurs.
  • Indépendance des Déploiements : Permet de déployer des services indépendamment sans craindre de casser l'ensemble du système.

2.2 Patterns de Résilience Clés

2.2.1 Retry (Réessai)

Le pattern de réessai consiste à retenter une opération qui a échoué. Utile pour les erreurs transitoires (problèmes réseau temporaires, verrouillages de base de données).

  • Considérations :
    • Idempotence : L'opération doit être idempotente (produire le même résultat si elle est exécutée plusieurs fois) pour éviter des effets secondaires indésirables.
    • Stratégie de réessai : Retries immédiats, avec délai fixe, ou avec backoff exponentiel (le délai entre les tentatives augmente exponentiellement). Le backoff exponentiel est crucial pour ne pas submerger le service en difficulté.
    • Nombre maximal de tentatives : Éviter les boucles infinies.
    • Jitter : Ajouter une petite variation aléatoire au délai de backoff pour éviter la "thundering herd problem" (tous les clients tentent en même temps).

2.2.2 Circuit Breaker (Disjoncteur)

Le pattern Circuit Breaker (Disjoncteur) empêche une application de tenter d'exécuter une opération qui risque de échouer, comme un appel à un service ou une ressource indisponible. Cela permet d'économiser des ressources CPU et d'éviter les défaillances en cascade.

  • États :
    • Closed (Fermé) : Opérations exécutées normalement. Si le nombre d'échecs dépasse un seuil, le disjoncteur passe en Open.
    • Open (Ouvert) : Le disjoncteur refuse immédiatement les appels au service défaillant, retournant une erreur rapide. Après un certain délai, il passe en Half-Open.
    • Half-Open (Semi-ouvert) : Le disjoncteur autorise un petit nombre d'appels "de test" pour vérifier si le service est rétabli. Si ces appels réussissent, il repasse en Closed. Sinon, il retourne en Open.

Implémentation avec .NET : Polly

Polly est une bibliothèque de résilience et de gestion des pannes pour .NET. Elle permet de définir des stratégies de réessai, disjoncteur, timeout, etc., de manière fluente.

// 1. Installation du package NuGet :
//    Install-Package Polly

// 2. Utilisation dans un service ou un client HTTP
using Polly;
using Polly.CircuitBreaker;
using System.Net.Http;
using System.Threading.Tasks;
using Microsoft.Extensions.Logging; // Pour la journalisation des événements Polly

public class ProductServiceClient
{
    private readonly HttpClient _httpClient;
    private readonly ILogger<ProductServiceClient> _logger;
    private readonly IAsyncPolicy<HttpResponseMessage> _resiliencePolicy;

    public ProductServiceClient(HttpClient httpClient, ILogger<ProductServiceClient> logger)
    {
        _httpClient = httpClient;
        _logger = logger;

        // Définition de la politique de résilience avec Polly
        _resiliencePolicy = Policy<HttpResponseMessage>
            .Handle<HttpRequestException>() // Gère les erreurs HTTP au niveau du transport
            .OrResult(response => !response.IsSuccessStatusCode) // Gère les statuts HTTP non 2xx
            .WaitAndRetryAsync(3, // Tente 3 fois
                retryAttempt => TimeSpan.FromSeconds(Math.Pow(2, retryAttempt)), // Backoff exponentiel (1s, 2s, 4s)
                onRetry: (exception, timeSpan, retryCount, context) =>
                {
                    _logger.LogWarning("Tentative #{RetryCount} pour appel au service produit. Délai de {TimeSpan} ms.", retryCount, timeSpan.TotalMilliseconds);
                })
            .WrapAsync( // Enveloppe la politique de réessai avec un disjoncteur
                Policy
                    .Handle<HttpRequestException>()
                    .OrResult(response => !response.IsSuccessStatusCode)
                    .CircuitBreakerAsync(
                        exceptionsAllowedBeforeBreaking: 5, // 5 erreurs consécutives avant d'ouvrir le circuit
                        durationOfBreak: TimeSpan.FromSeconds(30), // Le circuit reste ouvert 30 secondes
                        onBreak: (exception, breakDelay) =>
                        {
                            _logger.LogError("Circuit ouvert ! Le service produit est en panne. Délai de rupture : {BreakDelay} ms.", breakDelay.TotalMilliseconds);
                        },
                        onReset: () =>
                        {
                            _logger.LogInformation("Circuit réinitialisé ! Le service produit semble rétabli.");
                        },
                        onHalfOpen: () =>
                        {
                            _logger.LogInformation("Circuit semi-ouvert. Tentative de vérification du service produit.");
                        }
                    ));
    }

    public async Task<string> GetProductDetails(int productId)
    {
        // Exécution de l'appel HTTP via la politique de résilience
        var response = await _resiliencePolicy.ExecuteAsync(() => 
            _httpClient.GetAsync($"/api/products/{productId}"));

        response.EnsureSuccessStatusCode(); // Lance une exception si le statut n'est pas 2xx
        return await response.Content.ReadAsStringAsync();
    }
}

Explication du code : Ce code utilise Polly pour définir une stratégie de résilience combinant un réessai avec backoff exponentiel et un disjoncteur.

  1. _resiliencePolicy est créé en gérant à la fois les HttpRequestException (problèmes de connectivité) et les statuts HTTP non réussis (!response.IsSuccessStatusCode).
  2. WaitAndRetryAsync définit la stratégie de réessai : 3 tentatives, avec un délai qui double à chaque échec. Des actions onRetry sont définies pour logger les tentatives.
  3. WrapAsync enveloppe la politique de réessai avec une politique de disjoncteur.
  4. Le CircuitBreakerAsync est configuré pour s'ouvrir après 5 échecs consécutifs et rester ouvert pendant 30 secondes. Des actions onBreak, onReset et onHalfOpen permettent de logger les changements d'état du disjoncteur.
  5. Lorsque GetProductDetails est appelé, l'appel réel _httpClient.GetAsync est exécuté via _resiliencePolicy.ExecuteAsync(), ce qui applique automatiquement les stratégies de réessai et de disjoncteur.

2.2.3 Bulkhead (Cloisonnement)

Le pattern Bulkhead (cloisonnement) isole les ressources (comme les pools de threads, les connexions réseau, ou les instances de services) pour prévenir qu'une défaillance dans une partie du système n'affecte pas l'ensemble. C'est comme les compartiments étanches d'un navire.

  • Exemple : Allouer un pool de threads dédié pour les appels à un service externe potentiellement lent, distinct du pool de threads pour les appels à un service interne rapide. Si le service externe est en panne, seuls les threads de son pool sont bloqués, laissant d'autres opérations fonctionner normalement.

2.2.4 Timeout (Délai d'attente)

Le pattern Timeout consiste à définir une durée maximale pour l'exécution d'une opération. Si l'opération ne se termine pas dans ce délai, elle est annulée et une erreur est retournée. Cela empêche les opérations de bloquer indéfiniment des ressources.

  • Implémentation : HttpClient.Timeout en .NET, ou des politiques de Timeout dans Polly.

2.2.5 Fallback (Repli)

Le pattern Fallback (repli) consiste à fournir une voie alternative ou une valeur par défaut lorsque l'opération principale échoue. Cela permet au système de dégrader gracieusement plutôt que de échouer complètement.

  • Exemple : Si le service de recommandation de produits est en panne, afficher les produits les plus vendus par défaut plutôt que de ne rien afficher.

2.2.6 Rate Limiter (Limiteur de Taux)

Le pattern Rate Limiter contrôle le nombre de requêtes qu'un consommateur peut envoyer à un service dans un laps de temps donné. Il protège les services contre la surcharge et les attaques par déni de service (DoS).

  • Implémentation : Souvent géré par une API Gateway ou un service de gestion des API, mais peut aussi être implémenté au niveau du microservice. .NET 7+ introduit un RateLimiter intégré.

3. Intégration et Stratégies Avancées avec .NET

3.1 OpenTelemetry pour une Observabilité Unifiée

Nous avons déjà mentionné OpenTelemetry (Otel), mais il est crucial d'insister sur son importance. OpenTelemetry n'est pas un produit, mais un ensemble de spécifications, d'APIs, de SDKs et d'outils pour l'instrumentation. Son objectif est de fournir une manière standard, vendor-neutral, de collecter des données de télémétrie (logs, métriques, traces).

  • Pourquoi OpenTelemetry ?
    • Portabilité : Vous pouvez changer d'outil de backend (Jaeger, Prometheus, Application Insights) sans modifier le code de votre application.
    • Standardisation : Simplifie l'intégration et réduit la complexité.
    • Communauté : Soutenu par un large éventail d'entreprises et une communauté active.
    • Auto-instrumentation : Les SDKs OpenTelemetry pour .NET peuvent automatiquement instrumenter de nombreuses bibliothèques et frameworks courants (ASP.NET Core, HttpClient, Entity Framework Core).

En adoptant OpenTelemetry dès le début de vos projets de microservices .NET, vous vous assurez une flexibilité et une pérennité pour votre stratégie d'observabilité.

3.2 Design pour l'Observabilité

L'observabilité n'est pas une fonctionnalité à ajouter à la fin, c'est un aspect fondamental de la conception de vos microservices.

  • Instrumenter dès le début : Pensez à l'observabilité à chaque étape du développement. Identifiez les informations critiques à logger, les métriques pertinentes à collecter et les flux de requêtes à tracer.
  • Adopter des standards : Utilisez OpenTelemetry. Cela garantira que vos données de télémétrie sont cohérentes et exploitables par différents outils.
  • Des tableaux de bord significatifs : Créez des tableaux de bord (dans Grafana, Kibana, etc.) qui vous donnent une vue d'ensemble de la santé de vos services, des tendances de performance et des alertes. Concentrez-vous sur des métriques clés (RED: Rate, Errors, Duration).
  • Alerting : Mettez en place des alertes pour les situations critiques (erreurs, latences anormales, épuisement des ressources).

3.3 Design pour la Résilience

La résilience aussi doit être une priorité de conception.

  • Penser à l'échec : Partez du principe que tout peut échouer (réseau, dépendances, votre propre code). Concevez en conséquence.
  • Isoler les défaillances : Utilisez des patterns comme Bulkhead pour limiter l'impact d'une défaillance.
  • Éviter les points de défaillance uniques (SPOF) : Ne dépendez pas d'un seul service ou d'une seule instance d'une ressource.
  • Tests de Résilience (Chaos Engineering) : Injectez volontairement des pannes dans votre système pour voir comment il réagit. Des outils comme Chaos Monkey (bien que non spécifique à .NET, le concept est applicable) ou des frameworks de tests de charge peuvent vous aider.
  • Déploiements progressifs : Utilisez des stratégies comme les déploiements Canary ou Blue/Green pour minimiser les risques lors des mises à jour, permettant un retour arrière rapide en cas de problème.
  • Asynchronicité et files d'attente : Pour les opérations non critiques, utilisez des files d'attente de messages (RabbitMQ, Kafka, Azure Service Bus) pour découpler les services et absorber les pics de charge, améliorant ainsi la résilience.

Conclusion

L'observabilité et la résilience ne sont pas des luxes dans le monde des microservices, ce sont des nécessités absolues. Sans une visibilité claire sur le comportement de vos systèmes distribués, vous naviguerez à l'aveugle, et sans une conception pour la résilience, la défaillance d'un composant minime peut faire s'effondrer l'ensemble de votre architecture.

Nous avons exploré les trois piliers de l'observabilité (Logs, Métriques, Traces) et les principaux patterns de résilience (Retry, Circuit Breaker, Bulkhead, Timeout, Fallback, Rate Limiter). Nous avons également mis en évidence comment .NET et des bibliothèques comme Serilog, OpenTelemetry et Polly, ainsi que des pratiques de conception rigoureuses, peuvent vous aider à bâtir des systèmes robustes et maintenables.

Intégrer ces concepts et outils dans votre développement de microservices .NET est un investissement qui portera ses fruits en vous permettant de diagnostiquer rapidement les problèmes, d'optimiser les performances, et surtout, d'assurer une disponibilité et une fiabilité élevées pour vos utilisateurs. Maîtriser l'observabilité et la résilience, c'est maîtriser la complexité des systèmes distribués.