Redis ، Kafka یا RabbitMQ: کدام کارگزار پیام MicroServices را انتخاب کنید؟

هنگام استفاده از ارتباطات ناهمزمان برای میکروسرویس ، استفاده از یک کارگزار پیام معمول است. یک کارگزار تضمین می کند که ارتباط بین میکروسرویس های مختلف قابل اعتماد و پایدار است ، که پیام ها در سیستم مدیریت و کنترل می شوند و پیام ها از بین نمی روند. چند کارگزار پیام وجود دارد که می توانید از آن انتخاب کنید ، در مقیاس و قابلیت های داده متفاوت است. این پست وبلاگ سه کارگزار محبوب را با هم مقایسه می کند: RabbitMQ ، Kafka و Redis.

اما اول ، بیایید در مورد ارتباطات میکروسرویس بیاموزیم.

ارتباطات میکروسرویس: همزمان و ناهمزمان

دو روش مشترک وجود دارد که میکروسرویس با یکدیگر ارتباط برقرار می کنند: همزمان و ناهمزمان. در یک ارتباط همزمان ، تماس گیرنده قبل از ارسال پیام بعدی منتظر پاسخ است و به عنوان یک پروتکل REST در بالای HTTP فعالیت می کند. در مقابل ، در یک ارتباط ناهمزمان پیام ها بدون انتظار برای پاسخ ارسال می شوند. این برای سیستم های توزیع شده مناسب است و معمولاً برای مدیریت پیام ها به یک کارگزار پیام نیاز دارد.

نوع ارتباطی که شما انتخاب می کنید باید پارامترهای مختلفی را در نظر بگیرد ، مانند نحوه ساختاری از خدمات میکروسکوپ خود ، چه زیرساختی در محل ، تأخیر ، مقیاس ، وابستگی و هدف ارتباطات وجود دارد. ارتباطات ناهمزمان ممکن است برای ایجاد پیچیده تر باشد و نیاز به افزودن اجزای بیشتر برای پشته دارد ، اما مزایای استفاده از ارتباطات ناهمزمان برای خدمات میکروسرویس از منفی بیشتر است.

مزایای ارتباطات ناهمزمان چیست؟

اول و مهمتر از همه ، ارتباطات ناهمزمان با تعریف غیر مسدود کننده است. همچنین از مقیاس بهتر از عملیات همزمان پشتیبانی می کند. سوم ، در صورت خراب شدن میکروسرویس ، مکانیسم های ارتباطی ناهمزمان تکنیک های مختلف بازیابی را ارائه می دهند و به طور کلی در رسیدگی به خطاهای مربوط به تصادف بهتر است. علاوه بر این ، هنگام استفاده از کارگزاران به جای پروتکل REST ، خدمات دریافت کننده ارتباطات واقعاً نیازی به شناختن یکدیگر ندارند. حتی پس از مدتهاست که مدت طولانی در حال اجرا است ، می توان یک سرویس جدید را معرفی کرد ، یعنی خدمات جداسازی بهتر.

سرانجام ، هنگام انتخاب عملیات ناهمزمان ، توانایی خود را در ایجاد یک کشف مرکزی ، نظارت ، تعادل بار یا حتی مجری سیاست در آینده افزایش می دهید. این امر توانایی های انعطاف پذیری ، مقیاس پذیری و قابلیت های بیشتر در کد و ساختمان سیستم را در اختیار شما قرار می دهد.

انتخاب کارگزار پیام مناسب

ارتباطات ناهمزمان معمولاً از طریق یک کارگزار پیام انجام می شود. روش های دیگری نیز مانند Aysncio وجود دارد ، اما آنها کمیاب تر و محدود هستند.

هنگام انتخاب یک کارگزار برای اجرای عملیات ناهمزمان ، باید چند مورد را در نظر بگیرید:

1. مقیاس کارگزار - تعداد پیام های ارسال شده در ثانیه در سیستم.
2. پایداری داده ها - امکان بازیابی پیام ها.
3. قابلیت مصرف کننده-خواه کارگزار قادر به مدیریت مصرف کنندگان یک به یک و/یا یک به یک باشد.

ما جدیدترین و بزرگترین خدمات موجود در آنجا را بررسی کردیم تا دریابیم که ارائه دهنده در این سه دسته قوی ترین است.

مقایسه کارگزاران پیام مختلف

RabbitMQ (AMQP)

مقیاس: بر اساس پیکربندی و منابع ، Ballpark در اینجا حدود 50k msg در ثانیه است.

پایداری: هر دو پیام مداوم و گذرا پشتیبانی می شوند.

یک به یک در مقابل مصرف کنندگان یک به یک: هر دو.

RabbitMQ در سال 2007 منتشر شد و یکی از اولین کارگزاران پیام مشترک است که ایجاد شده است. این یک منبع باز است که با اجرای پروتکل های صف بندی پیام پیشرفته (AMQP) پیام ها را از طریق روش های نقطه به نقطه و میخانه ارائه می دهد. این برای پشتیبانی از منطق پیچیده مسیریابی طراحی شده است.

