صف پیام مدیریت‌شده، معماری رویدادمحور

الگوهای زیر رایج‌ترین دلیل استفاده از broker پیام در پروژه‌های ایرانی است:

RabbitMQ قدیمی‌ترین و شناخته‌شده‌ترین broker متن‌باز است و تقریباً برای هر زبان برنامه‌نویسی کتابخانهٔ پایدار دارد. مفهوم exchange در RabbitMQ اجازه می‌دهد پیام را بر اساس کلید یا الگو به صف‌های مختلف بفرستید. اگر فریم‌ورک شما (مثل Celery یا صف Laravel) از پیش با RabbitMQ کار می‌کند، انتخاب طبیعی همین است.

NATS یک سرور پیام‌رسان سبک است که به‌صورت یک فایل اجرایی واحد اجرا می‌شود و منابع کمی مصرف می‌کند. در حالت پایه، پیام‌ها فقط به مشترکانی می‌رسند که همان لحظه وصل‌اند؛ JetStream که در instance‌های ما فعال است، ذخیرهٔ پیام روی دیسک، پخش مجدد و مصرف‌کنندهٔ ماندگار را اضافه می‌کند.

در RabbitMQ پلاگین رابط مدیریتی فعال می‌شود، کاربری به نام admin با رمز تصادفی ۲۴ کاراکتری و برچسب administrator ساخته می‌شود و دسترسی کامل روی vhost پیش‌فرض (/) می‌گیرد. حساب پیش‌فرض guest حذف می‌شود تا هیچ ورود بدون رمزی باقی نماند.

در NATS نسخهٔ ۲.۱۰.۲۷ به‌صورت سرویس سیستمی نصب می‌شود، JetStream با محل ذخیره روی دیسک همان سرور فعال است و ورود فقط با کاربر admin و رمز تصادفی ممکن است. endpoint پایش NATS روی پورت ۸۲۲۲ برای مشاهدهٔ وضعیت سرور فعال است.

برای هر دو موتور، سرور به‌صورت اختصاصی به همان broker تعلق دارد و منابعی با سرویس دیگری تقسیم نمی‌شود. اندازهٔ سرور را هنگام ساخت انتخاب می‌کنید و رمز عبور در پنل به‌صورت رمزنگاری‌شده نگه‌داری می‌شود.

هزینه هر ساعت از کیف پول کسر می‌شود و شامل دو بخش است: هزینهٔ سرور اختصاصی با اندازهٔ انتخابی و هزینهٔ ثابت مدیریت. قیمت برای RabbitMQ و NATS یکسان است. معادل ماهانه بر مبنای ۷۳۰ ساعت محاسبه شده و فقط برای مقایسه است.

برای محیط توسعه و بیشتر صف‌های کاری کوچک اندازهٔ mini کافی است. اگر پیام‌ها بزرگ‌اند، صف‌ها مدتی پر می‌مانند یا تعداد اتصال‌ها زیاد است، standard یا plus حافظهٔ بیشتری در اختیار broker می‌گذارد. برای برآورد هزینهٔ کل پروژه از ماشین‌حساب هزینه استفاده کنید.

ساخت broker کاملاً از پنل انجام می‌شود:

خود broker فقط ابزار را فراهم می‌کند و تضمین تحویل به نحوهٔ تعریف صف و کد شما بستگی دارد. در RabbitMQ سه کار را انجام دهید: صف را durable تعریف کنید، پیام را با حالت persistent بفرستید و در مصرف‌کننده ack دستی را فقط پس از پایان موفق کار بفرستید. با publisher confirm هم تولیدکننده مطمئن می‌شود پیام به broker رسیده است.

برای پیام‌هایی که بارها پردازششان شکست می‌خورد، روی صف یک dead-letter exchange تعریف کنید تا پیام‌های ردشده به صف جداگانه‌ای بروند و بعداً بررسی شوند. تلاش مجدد با تأخیر را معمولاً با ترکیب TTL و dead-letter یا در خود کتابخانهٔ کلاینت پیاده می‌کنند؛ این‌ها پیکربندی سمت شماست و به‌صورت پیش‌فرض ساخته نمی‌شوند.

در NATS، پیام‌های معمولی ذخیره نمی‌شوند؛ اگر مصرف‌کننده‌ای وصل نباشد پیام از دست می‌رود. برای پیام‌های مهم یک stream در JetStream بسازید و مصرف‌کنندهٔ ماندگار (durable consumer) با ack تعریف کنید تا پیام‌ها روی دیسک بمانند و پس از اتصال دوباره تحویل شوند.

ورود به هر دو موتور فقط با نام کاربری و رمز امکان‌پذیر است و حساب پیش‌فرض بدون رمز وجود ندارد. رمز admin به‌صورت تصادفی ساخته می‌شود و در پنل رمزنگاری‌شده نگه‌داری می‌شود. اتصال فعلاً بدون TLS است، پس بهتر است سرویس‌هایی که به broker وصل می‌شوند در همان دیتاسنتر و روی سرورهای ابری ایران‌کلاد باشند.

در RabbitMQ با کاربر admin می‌توانید برای هر سرویس کاربر جداگانه با دسترسی محدود به یک vhost بسازید؛ اگر رمز یک سرویس لو برود، فقط همان بخش در خطر است. در NATS یک کاربر واحد وجود دارد و تفکیک دسترسی باید در سطح نام‌گذاری subject‌ها و کد انجام شود. برای بررسی دسترسی پورت از سرور خودتان از ابزار بررسی پورت استفاده کنید.

مهم‌ترین شاخص در هر صف پیام، تعداد پیام‌های در انتظار است. اگر این عدد مدام بالا می‌رود یعنی مصرف‌کننده‌ها کندتر از تولیدکننده‌ها کار می‌کنند و باید worker بیشتری اضافه کنید. در RabbitMQ رابط مدیریتی تعداد پیام هر صف، نرخ ورود و خروج و تعداد مصرف‌کننده را نشان می‌دهد.

در NATS‏، endpoint پایش HTTP اطلاعاتی مثل تعداد اتصال‌ها، حجم پیام‌ها و وضعیت JetStream را به‌صورت JSON برمی‌گرداند که می‌توانید آن را به Prometheus و Grafana روی سرور خودتان وصل کنید. برای هشدار ساده هم ابزارهایی مثل Uptime Kuma کافی‌اند.

مهاجرت صف پیام معمولاً با انتقال فایل انجام نمی‌شود بلکه با جابه‌جایی تدریجی ترافیک. ابتدا صف‌ها، exchange‌ها و کاربران را روی instance جدید تعریف کنید؛ در RabbitMQ می‌توانید تعریف‌ها را از رابط مدیریتی سرور قدیم به‌صورت فایل JSON خروجی بگیرید و در سرور جدید وارد کنید.

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

هر instance یک broker تک‌نودی است؛ کلاستر، صف‌های تکثیرشده و failover خودکار ارائه نمی‌شود. بکاپ خودکار برای پیام‌ها و تعریف صف‌ها وجود ندارد، اتصال TLS فعلاً فعال نیست، Kafka در فهرست موتورها نیست و تغییر اندازهٔ instance پس از ساخت از پنل ممکن نیست.

برای بیشتر صف‌های کاری و رویدادهای داخلی یک اپلیکیشن، این ساختار کافی و کم‌دردسر است. اگر فقط به یک صف ساده کنار cache نیاز دارید، Redis مدیریت‌شده هم با کتابخانه‌هایی مثل BullMQ و Sidekiq کار می‌کند؛ و اگر به چند نود و کنترل کامل نیاز دارید، کلاستر اختصاصی را بررسی کنید.