.NET Aspire 3: Par défaut du service

La série .NET Aspire se poursuit avec un aperçu des défaillances du service, un ensemble de méthodes d’extension qui compressent tous les câblage de l’OpenTelemetry, les sondes de santé, la découverte et les politiques Polly en un seul appel de méthode.

Il s’agit de la troisième partie d’une série exploratoire en six parties sur .NET Aspire.

Dans le premier épisode de cette série, nous avons dit HI à .NET Aspire, la boîte à outils d’opinion de Microsoft pour créer des applications prêtes pour le cloud. Dans la suite, nous avons jeté un coup d’œil au tableau de bord du développeur pour montrer comment nous pouvons ajouter une observabilité avec un code supplémentaire zéro.

Maintenant, nous voulons répondre à la question suivante de votre patron: «Comment pouvons-nous faire que chaque service de notre solution a une cohérence sans avoir à copier et coller des centaines de lignes de passe-partout dans chaque projet?»

«Cela dépend» ne vous sortira pas de celui-ci, mon ami. La réponse réside dans les défauts du service d’Aspire. Avec lui, vous pouvez attacher un seul builder.AddServiceDefaults() à votre application et il reçoit immédiatement:

• Traçage, journalisation et métriques de l’OpenTelelemetry, à votre exportateur préféré
• Points de terminaison à vérification de la santé qui distinguent «vivant» de «prêt»
• Découverte de service So-cluster, les appels de service à service fonctionnent sans URL codé en dur
• Un pipeline de résilience à propulsion de Polly avec des délais, des tentatives et des disjoncteurs

Commençons, d’accord?

Pourquoi s’embêter avec le service par défaut?

Comme nous l’avons discuté dans notre premier article, les services de construction peuvent devenir assez compliqués avec le fait que vous deviez saupoudrer la journalisation, le traçage, les tentatives, les configurations Docker, les contrôles de santé et tout ce dont vous avez besoin.

Avec la prémisse de .net Aspire pour être prêt pour le cloud par défaut, vous pouvez plutôt faire référence ServiceDefaults Une fois et instantanément, une ligne de référence qui fonctionne de la même manière partout, que ce soit sur votre ordinateur portable ou à l’intérieur des applications de conteneurs Azure. Ces conventions sont étroitement couplées à des intégrations qui font tourner l’infrastructure dont vous avez besoin (comme SQL Server, Redis et Key Vault) – avec une seule ligne de C #!

Tout est ensuite exprimé en code C # à l’intérieur de votre AppHost Projet, afin que vous puissiez contrôler la topologie de votre application, tout comme la logique d’application.

Étant donné que les conventions sont exprimées en un seul endroit, un changement futur – comme passer de Honeycomb au moniteur Azure – est un montage en une ligne.

Regardons maintenant un code et voyons comment tout cela fonctionne.

Regarder à l’intérieur du projet Servicefaults

Lorsque vous créez une nouvelle application Aspire ou ajoutez Aspire à votre solution existante, vous verrez un projet nommé ServiceDefaults.

Regardons dans le ServiceDefaults projet. Ouvrir le fichier Extensions.cs (ou quelque chose de similaire). Tu devrais voir un AddServiceDefaults Méthode d’extension qui ressemble à ceci:

public static TBuilder AddServiceDefaults<TBuilder>(this TBuilder builder) where TBuilder : IHostApplicationBuilder
{
    builder.ConfigureOpenTelemetry();
    builder.AddDefaultHealthChecks();
    builder.Services.AddServiceDiscovery();
    builder.Services.ConfigureHttpClientDefaults(http =>
    {
        http.AddStandardResilienceHandler();
        http.AddServiceDiscovery();
    });

    return builder;
}

Décomposons ce code.

Note: Les parties de la résilience et de la découverte de services méritent leur propre traitement et seront discutées en détail dans la partie 5 de notre série.

Configuration de l’Opentelémétrie

Quand on regarde builder.ConfigureOpenTelemetry.NET Aspire fournit un ensemble de défauts d’opinion pour l’OpenTelemetry.

Par défaut, Aspire ajoute:

Ceux-ci sont tous visibles à partir du tableau de bord Aspire que nous avons examiné dans le post précédent. Pour l’exportateur OTLP, il s’intègre facilement à votre télémétrie. Par exemple, dans Azure Container Apps, l’exportateur pointe sur Azure Monitor.

Rien de tout cela n’est magique. Si vous faites défiler vers le bas dans votre Extensions.csvous pouvez inspecter le ConfigureOpenTelemetry Méthode d’extension pour en savoir plus.

public static TBuilder ConfigureOpenTelemetry<TBuilder>(this TBuilder builder) where TBuilder : IHostApplicationBuilder
{
    builder.Logging.AddOpenTelemetry(logging =>
    {
        logging.IncludeFormattedMessage = true;
        logging.IncludeScopes = true;
    });

    builder.Services.AddOpenTelemetry()
        .WithMetrics(metrics =>
        {
            metrics.AddAspNetCoreInstrumentation()
                .AddHttpClientInstrumentation()
                .AddRuntimeInstrumentation();
        })
        .WithTracing(tracing =>
        {
            tracing.AddSource(builder.Environment.ApplicationName)
                .AddAspNetCoreInstrumentation()
                
                
                .AddHttpClientInstrumentation();
        });

    builder.AddOpenTelemetryExporters();

    return builder;
}

