Aracılığıyla paylaş


Dayanıklı HTTP uygulamaları oluşturma: Temel geliştirme desenleri

Geçici hata hatalarından kurtarabilecek güçlü HTTP uygulamaları oluşturmak yaygın bir gereksinimdir. Bu makalede, aktarılan temel kavramlar genişletildiğinden, dayanıklı uygulama geliştirmeye giriş makalesini okuduğunuz varsayılır. Dayanıklı HTTP uygulamaları oluşturmaya yardımcı olmak için Microsoft.Extensions.Http.Resilience NuGet paketi, özellikle için dayanıklılık mekanizmaları sağlar. Bu NuGet paketi, kitaplığı ve Microsoft.Extensions.Resiliencepopüler bir açık kaynak projesi olan Polly'yi kullanır. Daha fazla bilgi için bkz . Polly.

Kullanmaya başlayın

HTTP uygulamalarında dayanıklılık desenlerini kullanmak için Microsoft.Extensions.Http.Resilience NuGet paketini yükleyin.

dotnet add package Microsoft.Extensions.Http.Resilience --version 8.0.0

Daha fazla bilgi için bkz. dotnet paket ekleme veya .NET uygulamalarında paket bağımlılıklarını yönetme.

HTTP istemcisine dayanıklılık ekleme

HttpClient'a dayanıklılık eklemek için, kullanılabilir IHttpClientBuilder yöntemlerinden herhangi birini çağırarak döndürülen AddHttpClient türüne bir çağrı zinciri yaparsınız. Daha fazla bilgi için .NET ile IHttpClientFactory'ye bakın.

Çeşitli dayanıklılık odaklı uzantılar mevcuttur. Bazıları standarttır, bu nedenle çeşitli sektör en iyi uygulamalarını kullanırken diğerleri daha özelleştirilebilir. Dayanıklılık eklerken yalnızca bir dayanıklılık işleyicisi eklemeniz ve yığınlama işleyicilerinden kaçınmanız gerekir. Birden çok dayanıklılık işleyicisi eklemeniz gerekiyorsa, dayanıklılık stratejilerini özelleştirmenizi sağlayan uzantı yöntemini kullanmayı AddResilienceHandler düşünmelisiniz.

Önemli

Bu makaledeki tüm örnekler, AddHttpClient örneği döndüren Microsoft.Extensions.Http kitaplığındaki IHttpClientBuilder API'sini kullanır. IHttpClientBuilder örneği, HttpClient öğesini yapılandırmak ve dayanıklılık işleyicisini eklemek için kullanılır.

Standart dayanıklılık işleyicisi ekleme

Standart dayanıklılık işleyicisi, istekleri göndermek ve geçici hataları işlemek için varsayılan seçeneklerle birlikte birbirinin üzerine yığılmış birden çok dayanıklılık stratejisi kullanır. Standart dayanıklılık işleyicisi, bir AddStandardResilienceHandler örneğindeki IHttpClientBuilder uzantı yöntemi çağrılarak eklenir.

var services = new ServiceCollection();

var httpClientBuilder = services.AddHttpClient<ExampleClient>(
    configureClient: static client =>
    {
        client.BaseAddress = new("https://jsonplaceholder.typicode.com");
    });

Yukarıdaki kod:

  • Bir ServiceCollection örnek oluşturur.
  • Hizmet kapsayıcısına HttpClient türü için bir ExampleClient ekler.
  • HttpClient temel adres olarak "https://jsonplaceholder.typicode.com" kullanacak şekilde yapılandırılır.
  • httpClientBuilder Bu makaledeki diğer örneklerde kullanılan öğesini oluşturur.

Daha gerçek bir örnek, .NET Genel Ana Bilgisayar makalesinde açıklandığı gibi barındırma üzerine temellendirilebilir. Microsoft.Extensions.Hosting NuGet paketini kullanarak aşağıdaki güncelleştirilmiş örneği göz önünde bulundurun:

using Http.Resilience.Example;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

HostApplicationBuilder builder = Host.CreateApplicationBuilder(args);

IHttpClientBuilder httpClientBuilder = builder.Services.AddHttpClient<ExampleClient>(
    configureClient: static client =>
    {
        client.BaseAddress = new("https://jsonplaceholder.typicode.com");
    });

