Vercel Daemons برای اجرای پردازشهای طولانی و Workerهای دائمی طراحی شده است. بنابراین گزاره قدیمی «Vercel فقط برای درخواست کوتاه وب است» دیگر مبنای دقیقی برای انتخاب زیرساخت نیست. تصمیم امروز این است که Worker شما چه اتصال‌ها، داده پایدار، کنترل استقرار و هزینه‌ای نیاز دارد و کدام محیط آن نیاز را بهتر پوشش می‌دهد.
در این راهنما Daemon را با تابع Serverless و سرویس کانتینری مقایسه می‌کنیم. سپس مسیر انتخاب برای صف Node.js، Celery و Agent همیشه‌روشن را توضیح می‌دهیم. پلتفرم ابری پاستا یکی از گزینه‌های اجرای برنامه و سرویس مستقل در ایران است؛ این مقاله ادعای یکسان‌بودن قابلیت‌ها یا برتری مطلق هیچ ارائه‌دهنده‌ای ندارد.
تغییر جدید Vercel چیست؟
Vercel در اعلام ۱۵ اکتبر ۲۰۲۶، Daemons را وارد بتای عمومی کرد. در معرفی، پردازشهای طولانی مبتنی بر دریافت کار از صف، از جمله BullMQ و Celery، مطرح شده‌اند. این قابلیت از اجرای کانتینر و مدیریت تعداد نمونه‌ها استفاده می‌کند. وضعیت بتا، مناطق، قیمت و محدودیت‌ها را پیش از استفاده تجاری از مستندات جاری بررسی کنید.
بتای عمومی با تضمین یکسان برای همه نیازهای production مترادف نیست. همچنین اجرای دائمی پردازش به معنی اجرای دائمی همان نمونه خاص نیست؛ نمونه ممکن است در استقرار، خرابی یا عملیات نگهداری عوض شود. برنامه همچنان باید در برابر قطع و راه‌اندازی مجدد مقاوم باشد.
Daemon، Serverless و کانتینر سه نام برای یک چیز نیستند
Daemon یک الگوی اجرای پردازش است: برنامه زنده میماند و منتظر کار می‌شود. Serverless بیشتر درباره مدل مدیریت و فراخوانی منابع صحبت می‌کند. کانتینر هم روش بسته‌بندی و اجرای برنامه است. یک سرویس میتواند هم کانتینری باشد و هم زیرساختش را ارائه‌دهنده مدیریت کند؛ این اصطلاحات الزاماً گزینه‌های متضاد نیستند.
| الگو | کار مناسب | پرسش اصلی |
|---|---|---|
| تابع فراخوانی‌شونده | پاسخ وب یا کار کوتاه رویدادمحور | زمان اجرا و قرارداد رویداد چیست؟ |
| Worker دائمی | مصرف صف و اتصال طولانی | توقف، بازیابی و هم‌زمانی چگونه کنترل می‌شود؟ |
| سرویس کانتینری مستقل | برنامه با فرمان و وابستگی مشخص | شبکه، منابع، سلامت و ذخیره پایدار چگونه تعریف می‌شود؟ |
برای نمونه، پردازش یک گزارش پس از ثبت درخواست، بهتر است با صف از وب جدا شود. اما endpoint بررسی مجوز همان درخواست، باید قبل از پذیرش کار پاسخ قطعی بدهد. ابزار استقرار نباید مرز منطقی این دو وظیفه را پنهان کند.
چه بارهایی از Worker دائمی سود می‌برند؟
مصرف پیام از Broker، ساخت Embedding دسته‌ای، تبدیل فایل، Agent دارای زمان‌بندی و همگام‌سازی داده از نمونه‌های رایج‌اند. مزیت Worker، کنترل مستقل ظرفیت و چرخه عمر است. اگر وب‌سرور زیر بار زیاد باشد، می‌توانید ظرفیت پردازش پس‌زمینه را جدا بسنجید؛ البته دیتابیس مشترک همچنان ممکن است گلوگاه هر دو باشد.
در مقابل، نگه‌داشتن یک پردازش همیشه‌روشن برای کاری که روزی چند ثانیه طول می‌کشد ممکن است اقتصادی نباشد. هزینه زمان بیکاری، حداقل منابع و نیاز عملیاتی را کنار هزینه هر اجرا قرار دهید. برای کار زمان‌بندی‌شده کمتکرار، امکانات Job یا Scheduler همان پلتفرم را نیز بررسی کنید.
انتخاب زیرساخت را از قرارداد کار شروع کنید
قبل از مقایسه برندها، یک برگه نیاز بنویسید: حداکثر زمان هر کار، حجم پیام، نرخ ورود در اوج، میزان حافظه، مقصدهای شبکه و سیاست تکرار. مشخص کنید اگر Worker وسط کار خاموش شود چه اتفاقی می‌افتد. اگر پاسخ «نمی‌دانیم» است، مهاجرت به هیچ پلتفرمی بهتنهایی مسئله را حل نمیکند.
برای عملیات خارجی، تضمین دقیق یک‌باره را فرض نکنید. پیام ممکن است پس از قطع اتصال دوباره تحویل شود؛ درگاه، ایمیل یا سیستم مقصد باید با شناسه عملیات و کنترل تکرار هماهنگ شود. وضعیت قابل بازیابی باید بیرون حافظه پردازش ذخیره شود. فایل محلی داخل کانتینر هم بدون قرارداد ماندگاری، آرشیو مطمئن نیست.