وقتی از ارتباط ناهماهنگ (async) برای میکروسرویس‌ها استفاده میشه، معمولا از یه بروکر پیام استفاده میشه. این بروکر مطمئن میشه که ارتباط بین میکروسرویس‌های مختلف قابل اعتماد و پایدار باشه، پیام‌ها توی سیستم مدیریت و نظارت میشن و پیام‌ها گم نمی‌شن. چندتا بروکر پیام هم وجود داره که می‌تونیم انتخاب کنیم، همشون تو مقیاس و قابلیت‌های داده فرق می‌کنن. توی این وبلاگ سه تا از محبوب‌ترین بروکر های پیام، یعنی RabbitMQ، Kafka و Redis رو با هم مقایسه می‌کنیم.
ارتباط میکروسرویس‌ها: هماهنگ (sync) و ناهماهنگ (async)
دو روش رایج برای میکروسرویس‌ها برای با هم ارتباط برقرار کردن وجود داره: هماهنگ و ناهماهنگ. تو ارتباط هماهنگ، فراخواننده منتظر پاسخ می‌مونه قبل از اینکه پیام بعدی رو بفرسته، و این کار به شکل یه پروتکل REST روی HTTP انجام میشه. اما تو ارتباط ناهماهنگ، پیام‌ها بدون صبر کردن برای جواب ارسال میشن. این روش مناسب سیستم‌های توزیع یافته هست و معمولا برای مدیریت پیام‌ها به یه بروکر پیام نیاز داره.
برای نوع ارتباطی که انتخاب می‌کنیم باید به چند مورد فکر کنیم، مثل اینکه چطور میکروسرویس‌هامونو سازماندهی کردیم، چه زیرساختی داریم، همینطور تاخیر، مقیاس، وابستگی‌ها و هدف ارتباط. ارتباط ناهماهنگ شاید برقرار کردنش پیچیده‌تر باشه و نیاز به اضافه کردن قطعه‌های بیشتری به معماری داشته باشه، ولی مزایای استفاده از ارتباط ناهماهنگ برای میکروسرویس‌ها از معایبش بیشتره.
مزایای ارتباط ناهماهنگ
اولین و مهمترین مزیت ارتباط ناهماهنگ اینه که به تعریف خودش غیرمسدود کننده‌ست. همچنین از نظر مقیاس‌پذیری هم از عملیات هماهنگ بهتر پشتیبانی میکنه. سوم، وقتی میکروسرویس‌ها کرش می‌کنن، مکانیزم‌های ارتباط ناهماهنگ روش‌های مختلف بازیابی ارائه می‌کنن و به طور کلی در کنترل خطاهای مربوط به کرش بهتر عمل می‌کنن. به علاوه، وقتی از بروکر ها به جای پروتکل REST استفاده میشه، سرویس‌هایی که ارتباط دریافت می‌کنن نیازی به شناختن یکدیگر ندارن. حتی میشه سرویس جدیدی رو بعد از اجرای طولانی‌مدت یکی از سرویس‌های قدیمی معرفی کرد، به این معنا که خدانگهداری سرویس‌ها بهتر میشه.
در آخر، وقتی عملیات ناهماهنگ رو انتخاب می‌کنیم، توانایی ایجاد یک بخش مرکزی نظارت، توازن بار یا حتی اجراگر Policy رو در آینده بالا میبره. این قابلیت‌ها بهترین امکانات رو برای انعطاف‌پذیری، مقیاس‌پذیری و امکانات بیشتر توی کد و ساختار سیستم فراهم میکنه.
انتخاب کارگزار پیام مناسب
ارتباط ناهماهنگ معمولاً از طریق یک کارگزار پیام مدیریت میشه. راه‌های دیگری هم وجود دارن، مانند ای‌اس‌ای‌ان‌سی‌او، اما کمی کمتر پیدا میشه و محدودتره.
وقتی در حال انتخاب یک کارگزار برای اجرای عملیات ناهماهنگ هستیم، باید چند نکته را در نظر بگیریم:
مقیاس کارگزار - تعداد پیام‌های ارسالی در ثانیه در سیستم.
پایداری داده - توانایی بازیابی پیام‌ها.
قابلیت مصرف کننده - آیا کارگزار قادر به مدیریت مصرف‌کننده‌های یک به یک و/یا یک به چند هست.
یک به یک:
یک به چند:
ما آخرین و برترین خدمات موجود را بررسی کردیم تا بفهمیم کدام ارائه‌دهنده در این سه دسته بیشترین قدرت رو داره.
مقایسه کارگزارهای پیام مختلف
رابیت‌ام‌کیو (AMQP)
- مقیاس -> بر اساس تنظیمات و منابع، تقریباً حدود 50 هزار پیام در ثانیه.
- پایداری -> هم پیام‌های پایدار و هم پیام‌های موقتی پشتیبانی میشه.
- تعداد مصرف‌کننده‌های یک به یک در مقابل یک به بسیاری -> هر دو.
رابیت‌ام‌کیو در سال 2007 منتشر شد و یکی از اولین کارگزارهای پیام معمولیه که ایجاد شد. این کارگزار متن‌باز هست که پیام‌ها را از طریق روش‌های نقطه به نقطه و انتشار-اشتراکی ارسال میکنه با پیاده‌سازی پروتکل‌های پیشرفته صف‌های پیام (AMQP). همینطور طراحی شده تا از منطق مسیریابی پیچیده پشتیبانی کنه.
رابیت‌ام‌کیو تمام زبان‌های اصلی رو پشتیبانی میکنه، از جمله پایتون، جاوا، .NET، PHP، روبی، جاوااسکریپت، Go، Swift و بیشتر.
همچنین در حالت پایدار، انتظار برخی مشکلات عملکردی رو داشته باشیم.
کافکا
- مقیاس -> تا یک میلیون پیام در ثانیه
- پایداری -> بله.
- تعداد مصرف‌کننده‌های یک به یک در مقابل یک به بسیاری -> فقط یک به چند (عجیبه ، نه؟!).
کافکا توسط Linkedin در سال 2011 برای مدیریت پردازش با سرعت بالا و تاخیر پایین ایجاد شد. به عنوان یک پلتفرم پخش توزیع‌شده، کافکا یک خدمت انتشار-اشتراکی رو تکثیر میکنه. در نتیجه دارای پایداری داده هست و جریان‌های رکوردها رو ذخیره میکنه که اون رو قادر به تبادل پیام‌های با کیفیت میکنه.
کافکا تمام زبان‌های اصلی رو پشتیبانی میکنه، از جمله پایتون، جاوا، C/C++، .NET، PHP، روبی، جاوااسکریپت، Go، Swift و بیشتر.
ردیس
- مقیاس -> تا یک میلیون پیام در ثانیه
- پایداری -> اساساً نه - این یک دیتابیس مموری محور هست
- تعداد مصرف‌کننده‌های یک به یک در مقابل یک به بسیاری -> هر دو.
ردیس یکم با کارگزارهای پیام دیگه متفاوته. در اصل، ردیس یک مخزن داده در حافظه هست که می‌تونه به عنوان یک مخزن کلید-مقدار با عملکرد بالا یا به عنوان یک کارگزار پیام استفاده بشه . یک تفاوت دیگه این هست که ردیس هیچ پایداری ندارد، بلکه حافظه‌اش را در مموری ذخیره میکنه. همچنین برای پردازش داده‌های real-time بسیار مناسبه چون سرعت زیادی داره.
ردیس ابتدا یک به یک و یک به بسیاری نبوده. با این حال، از زمان معرفی امکان انتشار-اشتراکی در ردیس 5.0، قابلیت‌هاش افزایش یافته و یک به چند اضافه شده.
کارگزارهای پیام براساس مورد کاربرد
ما برخی از ویژگی‌های رابیت‌ام‌کیو، کافکا و ردیس را پوشش دادیم. هر سه تای اینها در دسته خود غول هستن، اما همانطور که توضیح داده شد، رفتارهای متفاوتی دارن. در ادامه توصیه ما برای انتخاب کارگزار پیام مناسب بر اساس کاربردهای مختلف اومده.
پیام‌های کوتاه مدت: ردیس
پایگاه داده در حافظه ردیس تقریباً به اندازه‌ای کاملاً مناسب برای کاربردهایی با پیام‌های کوتاه مدت هست که پایداری نیاز ندارن. از آنجایی که سرویس بسیار سریع و قابلیت‌های در حافظه‌ای را فراهم میکنه، ردیس کاندید مناسبی برای پیام‌های بازداری کوتاه هست که پایداری آنقدر مهم نیست و می‌تونیم برخی از از دست دادن هارو تحمل کنیم. با معرفی جریان‌های ردیس در نسخه 5.0، این نیز گزینه‌ای برای موارد کاربرد یک به چند شده که به دلیل محدودیت‌ها و قابلیت‌های قدیمی انتشار-اشتراکی قطعاً نیاز داشت.
مقدار زیادی داده: کافکا
کافکا یک صف توزیع شده با ظرفیت بالاست که برای ذخیره مقدار زیادی داده به مدت طولانی ساخته شده . کافکا برای موارد کاربرد یک به چند که پایداری نیاز داره، ایده‌آله.
مسیریابی پیچیده: رابیت‌ام‌کیو
رابیت‌ام‌کیو یک کارگزار قدیمی ولی پخته با بسیاری از ویژگی‌ها و قابلیت‌هایی هست که مسیریابی پیچیده رو پشتیبانی میکنه. حتی در صورتی که نرخ مورد نیاز بالا نباشه (بیش از چند ده هزار پیام در ثانیه)، رابیت‌ام‌کیو حمایت از ارتباط مسیریابی پیچیده رو انجام می‌ده.
پشتیبانی از استک نرم‌افزاری خودتون رو در نظر بگیرید
آخرین نکته، توجه به استک نرم‌افزاری کنونی شماست. اگر به دنبال یک فرآیند یکپارچه‌تر ادغام هستین و نمی‌خواهید کارگزارهای مختلفی رو در یک استک داشته باشیذ، شاید به تمایل به کار با یک کارگزار که از پیش توسط استک شما پشتیبانی میشه، باشید.
برای مثال، اگر در سیستم خودتون از Celery برای صف کار در بالای رابیت‌ام‌کیو استفاده می‌کنید، بهاره با رابیت‌ام‌کیو یا ردیس کار کنید به جای کافکا که پشتیبانی نمی‌شه و نیاز به تغییرات گسترده داره.
با تشکر فراوان ، معین معین نیا
