رشد ترافیک، مشکل خوبی است؛ اما فقط وقتی سیستم شما برای آن آماده باشد. بیشتر شکست‌های مقیاس نه از کمبود منابع، بلکه از نقاط کور معماری و تصمیم‌هایی می‌آیند که در ترافیک پایین بی‌خطر به نظر می‌رسند.

۱. قبل از تغییر، اندازه‌گیری کنید

اولین قدم اضافه کردن سرور نیست. باید بدانید زمان پاسخ کجا مصرف می‌شود، کدام queryها گران‌اند و چه درصدی از درخواست‌ها واقعاً به محاسبه تازه نیاز دارند. سه عدد را از همین امروز ثبت کنید: p95 latency، نرخ خطا و زمان اشغال connectionهای دیتابیس.

قاعده عملی: اگر هنوز نمی‌توانید کندترین ۵٪ درخواست‌ها را جداگانه ببینید، برای بهینه‌سازی زود است.

۲. مرزهای سیستم را روشن کنید

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

// Keep the request path short
const order = await orders.create(payload);
await queue.publish('order.created', order.id);
return response.created(order);

۳. کش را با قصد طراحی کنید

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

  • کلید کش را با نسخه schema همراه کنید.
  • برای داده‌های حساس، scope کاربر یا سازمان را فراموش نکنید.
  • نرخ hit و miss را مثل یک متریک محصول دنبال کنید.

۴. کار سنگین را به صف منتقل کنید

صف به شما امکان می‌دهد فشار لحظه‌ای را جذب کنید و سرعت پردازش را مستقل از سرعت دریافت درخواست افزایش دهید. مهم‌تر از انتخاب ابزار، تعریف retry، idempotency و dead-letter queue است.

۵. مشاهده‌پذیری را قبل از بحران بسازید

Log بدون context کافی نیست. برای هر درخواست یک شناسه یکتا داشته باشید و آن را میان سرویس‌ها عبور دهید. داشبوردی بسازید که قبل از تماس مشتری، تغییر رفتار سیستم را نشان دهد.

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