سلام و درود دوستان عزیزم من علیرضا احمدی هستم یک برنامه نویس BacK-end که بیشتر سمت بک اند با زبان برنامه نویسی php کار میکنم و به عنوان مشاور فنی با شرکت های مختلفی کار میکنم و در حال حاظر هم در پوزیشن مدیر فنی در یکی از شرکت های ایرانی مشغول به کار هستم و دوست دارم تجربیات خودم رو در خصوص RabbitMQ در اختیار شما دوستان قرار بدهم
خود سایت RabbitmQ این گونه خودش رو توصیف میکنه :
RabbitMQ is the most widely deployed open source message broker.
و در واقع میشه گفت یکی از پراستفاده ترین message broker های اپن سورس هست برای استقرار در یک پروژه که البته شما برای این که این تعریف رو بهتر درک کنید قبلش بهتر بدونید که اصلا message broker چی هست ؟
مسیج بروکر که برخی بهش صرافی پیام ها می گویند : در واقع به نظرم من یک لایه ارتباطی بین میکرو سرویس ها هست که هر کدام از میکروسرویس ها بخواهند پیامی رو بین سرویس ها جا به جا کنند / پیام هاشون رو از طریق بستر Message Broker ارسال و میکنند .
کاری که مسیج بروکر برای ما انجام میده این هست که صف هایی رو برای هر کدام از سرویس های ما ایجاد میکنه که ما میتونیم پیغام هامون رو به اون صف ارسال کنیم
و از همه مهم تر اگر گیرنده در دسترس نبود ما دیگه نگران از بین رفتن پیام مون نخواهیم بود چون میتونیم دوباره پیام رو از صف دریافت کنیم یا هر زمان که دوباره در دسترس قرار بگیره پیام ها ارسال میشه
یا اگر گیرنده به هر دلیلی پاسخی رو با تاخیر ارسال کند / درخواست های دیگر در صف همچنان پردازش می شوند و فرایند ما متوقف نمی شود .
برای این که مفهوم message broker رو بیشتر درک کنید بهتر یکم در مورد معماری میکروسرویس باهم صحبت کنیم
ما توی معماری میکرو سرویس با دو مفهوم روبرو هستیم :
۱) ارتباط های همزمان / synchronous یا به اختصار sync :
ارتباط sync به این صورت است که سرویس مبدأ به‌صورت مستقیم یک API از سرویس مقصد را call می‌کند و منتظر می‌ماند که Response آن را دریافت کند
یه مثال خیلی ساده :
به عنوان مثال میخواهیم اطلاعات Alexa یک سایت رو بگیریم / سرویس مبدا از کاربر ادرس سایت مورد نظرش رو دریافت میکنه و بعد Api مربوط به Alexa رو call l میکنیم که در جواب برمیگردونه که اصلا این سایت معتبر هست یا نه و اگر معتبر هست مثلا اطلاعات مربوط به اون سایت رو برمیگردونه
۲) ارتباط های غیرهمزمان / asynchronous یا به اختصار async
در این روش سرویس مبدأ منتظر پاسخ سرویس مقصد نمی‌ماند و به کار خودش ادامه می‌دهد و بعد پاسخ برای آن ارسال می‌شود
یکی از محبوب ترین روش ها همون پیاده سازی به صورت message broker هست که درخواست که درخواست ثبت میشه و در طی یک صف این پیام ها رسیدگی می شود و جواب آن به سمت کاربر بازگشت داده میشه .
در ارتباط همزمان اگر Api مربوط به alexa رو call کنیم و این Api به هر دلیل اگر پاسخ ندهد یا دیر پاسخ در عملکرد برنامه ما مشکل ایجاد میشه ولی در حالت message broker اگر Consumer پاسخ ندهد ما نگران از بین رفتن درخواست نخواهیم بود و یا دیر پاسخ بدهد اختلالی در برنامه ما به وجود نمیاد .
خوب فکر کنم الان یکمی براتون ماجرا مشخص تر شده است / اما توی این معماری با دو تا واژه Consumer و Publisher هم روبرو هستیم که در ادامه بیشتر در موردش توضیح میدهم .
یکی کلا کار کردن با message broker یکم پیچیده است / درک میکنم ولی برای این که بهتر این مسائل رو درک کنید من همه مفاهیم پیچیده رو دارم لایه به لایه ساده سازی میکنم تا اینقدر ساده باشه که راحت تر بتونید درکش کنید
به شما هم در آینده برای این که کار براتون راحت تر باشه پیشنهاد میکنم ابتدا تا جای ممکن در مورد مفاهیم مختلفش بخونید بعد برید سراغ پیاده سازید
در این معماری در واقع ما دو تا سرویس جداگانه داریم که یکی از آنها Publisher هست یا ناشر که کاری که قراره اتفاق بی افته رو میگه / مثلا توی مثال مربوط به الکسا میگه که قرار ما دیتای alexa رو جمع اوری کنیم / و سرویس دوم : Consumer یا مصرف کننده هست .
و کار در واقع جمع آوری دیتا با Consumer خواهد بود .
و خوب اگر به هر دلیلی Consumer ما از کار افتاده باشه ما میتونیم پیام ها رو داخل صف داشته باشیم و حداقل خیالمون راحت خواهد بود که چیزی رو از دست ندادیم .
وقتی داشتم سرچ میکردم برای یک معماری ساده رو پیدا کنم این تصویر رو پیدا کردم :
که برای خودم هم به شدت جالب بود و یک سیستم آپلود رو پیاده سازی کرده بود که یکمی براتون همین تصویر فضا رو باز تر میکنه .
فکر کنم حالا با message broker ها تا حدودی اشنا شدیم
ما message broker های مختلفی رو داریم که یکی از رایج ترین هاش RabitmQ هست و یکی دیگه از رایج ترین هاش Apache Kafka که هر کدام از این ها یکسری مزایای و معایب دارند
که برای این که این مقاله مون خیلی طولانی نشه فقط خواستم یک معرفی داشته باشم و در آینده بیشتر در موردش توضیح خواهم داد .
به نظرم من کلا زمانی خوبه برید سمت معماری میکروسرویس و استفاده از message broker ها که واقعا پروژه به یک بلوغ اولیه رسیده باشه
و به نظرم واقعا برای پروژه های بزرگ کاربردی خواهد بود وگرنه برای پروژه های کوچک همون ساختار مونولیت هم در ابتدا مفید تر خواهد بود
یا ساده تر بخواهم بگم به نظرم زمانی خوبه برید سمت این معماری که حدود ۱۰۰۰ کاربر فعال دارید و با یک سیستمی روبرو هستیم که داره بزرگتر میشه و دیگه معماری مونولیت داره روند توسعه اتون رو کند میکنه .
این تازه یک شروع بود و ما این موضوع رو ادامه خواهیم داد / من تلاش کردم خیلی ساده خیلی از مفاهیم پایه رو توضیح بدهم و یکمی فضا رو براتون شفاف تر کنم / اما در آینده تلاش میکنم این مسیر رو ادامه بدهم و مقالات بیشتری رو در موردش بنویسم و ویدیو هایی رو هم براش بسازم ...
