ارتباط میان خدمات در معماری میکروسرویس ها؟ بیایید آن را پاک کنیم!

هنگامی که سرویس ها در معماری میکروسرویس ها با یکدیگر ارتباط برقرار می کنند، دو الگوی مشترک وجود دارد: Sync و Async.

در معماری Sync، سرویس‌ها معمولاً از طریق تماس‌های مستقیم API یا سایر روش‌های درخواست/پاسخ با یکدیگر تماس می‌گیرند. این به این معنی است که اگر یک سرویس خاموش باشد، تمام سرویس های وابسته دیگر نیز قطع می شوند. اما این الگو می‌تواند سازگاری داده‌ها را ساده‌تر کند و تکرار داده‌ها را کاهش دهد زیرا هر سرویس می‌تواند در صورت نیاز داده‌ها را واکشی کند.

در معماری Async، سرویس‌ها پیام‌ها را از طریق سیستم‌های پیام‌رسانی مانند صف‌های پیام یا جریان‌های رویداد که در آن پیام‌ها بدون نیاز به پاسخ فوری ارسال می‌شوند، به یکدیگر ارسال می‌کنند. خدمات نسبتا مستقل هستند و نیازی به منتظر ماندن برای پاسخ یکدیگر ندارند. اگر یکی از سرویس‌ها خراب شود، سرویس‌های دیگر بدون توجه به کار خود به کار خود ادامه می‌دهند و پس از بازیابی سرویس ناموفق، پیام‌ها را هنگامی که در دسترس قرار می‌گیرند پردازش می‌کنند. اما این رویکرد معمولاً نیازمند تکثیر داده‌ها و مکانیسم‌های مدیریت سازگاری اضافی است، زیرا هر سرویس به احتمال زیاد نیاز به کپی داده‌های خود را دارد تا به طور مستقل ارائه شود.

ممکن است به نظر برسد که رویکرد async بهترین انتخاب برای پروژه‌های یونیکورن است، اما همیشه اینطور نیست. اینکه آیا استفاده از الگوی Sync یا Async به عوامل مختلفی مانند الزامات نرم افزار، بودجه، تقاضای بازار و غیره بستگی دارد. توجه به این نکته مهم است که کسب یک مزیت معمولاً به معنای قربانی کردن مزیت دیگری است. اکثر نرم افزارهای مقیاس بزرگ بر اساس یک الگوی ترکیبی ساخته شده اند تا بهینه سازی را به حداکثر برسانند.

من در حال ساختن یک برنامه ساده با استفاده از معماری میکروسرویس در اوقات فراغت خود برای سرگرمی هستم.

هر سوالی دارید شلیک کنید. برای دریافت به روز رسانی ها با ما همراه باشید <3