Önceki kod, elle ServiceCollection oluşturma yaklaşımına benzer, ancak bunun yerine hizmetleri kullanıma sunan bir konak oluşturmak için Host.CreateApplicationBuilder()'e dayanır.

ExampleClient aşağıdaki gibi tanımlanır:

using System.Net.Http.Json;

namespace Http.Resilience.Example;

/// <summary>
/// An example client service, that relies on the <see cref="HttpClient"/> instance.
/// </summary>
/// <param name="client">The given <see cref="HttpClient"/> instance.</param>
internal sealed class ExampleClient(HttpClient client)
{
    /// <summary>
    /// Returns an <see cref="IAsyncEnumerable{T}"/> of <see cref="Comment"/>s.
    /// </summary>
    public IAsyncEnumerable<Comment?> GetCommentsAsync()
    {
        return client.GetFromJsonAsAsyncEnumerable<Comment>("/comments");
    }
}

Yukarıdaki kod:

  • ExampleClient kabul eden bir yapıcıya sahip bir HttpClient tür tanımlar.
  • GET isteği gönderen ve GetCommentsAsync uç noktasından yanıt döndüren bir /comments yöntemini tanımlar.

Türü Comment aşağıdaki gibi tanımlanır:

namespace Http.Resilience.Example;

public record class Comment(
    int PostId, int Id, string Name, string Email, string Body);

Bir IHttpClientBuilder (httpClientBuilder) oluşturduğunuza ve ExampleClient uygulamasını ve buna karşılık gelen Comment modelini anladığınıza göre, aşağıdaki örneği dikkate alabilirsiniz:

httpClientBuilder.AddStandardResilienceHandler();

Yukarıdaki kod, standart dayanıklılık işleyicisini HttpClient öğesine ekler. Çoğu dayanıklılık API'sinde olduğu gibi, varsayılan seçenekleri ve uygulanan dayanıklılık stratejilerini özelleştirmenizi sağlayan aşırı yüklemeler vardır.

Standart dayanıklılık işleyicilerini kaldırın

Daha önce kaydedilmiş tüm dayanıklılık işleyicilerini kaldıran bir yöntem RemoveAllResilienceHandlers vardır. Kendi özel dayanıklılık işleyicinizi eklemek için mevcut olanları temizlemeniz gerektiğinde kullanışlıdır. Aşağıdaki örnekte, HttpClient yöntemini kullanarak özel bir AddHttpClient yapılandırma, önceden tanımlanmış tüm dayanıklılık stratejilerini kaldırma ve bunları yeni işleyicilerle değiştirme işlemleri gösterilmektedir. Bu yaklaşım, mevcut yapılandırmaları temizlemenize ve özel gereksinimlerinize göre yeni yapılandırmalar tanımlamanıza olanak tanır.

// By default, we want all HttpClient instances to include the StandardResilienceHandler.
services.ConfigureHttpClientDefaults(builder => builder.AddStandardResilienceHandler());
// For a named HttpClient "custom" we want to remove the StandardResilienceHandler and add the StandardHedgingHandler instead.
services.AddHttpClient("custom")
    .RemoveAllResilienceHandlers()
    .AddStandardHedgingHandler();

Yukarıdaki kod:

  • Bir ServiceCollection örnek oluşturur.
  • Standart dayanıklılık işleyicisini tüm HttpClient örneklerine ekler.
  • "Özel" HttpClient için:
    • Önceden kaydedilmiş tüm önceden tanımlanmış dayanıklılık işleyicilerini kaldırır. Bu, kendi özel stratejilerinizi eklemek için temiz bir durumla başlamak istediğinizde kullanışlıdır.
    • StandardHedgingHandler'e HttpClient ekler. AddStandardHedgingHandler() yeniden deneme mekanizmaları, devre kesiciler veya diğer dayanıklılık teknikleri gibi uygulamanızın gereksinimlerine uygun herhangi bir stratejiyle değiştirebilirsiniz.

Standart dayanıklılık işleyicisi varsayılanları

Varsayılan yapılandırma beş dayanıklılık stratejisini aşağıdaki sırayla zincirler (en dıştan en içe):

