🛰 الگوی Request-Response Messaging با MassTransit
ساخت برنامههای توزیعشده (Distributed Applications) در نگاه اول ساده به نظر میرسد فقط چند سرور هستند که با هم صحبت میکنند، درست است؟
اما در عمل، این نوع سیستمها مجموعهای از مشکلات بالقوه را ایجاد میکنند که باید به آنها توجه کنید.
اگر شبکه دچار اختلال شود چه؟ اگر یک سرویس بهطور غیرمنتظره کرش کند چه؟ اگر بخواهید سیستم را scale کنید و همه چیز زیر فشار از هم بپاشد چه؟
اینجاست که نحوه ارتباط سرویسها در سیستم توزیعشده اهمیت حیاتی پیدا میکند. ⚙️
ارتباطهای synchronous سنتی جایی که سرویسها مستقیماً یکدیگر را فراخوانی میکنند ذاتاً شکنندهاند.
این رویکرد باعث tight coupling میشود و در نتیجه، کل سیستم در برابر هرگونه نقطه شکست (single point of failure) آسیبپذیر میشود.
برای مقابله با این مشکل، میتوانیم از messaging توزیعشده (Distributed Messaging) استفاده کنیم.
(البته این کار خودش مجموعه جدیدی از چالشها را هم ایجاد میکند، ولی آن موضوع را میگذاریم برای مقالهای دیگر 😄)
یکی از ابزارهای قدرتمند برای انجام این کار در دنیای NET. ، کتابخانهی MassTransit است. 🚀
در این مقاله، به بررسی پیادهسازی الگوی Request-Response در MassTransit میپردازیم.
📨 مقدمهای بر الگوی Request-Response Messaging Pattern
بیایید ابتدا توضیح دهیم که این الگو چگونه کار میکند.
الگوی Request-Response بسیار شبیه به فراخوانی یک تابع معمولی است، با این تفاوت که این فراخوانی از طریق شبکه انجام میشود.
در این الگو:
• یک سرویس بهعنوان Requestor (درخواستدهنده)، یک پیام درخواست (Request Message) ارسال میکند
•و منتظر پیام پاسخ (Response Message) از سمت Responder (پاسخدهنده) میماند.
از دید Requestor، این فرآیند synchronous است.
✅ مزایا:
🔹️Loose Coupling:
سرویسها نیازی به دانستن مستقیم یکدیگر ندارند؛ تنها کافی است قرارداد پیام (message contract) را بشناسند.
این ویژگی باعث سهولت در تغییر و افزایش مقیاس (scalability) میشود.
🔹️Location Transparency:
درخواستدهنده نیازی ندارد بداند پاسخدهنده در کجا قرار دارد در نتیجه انعطافپذیری سیستم افزایش مییابد.
⚠️ معایب:
🔹️Latency:
سربار پیامرسانی باعث افزایش اندکی در زمان پاسخ میشود.
🔹️Complexity:
افزودن یک سیستم پیامرسان و مدیریت زیرساختهای مربوط به آن میتواند پیچیدگی پروژه را افزایش دهد.