طبق تعاریف رسمی ارائه شده برای Message Broker ها، برنامه‌های واسطی هستند که پیام‌ها را طبق پروتکل رسمی پیامی در سمت انتشار‌دهنده دریافت کرده و به فرمت مورد انتظار دریافت‌کننده در اختیار آن‌ها قرار می‌دهد. به عبارتی پیام را به‌نحوی‌که برای انتشاردهنده راحت‌تر است دریافت کرده و به‌صورت موردنظر برای دریافت‌کننده‌های آن پیام‌ها ارسال می‌کنند.
این پیام‌ها چه موقعی باید مورداستفاده قرار بگیرند؟ و جواب خیلی ساده است: زمانی که پردازش و route کردن پیام‌ها اهمیت دارد. به این معنی که شما میزان بسیاری زیادی پیام دارید (به هزاران، میلیون و میلیاردها پیام فکر کنید و در این حالت ارزش دارد تا از یک واسط پیامی به‌عنوان هسته اصلی تمامی پیام‌های خود استفاده کنید تا تمامی سرویس‌های موجود به‌عنوان منبع پیام‌های خود از این رابط پیامی استفاده کنند و تمامی پردازش‌ها و فعالیت‌های مربوطه در این نرم‌افزار صورت بگیرند.
یکی از بهترین نمونه استفاده این تکنولوژی‌ها می‌توان به بهره‌گیری در معماری میکرو سرویس‌ها اشاره کرد در قسمت ارتباطات غیرهم‌زمان در این مقاله نقش message brokerها توضیح داده شده است. Message Brokerها به‌خوبی می‌توانند برای ارتباط غیرهم‌زمان بین سرویس‌ها و اشتراک‌گذاری پیام‌های آن‌ها مورداستفاده قرار بگیرند.

کارگزار پیام چیست و چرا به آنها نیاز داریم؟

برای اینکه دو برنامه با یکدیگر صحبت کنند، ابتدا به یک رابط نیاز داریم. بدون آن، امکان برقراری ارتباط برای آنها وجود نخواهد داشت.که از این پروتکل ها میتوان برای برقرای ارتباط استفاده کرد HTTP، MQTT یا SMTP است.

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

کارگزار پیام یک واسطه است که همه پیام ها از طریق آن ارسال می شوند. بدین ترتیب ما به یک جداسازی اضافی بین فرستنده و گیرنده دست پیدا می کنیم. یک فرستنده پیامی را برای کارگزار پیام ارسال می کند و کارگزار پیام آن را به گیرنده ارسال می کند. یک مزیت کلیدی در اینجا این است که کارگزار پیام نیازی به دانستن مکان consumer در شبکه ندارد.

علاوه بر این، کارگزار پیام به عنوان یک بافر عمل می کند – تا زمانی که مصرف کننده آماده کار شود، پیام ها را نگه می دارد.

تقاوت معماری

Message broker Architectural Difference

Message broker Architectural Difference

هنگام انتخاب Message Broker چه مواردی را باید در نظر گرفت؟

زبان های برنامه نویسی پشتیبانی شده – در حالت ایده آل، باید بروکری را انتخاب کنید که از زبان های مختلف پشتیبانی می کند.
استانداردهای پیام رسانی پشتیبانی شده – آیا کارگزار پیام از استانداردهای مختلفی مانند AMQP و STOMP پشتیبانی می کند یا اختصاصی است؟

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

 

Trade-Offs

هر کارگزاری نوع متفاوتی از مبادله دارد. بنابراین، تأخیر بسیار کم را می توان با پیام های خارج از سفارش، عدم ضمانت تحویل و ذخیره سازی فقط در RAM مرتبط کرد. پیغام‌های ماندگار روی دیسک آن‌ها را به‌طور دائم ذخیره می‌کند، اما احتمالاً تأخیر بیشتری را ایجاد می‌کند. انتخاب کارگزار مناسب بستگی به شرایط دارد.

اگر نمی خواهید پیام ها از بین بروند، باید روی دیسک نوشته شوند، اما باید توجه داشت که سرعت نوشتن روی دیسک بین 100 تا 1000 برابر کندتر از نوشتن روی رم است.

به طور کلی message brokerهای معروفی وجود دارند که برخی از آن‌ها می‌توان به موارد زیر اشاره کرد:

 

  • Apache Kafka
  • RabbitMQ
  • Apache ActiveMQ
  • Kestrel
  • WSO2 Message Broker
  • Azure event hubs