Sipariş Strateji Açıklama Varsayılanlar
1 Hız sınırlayıcı Hız sınırlayıcı işlem hattı, bağımlılık için gönderilen en fazla eşzamanlı istek sayısını sınırlar. Sıra: 0
Ruhsat: 1_000
2 Toplam zaman aşımı Toplam istek zaman aşımı işlem hattı, yürütmeye genel bir zaman aşımı uygulayarak isteğin yeniden deneme denemeleri de dahil olmak üzere yapılandırılan sınırı aşmadığından emin olur. Toplam zaman aşımı: 30s
3 Yeniden Dene Yeniden deneme işlem hattı, bağımlılığın yavaş olması veya geçici bir hata döndürmesi durumunda isteği yeniden dener. En fazla yeniden deneme sayısı: 3
Geri çekilme: Exponential
Jitter kullan: true
Gecikme:2s
4 Devre kesici Çok fazla doğrudan hata veya zaman aşımı algılanırsa devre kesici yürütmeyi engeller. Hata oranı: %10
En düşük aktarım hızı: 100
Örnekleme süresi: 30s
Kesme süresi: 5s
5 Deneme zaman aşımı Deneme zaman aşımı işlem hattı her istek deneme süresini sınırlar ve aşılırsa atar. Deneme zaman aşımı: 10s

Yeniden denemeler ve devre kesiciler

Yeniden deneme ve devre kesici stratejileri belirli HTTP durum kodları ve özel durumlar kümesini işler. Aşağıdaki HTTP durum kodlarını göz önünde bulundurun:

  • HTTP 500 ve üzeri (Sunucu hataları)
  • HTTP 408 (İstek zaman aşımına uğradı)
  • HTTP 429 (Çok fazla istek var)

Ayrıca, bu stratejiler aşağıdaki özel durumları işler:

  • HttpRequestException
  • TimeoutRejectedException

Belirli bir HTTP yöntemleri listesi için yeniden denemeleri devre dışı bırakma

Varsayılan olarak, standart dayanıklılık işleyicisi tüm HTTP yöntemleri için yeniden denemeler yapacak şekilde yapılandırılır. Bazı uygulamalar için bu tür davranışlar istenmeyen ve hatta zararlı olabilir. Örneğin, post isteği veritabanına yeni bir kayıt eklerse, böyle bir istek için yeniden denemeler yapmak verilerin çoğaltılmasıyla sonuçlanabilir. Belirli bir HTTP yöntemleri listesi için yeniden denemeleri devre dışı bırakmanız gerekiyorsa DisableFor(HttpRetryStrategyOptions, HttpMethod[]) yöntemini kullanabilirsiniz:

httpClientBuilder.AddStandardResilienceHandler(options =>
{
    options.Retry.DisableFor(HttpMethod.Post, HttpMethod.Delete);
});

Alternatif olarak, DisableForUnsafeHttpMethods(HttpRetryStrategyOptions), POST, PATCH, PUTve DELETE istekleri için yeniden denemeleri devre dışı bırakan CONNECT yöntemini kullanabilirsiniz. RFC 'e göre, bu yöntemler güvensiz olarak değerlendirilir; anlamlarına göre salt okunur olmadıkları anlamına gelmektedir.

httpClientBuilder.AddStandardResilienceHandler(options =>
{
    options.Retry.DisableForUnsafeHttpMethods();
});

Standart riskten korunma işleyicisi ekleme

Standart riskten korunma işleyicisi, isteğin yürütülmesini standart bir riskten korunma mekanizmasıyla sarmalar. Yavaş istekleri paralel olarak yeniden denemek için hedging kullanılır.

Standart riskten korunma işleyicisini kullanmak için uzantı yöntemini çağırın AddStandardHedgingHandler . Aşağıdaki örnek, ExampleClient öğesini standart riskten korunma işleyicisini kullanacak şekilde yapılandırılır.

httpClientBuilder.AddStandardHedgingHandler();

Yukarıdaki kod, standart riskten korunma işleyicisini öğesine HttpClientekler.

Standart hedge işleyicisi varsayılanları

