فرض کنید API یک مدل زبانی را با برند خودتان میفروشید. مشتری «سرویس Acme AI» را با قیمت شما میخرد؛ نمیداند پشت صحنه امروز از کدام ارائهدهنده بالادستی پاسخ میگیرد.
تا وقتی همهچیز روان است، همین کافی است. اما یک روز پرترافیک، سهمیه مشترک کلید API ارائهدهنده اصلی تمام میشود — سقف روزانه، بودجه ماهانه، یا حداکثر همزمانی که برای «کل سرویس» تعریف کردهاید.
بدون راهحل، دو گزینه بد دارید:
- به مشتری
429بدهید و درآمد همان لحظه از دست برود. - دستی مسیر را عوض کنید و امیدوار باشید تیم مالی بعداً بفهمد کدام ارائهدهنده واقعاً سرویس داده — معمولاً تسویه بههم میریزد.
Failover سرویس فینو گزینه سوم است: سرویس ادامه پیدا کند، مشتری مثل همیشه صورتحساب شود، و در گزارش تسویه، همان ارائهدهندهای که واقعاً پاسخ داده حقوقش ثبت شود.
این با «مرگ گره کلاستر» فرق دارد
وقتی میگوییم failover، خیلیها یادشان میآید HA: یک سرور از کار افتاد، سرور دیگر جایش را گرفت، داده از دست نرفت.
فینو این را هم با Raft دارد — شارژها پایدار میمانند.
Failover سرویس مشکل دیگری است:
- کلاستر سالم است.
- دروازه سالم است.
- موجودی مشتری هست.
- اما ظرفیت مشترک ارائهدهنده برای آن سرویس تمام شده.
یعنی مشکل از «سرور ما» نیست؛ مشکل از «سقفی که روی کلید upstream گذاشتهایم» است.
یک مثال ساده
سرویس «تولید تصویر» را ۵۰۰ تومان (در ledger: میکرو-ریال) برای هر فراخوانی میفروشید.
- بالادست اصلی: ارائهدهنده A — ۱۰٬۰۰۰ فراخوانی در روز روی یک کلید مشترک.
- بالادست پشتیبان: ارائهدهنده B — بهصورت سرویس فقط-backend در فینو تعریف شده؛ مشتری در کاتالوگ نمیبیند، اما دروازه میداند چطور به آن برسد.
ساعت ۱۵ ظهر، سقف روزانه A صفر میشود. از آن لحظه:
- درخواست بعدی مشتری همچنان به تولید تصویر میرسد (همان محصولی که خریده).
- فینو میبیند بودجه مشترک سرویس تمام شده.
- بهجای رد کردن، اولین هدف failover با ظرفیت آزاد را امتحان میکند — مثلاً B.
- مشتری تصویر را میگیرد و همان ۵۰۰ تومان (قیمت سرویس اصلی) برایش ثبت میشود.
- در تسویه، B هزینه عمده همان فراخوانی را میگیرد، چون واقعاً او سرویس داده.
تجربه مشتری قطع نمیشود. کتابها هم درست میمانند.
پیکربندی به زبان ساده
در داشبورد ادمین، روی سرویس consumer-facing میروید و اهداف failover اضافه میکنید — فهرست اولویتدار سرویسهایی که وقتی سقف مشترک پر شد، جایگزین میشوند.
برای هر هدف میتوانید بسته هزینه ارائهدهنده جدا بگذارید تا حاشیه سود درست بماند، حتی اگر پشتیبان ارزانتر یا گرانتر باشد.
سرویس backend-only در کاتالوگ مشتری دیده نمیشود؛ فقط برای زنجیره failover یا spill استفاده میشود.
مدل صورتحساب عوض نمیشود. همان Reserve → Finalize → Ledger اجرا میشود؛ فقط مسیر upstream عوض میشود.
چه چیزی عمداً دور زده نمیشود
Failover برای محدودیت مشترک ارائهدهنده است، نه فرار مشتری از قرارداد خودش.
اگر برای مصرفکننده X سقف ۵۰۰ فراخوانی در روز گذاشتهاید، در ۵۰۰ همچنان 429 میگیرد — حتی اگر پشتیبان ظرفیت زیاد داشته باشد. فراخوانیهایی که از failover میآیند در همان سقف حساب میشوند.
برای سهمیه اشتراک هم همینطور: اگر سهمیه تمام شده و سیاست overage میگوید «مسدود»، اول همان اعمال میشود؛ failover راه فرار نیست.
کنار Survival Mode
- Failover سرویس: سهمیه upstream تمام شد — آیا هنوز میتوانیم سرویس دهیم؟
- Survival Mode: فشار CPU/RAM روی ماشین خودمان — چه چیزی را کم کنیم تا سرویس زنده بماند؟
دو بحران متفاوت. گاهی هر دو با هم پیش میآیند: upstream کند میشود، همزمانی زیاد میشود، میزبان تحت فشار قرار میگیرد.
داستان کامل Survival Mode: وبلاگ Survival Mode · مرور امکانات: تابآوری در صفحه امکانات
کی به درد میخورد؟
- بازفروش API با سقف روزانه/ماهانه روی کلید مشترک upstream
- چند حساب یا چند ارائهدهنده برای یک سطح محصول
- نیاز به تداوم سرویس مهمتر از یکسان بودن ۱۰۰٪ مسیر upstream — به شرط تسویه درست
اگر upstream شما واقعاً نامحدود است، شاید هرگز failover تنظیم نکنید. اما بیشتر تیمهای resale روزی به سقف provider میخورند — همان روز این قابلیت خودش را نشان میدهد.
سوالی درباره زنجیره failover یا تسویه با چند ارائهدهنده دارید؟ تماس با ما