معماری message queue

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

پارادایم صف مشابه الگوی صادرکننده - امضا کننده است و معمولاً بخشی از یک سیستم میان افزار پیام محور بزرگتر است. اکثر سیستم‌های پیام‌رسان از دو مدل‌ الگوی صادرکننده - امضا کننده و مدل‌های الگوی صف پیام در رابط خود پشتیبانی می‌کنند. به عنوان مثال سرویس پیام جاوا (JMS) یک نمونه از آن است.

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

بسیاری از پیاده سازی های صف پیام به صورت داخلی در یک سیستم عامل یا در یک برنامه کاربردی عمل می‌کنند که به طور خاص برای اهداف آن سیستم هستند. در پیاده سازی‌های دیگر امکان پیام رسانی میان سیستم های مختلف کامپیوتری، اتصال بالقوه برنامه های کاربردی و سیستم عامل های مختلف فراهم می‌شود. سیستم‌های صف پیام معمولاً قابلیت انعطاف‌پذیری به سیستم می‌دهند تا اطمینان حاصل شود پیام‌ها در صورت خرابی سیستم از دست نروند. نمونه‌هایی از پیاده‌سازی تجاری این نوع نرم‌افزار صف‌بندی پیام شامل IBM MQ (سری MQ سابق) و Oracle Advanced Queuing (AQ) است. یک استاندارد در زبان جاوا به نام Java Message Service وجود دارد که چندین نوع پیاده سازی اختصاصی و رایگان دارد.

سیستم‌ عامل‌های بلادرنگ (RTOS) مانند VxWorks و QNX استفاده از صف پیام به‌عنوان مکانیسم ارتباطی اولیه بین فرآیندی یا میان تردها ترغیب می‌کند و می تواند یکپارچگی ارسال پیام و زمان بندی CPU را ارائه دهد. نمونه‌های اولیه سیستم‌ عامل‌های بلادرنگ ​​تجاری که مبنای صف پیام را برای ارتباطات بین تردها ترغیب می‌کردند نیز شامل VRTX و pSOS+ هستند که هر دو در اوایل دهه 1980 ظهور کرده اند. زبان برنامه نویسی Erlang از فرآیندها برای ایجاد همزمانی و موازی سازی استفاده می‌کند. این فرآیندها به صورت ناهمزمان با استفاده از صف پیام ارتباط برقرار می‌کنند.

نرم افزار صف پیام می تواند اختصاصی، متن باز یا ترکیبی از هر دو باشد که در سرورهای خصوصی یا در سرورهای ابری خارجی (سرویس صف پیام) اجرا می‌شوند.

میان افزارهای اختصاصی سابقه زیادی دارند و شامل محصولاتی از ابتدای ظهور صف پیام‌ها، مانند IBM MQ، محصولات مرتبط با سیستم‌عامل‌های خاص، مانند مایکروسافت Message Queuing (MSMQ) می‌شوند. ارائه دهندگان خدمات ابری همچنین راه حل‌های اختصاصی خود مانند Amazon Simple Queue Service (SQS)، StormMQ، Solace و IBM MQ را ارائه می‌دهند.

میان افزارهای منبع باز پیام رسانی شامل Apache ActiveMQ، Apache Kafka، Apache Qpid، Apache RocketMQ، Enduro/X، JBoss Messaging، JORAM، RabbitMQ، Sun Open Message Queue و Tarantool است.

محصولات Solace، Apigee و IBM MQ نیز نمونه هایی از میان افزارهای پیام رسانی مبتنی بر سخت افزار هستند.

نحوه استفاده

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

اصططلاحات و مفاهیمی برای مفهوم دقیق ارسال پیام وجود دارد که در ادامه اشاره می‌شود:

دوام: پیام ها ممکن است در حافظه نگهداری شوند، روی دیسک نوشته شوند یا در یک DBMS ثبت شوند.

سیاست های امنیتی: کدام برنامه‌ها میتوانند به این پیام ها دسترسی داشته باشند و کدامیک نباید دسترسی داشته باشند؟

سیاست پاکسازی پیام: صف‌ها یا پیام‌ها ممکن است یک زمان مشخص به نام زمان حیات داشته باشند.

فیلتر کردن پیام: برخی سیستم‌ها از فیلتر کردن داده‌ها پشتیبانی می‌کنند تا کاربر مربوطه فقط پیام‌هایی را ببیند که با معیارهای از پیش تعیین‌شده و مورد نیازش مطابقت دارند.

سیاست ارسال: تضمین کردن تحویل پیام حداقل یک بار یا بیش از یک بار نیاز است؟

سیاست های مسیریابی: در سیستمی با تعداد زیادی سرور صف، چه سرورهایی باید پیام یا پیام های صف را دریافت کنند؟