Standart risk koruması, iyi durumda olmayan uç noktaların hedged edilmediğinden emin olmak için bir devre kesici havuzu kullanır. Varsayılan olarak, havuzdan yapılan seçim URL yetkilisini (scheme + host + port) temel alır.

İpucu

Stratejilerin seçilme şeklini daha gelişmiş senaryolar için StandardHedgingHandlerBuilderExtensions.SelectPipelineByAuthority veya StandardHedgingHandlerBuilderExtensions.SelectPipelineBy çağrısı yaparak yapılandırmanız önerilir.

Yukarıdaki kod, standart riskten korunma işleyicisini öğesine IHttpClientBuilderekler. Varsayılan yapılandırma beş dayanıklılık stratejisini aşağıdaki sırayla zincirler (en dıştan en içe):

Sipariş Strateji Açıklama Varsayılanlar
1 İstek zaman aşımının toplam süresi Toplam istek zaman aşımı işlem hattı, yürütmeye genel bir zaman aşımı uygulayarak, istek ve riskten korunma girişimleri de dahil olmak üzere, yapılandırılan sınırı aşmadıklarından emin olur. Toplam zaman aşımı: 30s
2 Riskten Korunma Riskten korunma stratejisi, bağımlılığın yavaş olması veya geçici bir hata döndürmesi durumunda istekleri birden çok uç noktaya karşı yürütür. Yönlendirme seçeneklerdir. Varsayılan olarak yalnızca özgün HttpRequestMessage tarafından sağlanan URL'yi gizler. Minimum denemeler: 1
En fazla deneme sayısı: 10
Gecikme: 2s
3 Hız sınırlayıcı (uç nokta başına) Hız sınırlayıcı işlem hattı, bağımlılık için gönderilen en fazla eşzamanlı istek sayısını sınırlar. Sıra: 0
Ruhsat: 1_000
4 Devre kesici (uç nokta başına) Çok fazla doğrudan hata veya zaman aşımı algılanırsa devre kesici yürütmeyi engeller. Hata oranı: %10
En düşük aktarım hızı: 100
Örnekleme süresi: 30s
Kesme süresi: 5s
5 Deneme zaman aşımı (uç nokta başına) Deneme zaman aşımı işlem hattı her istek deneme süresini sınırlar ve aşılırsa atar. Zaman aşımı: 10 sn

Riskten korunma işleyicisi rota seçimini özelleştirme

Standart hedging işleyicisini kullanırken, istek uç noktalarının IRoutingStrategyBuilder seçilme şeklini türdeki çeşitli uzantıları çağırarak özelleştirebilirsiniz. Bu, isteklerin yüzdesini farklı bir uç noktaya yönlendirmek istediğiniz A/B testi gibi senaryolar için yararlı olabilir:

httpClientBuilder.AddStandardHedgingHandler(static (IRoutingStrategyBuilder builder) =>
{
    // Hedging allows sending multiple concurrent requests
    builder.ConfigureOrderedGroups(static options =>
    {
        options.Groups.Add(new UriEndpointGroup()
        {
            Endpoints =
            {
                // Imagine a scenario where 3% of the requests are 
                // sent to the experimental endpoint.
                new() { Uri = new("https://example.net/api/experimental"), Weight = 3 },
                new() { Uri = new("https://example.net/api/stable"), Weight = 97 }
            }
        });
    });
});

Yukarıdaki kod:

  • öğesine IHttpClientBuilder riskten korunma işleyicisini ekler.
  • IRoutingStrategyBuilder öğesini, sıralı grupları yapılandırmak için ConfigureOrderedGroups yöntemini kullanacak şekilde yapılandırır.
  • EndpointGroup bir öğeyi, isteklerin %3'ünü orderedGroup uç noktasına ve %97'sini https://example.net/api/experimental uç noktasına yönlendiren https://example.net/api/stable öğesine ekler.
  • IRoutingStrategyBuilder öğesinin, ConfigureWeightedGroups yöntemini kullanacak şekilde yapılandırılması yapılır.

Ağırlıklı bir grup yapılandırmak için ConfigureWeightedGroups türündeki IRoutingStrategyBuilder yöntemini çağırın. Aşağıdaki örnek, IRoutingStrategyBuilder'yi, ağırlıklı grupları yapılandırmak için ConfigureWeightedGroups yöntemini kullanacak şekilde yapılandırır.

