در ارتباطات ناهمزمان یا Async بین میکروسرویس ها از ابزاری که اصطلاحا به اون واسط پیام یا message broker میگن، استفاده میشه. این مسیج بروکر تضمین میکنه که ارتباط بین میکروسرویس های مختلف پایدار و قابل اعتماد باشه، اینطوری که پیام ها داخل این سیستم مدیریت و نظارت میشن اینطوری پیامی از بین نمیره.مسیج بروکرهای مختلفی وجود داره که در مقیاس و قابلیت های داده ها متفاوتند، توی این نوشته سعی کردم مقایسه ای داشته باشم بین مسیج بروکر معروف RabbitMQ، Kafka و Redis، امیدوارم که براتون مفید باشه.
دو راه متداول برای ارتباط میکروسرویس ها با هم وجود داره: همزمان و ناهمزمان ((Synchronous and Asynchronous)). در یه ارتباط همزمان، تماس گیرنده قبل از ارسال پیام بعدی منتظر جواب می مونه و به عنوان یک پروتکل REST در بالای HTTP عمل می کنه. برعکس، در ارتباطات ناهمزمان، پیام ها بدون انتظار برای جواب ارسال می شن. این مدل برای سیستم های توزیع شده مناسبه و معمولاً به یه مسیج بروکر برای مدیریت پیام ها نیاز داره.
در این شرایط نوع ارتباطی که برای ارتباط بین میکروسرویس هاتون انتخاب می‌کنین باید براش پارامترهای مختلفی را در نظر داشته باشین، برای مثال میشه به نحوه ساختار میکروسرویس‌هایی که دارین، زیرساخت‌های موجود، تأخیر، مقیاس، وابستگی‌ها و هدف ارتباط اشاره کرد. برقراری ارتباط ناهمزمان ممکن که پیچیده‌تر باشه و نیاز به اضافه کردن اجزای بیشتری به سیستم داشته باشیم، اما مزایای استفاده از ارتباطات ناهمزمان برای میکروسرویس‌ها بیشتر از معایب اونهاست.
اول و مهمتر از همه، اینکه ارتباط ناهمزمان بنا به تعریف غیرقابل مسدود شدن هستن. همچنین از مقیاس پذیری بهتری نسبت به ارتباط همزمان بهره میبرن. سوم اینکه، در صورت بروز مشکل برای میکروسرویس، مکانیسم های ارتباطی ناهمزمان تکنیک های بازیابی مختلفی را ارائه می دن و به طور کلی در مدیریت خطاهای مربوط به خرابی بهتر عمل میکنن. علاوه بر این، در زمان استفاده چون از مسیج بروکرها به جای پروتکل REST استفاده میکنن، در نتیجه خدمات دریافت کننده ارتباط واقعاً نیازی به شناخت فرستنده نداره، اینطوری که یه سرویس جدید حتی می‌توانه پس از گذشت زمان و خدمات دهی سرویس قدیمی، داخل سیستم جایگزین بشه.
در نهایت، استفاده از ارتباط ناهمزمان "Asynchronous"، توانایی ، نظارت، پایداری سیستم یا حتی اجرای سیاستهایی در آینده را افزایش می ده. این به شما توانایی هایی برای انعطاف پذیری، مقیاس پذیری و قابلیت های بیشتر در کدنویسی و ساخت سیستم ارائه می کنه.
ارتباطات ناهمزمان معمولاً از طریق یه مسیج بروکر مدیریت می شن. اما راه های دیگه ای هم وجود داره، مثل aysncio، که محدودیت های خودش رو داره.
در انتخاب مسیج بروکر مناسب نکاتی وجود داره که اینجا توضیح میدم:
۱- مقیاس پذیری مسیج بروکر -- تعداد مسیج هایی که در ثانیه به سیستم ارسال میشه.
۲-پایداری داده ها -- قابلیت بازیابی مسیج ها.
۳- ظرفیت مصرف کنندها -- آیا مسیج بروکر قادر به مدیریت یک به یک و/یا یک به چند بین خودش و مصرف کننده ها هست یا نه.
خب تا اینجا مواردی که ممکن توی کار بهش بر بخورین و مفاهیم اولیه رو توضیح دادم حالا بین مسیج بروکر های فعلی بازار مقایسه ای میکنم تاببینیم کدوم یکی بهتر میتونه نیاز شما رو برطرف کنه.
مقیاس پذیری: بر اساس پیکربندی و منابع، بصورت تخمینی در حدود 50 هزار پیام در ثانیه است.
پایداری : پایداری تضمین میشه.
اتصال یک به یک و/یا یک به چند: هردو پشتیبانی میشن.
ربیت ام کیو در سال ۲۰۰۷ برای اولین بار منتشر میشه و جز اولین مسیج بروکرهاست.ربیت ام کیو یه ابزار منبع باز است که پیام ها را از دو روش نقطه به نقطه و pub-sub با پیاده سازی پروتکل های پیشرفته صف پیام یا (AMQP) ارسال می کنه.باید اشاره کنم که ربیت ام کیو طراحی شده تا از منطق مسیریابی پیچیده هم پشتیبانی کنه.RabbitMQ از تمامی زبان ها از جمله پایتون، جاوا، دات نت، پی اچ پی، روبی، جاوا اسکریپت، گو، سوئیفت و غیره پشتیبانی می کنه.
و در اخر باید اضافه کنم که زمانی که در حالت پایدار هستین، باید منتظر برخی مشکلات عملکردی هم باشین.
مقیاس پذیری: امکان ارسال تا یک میلیون پیام را درثانیه داره.
پایداری: تضمین میکنه.
اتصال یک به یک و/یا یک به چند: فقط از اتصال یک به چند پشتیبانی میکنه.
کافکا توسط Linkedin در سال ۲۰۱۱ ایجاد شد تا پردازش با توان بالا و تاخیر کم را انجام بده. به عنوان یک پلتفرم پخش توزیع شده، کافکا یه سرویس انتشار-اشتراک (pub-sub) را تکرار می کنه. پایداری داده‌ها را فراهم میکنه و استریم هایی از رکوردها را ذخیره میکنه که اون رو قادر به حفظ کیفیت تبادل پیام‌ها میکنه.
کافکا به عنوان SaaS روی Azure، AWS و Confluent پیاده سازی شده چرا که همه اونها به نوعی خالقان و مشارکت کنندگان اصلی پروژه کافکا هستن. کافکا از همه زبان‌های اصلی، از جمله Python، Java، C/C++، Clojure، .NET، PHP، Ruby، JavaScript، Go، Swift و غیره پشتیبانی میکنه.
مقیاس پذیری: امکان ارسال تا یک میلیون پیام را درثانیه داره.
ماندگاری : اساساً، نه - چرا که ذخیره‌سازی اطلاعات در حافظه (مموری) اتفاق داره میفته.
اتصال یک به یک و/یا یک به چند : هردو پشتیبانی میشن.
ردیس متفاوت تر از بقیه مسیج بروکرهاست. ردیس در هسته خودش، بصورت یه دیتا استور که داد ها رو in-memory ذخیره میکنه و میشه ازش بعنوان یه دیتابیس key-value و یا مسیج بروکر ازش استفاده کرد، تعریف میشه. نکته مهمی که باید بهش اشاره کنم این که چون ردیس داده ها رو بصورت in-memory نگهداری میکنه قابلیت ماندگاری نداره اما برای پردازش های در لحظه عالیه.
با اینکه ردیس از اتصال یک به چند اساسا پشتیبانی نمیکرده اما این قابلیت از نسخه ۵ به ردیس اضافه شده.
ما برخی از ویژگی های ربیت ام کیو، کافکا و ردیس رو توضیح دادم. هر کدوم در قابلیت ها ویژگی های مهمی دارن، اما همانطور که توضیح دادم، کاملاً متفاوت عمل می کنن. توصیه من برای انتخاب مسیج بروکر مناسب، انتخاب اون با توجه به موارد استفاده اون ابزار و نیاز خودتون.
ردیس یه دیتابیس که داده ها رو in-memory نگهداری میکنه، اصولا برای مواردی مناسب تر که پایداری (persistency) پیام خیلی مهم نیست.چراکه برای ردیس سرعت انتقال مهمه و قابلیت in-memory ردیس کاندیدای مناسبی برای مواردی که در اونها ماندگاری چندان مهم نیست و میشه مقداری ضرر رو هم تحمل کرد.
ربیت ام کیو، یکی از قدیمی ترین مسیج بروکر ها و در عین حال ویژگی ها و قابلیت های زیادی داره که از اونها میشه به مسیریابی پیچیده اشاره کرد. حتی زمانی که نرخ تبادل مورد نیاز بالا نباشه یعنی (بیش از چند ده هزار msg/sec نباشه) بازم از مسیریابی پیچیده پشتیبانی می کنه.
در نهایت اینکه، اصل مهم ، استک نرم افزار فعلی شما و نیاز پروژتون که مشخص کننده ابزار مورد نیازشماست. اگه به دنبال یک فرآیند یکپارچه سازی نسبتا آسون هستین و نمی خواین مسیج بروکرهای مختلف رو وارد بازی کنین، ممکن که تمایل بیشتری به کار با بروکری داشته باشین که قبلاً توسط استک نرم افزاری شما پشتیبانی میشه.
به عنوان مثال، اگر از Celery برای Task Queue در سیستم خودتون استفاده می کنین، احتمالا کار با ربیت ام کیو یا ردیس گزینه بهتری باشه برخلاف کافکا که از Task Queue پشتیبانی نمیکنه و نیاز به بازنویسی قسمت های از کدتون رو دارین.
مهم است که به یاد داشته باشین که هر ابزار مزایا و معایب خاص خودشو رو داره و در مورد درک اونها و انتخاب گزینه مناسب برای کار ، باید موقعیت و الزامات خاص پروژتون رو همیشه در نظر بگیرین.
پی نوشت: طبق معمول همه نوشته ها، سعی کردم که نوشتم با زبان محاوره و ساده گفته بشه که برای همه قابل درک باشه. اگه مورد و مشکلی وجود داره خوشحال میشم که برام بنویسین تا اون رو اصلاح کنم حتما.
شاد باشین (:
