اگر با این سری مقاله ها آموزش NATS من همراه بوده باشید، در قسمت اول به پرسش NATS چیست؟ پاسخ دادم و همچنین از اهمیت جایگاه این تکنولوژی در معماری Microservice گفتم. در قسمت دوم هم روش های مختلفی که برای ارسال و دریافت پیام وجود دارد را گفتم و سپس به این پرسش پاسخ دادم که Publisher/Subscriber در NATS چگونه کار می کند؟. اگر دو قسمت قبلی را هنوز نخوانده اید، پیشنهاد می کنم اول آنها را بخوانید، سپس این قسمت را مطالعه کنید که موضوع برایتان روشن تر باشد.
وقتی به یک سرویس RESTful با استفاده از HTTP درخواستی را ارسال می کنیم و پاسخی را دریافت می کنیم، به صورت پیشفرض درحال استفاده از الگوی Request-Response هستیم.
در بسیاری از سیستم های پیام رسان، پیاده سازی الگوی Request-Reply یا کلا شدنی نیست و یا خیلی سخت است و نیاز است کارهای زیادی انجام بدهیم تا شاید به صورت دست و پا شکسته این قابلیت را بتوانیم پیاده سازی کنیم. اما پیاده سازی این الگو در NATS بسیار ساده است و فقط لازم است در هنگام انتشار یک پیام، موضوع (Subject) مجزایی را برای دریافت پاسخ مشخص کنید.
برای روشن شدن عملکرد NATS در الگوی Request/Reply اجازه بدهید با یک مثال ساده پیش برویم. فرض کنید قرار است ما لیست ویدیو هایی که یک فرد خاص در آنها هست را درخواست بدهیم. نکته ی مهمی که لازم است به خاطر داشته باشید این است که ما نمی دانیم قرار است چه کسی یا سرویسی پاسخ درخواست ما را بدهد. و تنها کاری که ما انجام می دهیم، منتشر کردن درخواست مان و انتظار برای دریافت پاسخ مان است.
این عدم وابستگی بخش های مختلف سیستم به هم، باعث می شود محصول ما در برابر ارتقا یا توسعه، بسیار منعطف برخورد کند و دست ما را برای ارتقای محصول مان، بدون اینکه نیازی به متوقف کردن برنامه داشته باشیم باز میگذارد.
مراحل پیاده سازی Request/Reply در NATS
بیایید برای مثال بالا، ببینیم به صورت گام به گام NATS چه کارهایی انجام میدهد:
1- Publisher یا منتشر کننده ی پیام در موضوعی باعنوان vididentify.reply عضو می شود (در این موضوع Subscribe می کند)
2- سپس Publisher پیامی را در موضوعی با عنوان vididentify.inquiry ارسال می کند. در همین دستور PUB، مشخص می کند که برروی موضوع vididentify.reply منتظر دریافت پاسخ است.
3- بعد از آن Publisher برای دریافت پاسخ، مدتی را منتظر می ماند.
4- بعد از اتمام زمان انتظار یا بعد از رسیدن پاسخ، Publisher دیگر از عضویت در موضوع vididentify.reply انصراف می دهد (Unsubscribe می کند.)
5- Publisher پاسخ رسیده را براساس هدفی که دارد مدیریت میکند.
برای اینکه چندین درخواست همزمان از یک نوع، روی یکدیگر قرار نگیرند و مطمئن باشیم که پاسخ تولید شده برای درخواست هر ناشر به خود او میرسد، باید به روشی Subject انتخاب شده برای هر درخواست را منحصر به فرد کنیم. برای این منظور هم از یک شناسه ی منحصر به فرد به عنوان پسوند نام Subject، استفاده می شود. برای مثال مطرح شده در بالا درخواست PUB به صورت زیر خواهد بود:
PUB vididentify.inquiry vididentify.reply.1b807ae3-bc12-42ab-b667-ccbd6c677745 25
{ "person_id": 4237249 }
+OKدر درخواست بالا 1b807ae3-bc12-42ab-b667-ccbd6c677745 همان شناسه ی منحصر به فردی است که به انتهای اسم Subject انتخاب شده (vididentify.reply) اضافه شده است تا از ایجاد مشکل در پاسخ های تولید شده جلوگیری شود.
معمولا انتخاب نام و منحصر به فرد کردن اسم این کانال ارتباطی، به خاطر پیچیدگی هایی که دارد توسط کتابخانه هایی که در هر زبان برنامه نویسی وجود دارد، پشتیبانی می شود در نتیجه این پیچیدگی ها از جلوی دست برنامه نویس ها برداشته شده تا راحت تر بتوانند پاسخ درخواست خود را دریافت کنند.
نمونه کد پیاده سازی Request/Reply در NATS
برای مثلا به کد زیر دقت کنید، این کد توسط زبان Go (گولنگ) نوشته شده است و از کتابخانه ی کلاینت NATS استفاده می کند:
nc, err := nats.Connect(*urls)
if err != nil {
log.Fatalf("Can't connect: %v\n", err)
}
defer nc.Close()
// get payload...
msg, err := nc.Request("vididentify.inquiry", []byte(payload), 100*time.Millisecond)همانطور که در تکه کد بالا مشاهده می کنید، کلاینت Go به طور کلی، ایجاد کانال پاسخ را از دید برنامه نویس مخفی کرده است. حتی مراحل Subscribe و Unsubscribe کردن در موضوع ایجاد شده هم، به صورت خودکار توسط کلاینت انجام می شود. در این تکه کد، Publisher فقط لازم است درخواستی را ارسال کند و 100 میلی ثانیه برای دریافت پاسخ آن صبر کند.
ولی اگر کتابخانه ی کلاینتی که استفاده می کنید، این مراحل را برای شما انجام نمی داد، پیشنهاد می کنم یک wrapper برای آن بنویسید تا در هربار استفاده از آن مجبور نباشید این مراحل را خودتان مدیریت کنید.
با من همراه باشید تا در قسمت بعدی کاربرد جذاب دیگری از NATS را هم باهم بررسی کنیم...