httpClientBuilder.AddStandardHedgingHandler(static (IRoutingStrategyBuilder builder) =>
{
    // Hedging allows sending multiple concurrent requests
    builder.ConfigureWeightedGroups(static options =>
    {
        options.SelectionMode = WeightedGroupSelectionMode.EveryAttempt;

        options.Groups.Add(new WeightedUriEndpointGroup()
        {
            Endpoints =
            {
                // Imagine A/B testing
                new() { Uri = new("https://example.net/api/a"), Weight = 33 },
                new() { Uri = new("https://example.net/api/b"), Weight = 33 },
                new() { Uri = new("https://example.net/api/c"), Weight = 33 }
            }
        });
    });
});

Yukarıdaki kod:

  • öğesine IHttpClientBuilder riskten korunma işleyicisini ekler.
  • Ağırlıklı grupları yapılandırmak için IRoutingStrategyBuilder, ConfigureWeightedGroups yöntemini kullanacak şekilde yapılandırılır.
  • SelectionMode'yi WeightedGroupSelectionMode.EveryAttempt olarak ayarlar.
  • WeightedEndpointGroup, isteklerin %33'ünü weightedGroup uç noktasına, %33'ünü https://example.net/api/a uç noktasına ve %33'ünü https://example.net/api/b uç noktasına yönlendiren https://example.net/api/c öğesine ekler.

İpucu

Maksimum riskten korunma denemesi sayısı, yapılandırılan grup sayısıyla doğrudan bağıntılı. Örneğin, iki grubunuz varsa, deneme sayısı üst sınırı ikidir.

Daha fazla bilgi için bakınız: Polly belgeler: Hedging dayanıklılık stratejisi.

Sıralı veya ağırlıklı bir grup yapılandırmak yaygındır, ancak her ikisini de yapılandırmak mümkündür. İsteklerin yüzdesini A/B testi gibi farklı bir uç noktaya göndermek istediğiniz senaryolarda sıralı ve ağırlıklı grupların kullanılması yararlı olur.

Özel dayanıklılık yöneticileri ekle

Daha fazla denetime sahip olmak için, API'yi kullanarak AddResilienceHandler dayanıklılık işleyicilerini özelleştirebilirsiniz. Bu yöntem, dayanıklılık stratejilerini ResiliencePipelineBuilder<HttpResponseMessage> oluşturmak için kullanılan örneği yapılandıran bir temsilci kabul eder.

Adlandırılmış bir dayanıklılık işleyicisini yapılandırmak için, işleyicinin adıyla AddResilienceHandler uzantı yöntemi çağırın. Aşağıdaki örnekte adlı "CustomPipeline"adlandırılmış bir dayanıklılık işleyicisi yapılandırılır.

httpClientBuilder.AddResilienceHandler(
    "CustomPipeline",
    static builder =>
{
    // See: https://www.pollydocs.org/strategies/retry.html
    builder.AddRetry(new HttpRetryStrategyOptions
    {
        // Customize and configure the retry logic.
        BackoffType = DelayBackoffType.Exponential,
        MaxRetryAttempts = 5,
        UseJitter = true
    });

    // See: https://www.pollydocs.org/strategies/circuit-breaker.html
    builder.AddCircuitBreaker(new HttpCircuitBreakerStrategyOptions
    {
        // Customize and configure the circuit breaker logic.
        SamplingDuration = TimeSpan.FromSeconds(10),
        FailureRatio = 0.2,
        MinimumThroughput = 3,
        ShouldHandle = static args =>
        {
            return ValueTask.FromResult(args is
            {
                Outcome.Result.StatusCode:
                    HttpStatusCode.RequestTimeout or
                        HttpStatusCode.TooManyRequests
            });
        }
    });

    // See: https://www.pollydocs.org/strategies/timeout.html
    builder.AddTimeout(TimeSpan.FromSeconds(5));
});

