مفهوم Resiliency یا تاب‌آوری، به توانایی یک سیستم برای بازیابی شرایط پایدار در صورت بروز خطا گفته می‌شه. حالا این بازیابی می‌تونی تلاش برای بازیابی باشه، یا انتخاب راه جایگزین. مثل اینکه شما ۲ بار تلاش می‌کنی از API آب‌وهوا مقدار دمای فعلی یک منطقه رو بگیری، هر بار با فاصله زمانی ۵ ثانیه API رو صدا می‌زنی ولی بعد از اینکه پاسخ موفق نمی‌گیری (تا اینجا به این می‌گن استراتژی retry) بعد تصمیم می‌گیری از cache آخرین مقداری که کم‌تر از ۵ ساعت گذشته وجود داشته رو استفاده کنی که فعلا کار راه بیوفته (استراتژی fallback) یا … به هر کدوم از این رفتارها برای تداوم کار و مقابله با موانع، می‌گن resiliency strategy.
کتابخونه Polly محبوب‌ترین در بین دات‌نتی‌هاست. و تو دل Aspire هم ازش استفاده شده، برای درک بهتر ویدیوی Aspire که به زودی پابلیش می‌شه، خوبه یه مرور روی انواع استراتژی‌ها کنیم…
دو گروه اصلی داریم:
⚙️گروه استراتژی‌های Reactive (واکنشی)
وقتی به کار می‌رن که یک خطا یا مشکلی رخ داده و سیستم باید به شکلی واکنش نشون بده.
🛡 ۱: استراتژی Retry
فرضیه: خطاها موقتی هستن و ممکنه با کمی تأخیر و تلاش مجدد برطرف بشن.
در این استراتژی، سیستم تلاش می‌کنه که یک عملیات ناموفق رو بعد از یک بازه‌ی زمانی مشخص دوباره امتحان کنه. این بازه زمانی می‌تونه ثابت یا متغیر باشه (مثل Exponential Backoff). مثلاً اگر سرور موقتی قطع شده باشه، با چند بار Retry ممکنه مشکل حل بشه. در Polly، این با “Retry Policy” قابل پیاده‌سازی است. و تعداد دفعات و بازه زمانی بین هر تلاش به تصمیم ما وابسته است.
🛡 ۲: استراتژی Circuit-Breaker
فرضیه: وقتی سیستم به شدت دچار مشکل می‌شه، بهتره سریعاً فرآیندها متوقف بشن به جای اینکه کاربران منتظر بمونن.
چطور کمک می‌کنه؟ مدار رو قطع می‌کنه (اجرای درخواست‌ها رو متوقف می‌کنه) در زمانی که خطاها از حدی مشخص بیشتر می‌شن (مثل وقتی می‌فرسته به صف ولی هِی روی هم انباشت می‌شه و از اون طرف پردازش نمی‌شن)
شبیه به فیوز برق که اگر بیش از حد فشار وارد بشه، مدار رو قطع می‌کنه. این استراتژی به سیستم اجازه می‌ده برای مدتی مشخص درخواست‌ها رو به مقصد ارسال نکنه تا از خرابی‌های بیشتر جلوگیری بشه. مثلاً در Polly می‌تونید مدت‌زمانی که Circuit باز می‌مونه و شرایط بازگشت به حالت نرمال رو تنظیم کنیم.
🛡 ۳: استراتژی Fallback
فرضیه: خطا تداوم خواهد داشت؛ پس برای پلن B برنامه‌ریزی می‌کنیم.
چطوری کمک می‌کنه؟ یک مقدار یا راه حل جایگزین در صورت بروز یا تداوم خطا ارائه می‌ده.
وقتی یک عملیات شکست می‌خوره، به جای نمایش خطا به کاربر، یک نتیجه جایگزین برمی‌گرده. مثلاً به جای اینکه پیام “سرور API در دسترس نیست” نمایش داده بشه، می‌تونید یک مقدار ذخیره شده از کش رو ارائه بدید.
🛡 ۴: استراتژی Hedging
فرضیه: گاهی اوقات برخی مسیرها شاید کند یا حتی ناموفق باشن؛ پس بهتره چندین راه برای رسیدن به هدف در نظر بگیریم، هر کدوم زودتر جواب داد، همون.
چطوری کمک می‌کنه؟ برای یک کار، چند راه رو تلاش می‌کنه به طور موازی پی بگیره و منتظر اولین پاسخ موفق می‌مونه.
در این استراتژی، همزمان چند درخواست به چند مقصد مختلف ارسال می‌شه و اولین پاسخ موفق به عنوان نتیجه پذیرفته می‌شه. این کار برای کاهش زمان انتظار و بهبود اطمینان‌پذیری استفاده می‌شه.
⚙️گروه استراتژی‌های Proactive (کنشگر)
این استراتژی‌ها برای پیشگیری از بروز مشکلات در سیستم طراحی شده‌اند.
🛡 ۱: استراتژی Timeout
فرضیه: بعد از مدت زمانی مشخص، موفقیت بعیده.
چطوری کمک می‌کنه؟ تضمین می‌کنه که درخواست‌ها بیشتر از زمان مشخص منتظر نمی‌مونن.
در این استراتژی، زمان محدودی برای انجام یک عملیات در نظر گرفته می‌شه. اگر عملیات در این زمان به نتیجه نرسید، سیستم اون رو قطع می‌کنه. این کار مانع از این می‌شه که یک درخواست معلق منابع سیستم رو اشغال کنه.
🛡 ۲: استراتژی Rate Limiter
فرضیه: محدود کردن تعداد درخواست‌هایی که سیستم در یک بازه زمانی مشخص می‌پذیره (راهی برای کنترل بار ورودی).
چطوری کمک می‌کنه؟ اجرای درخواست‌ها رو محدود می‌کنه تا از حد مشخصی فراتر نره.
برای جلوگیری از بار زیاد روی سیستم، این استراتژی تعداد درخواست‌ها در یک بازه زمانی مشخص رو محدود می‌کنه. مثلاً اگر کاربران زیادی همزمان به سیستم درخواست بفرستن، Rate Limiter می‌تونه از خرابی جلوگیری کنه.
ℹ️ ما می‌تونیم از یک یا ترکیبی از چند استراتژی برای افزایش تاب‌آوری سیستم‌هامون استفاده کنیم.