برخی از خدمات مدیریت شده وجود دارد که به شما امکان می دهد از آن به عنوان SaaS استفاده کنید اما این بخشی از پشته ارائه دهنده Cloud Major Cloud نیست. RabbitMQ از تمام زبانهای اصلی ، از جمله پایتون ، جاوا ، .net ، PHP ، روبی ، جاوا اسکریپت ، برو ، سوئیفت و موارد دیگر پشتیبانی می کند.

انتظار برخی از مشکلات عملکرد را در حالت مداوم داشته باشید.

کافکا

مقیاس: می تواند به میلیون ها پیام در ثانیه ارسال کند.

پایداری: بله.

یک به یک در مقابل مصرف کنندگان یک به یک: فقط یک به یک (به نظر می رسد در نگاه اول عجیب است ، درست است؟).

کافکا در سال 2011 توسط LinkedIn ایجاد شد تا بتواند پردازش با تأخیر کم و پایین را انجام دهد. به عنوان یک پلت فرم پخش توزیع شده ، کافکا یک سرویس انتشار منتشر می کند. این داده ها پایدار است و جریان سوابق را که قادر به تبادل پیام های با کیفیت هستند ، ذخیره می کند.

کافکا SaaS را در لاجورد ، AWS و تلاقی مدیریت کرده است. آنها همه سازندگان و مشارکت کنندگان اصلی پروژه کافکا هستند. کافکا از تمام زبانهای اصلی ، از جمله پایتون ، جاوا ، C/C ++ ، Clojure ، .net ، PHP ، Ruby ، JavaScript ، Go ، Swift و موارد دیگر پشتیبانی می کند.

مجدداً

مقیاس: می تواند حداکثر یک میلیون پیام در ثانیه ارسال کند.

پایداری: اساساً ، نه-این یک داده در حافظه است.

یک به یک در مقابل مصرف کنندگان یک به یک: هر دو.

Redis کمی متفاوت از سایر کارگزاران پیام است. Redis در هسته خود یک ذخیره سازی داده در حافظه است که می تواند به عنوان یک ذخیره سازی با ارزش کلیدی با کارایی بالا یا به عنوان یک واسطه پیام مورد استفاده قرار گیرد. تفاوت دیگر این است که Redis هیچ ماندگاری ندارد بلکه حافظه خود را در یک Disk/DB می ریزد. همچنین برای پردازش داده ها در زمان واقعی عالی است.

در اصل، ردیس یک به یک و یک به چند نبود. با این حال، از زمانی که Redis 5. 0 pub-sub را معرفی کرد، قابلیت ها افزایش یافت و یک به چند به یک گزینه واقعی تبدیل شد.

کارگزاران پیام در هر مورد استفاده

ما برخی از ویژگی های RabbitMQ، Kafka و Redis را پوشش دادیم. هر سه در دسته خود جانورانی هستند، اما همانطور که توضیح داده شد، کاملاً متفاوت عمل می کنند. در اینجا توصیه ما برای کارگزار پیام مناسب برای استفاده با توجه به موارد مختلف است.

پیام های کوتاه مدت: Redis

پایگاه داده درون حافظه Redis تقریباً برای موارد استفاده با پیام های کوتاه مدت که در آن نیازی به تداوم نیست، مناسب است. از آنجایی که خدمات بسیار سریع و قابلیت های درون حافظه را ارائه می کند، Redis کاندیدای مناسبی برای پیام های نگهداری کوتاه است که در آن ماندگاری چندان مهم نیست و می توانید مقداری از دست دادن را تحمل کنید. با انتشار استریم های ردیس در نسخه 5. 0، همچنین کاندیدایی برای موارد استفاده یک به چند است که به دلیل محدودیت ها و قابلیت های قدیمی میخانه-زیر قطعاً مورد نیاز بود.

مقادیر زیاد داده: کافکا

کافکا یک صف توزیع شده با توان عملیاتی بالا است که برای ذخیره مقدار زیادی داده برای مدت زمان طولانی ساخته شده است. کافکا برای موارد استفاده از یک تا چند مورد که در آن تداوم لازم است ایده آل است.

مسیریابی پیچیده: RabbitMQ

RabbitMQ یک کارگزار قدیمی و در عین حال بالغ با ویژگی ها و قابلیت های زیادی است که از مسیریابی پیچیده پشتیبانی می کند. حتی زمانی که نرخ مورد نیاز بالا نباشد (بیش از چند ده هزار msg/sec) از ارتباطات مسیریابی پیچیده پشتیبانی می کند.

پشته نرم افزار خود را در نظر بگیرید

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

به عنوان مثال، اگر از Celery for Task Queue در سیستم خود در بالای RabbitMQ استفاده می کنید، انگیزه ای برای کار با RabbitMQ یا Redis خواهید داشت که برخلاف کافکا که پشتیبانی نمی شود و نیاز به بازنویسی دارد.

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