Yukarıdaki kod:

  • Hizmet kapsayıcısına "CustomPipeline" adıyla, pipelineName olarak bir dayanıklılık işleyicisi ekler.
  • Dayanıklılık oluşturucusuna üstel geri çekilme, beş yeniden deneme ve dalgalanma tercihi ile bir yeniden deneme stratejisi ekler.
  • Direnç oluşturucusuna, örnekleme süresi 10 saniye olan, hata oranı 0,2 (%20), minimum aktarım hızı üç olan ve RequestTimeout ve TooManyRequests HTTP durum kodlarını işleyen bir koşula sahip bir devre kesici stratejisi ekler.
  • Dayanıklılık oluşturucusuna, süresi beş saniye olan bir zaman aşımı stratejisi ekler.

Dayanıklılık stratejilerinin her biri için birçok seçenek mevcuttur. Daha fazla bilgi için Polly belgelerinin Stratejiler bölümüne bakın. Vekil yapılandırması hakkında daha fazla bilgi için ShouldHandle bölümüne bakın. Polly belgeleri: Reaktif stratejilerde hata işleme.

Uyarı

Hem yeniden deneme hem de zaman aşımı stratejilerini kullanıyorsanız ve temsilciyi ShouldHandle yeniden deneme stratejinizde yapılandırmak istiyorsanız, Polly'nin zaman aşımı özel durumunu işlemesi gerekip gerekmediğini göz önünde bulundurun. Polly, TimeoutRejectedException'den devralan Exception'yu atar, standard TimeoutException değil.

Dinamik yeniden yükleme

Polly, yapılandırılmış dayanıklılık stratejilerinin dinamik olarak yeniden yüklenmesini destekler. Bu, çalışma zamanında dayanıklılık stratejilerinin yapılandırmasını değiştirebileceğiniz anlamına gelir. Dinamik yeniden yüklemeyi etkinleştirmek için, AddResilienceHandler öğesini kullanan uygun ResilienceHandlerContext aşırı yüklemesini kullanın. Belirtilen bağlamda, ilgili dayanıklılık stratejisi seçeneklerinin EnableReloads çağrısını yapın.

httpClientBuilder.AddResilienceHandler(
    "AdvancedPipeline",
    static (ResiliencePipelineBuilder<HttpResponseMessage> builder,
        ResilienceHandlerContext context) =>
    {
        // Enable reloads whenever the named options change
        context.EnableReloads<HttpRetryStrategyOptions>("RetryOptions");

        // Retrieve the named options
        var retryOptions =
            context.GetOptions<HttpRetryStrategyOptions>("RetryOptions");

        // Add retries using the resolved options
        builder.AddRetry(retryOptions);
    });

Yukarıdaki kod:

  • Hizmet kapsayıcısına "AdvancedPipeline" adıyla, pipelineName olarak bir dayanıklılık işleyicisi ekler.
  • Adlandırılmış "AdvancedPipeline" seçenekler değiştiğinde RetryStrategyOptions işlem hattının yeniden yüklenmesini etkinleştirir.
  • Hizmetten IOptionsMonitor<TOptions> adlandırılmış seçenekleri alır.
  • Dayanıklılık oluşturucuya alınan seçeneklerle bir tekrar deneme stratejisi ekler.

Daha fazla bilgi için, Polly belgeleri: Gelişmiş bağımlılık enjeksiyonu'na bakın.

Bu örnek, appsettings.json dosyası gibi değiştirebilen bir seçenekler bölümüne dayanır. Aşağıdaki appsettings.json dosyasını göz önünde bulundurun:

{
    "RetryOptions": {
        "Retry": {
            "BackoffType": "Linear",
            "UseJitter": false,
            "MaxRetryAttempts": 7
        }
    }
}

Şimdi bu seçeneklerin uygulamanın yapılandırmasına bağlı olduğunu ve HttpRetryStrategyOptions öğesinin "RetryOptions" bölümüne bağlandığını hayal edin.

var section = builder.Configuration.GetSection("RetryOptions");

builder.Services.Configure<HttpStandardResilienceOptions>(section);

Daha fazla bilgi için bkz . .NET'te seçenekler deseni.

Örnek kullanım

