کارگزار ها یا واسط های پیام | Message Brokers

منبع تصویر : unsplash.comکارگزار ها یا واسط های پیام ( Message Brokers ) یک تکنولوژی و فناوری ارتباطی میان اپلیکیشن ها هستند که به ایجاد مکانیزم ادغام سازی و یکپارچه سازی مشترک برای پشتیبانی از معماری های که ابری ( cloud native )، بر اساس میکروسرویس ها ، بدون سرور ( Serverless ) و هیبرید هستند کمک میکنند . کارگزار ها یا واسط های پیام چه هستند ؟ یک واسط یا کارگزار پیام ( Message Broker ) ، نرم افزاری است که اپلیکیشن ها ، سیستم ها و سرویس ها را قادر می سازد تا با یک دیگر در ارتباط باشند و اطلاعات مبادله کنند . کارگزار پیام ، این کار را از طریق ترجمه کردن message ها بین پروتکل های رسمی پیام انجام می دهد . این کار به سرویس های مستقل اجازه می دهد تا به صورت مستقیم بایکدیگر " گفتگو" کنند . حتی اگر به زبان های مختلف نوشته شده باشند یا اینکه در پلتفرم های متفاوتی پیاده سازی شده باشند . واسط های پیام ( Message Brokers ) ، ماژول های نرم افزاری هستند که از جمله راه حل های میان افزار پیامرسانی ( messaging middleware ) یا میان افزار پیام گرا ( message-oriented middleware - MOM ) هستند . این نوع میان افزار ( middleware) ابزار های استانداردی را برای مدیریت جریان داده ها ( Data Flow ) میان قسمت های یک اپلیکیشن فراهم میکند و در اختیار توسعه دهندگان قرار میدهد تا آن ها بتوانند بر روی منطق اصلی و Core Logic اپلیکیشن تمرکز داشته باشند . این واسط ها ، می توانند به عنوان یک لایه ارتباطی توزیع شده عمل کنند که اجازه میدهد اپلیکیشن های موجود در چندین پلتفرم ، به صورت داخلی بایکدیگر ارتباط برقرار کنند . واسط ها یا کارگزار های پیام ( Message Brokers ) می توانند پیام ها را اعتبارسنجی ( validate ) ، ذخیره ، مسیر یابی کنند و به مقصد مناسب و مورد نظر ارسال کنند . همچنین به عنوان واسط میان اپلیکیشن های دیگر عمل می کنند و به فرستنده ها این امکان را می دهند که بدون اینکه بدانند گیرنده ها در کجا هستند ، آیا فعال هستند یا نه ، یا تعداد آن ها چقدر است ، پیام هایشان را ارسال کنند . این کار واسط ها یا کارگزار های پیام ، امر جداسازی فرایند ها و سرویس ها در سیستم ها را تسهیل و آسان می کند .واسط ها یا کارگزار های پیام ( Message Brokers ) ، برای ذخیره مطمئن پیام ها و تضمین تحویل پیام ها ، معمولا به زیرساختی به نام صف پیام یا Message Queue متکی هستند که پیام ها را تا زمانی که اپلیکیشن مصرف کننده بتواند آن ها را پردازش کند ، ذخیره و مرتب سازی سازی می کند . در یک صف پیام ، پیام ها دقیقا به همان ترتیبی که ارسال شده اند ، ذخیره می شوند و تا زمانی که دریافت پیام تایید شود ، در صف باقی خواهند ماند .معماری RabbitMQ که یکی از Message Broker های محبوب استپیام رسانی ناهمزمان ( Asynchronous Messaging ) ، یکی از انواع ارتباط میان اپلیکیشن ها است که واسط های پیام ( Message Brokers ) آن را ممکن می سازند . پیام رسانی ناهمزمان ، جلوی از دست دادن داده های ارزشمند را می گیرد و این امکان را فراهم می سازد که حتی در مواردی که مشکلات اتصال و تاخیر که در شبکه های عمومی رایج است ، رخ دهد ، سیستم ها به عملکرد خود ادامه دهند . پیام رسانی ناهمزمان تضمین می کند که پیام ها فقط و فقط یک بار با ترتیبی صحیح نسبت به پیام های دیگر ، تحویل داده می شوند.واسط ها یا کارگزار های پیام ممکن است در بردارنده مدیران صف ( Queue Managers ) باشند تا تعاملات و ارتباط بین صف های پیام متعدد ، همچنین سرویس هایی که مسیریابی داده ها ، ترجمه پیام ها ، پایداری و عملکرد های مدیریت وضعیت کلاینت ها را فراهم میکنند ، را انجام دهند .مدل های کارگزار یا واسط پیام ( Message Broker Models )واسط ها یا کارگزار های پیام ( Message Brokers ) ، دو الگوی اصلی توزیع پیام یا استایل پیام دادن را ارائه میدهند :پیام رسانی نقطه به نقطه ( Point-to-Point Messaging ) : این الگوی توزیع پیام در صف های پیام با یک رابطه یک به یک میان فرستنده و گیرنده پیام ، مورد استفاده قرار می گیرد . هر پیام موجود در صف فقط برای یک گیرنده ارسال می شود و فقط یک بار مورد مصرف واقع می شود . پیام رسانی نقطه به نقطه زمانی مورد استفاده قرار میگیرد که یک پیام فقط باید یک بار عمل کند . نمونه هایی از استفاده از این مدل ، میتوان پرداخت حقوق و پردازش تراکنش های مالی را مثال زد . در این سیستم ها هم فرستنده و هم گیرنده نیاز به این ضمانت دارند که هر پرداختی فقط و فقط یک بار ارسال شود .پیام رسانی انتشار / اشتراک ( Publish / Subscribe Messaging ) : در این الگوی توزیع پیام ، که معمولا تحت عنوان "pub/sub" مطرح می شود ، تولید کننده هر پیام ، آن پیام را در یک topic منتشر و publish می کند و چندین مصرف کننده پیام به موضوعاتی که میخواهند پیام های آن ها را دریافت کنند subscribe می کنند و درواقع مشترک آن topic می شوند . همه پیام های منتشر شده در یک topic یا موضوع ، به همه اپلیکیشن هایی که مشترک و subscribed آن موضوع یا topic هستند ، توزیع می شود . این روش توزیع به سبک Broadcast یا پخش می باشد که در آن یک رابطه یک به چند ( One to Many ) بین تولید کننده پیام و مصرف کنندگان آن پیام وجود دارد .برای مثال یک شرکت هواپیمایی قرار است که بروزرسانی هایی را در مورد زمان فرود یا وضعیت تاخیر پرواز های خود منتشر کند ، چندین طرف میتوانند از این اطلاعات استفاده کنند : خدمه روی زمین که نگهداری و سوخت گیری هواپیما را بر عهده دارند - حمل کننده های چمدان ها - مهماندار ها و خلبانان سفر بعدی هواپیما - اپراتور های نمایشگر های موجود در فرودگاه که مردم را مطلع می کنند. استایل پیام رسانی pub/sub برای چنین سناریو و شرایطی می تواند مناسب باشد . کارگزار های پیام در معماری های ابری ( Cloud Architectures )اپلیکیشن های native ابری ، برای استفاده از مزایای رایانش ابری ، از جمله انعطاف پذیری و مقیاس پذیری ( Scalability ) و گسترش سریع ، ساخته شده اند . این اپلیکیشن ها از قسمت های کوچک ، گسسته و با قابلیت استفاده مجدد ساخته شده اند که میکروسرویس ها نامیده می شوند . هر میکروسرویس میتواند مستقل از سایر میکروسرویس ها ، گسترش یابد و اجرا شود . این به این معنی است که هر کدام از این میکروسرویس ها میتوانند بدون تاثیر بر سرویس های دیگر موجود در سیستم ، بروزرسانی و توسعه و راه اندازی مجدد شود . میکروسرویس ها که به طور معمول در کانتینر ها ( Containers ) بسته بندی می شوند ، باهم کار می کنند تا یک اپلیکیشن کامل را تشکیل دهند . ولی هر کدام از این میکروسرویس ها دارای Stack و فناوری خاص خود هستند ، که شامل پایگاه داده و مدل داده که ممکن است متفاوت از بقیه میکروسرویس ها باشد .میکروسرویس ها باید ابزاری برای برقراری ارتباط با یکدگیر را در اختیار داشته باشند تا بتوانند به صورت هماهنگ با یکدیگر عمل کنند . واسط ها یا کارگزار های پیام ( Message Brokers ) ، یکی از مکانیسم هایی هستند که میکروسرویس ها استفاده میکنند تا پایه و اساس و ستون های این ارتباط مشترک را ایجاد کنند . کارگزار های پیام ، معمولا برای مدیریت ارتباط بین سیستم های داخلی ( on-premises ) و قسمت ها و کامپوننت های ابری در محیط های هیبرید ابری مورد استفاده قرار می گیرند . استفاده از کارگزار پیام یا همان Message Broker ، کنترل بیشتری بر ارتباط میان سرویسی ایجاد میکند و تضمین میکند که داده ها به طور امن و قابل اعتماد و درست و کارآمد بیت قسمت های یک اپلیکیشن ارسال می شوند. کارگزار های پیام ، میتوانند نقش مشابهی را در یکپارچه سازی محیط های چندابری ( MultiCloud ) ایفا کنند و ارتباط بین Workload ها و زمان های اجرا ( Runtimes ) را در پلتفرم های مختلف امکان پذیر کنند . کارگزار های پیام همچنین برای استفاده در پردازش های Serverless یا همان Serverless Computing مناسب هستند که در آن ، سرویس های میزبانی ابری مفرد و جداگانه ، بر اساس تقاضا ( on-demand ) و بر اساس درخواست ( per-request ) اجرا می شوند . کارگزار های پیام در مقایسه با API ها ( Message Brokers vs APIs )از REST API ها معمولا برای ارتباط بین میکروسرویس ها مورد استفاده قرار می گیرند . عبارت زیر Representational State Transferیا به اختصار REST یکسری مفاهیم و اصول را بیان و تعریف میکند که توسعه دهندگان می توانند به هنگام ساخت وب سرویس های خود از آن ها پیروی کنند . هر سرویسی که به این مفاهیم و اصول پایبند باشد ، می تواند به کمک یکسری از اپراتور ها و درخواست های مشترک Stateless ، با یکدگیر ارتباط برقرار کند . عبارتApplication Programming Interfaceیا به اختصار API ، نشان دهنده کد پایه ای است که اگر با قوانین REST مطابقت داشته باشد ، به سرویس ها این اجازه را می دهد که با یکدیگر صحبت کنند . REST API ها از Hypertext Transfer Protocol یا HTTP استفاده می کنند . چون HTTP پروتکل استاندارد انتقال اینترنت عمومی است ، REST API ها به طور گسترده شناخته شده هستند و زیاد مورد استفاده قرار می گیرند و به طور گسترده ای قابل تعامل هستند . پروتکل HTTP یک پروتکل request/response می باشد . با این حال ، بهترین شرایطی که برای استفاده از این پروتکل وجود دارد شرایطی است که یک request/reply همزمان ( Synchronous ) را نیاز دارد . این به این معنا است که سرویس هایی که Request هایی را از طریق REST APIs ایجاد می کنند ، باید به گونه ای طراحی شوند که انتظار یک پاسخ سریع و فوری را داشته باشند . اگر کلاینت دریافت کننده پاسخ ، قطع ( down ) باشد ، سرویس ارسال تا زمانی که در انتظار پاسخ است مسدود می شود . مدیریت خطا ( Error Handling ) باید در هر دو سرویس نوشته و تعبیه شود . کارگزار های پیام ( Message Brokers ) ارتباط ناهمزمان یا asynchronous را بین سرویس ها فراهم می کنند تا سرویس ارسال کننده ، منتظر پاسخ سرویس گیرنده نباشد . این کار باعث بهبود تلرانس ( تحمل ) خطا و انعطاف پذیری سیستم ها می شود . همچنین استفاده از کارگزار های پیام ، گسترش سیستم ها را آسان تر می کند ، زیرا یک الگوی پیام رسانی pub/sub ، به راحتی از تغییر تعداد سرویس ها پشتیبانی می کند . کارگزار های پیام همچنین وضعیت مصرف کنندگان را نیز پیگیری میکنند . کارگزار های پیام در مقایسه با پلتفرم های Event Streamingکارگزار های پیام ( Message Brokers ) می توانند از دو یا تعداد بیشتری الگوی پیام رسانی از جمله صف های پیام ( Message Queues ) و pub/sub پشتیبانی کنند ، در حالی که پلتفرم های Event Streaming یا پلتفرم های جریان رویداد فقط از استایل توزیع پیام pub/sub پشتیبانی می کنند . این پلتفرم ها که برای استفاده با حجم بالایی از پیام ها طراحی شده اند ، به آسانی قابل گسترش هستند . آن ها می توانند استریم های ریکورد ها را در دسته هایی به نام topic مرتب کنند و آن ها را برای مدت زمانی که از پیش تعیین شده ، ذخیره کنند . بر خلاف کارگزار های پیام ، این پلتفرم ها نمیتوانند تحویل پیام را تضمین کنند یا ردیابی کنند که مشتری های کدام پیام ها را دریافت کرده اند .پلتفرم های Event Streaming ، گسترش و Scalability بیشتری را نسبت به کارگزار های پیام ارائه می دهند . اما ویژگی های کمتری ارائه میدهند که تلرانس خطا ( مانند ارسال مجدد پیام ) و قابلیت های مسیریابی و روتینگ و صف بندی پیام ها با محدودیت بیشتر را تضمین می کنند .موارد استفاده از کارگزار های پیام ( Message Brokers )پیاده سازی Message Broker ها می تواند طیف عظیمی از نیاز های بیزینسی را در صنایع و محیط های سازمانی گوناگون برطرف کند . Message Broker ها در هر زمانی و مکانی که به ارتباط قابل اعتماد و تحویل با اطمینان پیام بین اپلیکیشن ها نیاز باشد ، مفید هستند . معمولا به روش های زیر ، Message Broker ها به کار گرفته می شوند :تراکنش های مالی و پردازش پرداخت ها : بسیار مهم و حیاتی است که مطمئن باشیم پرداخت ها فقط و فقط یک بار ارسال می شوند . استفاده از Message Broker ها برای رسیدگی به داده های این تراکنش ها تضمین می کند که اطلاعات پرداخت ، نه از بین می رود و نه به طور تصادفی تکرار می شود ، تایید دریافت را فراهم می کند و به سیستم ها اجازه می دهد به طور قابل اعتمادی حتی زمانی که شبکه های واسطه از کار افتاده باشند ، ارتباط برقرار کنند .پردازش و انجام سفارشات E-Commerce : اگر بیزینس آنلاین انجام می دهید ، قدرت و شهرت برند شما به میزان قابلیت اطمینان به سایت و پلتفرم شما بستگی دارد . قابلیت های کارگزار های پیام برای افزایش تلرانس و تحمل خطا و تضمین اینکه پیام ها یکبار و فقط یکبار مصرف می شوند ، آن ها را به انتخابی طبیعی برای استفاده در هنگام پردازش سفارش های آنلاین تبدیل می کند .حفاظت از داده های بسیار مهم و حساس در حالت استراحت و جابجایی : اگر صنعت شما به شدت تحت نظارت است یا کسب و کار شما با خطرات امنیتی قابل توجهی مواجه است ، می توانید از یک راه حل پیامرسانی و messaging با قابلیت رمزگذاری سرتاسر ( end-to-end ) استفاده کنید . نمونه های Message Brokers : محبوب ترین کارگزار ها یا واسط های پیام عبارتند از :RabbitMQ , Apache Kafka , Redis , Amazon SQS , Amazon SNSهمه مواردی که ذکر شد جزو ابزار های خیلی عالی و برتر در این زمینه هستند و در مواقعی که لود کار پایین است تفاوتی را بین آن ها از نظر پرفرومنس احساس نمی کنید . ولی زمانی که در مقیاس های عملیاتی گسترده و پیشرفته کار کنیم ، هر کدام از این ها ، به طور متفاوتی کار میکنند .نتیجه گیریاپلیکیشن های مدرن ، روز به روز پیچیده تر می شوند . عملیات های مصرف کننده زمانی و منابعی ، ارتباط بین چندین سرویس ، پردازش داده های زیاد و … فقط تعدادی از مشکلاتی هستند که توسعه دهنده ها با آن ها دست و پنجه نرم می کنند . برای رفع این مشکلات میتوانیم از Message Broker ها استفاده کنیم که بسیاری از مشکلات مطرح شده را تا حد زیادی رفع می کنند و در صرفه جویی منابع و زمان کمک بسیاری به ما میکنند . منبع :ibm.com/cloud