Technical Tutorials

در عرصه معماری نرم‌افزار مدرن، تزریق وابستگی (DI) به استاندارد پیش‌فرض برای مدیریت ایجاد شیء و کاهش وابستگی تبدیل شده است. اگرچه پیاده‌سازی DI در یک مونولیت ساده straightforward است، اما مدیریت چرخه‌های حیات در یک سیستم توزیع‌شده از میکروسرویس‌ها لایه‌ای از پیچیدگی را معرفی می‌کند که اغلب حتی مهندسان ارشد را دچار مشکل می‌کند. کانتینر کنترل معکوس (IoC) تنها یک کارخانه برای ایجاد شیء نیست؛ بلکه یک مدیر چرخه حیات است که تعیین می‌کند منابع چه زمانی تخصیص داده شوند و از اهمیت بیشتری برخوردار است، چه زمانی آزاد شوند.

مدیریت نادرست این چرخه‌های حیات می‌تواند منجر به نشت حافظه، مشکلات داده‌های منسوخ یا تخلیه مخزن اتصال شود. این پست به پیاده‌سازی عملی چرخه‌های حیات DI می‌پردازد و بر ظرافت‌های مدیریت حالت در مرزهای سرویس تمرکز دارد.

درک چرخه‌های حیات اصلی

بیشتر کانتینرهای IoC، مانند Autofac، Spring Framework یا ارائه‌دهنده داخلی .NET Core، از سه محدوده چرخه حیات اصلی پشتیبانی می‌کنند. درک تفاوت معنایی بین این‌ها اولین قدم به سوی معماری مقاوم است.

گذرا (Transient): هر بار که سرویس درخواست می‌شود، یک نمونه جدید ایجاد می‌شود. این گزینه برای سرویس‌های بدون حالت یا شیء‌های سبک ایده‌آل است.
محدوده‌دار (Scoped): یک نمونه واحد به ازای هر محدوده ایجاد می‌شود. در برنامه‌های وب، یک محدوده معمولاً به یک درخواست HTTP واحد نگاشت می‌شود. این گزینه برای الگوهای واحد کار، مانند DbContext Entity Framework، عالی است.
تک‌نمونه (Singleton): یک نمونه واحد به ازای هر کانتینر ایجاد می‌شود. این برای پیکربندی دارای حالت یا سرویس‌هایی که حالت جهانی را حفظ می‌کنند، استفاده می‌شود.

دام چرخه حیات محدوده‌دار در میکروسرویس‌ها

شایع‌ترین خطای معماری زمانی رخ می‌دهد که توسعه‌دهندگان تلاش می‌کنند سرویس‌های محدوده‌دار را در مرزهای ناهمگام که به محدوده درخواست اصلی وابسته نیستند، به اشتراک بگذارند. در یک معماری میکروسرویس، یک درخواست ورودی واحد ممکن است باعث ایجاد طیفی از تماس‌های داخلی از طریق صف‌های پیام یا کلاینت‌های HTTP شود.

اگر یک سرویس محدوده‌دار (مانند زمینه پایگاه داده) به یک کارگر پس‌زمینه که خارج از محدوده درخواست عمل می‌کند، تزریق شود، یا در حل آن شکست می‌خورد یا مشکلات جدی همزمانی ایجاد می‌کند.

الگوی مشکل‌دار زیر را در C# در نظر بگیرید:

// ❌ خطرناک: تزریق یک سرویس محدوده‌دار به یک تک‌نمونه
public class BackgroundWorker
{
    private readonly IDataService _dataService; // IDataService به عنوان Scoped ثبت شده است

    public BackgroundWorker(IDataService dataService)
    {
        _dataService = dataService; // کانتینر ممکن است در اینجا خطا پرتاب کند
        // یا به یک مرجع از یک نمونه از دست‌رفته نگه دارد
    }
}

برای رفع این مشکل، باید محدوده را به صراحت در داخل وظیفه پس‌زمینه مدیریت کنیم. مصرف‌کننده نباید سرویس محدوده‌دار را مستقیماً به کارگر تک‌نمونه تزریق کند. در عوض، کارگر باید یک IServiceScopeFactory را بپذیرد، به طوری که بتواند برای هر واحد کار، یک محدوده جدید ایجاد کند.

راه‌حل عملی: مدیریت صریح محدوده

با تزریق کارخانه محدوده، اطمینان حاصل می‌کنیم که زمینه پایگاه داده یا سایر وابستگی‌های محدوده‌دار به درستی برای هر پیامی که توسط کارگر پردازش می‌شود، ایجاد و آزاد می‌شوند.

// ✅ ایمن: استفاده از IServiceScopeFactory برای مدیریت وابستگی‌های محدوده‌دار
public class SafeBackgroundWorker
{
    private readonly IServiceScopeFactory _scopeFactory;

    public SafeBackgroundWorker(IServiceScopeFactory scopeFactory)
    {
        _scopeFactory = scopeFactory;
    }

    public async Task ProcessMessageAsync(string message)
    {
        // ایجاد یک محدوده جدید برای این عملیات خاص
        using (var scope = _scopeFactory.CreateScope())
        {
            // حل سرویس محدوده‌دار در داخل محدوده جدید
            var dataService = scope.ServiceProvider.GetRequiredService<IDataService>();
            
            await dataService.UpdateAsync(message);
        } // محدوده و تمام سرویس‌های از دست‌رفته آن در اینجا تمیز می‌شوند
    }
}

نتیجه‌گیری

مدیریت چرخه‌های حیات IoC در میکروسرویس‌ها نیازمند رویکردی منضبط به حل وابستگی است. در حالی که گذرا ایمن و تک‌نمونه‌ها قدرتمند هستند، سرویس‌های محدوده‌دار نیاز به مدیریت صریح مرزها دارند. با درک طول عمر وابستگی‌های خود و اجتناب از اشتراک‌گذاری ضمنی محدوده در مرزهای ناهمگام، می‌توانید سیستم‌هایی بسازید که نه تنها ماژولار، بلکه در برابر نشت حافظه و باگ‌های همزمانی مقاوم باشند. به خاطر داشته باشید: در سیستم‌های توزیع‌شده، وضوح چرخه حیات به اندازه وضوح کد اهمیت دارد.