مسیج چه بروکری ؟!

سلام سلام، توی این مقاله میخوام هر آنچه که نیازه راجع به مسیج بروکر ها(بیشتر rabbitMQ) بنویسم تا درک خوبی از علت وجودشون بدونیم.

اما برای درک بروکر ها بهتر که قبلش با معماری هایی مثل monolith و microservice آشنا بشیم.البته خود این دو مبحث کلی میشه روشون صحبت کرد ولی خب اینجا ما یه گریزی بهشون میزنیم

دقت کنید که مسیج بروکری که ما داریم روش حرف میزنیم به صورت پیشفرض rabbitMQ هستش و ممکنه یک سری جاها توی نحوه کارکرد با بقیه بروکر ها(نه خیلی) فرق کنه

✅ معماری مونولیت و میکروسرویس

با یه مثال توی دنیای واقعی شروعش کنیم، توی ذهنتون یه آشپزخونه رو درنظر بگیرید:

• معماری مونولیت 👈 اگه همه چیز توسط یک آشپزخونه واحد انجام بشه؛ از پخت غذا گرفته تا پذیرش سفارش و شستن ظرف‌ها و خلاصه همه چی. به این میگن معماری مونولیت که اگ یک نفر مریض بشه یا آشپزخونه دچار مشکل بشه، کل رستوران به فنا میره. پسسس توی این نوع معماری، تمام بخش‌های نرم‌افزار (مثل بخش‌های مربوط به احرازهویت، مدیریت کاربران، پایگاه داده یا ....) به صورت یکپارچه و در قالب یک پروژه بزرگ نوشته می‌شه. این بخش‌هایی که نام بردیم توی یک سرور اجرا میشه و همشون در قالب یک سورس کد بزرگ کار میکنن.
• معماری میکروسرویس👈 حالا همون آشپزخونه رو بازم تو ذهنت داشته باش ولی اینبار بیاییم آشپزخونه رو غرفه غرفه(تیم) کنیم و هر غرفه مسئول یه کار خاصی بشه مثلا یک تیم فقط پخت غذا رو انجام بده، یک تیم فقط پذیرش سفارش، و یک تیم فقط نظافت رو انجام بده. یعنی هر بخش مستقل میشه و اگر یک بخش دچار مشکل بشه، بقیه بخش‌ها می‌تونن همچنان به کار خودشون ادامه بدن. پسسس توی این نوع معماری، سیستم ما به مجموعه‌ای از سرویس‌های کوچک و مستقل تقسیم می‌شه که هر سرویس وظیفه خاص خودشو داره.

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

✅ دو نوع ارتباط میان میکروسرویس ها

حالا این سرویس هایی که توی این معماری داریم باید یه طوری بتونن باهم ارتباط برقرار کنن یا نه؟ ما به دو روش میتونیم میون این سرویس ها ارتباط برقرار کنیم یکی sync و یکی async

• توی روش sync از Rest API و HTTP استفاده میکنیم. دقیقا عین همون درخواست هایی که به سایت میزنیم ولی اینجا فرقش اینه دوتا سرویس دارن به هم درخواست میزنن پس یعنی توی این روش از زمانی که request ارسال میشه تا زمانی که  response اون دریافت میشه سیستم در حالت انتظار میمونه.
• حالا توی روش async ما میتونیم درخواست خودمون رو برای سرویس موردنظر ارسال کنیم و برعکس sync دیگه منتظر پاسخ اون نمونیم. حالا که مستقیم سرویس ها برای هم پیام ارسال نمیکنن پس چطوری اینا باهم حرف میزنن ؟؟ و این جا همون قسمتی هستش که message broker ها وارد داستان میشن و شاعر میگه : من مسیج بروکر هستم، نمی‌گذارم سرویس ها باهم قهر کنن!

✅ مسیج بروکر ها چی هستن

