در بخش اول از سری مقاله های آموزش NATS؛ فناوری انتقال پیام با موضوع جایگاه میان افزارهای مبتنی بر پیام یا Message Oriented Middleware ها آشنا شدیم که چه اهمیت بالایی در معماری Microservice دارند و با بعضی از اصلی ترین تکنولوژی های و ابزارهای این حوزه یعنی Kafka، RabbitMQ و Redis آشنا شدیم که هرکدام از آنها نقاط قوتی دارند که در جای خود بسیار مفید خواهند بود. در ادامه ی همان مقاله NATS را به عنوان یک سیستم پیام‌رسانی فوق‌العاده سریع و منبع باز که بر اساس یک هسته ساده و در عین حال قدرتمند ساخته شده است معرفی کردیم و در آخر هم اجزای اصلی آن یعنی Client و دو نوع سرور NATS Server و NATS Streaming را معرفی کردیم.
NATS بر اساس روش Publisher/Subscriber یا ارسال کننده ی پیام / دریافت کننده ی پیام کار میکند که در این روش کلاینت هایی وجود دارند که هم پیامی را در کانال ارتباطی ارسال می کنند و هم پیام های موجود در کانال را دریافت می کنند. همچنین NATS می تواتند از روش های Request/Reply (ارسال درخواست و دریافت پاسخ) و مدیریت صف پیام ها هم پشتیبانی کند. در زیر سه روش را می توانید مشاهده کنید:
روش Pub/Sub چگونه کار می کند؟
همانطور که در تصویر بالا مشاهده می کنید در روش منتشرکننده - دریافت کننده، پیام مورد نظر ما در موضوعی خاص منتشر شده و علاقه مندان به آن موضوع می توانند پیام را دریافت کرده و از آن استفاده کنند. این روش که به Publisher/Subscriber یا به اختصار Pub/Sub نیز معروف است، یکی از پایه ای ترین موارد استفاده از فناوری هایی مانند NATS است.
روش Queueing چگونه کار می کند؟
در این روش پیام ها ابتدا صف بندی شده و سپس طبق الگوی تخلیه ی صف هرکدام از آنها به دست دریافت کننده های پیام می رسد. همانطور که در تصویر مشاهده می کنید، در این روش هم تولید کننده و دریافت کننده پیام مانند روش Pub/Sub وجود دارند.
روش Request/Reply چگونه کار می کند؟
روش Request/Reply یکی از حرفه ای ترین موارد استفاده از فناوری هایی مانند NATS است که بسیاری از رقبای آن، این توانایی را ندارند. در این روش Subscriber ها می توانند پاسخی را به پیام دریافت شده بدهند که این پاسخ ها به دست Publisher می رسد.
در ادامه قصد دارم رایج ترین موارد استفاده از NATS را برایتان بگویم در این قسمت به Pub/Sub می پردازم و با روش عمل کردن NATS در این روش انتقال پیام آشنا خواهید شد.
استفاده از NATS در الگوی Publish و Subscribe
در ساده ترین مدل pub/sub، ما یک Publisher داریم که پیام ها را در یک موضوع (شما ممکن است با عبارت های topic یا subject آشنا باشید) منتشر می کند و هر Subscriber ای که موضوع پیام، به او مرتبط می شود از پیام استفاده می کند. NATS هم ضمانت می کند که پیام حداکثر یکبار به یک Subscriber ارسال بشود. وقتی یک Publisher داشته باشیم، پیام ها به ترتیبی که تولید شده اند به دست Subscriber ها می رسد ولی وقتی چندین Publisher داشته باشیم، دیگر ضمانتی برای این نظم وجود نخواهد داشت.
فرض کنید ما یک سیستم آنالیز ویدیو با قابلیت تشخصی چهره درست کرده ایم. قصد داریم همانطور که آنالیزرمان درحال کار برروی یک ویدیوی طولانی است، نتایج را برای هرکسی که علاقه داشت از آن استفاده کند منتشر کنیم.
از آنجایی که NATS یک پروتکل متنی است، شما فقط لازم است دستور زیر را منتشر کنید:
PUB analysis.progress 55
{"hash": "abc56fghe", id: 12, progress: 32, faces: 78}
+OKدر دستور بالا ما به NATS موضوع را که analysis.progress است و طول محتوای پیام یعنی 55 بایت را اطلاع می دهیم. سپس در خطی جدید، پیام را ارسال می کنیم. اگر همه چیز به خوبی پیش برود، NATS، پاسخ +OK را به ما بر می گرداند.
برای Subscribe، ما یک اشتراک (موضوع) با یک شناسه ی منحصر به فرد برای آن موضوع می سازیم. توجه داشته باشید که شناسه ی موضوع، به صورت خصوصی در همین Connection من می ماند.
SUB analysis.progress 50دستور بالا یعنی شناسه ی موضوعی 50، نشان دهنده ی اشتراک analysis.progress است.
حالا هر یک از Subscriber ها، پیامی به صورت زیر را دریافت می کنند:
MSG analysis.progress 50 55
{"hash": "abc56fghe", id: 12, progress: 32, faces: 78}مانند حالت انتشار (PUB)، اطلاعات پیام و خود پیام در دو خط مجزا قرار میگیرند که به راحتی از هم جدا شده باشند. هر پروتکل پیام MSG شامل شناسه ی موضوع (50) و طول محتوای پیام خام (55) می شود.
بعد از اینکه دیگر موارد رایج برای استفاده از NATS را گفتم، یک Pub/Sub را با هم پیاده سازی خواهیم کرد.
