‫گذار به تاب‌آوری بومی: بررسی راهبرد مایکروسافت با ارائه بسته Microsoft.Extensions.Resilience در دات‌نت نوین

چکیده: در سیستم‌های توزیع‌شده و معماری‌های مبتنی بر ریزسرویس‌ها (Microservices)، بروز خطاهای گذرا (Transient Faults) امری اجتناب‌ناپذیر است. سال‌ها کتابخانه شناخته‌شده Polly مرجع اصلی پیاده‌سازی الگوهای تاب‌آوری نظیر تلاش مجدد (Retry)، قطع‌کننده مدار (Circuit Breaker) و محدودکننده نرخ (Rate Limiter) در جامعه دات‌نت بود. با این حال، نیاز مبرم به کارایی بالاتر، همگرایی با استانداردهای رصدپذیری (Observability)، کاهش سربار تخصیص حافظه و یکپارچگی عمیق‌تر با هسته فریم‌ورک، مایکروسافت را بر آن داشت تا با بازطراحی ساختاری Polly (نسخه ۸ به بعد) بسته رسمی Microsoft.Extensions.Resilience را ارائه کند. این مقاله به بررسی فنی معماری این بسته نوین، مزایای آن از منظر کارایی، رصدپذیری استاندارد، و جایگزینی انتزاعات قدیمی با خط‌لوله‌های تاب‌آوری (Resilience Pipelines) می‌‌پردازد.

• تخصیص بالای حافظه (Heap Allocations): ساختار مبتنی بر پالیسی‌های قدیمی Polly v7 سربار حافظه قابل‌توجهی برای Garbage Collector ایجاد می‌کرد.
• جدایی از رصدپذیری نوین: معیارهای سنجش (Metrics) و تله‌متری به شکل یکپارچه درون خطوط لوله تعبیه نشده بودند.
• پیچیدگی در ترکیب الگوها: ترکیب چند سیاست محافظتی (Policy Wrap) سینتکس ناخوانا و هزینه‌های اجرایی پنهانی به دنبال داشت.

Request ──► [ Rate Limiter ] ──► [ Circuit Breaker ] ──► [ Retry ] ──► [ Timeout ] ──► Core Execution

• تخصیص نزدیک به صفر (Near-Zero Allocation): طراحی مجدد بر پایه ValueTask، خط‌لوله‌ها را برای سناریوهای فوق پرسرعت (High-Throughput) بهینه‌سازی کرده است.
• جدایی استراتژی از نحوه ارسال: بر خلاف پکیج‌های گذشته که عمدتاً روی HttpClient متمرکز بودند، خط‌لوله‌ها از نوع اجرا مستقل‌اند؛ می‌توان آن‌ها را برای پایگاه‌داده، کش، فراخوانی‌های gRPC یا محاسبات درون‌برنامه‌ای به کار بست.

• محدودکننده نرخ (Rate Limiting)
• مهلت زمانی سراسری (Total Request Timeout)
• تلاش مجدد هوشمند با تأخیر تصادفی (Retry with Jitter)
• قطع‌کننده مدار (Circuit Breaker)
• مهلت زمانی تلاش مجزا (Attempt Timeout)

// رویکرد سنتی و وابسته به پکیج‌های قدیمی
services.AddHttpClient("LegacyClient")
    .AddTransientHttpErrorPolicy(policy => 
        policy.WaitAndRetryAsync(3, _ => TimeSpan.FromSeconds(2)))
    .AddTransientHttpErrorPolicy(policy => 
        policy.CircuitBreakerAsync(5, TimeSpan.FromSeconds(30)));

// فعال‌سازی بسته جامع تاب‌آوری روی HttpClient
builder.Services.AddHttpClient("ModernClient", client =>
{
    client.BaseAddress = new Uri("https://api.example.com");
})
.AddStandardResilienceHandler(options =>
{
    // سفارشی‌سازی تنظیمات در صورت نیاز
    options.Retry.MaxRetryAttempts = 3;
    options.Retry.Delay = TimeSpan.FromSeconds(1);
    options.AttemptTimeout.Timeout = TimeSpan.FromSeconds(5);
    options.CircuitBreaker.SamplingDuration = TimeSpan.FromSeconds(10);
});

// تعریف و ثبت خط‌لوله عمومی در DI
builder.Services.AddResiliencePipeline("database-pipeline", pipelineBuilder =>
{
    pipelineBuilder
        .AddRetry(new RetryStrategyOptions
        {
            MaxRetryAttempts = 2,
            Delay = TimeSpan.FromMilliseconds(500)
        })
        .AddTimeout(TimeSpan.FromSeconds(3));
});

// استفاده در یک سرویس کاری
public class ProductService(ResiliencePipelineProvider<string> pipelineProvider)
{
    public async ValueTask<Product?> GetProductAsync(int id, CancellationToken ct)
    {
        var pipeline = pipelineProvider.GetPipeline("database-pipeline");

        return await pipeline.ExecuteAsync(async state =>
        {
            return await QueryDatabaseAsync(id, state);
        }, ct);
    }

    private static ValueTask<Product?> QueryDatabaseAsync(int id, CancellationToken ct)
    {
        // شبیه‌سازی فراخوانی پایگاه داده
        return ValueTask.FromResult<Product?>(new Product(id, "لپ‌تاپ"));
    }
}

public record Product(int Id, string Name);

• رویدادهای باز شدن مدارهای ارتباطی (Circuit breaker state changes)
• تعداد دفعات وقوع Retry و علت آن
• تاخیرهای ناشی از مهلت زمانی (Timeout events)

• امنیت پایداری و کاهش ریسک وابستگی: تبدیل این مکانیزم‌ها به یک ماژول رسمی با پشتیبانی مستقیم مایکروسافت، ریسک ناشی از توقف پشتیبانی یا تغییر ناگهانی مدل‌های درآمدی کتابخانه‌های شخص ثالث را از بین برده است.
• پیکربندی ساختاریافته (Options Pattern): تمامی پارامترهای تاب‌آوری قابلیت نگاشت خودکار به فایل‌های پیکربندی (appsettings.json) را دارند و بدون کامپایل مجدد، از طریق پیکربندی مجدد و Hot Reload قابل به‌روزرسانی هستند.
• هم‌راستایی با فرهنگ Cloud-Native: عملکرد بالا، کمینه‌بودن مصرف حافظه و رصدپذیری خودکار، این ابزار را با نیازمندی‌های مقیاس‌پذیری افقی در زیرساخت‌هایی نظیر Kubernetes و .NET Aspire هم‌‌سو کرده است.