La configuration de votre exportateur est super facile. Parce que l’URL de l’exportateur vient de OTEL_EXPORTER_OTLP_ENDPOINTChanger où les flux de télémétrie est une ligne simple:

export OTEL_EXPORTER_OTLP_ENDPOINT=https://api.honeycomb.io

Dans le AddOpenTelemetryExportersvous le verrez en action. Besoin d’un moniteur Azure à la place? Décommente le bloc pertinent dans AddOpenTelemetryExportersfournir un APPLICATIONINSIGHTS_CONNECTION_STRINGet appelez-le un jour.

private static TBuilder AddOpenTelemetryExporters<TBuilder>(this TBuilder builder) where TBuilder : IHostApplicationBuilder
{
    var useOtlpExporter = !string.IsNullOrWhiteSpace(builder.Configuration["OTEL_EXPORTER_OTLP_ENDPOINT"]);

    if (useOtlpExporter)
    {
        builder.Services.AddOpenTelemetry().UseOtlpExporter();
    }

    
    
    
    
    
    

    return builder;
}

Chèques de santé par défaut

Passer à autre chose: qu’est-ce qui fait builder.AddDefaultHealthChecks() nous faire? Cette ligne puissante ajoute un ensemble de valeurs par défaut d’opinion pour les vérifications de santé, qui peuvent être utilisées par les systèmes et les applications pour voir si votre application est prête.

Le AddDefaultHealthChecks La méthode ajoute une vérification par défaut pour vérifier si l’application est réactive.

public static TBuilder AddDefaultHealthChecks<TBuilder>(this TBuilder builder) where TBuilder : IHostApplicationBuilder
{
    builder.Services.AddHealthChecks()
        
        .AddCheck("self", () => HealthCheckResult.Healthy(), ["live"]);

    return builder;
}

Vous pouvez voir comment tout cela fonctionne dans le MapDefaultEndpoints Méthode d’extension, où il expose un /health point final et un /alive point de terminaison. Le /health Endpoint illustre si l’application est en cours d’exécution et prête à recevoir des demandes. Le /alive Le point de terminaison indique si l’application est en cours d’exécution ou doit être redémarrée en raison d’un crash.

public static WebApplication MapDefaultEndpoints(this WebApplication app)
{
    
    
    if (app.Environment.IsDevelopment())
    {
        
        app.MapHealthChecks("/health");

        
        app.MapHealthChecks("/alive", new HealthCheckOptions
        {
            Predicate = r => r.Tags.Contains("live")
        });
    }

    return app;
}

Comme vous pouvez le voir, les valeurs par défaut sont pour développement uniquement. Vous devez opter pour l’exposition à la production.

Les contrôles de santé sont également intégrés avec les diverses intégrations d’Aspire. Par exemple, le Vérification de la santé pour SQL Server vérifie que SQL Server est en cours d’exécution et qu’une connexion peut être établie.

Créer un projet de défaut de service personnalisé

Si vous regardez le MyApp.ServiceDefaults.csprojvous remarquerez un FrameworkReference dépendance Microsoft.AspNetCore.App.

<FrameworkReference Include="Microsoft.AspNetCore.App" />

Cette référence apporte l’ensemble du cadre partagé ASP.NET Core (avec Kestrel, MVC, SignalR et ainsi de suite).

Dans certaines situations, vous ne voudrez peut-être pas cela:

• Charges de travail non HTTP: Les travailleurs de l’arrière-plan ou les processeurs de file d’attente n’ont pas besoin de Kestrel.
• Hôtes sans serveur: Les fonctions Azure expédient leur propre copie de base ASP.NET. Une deuxième copie peut provoquer des conflits contraignants.
• Bibliothèques de classe réutilisables: Transitive Framework références oblige les applications grand public à transporter ASP.NET Core. Et si la bibliothèque est authorable?

Dans ce cas, vous pouvez créer un projet par défaut de service personnalisé. Selon les documents Microsoft, vous pouvez créer un nouveau projet de bibliothèque de classe et ajouter ses dépendances au fichier de projet. Découvrez le Docs pour plus d’informations.

Emballage

Les défauts de service sont le héros méconnu de .NET Aspire. Ils compressent tous les câblage d’opentelémétrie, les sondes de santé, la découverte et les politiques Polly en un seul appel de méthode. En conséquence, chaque service se comporte de manière prévisible, la télémétrie est toujours en cours et votre nouvelle location accélère rapidement (pensez aux minutes, pas aux jours).

Dans le prochain épisode, nous explorerons les intégrations. Nous verrons comment Aspire tourne les conteneurs SQL Server et Redis – tous orchestrés à partir de notre apphost. Restez à l’écoute!