سیاست‌های دسته‌بندی: آیا پیام‌ها باید در لحظه تحویل داده شوند؟ یا اینکه سیستم باید کمی صبر کند و سعی بر ارسال همزمان چندین پیام باشد؟

معیارهای صف: چه زمانی یک پیام باید در صف قرار گیرد؟ چه زمانی یک صف آن را داراست؟ یا چه زمانی حداقل به یک صف از راه دور ارسال شده است؟ یا چه زمانی به همه صف‌ها ارسال شده است؟

اعلان رسید: ممکن است ارائه دهنده نیاز داشته باشد بداند که برخی یا همه مشترکین پیامی را دریافت کرده اند یا خیر؟

این موارد ملاحظاتی هستند که می توانند تأثیرات قابل توجهی بر معناشناسی معاملات، قابلیت اطمینان سیستم و کارایی سیستم داشته باشند.

استانداردها و پروتکل‌ها

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

اولین تلاش برای فراگیرتر کردن صف پیام ها، مشخصات JMS Sun Microsystems بود که یک انتزاع جاوا برای API مشتری ارائه می کرد و به توسعه دهندگان جاوا اجازه داد تا بین ارائه دهندگان صف پیام (به روشی مشابه توسعه دهندگان پایگاه داده های SQL) جابجا شوند. در عمل، با توجه به تنوع تکنیک ها و سناریوهای صف بندی پیام، این روش آنقدر کارایی در عمل نداشت. به این ترتیب پروتکل‌ها و استانداردهایی ایجاد شد. سه استاندارد در اجرای صف پیام منبع باز شامل موارد زیر است:

· پروتکل صف پیام پیشرفته (AMQP): پروتکل صف پیام غنی از ویژگی، از آوریل 2014 به عنوان ISO/IEC 19464 تایید شده است.

· پروتکل پیام رسانی متن محور (STOMP): پروتکل پیام ساده و متن محور

· در MQTT (قبلاً MQ Telemetry Transport نامیده می شد): پروتکل صف پیام سبک به ویژه برای دستگاه‌های کم توان.

دو پروتکل اول در سطح HTTP وMQTT در سطح TCP/IP عمل می‌کنند. برخی از پیاده سازی های اختصاصی نیز از HTTP برای ارائه صف پیام از پیاده سازی هایی مانند SQS آمازون استفاده می‌کنند زیرا همیشه امکان لایه‌بندی رفتار ناهمزمان (که برای صف‌بندی پیام لازم است) روی یک پروتکل همزمان وجود دارد. با این حال، چنین پیاده‌سازی‌هایی توسط پروتکل زیربنایی در این مورد محدود شده‌اند.

تفاوت همزمانی و نا همزمانی

بسیاری از پروتکل‌های ارتباطی شناخته شده‌تر در حال استفاده، به‌صورت همزمان عمل می‌کنند. پروتکل HTTP که در شبکه جهانی وب و در خدمات وب استفاده می شود یک مثال واضح ارائه می دهد که در آن کاربر درخواستی برای یک صفحه وب ارسال می کند و سپس منتظر پاسخ می ماند.

با این حال، سناریوهایی وجود دارد که در آنها رفتار همزمان مناسب نیست. به عنوان مثال، AJAX (جاوا اسکریپت ناهمزمان و XML) می تواند برای ارسال ناهمزمان متن، پیام های JSON یا XML برای به روز رسانی بخشی از یک صفحه وب با اطلاعات مرتبط تر استفاده شود. Google از این رویکرد برای Google Suggest خود استفاده می‌کند، یک ویژگی جستجو که درخواست‌های نیمه تایپ‌شده کاربر را به سرورهای Google ارسال می‌کند و فهرستی از درخواست‌های کامل احتمالی را برمی‌گرداند. این لیست به صورت ناهمزمان با تایپ کاربر به روز می شود. نمونه های ناهمزمان دیگر در سیستم های اطلاع رسانی رویداد و سیستم های انتشار/اشتراک وجود دارد. یک برنامه ممکن است نیاز داشته باشد که به دیگری اطلاع دهد که رویدادی رخ داده است، اما نیازی نیست منتظر پاسخ باشد. در سیستم‌های انتشار/اشتراک، یک برنامه کاربردی اطلاعات را برای هر تعداد مشتری برای خواندن منتشر می‌کند. در هر دو مثال فوق منطقی نیست که فرستنده اطلاعات مجبور باشد برای مثال اگر یکی از گیرندگان از کار افتاده بود منتظر بماند.

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

در تمام این شرایط، داشتن یک سیستم فرعی که صف بندی پیام را انجام می دهد (یا به طور متناوب، یک سیستم پیام رسانی پخش) می تواند به بهبود رفتار سیستم کلی کمک کند.

مزیت ها

راه‌حل‌های صف پیام به طور گسترده در صنایع مورد استفاده قرار می‌گیرند و می‌توانند مجموعه‌ای از مزایا را به توسعه‌دهندگان و مدیران سیستم ارائه دهند، از جمله موارد زیر:

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

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