Uygulamanız, bağımlılık enjeksiyonu kullanarak ExampleClient ve karşılık gelen HttpClient öğesini çözümlemeye dayanır. Kod, IServiceProvider'yi oluşturur ve bunun üzerinden ExampleClient'yi çözümler.

IHost host = builder.Build();

ExampleClient client = host.Services.GetRequiredService<ExampleClient>();

await foreach (Comment? comment in client.GetCommentsAsync())
{
    Console.WriteLine(comment);
}

Yukarıdaki kod:

Ağın kapandığı veya sunucunun yanıt vermemeye başladığı bir durum düşünün. Aşağıdaki diyagram, ExampleClient ve GetCommentsAsync yöntemleri dikkate alınarak dayanıklılık stratejilerinin durumu nasıl ele alacağını göstermektedir.

Dayanıklılık işlem hattı ile örnek HTTP GET iş akışı.

Yukarıdaki diyagramda aşağıdakiler gösterilmiştir:

  • ExampleClient uç noktaya HTTP GET isteği gönderir.
  • HttpResponseMessage değerlendirilir:
    • Yanıt başarılı olursa (HTTP 200), yanıt döndürülür.
    • Yanıt başarısız olduğunda (HTTP 200 dışındaki durumlarda), direnç işlem hattı yapılandırılmış direnç stratejilerini kullanır.

Bu basit bir örnek olsa da, dayanıklılık stratejilerinin geçici hataları işlemek için nasıl kullanılabileceğini gösterir. Daha fazla bilgi için bkz: Polly belgeleri: Stratejiler.

Bilinen sorunlar

Aşağıdaki bölümlerde bilinen çeşitli sorunlar ayrıntılı olarak ele alınıyor.

Grpc.Net.ClientFactory paketi ile uyumluluk

Sürüm Grpc.Net.ClientFactory veya daha eski bir sürümü kullanıyorsanız, gRPC istemcisi için standart dayanıklılık veya riskten korunma işleyicilerini etkinleştirmek çalışma zamanı hatasına neden olabilir. Özellikle aşağıdaki kod örneğini göz önünde bulundurun:

services
    .AddGrpcClient<Greeter.GreeterClient>()
    .AddStandardResilienceHandler();

Yukarıdaki kod aşağıdaki özel duruma neden olur:

System.InvalidOperationException: The ConfigureHttpClient method is not supported when creating gRPC clients. Unable to create client with name 'GreeterClient'.

Bu sorunu çözmek için Grpc.Net.ClientFactory2.64.0 sürümüne veya daha yenisine yükseltmenizi öneririz.

Derleme zamanı denetimi, Grpc.Net.ClientFactory sürümü 2.63.0 veya daha eskisini kullanıp kullanmadığınızı doğrular ve eğer öyleyse, denetim bir derleme uyarısı oluşturur. Proje dosyanızda aşağıdaki özelliği ayarlayarak uyarıyı gizleyebilirsiniz:

<PropertyGroup>
  <SuppressCheckGrpcNetClientFactoryVersion>true</SuppressCheckGrpcNetClientFactoryVersion>
</PropertyGroup>

.NET Application Insights ile uyumluluk

.NET Application Insights sürümünü 2.22.0 veya daha düşük bir sürüm kullanıyorsanız, uygulamanızda dayanıklılık işlevselliğinin etkinleştirilmesi tüm Application Insights telemetri verilerinin kaybolmasına neden olabilir. Dayanıklılık işlevselliği Application Insights hizmetlerinden önce kaydedildiğinde sorun oluşur. Soruna neden olan aşağıdaki örneği göz önünde bulundurun:

// At first, we register resilience functionality.
services.AddHttpClient().AddStandardResilienceHandler();

// And then we register Application Insights. As a result, Application Insights doesn't work.
services.AddApplicationInsightsTelemetry();

Bu sorun, .NET Application Insights 2.23.0 veya üzeri bir sürüme güncelleştirilerek düzeltilebilir. Güncelleştiremiyorsanız, aşağıda gösterildiği gibi dayanıklılık işlevselliğinden önce Application Insights hizmetlerini kaydetmek sorunu düzeltir:

// We register Application Insights first, and now it will be working correctly.
services.AddApplicationInsightsTelemetry();
services.AddHttpClient().AddStandardResilienceHandler();