به نام حضرت دوست که هرچه داریم از اوست
سلام، من حمیدرضامعدنی هستم و قصد دارم در این سری مقاله های آموزش NATS، فناوری انتقال پیام درباره ی یکی از اجزای کلیدی و مهم در معماری Microservice و البته هر معماری دیگری که در آن، بین اجزای برنامه یا برنامه های مختلف، نیازمند انتقال اطلاعات باشیم، آموزش هایی را ارائه بدهم و یک فناوری سریع و راحت را هم به شما معرفی کنم که در بسیاری از سناریوها، بهترین انتخاب شما خواهد بود.
وقتی صحبت از معماری میکروسرویس می شود، یکی از موارد بسیار مهمی که باید به آن دقت شود انتخاب یک سرویس میانی برای تبادل پیام بین هرکدام از بخش های برنامه است. از آنجا که میان افزارهای مبتنی بر پیام (Message Oriented Middleware) و کارگزار‌های پیام (Message Broker) زیادی با مزایا و معایب مختلفی وجود دارند؛ وقتی می خواهیم یکی از این سرویس ها را انتخاب کنیم، تازه اول سردرگمی مان شروع می شود.
👈 برای آشنایی با انواع این سرویس‌ها می‌توانید به مقاله‌ی کاوش در Message Broker ها مراجعه کنید.
چطور یک Message Broker یا Messaging Architecture برای برنامه مان انتخاب کنیم؟
ابتدا اجازه بدهید با Kafka شروع کنیم، فناوری که در معیارهای پیچیدگی و توانایی تحمل سایز با اختلاف زیاد از همه ی رقبایش جلوتر است. معمولا از Kafka به عنوان فضای ذخیره سازی Log های توزیع شده یاد می کنند. در استفاده از Kafka فرض بر این است که پیام های ذخیره شده در آن، قرار است برای مدت طولانی در آن بماند و با وجود مفهوم Consumer Group، این امکان را فراهم می کند تا پیام ها بین سرویس های مشابه توزیع شود. Kafka بسیار قدرتمند است ولی با این قدرت مسائل جانبی هم ایجاد می شود، مثلا نگه داری آن یا یادگیری و استفاده از آن بسیار سخت تر از بقیه ی فناوری های در این حوزه است.
انتخاب رایج دیگر RabbitMQ یا هر AMQP (Advanced Message Queuing Protocol) دیگری است که واسطه گری پیام را بر عهده بگیرد. RabbitMQ به طور قابل توجهی سبک تر از Kafka است و به جای استفاده از مفهوم Consumer Group از سازوکار ساده تری استفاده میکند، در RabbitMQ خود مصرف کننده های (Consumerها) پیام های داخل صف ها را برداشته و استفاده می کنند. اگر مصرف کننده ای یک پیام برداشته شده را تایید (acknowledge) نکند، پیام مجددا به صف برمیگردد تا توسط مصرف کننده ی دیگری مورد استفاده قرار بگیرد.
حتی از برنامه هایی مانند Redis که خودشان هم ادعای Message Broker بودن ندارند هم میشود به عنوان یک سیستم انتقال پیامی که پیام ها، تولید کننده و مصرف کننده داشته باشند، استفاده کرد.
همانطور که دیدید لیست برنامه ها و سرویس هایی که می توان به عنوان واسطه گری پیام (Message Broker) از آنها استفاده کرد، متنوع و گیج کننده است. هر کدام از این سرویس ها ویژگی هایی دارند که می درخشند و شما را به استفاده و انتخاب آنها ترقیب می کنند. برای مثال Kafka قدرت زیادی در مدیریت کردن پیام هایی در ابعاد وسیع دارد و همچنین تجمیع لاگ های پیام هایی که برای مدت طولانی تری ذخیره می شوند. RabbitMQ در مواقعی که شما به عملکرد ساده ای از یک Pub/Sub (تولید کننده / مصرف کننده پیام) نیاز دارید کاربرد دارد و شما را از پیچیدگی های پیاده سازی و نگه داری دور نگه می دارد. و البته Redis هم اگر همه ی کلاینت های شما بتوانند با Redis برای cache کردن اطلاعات ارتباط بگیرند و شما هم نیاز خاصی به نگه داری مطمئن اطلاعات نداشته باشید می تواند مفید باشد.
حالا اگر بخواهم همه ی این مزایا را باهم داشته باشیم ولی ایرادها و سختی های آنها را نداشته باشیم. مثلا بخواهیم Pub/Sub را به صورت سنتی خودش داشته باشیم و همزمان سیستم مان توانایی ارسال درخواست و دریافت پاسخ هم داشته باشد و البته بخواهیم همه چیز را سبک و چابک نگه داریم باید چه کنیم؟ در این شرایط NATS وارد کار می شود.
NATS چیست؟
NATS یک سیستم پیام‌رسانی فوق‌العاده سریع و منبع باز است که بر اساس یک هسته ساده و در عین حال قدرتمند ساخته شده است. سرور NATS از یک پروتکل متنی استفاده می کند که برای استفاده از آن تعداد زیادی کتابخانه های مختلف در زبان های برنامه نویسی توسعه داده شده است که شما می توانید به معنوای واقعی کلمه با استفاده از telnet به یک سرور NATS متصل شوید و پیام هایی را بفرستید و دریافت کنید. NATS به گونه ای طراحی شده است که همیشه درحال کار، متصل و آماده ی دریافت دستورات باشد.
NATS فناوری است که در لایه ی اتصال بین دو بخش از سیستم های توزیع شده (Distributed Systems) نقش ایفا می کند تا این بخش ها بتوانند به راحتی هم دیگر را پیدا کنند و برای هم پیام بفرستند. فناوری هایی مانند NATS، یکی از اصلی ترین اجزای معماری Microservice هستند.
Telnet یک پروتکل شبکه ای است، که برای دسترسی مجازی به یک کامپیوتر و ایجاد یک کانال ارتباطی دو طرفه، مشارکتی و مبتنی بر متن بین دو ماشین استفاده می شود.
برنامه نویس ها با استفاده از NATS می توانند:
- بدون زحمت اضافه، برنامه های Client-Server ای توزیع پذیر و مقیاس پذیر بسازند.
- داده ها را به صورت توزیع شده و با روش های مختلفی ذخیره کنند. این کار را می توانند در محیط ها و با زبان های مختلفی روی سرورهای داخلی یا ابری انجام بدهند.
همانطور که متوجه شدید در ادامه ی این سری مقاله ها قرار است با NATS که یک سرویس تبادل پیام بین سرویس های برنامه یا برنامه های مختلف است آشنا بشویم. رقبای قوی در بازار این سرویس ها، Rabbit MQ و Kafka هستند. در پایان این سری مقاله های آموزش NATS و با دانشی که کسب کرده اید می توانید در طراحی سیستم های نرم افزاری تان (Design System) در محل مناسب از NATS هم بهره ببرید. زیرا در بعضی از مسائل، جایگزینی سریعتر و بهینه تر از رقبای خودش است.
اطلاعات زیر هم ممکن است برای شما جذاب باشد:
- NATS در سال 2010 توسط Derek Collison و برای استفاده ی اختصاصی در CloudFoundry توسعه داده شده است.
- این ابزار ابتدا با Ruby نوشته شده بود، ولی در سال 2012 با زبان برنامه نویسی Go (گولنگ) بازنویسی شد.
- 8 سال است که این ابزار، زیر فشار استفاده مستمر در لایه ی Production قرار دارد. (و هنوز آخ هم نگفته 😉)
اجزای تشکیل دهنده ی NATS
NATS به از دو بخش اصلی Server و Client تشکیل شده است.
سرور NATS
سروری است که با زبان گولنگ نوشته شده است و وظیفه دارد با ساختار سبک خودش، کانال ارتباطی را ایجاد کرده و نگه داری کند.
کلاینت NATS
کلاینت های NATS بخش های مستقلی هستند که به سرور NATS وصل شده و داده ها را برای آن ارسال می کنند و یا اطلاعاتی را از آن دریافت می کنند. NATS در اکثر زبان های برنامه نویس رایج، کتابخانه های کلاینتی دارد که می توان از آنها به راحتی استفاده کرد. حتی کتابخانه هایی در زبان های GO، Node، Ruby، JAVA، C، C و ... توسط خود تیم NATS توسعه داده شده است.
انواع سرورهای NATS
خب، حالا بیایید نگاهی هم به دو نوع سرور NATS بیاندازیم. NATS Server و NATS Streaming دو نوع سرور NATS هستند که تفاوت آنها در روش انتقال و تحویل پیام است. در NATS به منظور افزایش QoS (کیفیت خدمات) از دو حالت تحویل پیام با نام های تحویل حداکثر یکبار (At-most-once delivery) و تحویل حداقل یکبار (At-least-once delivery) استفاده می شود.
تحویل حداکثر یکبار (At-most-once delivery)
در NATS Server این روش تحویل پیام پیاده سازی شده است. که در آن هیچ اصراری برای رسیدن پیام به دست Client نیست. به عبارت دیگر، اگر کلاینت در زمان ارسال پیام ارتباطش به سرور دچار مشکل شده باشد با به هر دلیلی به سرور متصل نباشد، پیام را دریافت نخواهد کرد.
تحویل حداقل یکبار (At-least-once delivery)
در سرورهای NATS Streaming از این روش برای رساندن پیام ها به دست کلاینت ها استفاده شده است. در این روش، سرور تمام تلاش خودش را می کند تا پیام به دست کلاینت برسد. در نتیجه پیام در سرور می ماند تا زمانی که یکی از کلاینت های Subscriber تایید کند که پیام به دستش رسیده است، یا تاریخ انقضای پیام برسد (پیام timeout شود)، یا فضای حافظه پر شود.
در قسمت بعدی با یکی از رایج ترین موارد استفاده از NATS و نحوه ی کار آن در سیستم های Pub/Sub آشنا می شوید.
