IOSOR دانش
چه زمانی سقف مستأجر تعبیهشده باید ارسال را متوقف کند
سقفهای سهم منصفانه درون محصول ISV باید ارسال را برای آن مستأجر به طور قطعی متوقف کنند — هرگز پس از رسیدن به سقف، پاسخ API 200 ساختگی ارسال نکنید.
نرمافزارهای SaaS چندمشتری تعبیهشده به سقفهای سهم منصفانه نیاز دارند تا یک مستأجر پرترافیک نتواند اعتبار اعتباری مشترک را تمام کند یا مانع بقیه شود. سقفی که فقط یک هشدار روی داشبورد نشان میدهد در حالی که API همچنان درخواستها را میپذیرد، ناکارآمد است. وقتی مستأجر به حد مجاز میرسد، ارسال برای آن مستأجر باید با یک خطای مشخص و وضعیت غیرموفق API متوقف شود. پاسخهای ساختگی 200 فرآیند تطبیق مالی را خراب کرده و باعث سوءاستفاده میشوند.
سقفها در لایه محصول ISV قرار دارند — نه جایگزینی برای محدودیتهای نرخ مستأجر فرعی پارتنر هستند و نه رهاسازی صامت صف. توقف صادقانه یعنی: رابط کاربری SaaS وضعیت متوقفشده یا محدودشده را نشان دهد، سرویس تعبیهشده درخواستهای جدید برای آن شناسه مستأجر را رد کند، و تیم عملیات بتواند گزارش افرادی که به سقف رسیدهاند را استخراج کند.
قرارداد توقف را پیش از ترافیک آزمایشی تنظیم کنید: واحد سقف (پیام / هزینه / روز)، پنجره بازنشانی، افراد مجاز برای افزایش سقف، و آنچه کاربر نهایی میبیند.
رسیدن به سقف یعنی رد ارسال، نه هشدار نرم همیشگی
هشدارهای نرم فقط اخطارهای اولیه هستند. در سقف قطعی، سرویس تعبیهشده خطای رسیدن به سقف مستأجر را برمیگرداند و API پیامرسانی را برای درخواستهای جدید فراخوانی نمیکند. پیامهای در حال پردازش میتوانند تکمیل شوند؛ ارسالهای جدید OTP و کمپینها باید منتظر بازنشانی یا افزایش تأییدشده باشند.
هر رد درخواست را با شناسه مستأجر، قانون سقف و برچسب زمانی ثبت کنید. پشتیبانی هنگام ادعای مشتری مبنی بر قطع ارسال به این دادهها نیاز دارد.
هرگز وضعیت تحویل موفق روی مسیر محدودشده تولید نکنید
| پاسخ | زمان مجاز | ممنوع در |
|---|---|---|
| محصول محدود / متوقف شده | رسیدن به سقف قطعی | مسیر رد سقف |
| خطا / وضعیت غیرموفق HTTP | رد سقف | — |
| تحویل داده شده / موفقیت 200 | مسیر پذیرش واقعی | رد سقف |
| رهاسازی صامت | هرگز | همیشه |
| رهاسازی صامت و پاسخهای ساختگی 200 مشابه سرریز صف هستند که تظاهر به موفقیت میکنند. |
سقفهای محصول را با خطوط توقف کیف پول هماهنگ کنید
یک مستأجر میتواند زیر سقف سهم خود باشد در حالی که خط توقف کیف پول ISV قرمز شده است. در این حالت کل مسیر تعبیهشده متوقف میشود — نه فقط مستأجر پرترافیک. کیف پول فعال باعث معافیت مستأجری که سهم خود را مصرف کرده نمیشود. از یک زبان وضعیت واحد استفاده کنید: سقف مستأجر در برابر توقف حساب.
درخواستهای افزایش سقف نیاز به تأییدکننده مشخص دارند. افزایش خودکار و نامحدود سقف، هدف سهم منصفانه را از بین میبرد.
توقف را در محیط Staging با یک مستأجر پرترافیک تست کنید
پیش از تولید، یک مانور در محیط staging اجرا کنید: یک مستأجر پیامهای OTP را تا زمان فعال شدن سقف ارسال میکند، سایر مستأجران به ارسال ادامه میدهند، و گزارشها خطوط رد درخواست را بدون موفقیتهای ساختگی نشان میدهند. اگر سایر مستأجران متوقف شوند، دامنه سقف نادرست تنظیم شده است.
مسیرهای عملیاتی مرتبط
- اجرای ایمن محدودیتهای نرخ برای حسابهای چندمشتری
- سرریز صف: توقف، رهاسازی صامت ممنوع
- خطوط توقف کیف پول پیش از ترافیک عملیاتی
شروع با IOSOR
کنسول را باز کنید و سهم منصفانه زیرمجموعه را طوری تنظیم کنید که در زمان رسیدن به حد نصاب، درخواستها در دروازه ارسال قاطعانه رد شوند. نگاشت پاسخ API را طوری پیکربندی کنید که کاربران محدود شده به جای یک محتوای پذیرفتهشده، یک خطای صریح دریافت کنند. یک تست در محیط آزمایشی با یک کاربر پرمصرف اجرا کنید تا مطمئن شوید ترافیک سایرین آزادانه جریان دارد و ارسالهای مسدود شده به عنوان گزارشهای رد صریح ثبت میشوند.
جمعبندی IOSOR
هنگامی که یک زیرمجموعه با افزایش ناگهانی ترافیک مواجه میشود، هشدارهای ملایم نمیتوانند از صفهای پاییندستی محافظت کنند. این راهنمای عملیاتی ثابت کرد که سقفهای سهم منصفانه باید به عنوان یک رد فوری در دروازه ارسال عمل کنند و تفکیک روشنی میان خطاهای سقف کاربر و خطوط توقف کیف پول جهانی حفظ نمایند.
پاسخهای وضعیت محدودشده مشخص را به لایه برنامهنویسی خود بازگردانید تا زیرمجموعهها بتوانند درخواست افزایش حد نصاب را به درستی ثبت کنند. برای تلاشهای مسدود شده، پاسخ موفقیتآمیز جعلی یا گزارش تحویل تأییدشده ارسال نکنید، زیرا ساخت موفقیت دروغین، خرابیهای واقعی تحویل را پنهان کرده و قابلیت حسابرسی کاربر را از بین میبرد.
آیا این راهنما مفید بود؟
راهنماهای مرتبط
- جاسازی API در برابر پورتال شریک وایت لیبل
محصولات SaaS که پیامرسانی را جاسازی میکنند در سطح ISV باقی میمانند. پورتالهای شریک وایت لیبل زیر مجموعه شریک باقی میمانند — برند، کلیدها و مالکیت عملیاتی را ترکیب نکنید.
- ارسال کاربر نهایی همچنان به یک دفتر کل پیشپرداخت متصل است
ارسال تعبیهشده همچنان کیف پول پیشپرداخت ISV را بدهکار میکند. دفتر کل دوم نرا بسازید که محصول آن را تامین مالی نمیکند — نگهداشتها، تلاشهای مجدد و همتوانی صادقانه باقی میمانند.