• مسیج بروکر یک‌لایه ارتباط بین سرویس‌ها هست که اگر هرکدوم از سرویس‌ها بخوان پیامی برای سرویس دیگه بفرستن پیام خودشون رو روی Message Broker می‌فرستن و گیرنده، پیام خودشو از روی Message Broker برمیداره.
• توی بروکر ها به فرستنده میگیم publisher یا producer و به گیرنده میگیم consumer یا subscriber
• با استفاده از مسیج بروکر ها در جای درست خودش، اپلیکیشنمون loosely couple میشه یعنی سرویس هامون کمتر به هم وابسته میشن

✅ مسیج بروکر ها چطور کار میکنن

پابلیشرها وقتی یک message میفرستن سمت بروکر، بروکر از طریق کامپوننتی به اسم exchange اون پیام رو میگیره فعلا exchange رو مثل یک router در نظر بگیر که پیام تولید شده رو مسیریابی میکنه به کجا برسه(جلوتر دقیق توضیحش میدم) خب این آقا یا خانم exchange پیام رو مستقیم و دودستی نمیده به گیرنده که!! بلکه قبلش میفرستتش به message queue یعنی پیام هامون وارد یک صف میشن و هر دریافت کننده صف خودشو داره و پیام اینطوری میرسه دست دریافت کننده خودش ، حالا دریافت کننده وقتی پیام رو گرفت و کارش رو با موفقیت تموم کرد اون پیام از صف پاک میشه دقیقا مثل تصویر زیر:

✅ ا Exchange ها چی هستن و انواع شون

مسئول این هستن که اون message رو طبق rule هایی که دارن مسیردهی کنن تا برسن به مقصد و چندین نوع exchange داریم که اون سه تا مهمشو من میگم:

• ا Direct Exchange 👈 در این نوع، پیام‌ها بر اساس کلید مسیریابی (Routing Key) دقیقاً به Queueهایی هدایت میشن که همون کلید رو دارن.پس کلید مسیریابی پیام باید دقیقاً با کلید Queue مطابقت داشته باشه. برای کجاها مناسبه ؟ اونجاهایی که پیام‌ها فقط باید به یک Queue خاص ارسال بشن
• ا Topic Exchange 👈 در این نوع، پیام‌ها بر اساس یک الگو (Pattern) در Routing Key به Queueهایی هدایت میشن که کلیدشوم با الگوی پیام تطابق داره. مثلا توی سناریوهایی لازمه که نیاز به مسیریابی بر اساس دسته‌بندی‌های پیچیده‌تر دارن.
• ا Fanout Exchange 👈 تقریبا مثل Topic هستش با این تفاوت که دیگه طبق الگو پیام ها مسیر دهی نمیشن بلکه بدون توجه به کلید مسیریابی به تمام Queueهای متصل به این Exchange ارسال میشن.

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

✅ دو الگوی (pattern) مهم در message brokers

• الگوی Point To Point 👈 توی این الگو یک رابطه یک به یک بینsender و receiver وجود داره و message فقط یکبار توسط دریافت کننده consume یا استفاده میشه. خب شاید بگی این شد همون rest api که؟!!! دقت کن که تفاوتش با Rest اینه که بروکر تضمین میکنه consumer حتما و حتما پیام رو دریافت کنه حتی اگه آفلاین باشه، منتظر آنلاین شدن اون میشه تا مطمعن بشه پیام به دستش میرسه
• الگوی PUB/SUB👈 توی این الگو یک publisher پیام رو به چندین consumer میفرسته (حالا یا topic یا fanout) در واقع توی exchange از اون message کپی میگیره و میفرسته . دقت کنیم که فرستنده و گیرنده از هم اصلا خبر ندارند و براشونم مهم نیست
• طبیعتا وقتی نیاز داری یک پیام به چندین سرویس یا اپلیکیشن ارسال بشه از pub/sub استفاده کن و وقتی هر پیام فقط باید توسط یک سرویس پردازش بشه هم از point to point.

امیدوارم مورد استفاده اتون قرار گرفته باشه

اگه دوست داشتید توی کانال تلگرامیمون هم عضو بشید LearnByLearn@

بدروووود تا بعد ❤️