تطبیق پذیری: راه حل های صف پیام می توانند چندین زبان مانند Java، Node.js، COBOL، C/C++، Go، .NET، Python، Ruby و C# را پشتیبانی کنند. آنها همچنین می توانند از چندین رابط برنامه نویسی برنامه (API) و پروتکل ها، از جمله MQTT، AMQP، و REST و همچنین موارد دیگر پشتیبانی کنند.

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

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

انتقال فایل یکپارچه: برخی از راه حل‌های صف پیام دارای ویژگی های اضافی مانند توانایی انتقال فایل‌ها هستند و می‌تواند جایگزینی برای FTP باشد.

مقایسه با دیگر نرم افزارها

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

ابزارها

• MuleSoft Anypoint Platform.
• IBM MQ.
• Azure Scheduler.
• Apache Kafka.
• TIBCO Rendezvous.
• RabbitMQ.
• IBM Cloud Pak for Integration.
• Google Cloud Pub/Sub.

ابزار RabbitMQ

· تهیه کننده پیامی را برای تبادل منتشر می‌کند و باید نوع آن باید مشخص شود.

· پیام برای تبادل دریافت می‌شود و مسئول مسیریابی پیام می‌شود. بسته به نوع مبادله، ویژگی‌های پیام مختلفی مانند کلید مسیریابی در نظر گرفته می‌شود.

· اتصالات باید از تبادل به صف ایجاد شود. تبادل پیام بسته به ویژگی‌های پیام به صف‌ها هدایت می‌شود.

· پیام ها در صف می مانند تا زمانی که توسط یک مصرف کننده مدیریت شوند.

· مصرف کننده پیام را مدیریت می کند.

انواع تبادل:

direct: پیام به صف هایی هدایت می شود که کلید اتصال آن‌ها دقیقاً با کلید مسیریابی پیام مطابقت دارد.

Fanout: یک مبادله fanout پیام ها را به تمام صف‌های متصل به آن هدایت می‌کند.

topic: تطبیق بین کلید مسیریابی و الگوی مسیریابی مشخص شده در binding انجام می دهد.

header: از ویژگی های هدر پیام برای مسیریابی استفاده می کنند.

ابزار kafka

آپاچی کافکا یک سیستم انتشار/اشتراک بسیار محبوب است که می تواند برای پردازش قابل اعتماد جریانی از داده ها استفاده شود.

می‌توان با استفاده از کدهای موجود در مخزن kmq که در GitHub در دسترس است، نحوه عملکرد این کار را در عمل امتحان کرد. بخش اصلی پیاده سازی در ماژول اصلی قرار دارد که شامل کلاس های زیر است:

KmqClient - یک رابط به سبک تکرار کننده برای خواندن پیام ها از یک موضوع صف و ارسال نشان‌گرهای شروع ارائه می دهد. پس از پردازش پیام ها، هر کدام باید با استفاده از متد processed تایید شوند. به عبارت دیگر، جریان پردازش پیام 5 مرحله ای را مدیریت می‌کند.

RedeliveryTracker - یک برنامه Kafka+Akka و یک سرویس راه اندازی می کند که پیام هایی را که باید دوباره تحویل داده شوند را ردیابی می کند و در صورت نیاز تحویل مجدد را انجام می دهد.

MarkerKey، MarkerValue - کلاس‌هایی که نشانگرهای شروع و پایان را نشان می‌دهد.

KmqConfig - کلاس پیکربندی حاوی نام موضوعات صف و نشانگر.

ماژول example-java شامل دو نوع تنظیم پردازش پیام است، یکی با استفاده از نمونه تعبیه شده کافکا، و دیگری با استفاده از یک نمونه مستقل کافکا که در پس‌زمینه اجرا می‌شود. می‌توان کلاس EmbeddedExample یا سه کلاس مستقل جداگانه را برای آزمایش اجرا کرد. همچنین یک نمونه Scala مستقل در example-scala وجود دارد که شامل پیاده‌سازی مجدد KmqClient با استفاده از جریان‌های reactive-kafka و Akka است.

نتیجه گیری

صف پیام به سرورهای وب این امکان را می دهد که به درخواست ها به سرعت پاسخ دهند به جای اینکه مجبور باشند پردازه‌های سنگینی انجام دهند که ممکن است زمان پاسخ را به تاخیر بیندازد. صف پیام زمانی که لازم است پیامی را بین چندین مصرف کننده توزیع کرد یا بارها را متعادل کرد مناسب است.

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

این ابزار همانطور که توضیح داده شد میتواند در شرکت هایی مانند آپ و بام که نیاز به پاسخ سریع دارد و ارسال پیام باید تضمین شود میتواند مناسب باشد.

«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است»

منابع

https://softwaremill.com/using-kafka-as-a-message-queue/