ساخت API‌های مقیاس‌پذیر که از پس ترافیک واقعی برمی‌آیند

«API مقیاس‌پذیر» برای گفتن «از میکروسرویس استفاده کردیم» به کار می‌رود. این به‌ندرت همان چیزی است که مقیاس‌پذیری واقعاً نیاز دارد. بیشتر APIها زیر بار به دلایل کسل‌کننده‌ای از کار می‌افتند: کوئری‌های بی‌کران، نبود صفحه‌بندی، نبود محدودیت نرخ و endpointهایی که کار زیادی را همگام انجام می‌دهند. اول این‌ها را درست کنید؛ کوبرنتیز را بعداً سراغ بگیرید.

صفحه‌بندی از روز اول

هر endpointی که فهرستی برمی‌گرداند سرانجام بیش از حد برمی‌گرداند. صفحه‌بندی را از همان ابتدا در قرارداد API طراحی کنید — تغییرش بعداً کلاینت‌ها را می‌شکند.

GET /api/v1/courses?page=2&per_page=20

{
  "data": [...],
  "meta": {
    "current_page": 2,
    "per_page": 20,
    "total": 847,
    "last_page": 43
  }
}

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

خنثی‌پذیری برای نوشتن‌ها

شبکه‌ها تلاش مجدد می‌کنند. کلاینت‌ها دوباره ارسال می‌کنند. بدون خنثی‌پذیری، یک API پرداخت که دوبار شارژ می‌کند یک شکایت حقوقی است، نه یک گزارش باگ. یک هدر کلید خنثی‌پذیری بپذیرید و نتیجه اولین درخواست موفق را ذخیره کنید:

POST /api/v1/payments
Idempotency-Key: 550e8400-e29b-41d4-a716-446655440000

هر endpoint جهش‌دهنده‌ای که می‌تواند دوباره تلاش شود باید خنثی‌پذیر باشد. اگر نباشد، یک بمب ساعتی ساخته‌اید.

نسخه‌بندی بدون درد

نسخه را در مسیر URL بگذارید (/api/v1/) و با تغییرات شکننده مثل یک نسخه جدید رفتار کنید. افزوده‌های غیرشکننده (فیلدهای اختیاری جدید) می‌توانند در v1 بمانند. تعریف کنید «شکننده» برای تیمتان یعنی چه و به آن پایبند بمانید.

محدودیت نرخ و افت برازنده

محدودیت نرخ شما را از سوءاستفاده و از کلاینت‌های باگ‌دار خودتان محافظت می‌کند. 429 Too Many Requests با هدر Retry-After برگردانید. برای endpointهای پرخوانش، با شدت کش کنید و به‌جای شکست سخت هنگام سکسکه پایگاه داده، داده کهنه سرو کنید.

ناهمگام برای کار کند

هر چیزی که بیش از چند صد میلی‌ثانیه طول می‌کشد — ارسال ایمیل، تولید PDF، پردازش آپلود — باید 202 Accepted با یک شناسه کار برگرداند و در پس‌زمینه پردازش شود. کلاینت‌ها نظرسنجی می‌کنند یا وقتی تمام شد یک webhook دریافت می‌کنند.

اشتباهات رایج

• endpointهای خدا. یک endpoint که می‌سازد، به‌روز می‌کند، جست‌وجو و خروجی می‌گیرد، پیچیدگی را تضمین می‌کند. بر اساس مسئولیت تقسیم کنید.
• برگرداندن ناهماهنگ شناسه‌های داخلی. UUID یا عدد صحیح را انتخاب کنید و همه‌جا استفاده کنید؛ در بعضی مسیرها شناسه‌های افزایشی و در بعضی UUID لو ندهید.
• نبود اعتبارسنجی درخواست در مرز. ورودی نامعتبر باید با خطاهای روشن، قبل از رسیدن به منطق کسب‌وکار سریع شکست بخورد.

بهترین شیوه‌ها

• قرارداد API را قبل از پیاده‌سازی طراحی کنید؛ زود با مصرف‌کننده‌ها به اشتراک بگذارید.
• شناسه‌های درخواست را لاگ کنید و در سرتاسر پشته‌تان برای دیباگ منتشر کنید.
• endpointهایی را که انتظار دارید پرترافیک باشند قبل از راه‌اندازی بار-تست کنید، نه بعد.

جمع‌بندی

API‌های مقیاس‌پذیر روی پایه‌های کسل‌کننده ساخته می‌شوند: صفحه‌بندی، خنثی‌پذیری، نسخه‌بندی، محدودیت نرخ و پردازش ناهمگام. این‌ها را مسلط شوید قبل از اینکه مونولیتتان را توزیع کنید. خودِ آینده‌تان ساعت سه نیمه‌شب از شما ممنون خواهد بود. این هفته سنگین‌ترین endpoint فهرستی‌تان را بازبینی و اگر صفحه‌بندی ندارد اضافه کنید — اغلب پربازده‌ترین اصلاح است.