مدل های Communication در معماری میکروسرویس (قسمت اول)

یک سوالی که در زمینه ارتباط میکروسرویس ها پیش می آید اینست که : چرا سرویس ها باید با یکدیگر ارتباط برقرار کنند مگرهر سرویس مستقل نیست؟

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

ابتدا اعتبار مشتری وارد شده بررسی و داده‌های ورودی را با جدول مشتری بررسی می کنیم. اگر مشتری اعتبار موردنظر راداشته باشد، سرویس مشتری را به عنوان یک مشتری معتبر تایید می‌کنیم؛ در غیر این صورت، سرویس مشتری را به عنوان یک مشتری unauthenticated رد می‌کنیم. در حال حاضر، این سرویس از لحاظ عملکردی مستقل است.

یک سرویس دیگر را در نظر بگیرید : سرویس پرداخت customer-centric . یک مشتری به خرید محصولی از یک نقطه فروش(که می تواند یک فروشگاه اینترنتی باشد) علاقه‌مند است . او درخواست خرید را به سرویس پرداخت customer-centric ارائه می کند . در اینجا ، سرویس پرداخت customer-centric باید با سرویس های دیگر مانند ، سرویس تایید کاربر و سرویس مجوز پرداخت customer-centric ارتباط برقرار کند .

در این مثال ، سرویس مجوزcustomer-centric با چک کردن وضعیت(بالانس) حساب ، محدودیت‌های اعتباری و تعاملات مشتری با بانک ، اجازه خرید را می‌دهد .توجه داشته باشید که این سرویس ، صحت سنجی را به صورت زیر انجام می‌دهد .

اگر قیمت محصول < = (بالانس)حساب + محدودیت کارت اعتباری + اعتبار اخذ شده از طریق رفتار مشتری ، باشد خرید مجاز خواهد بود در غیر این صورت خریدمجاز نیست . تعاملات بین سرویس‌های مختلف در شکل نشان‌داده شده‌است .

از مثال بالا ، مشخص می شود که یک سرویس ممکن است یک قابلیت کاربردی منفرد ایجاد کند که به تنهایی برای انجام یک فرایند کسب وکاری کافی نیست . به منظور تولید یا ارایه یک عملکرد مفید کسب وکاری ، برخی مواقع نیاز است سرویس ها باید با ارسال فرمان‌ها و یا notifications و یا پیام‌ها با یکدیگر تعامل داشته باشند .

اساسا دو سبک ارتباطی وجود دارد: ارتباط همزمان و ارتباط نا همزمان که در شکل زیر نشان‌داده شده‌است .

ارتباط همزمان

در ارتباط همزمان , فرستنده و گیرنده در طول مدت ارتباط باید با یکدیگر متصل(=connected) باشند . فرستنده ( یا مشتری ) درخواستی را به گیرنده می‌فرستد و تا زمانی که پاسخی از گیرنده دریافت نکند منتظر می‌ماند . در میکروسرویس ها, یک سرویس می‌تواند سرویس دیگری را برای دریافت اطلاعات فراخوانی کند و سرویس گیرنده باید صبر کند تا پاسخی از سرویس دهنده دریافت کند . این امر در شکل زیر بصورت ارتباط فرستنده و گیرنده با یکدیگر به روش نقطه به نقطه (point-to-point) نشان داده می‌شود .

میکروسرویس ها از سبک معماری REST که به طور ضمنی از پروتکل HTTP جهت برقراری ارتباط استفاده می‌کند بابت ارتباط همزمان با یکدیگر استفاده می‌کنند . HTTP یک پروتکل همزمان است که در آن یک مشتری درخواست ارسال می‌کند و منتظر پاسخ از سرور می ماند.مشتری تنها در صورتی می‌تواند کار خود را ادامه دهدکه پاسخی از سرور دریافت کند .

چرا ارتباط همزمان در میکروسرویس ها توصیه نمی شود ؟

یک ارتباط همزمان ساده بین چهار سرویس ، A، B ، C ، D را در نظر بگیرید همانطور که در شکل زیر نشان‌داده شده‌است .

همانطور که مشاهده می کنیم ، سرویس A درخواستی به سرویس Bرا می‌دهد و صبر می‌کند تا پاسخی از سرویس Bدریافت کند . سرویس Bدرخواستی به سرویس Cرا ارسال می‌کند و سرویس Cهم به نوبه خود درخواستی به سرویس Dارسال می کند . در هر تعامل ، سرویس ‌گیرنده باید صبر کند تا سرویس دهنده پاسخ را ارسال کند . به خاطر حالت انتظار ارتباط همزمان، چرخه‌ پاسخ درخواست طولانی خواهد داشت از اینرو کارایی برنامه بسیار ضعیف خواهد شد . لذا ارتباط همزمان حتی برای پرس و جو‌ها توصیه نمی‌شوند . هدف اصلی معماری میکروسرویس این است که هر سرویس بصورت مستقل ،خودمختار و بدون درنظر گرفتن شرایط سرویس دیگری در اختیار مشتری قرار گیرد . هنگامی که ارتباط همزمان مورد استفاده قرار می‌گیرد ، این هدف اصلی نقض می شود.

ارتباط ناهمزمان

در ارتباطات ناهمزمان، کلاینت (سرویس گیرنده ) درخواستی را به سرور ارسال می کند ولیکن منتظر پاسخ سرور نمی ماند و می تواند به ادامه کارخود بپردازد در نهایت برای دریافت پاسخ از سرور می تواند به سه راه اقدام نماید: (اول) با استفاده از تابع callback (دوم) با استفاده از روش سرکشی (polling) مکرر (سوم) با استفاده از message broker.

استفاده از تابع callback

در این روش کلاینت (سرویس گیرنده) درخواستی را به سرور ارسال می کند. هنگام ارسال درخواست به سرور، کلاینت یک مشخصه مرجع نیز به تابع callback ارسال می کند (پیاده سازی تابع callback در سمت کلاینت است) که پس از پردازش درخواست توسط سرور فراخوانی می شود. بنابراین، به محض پردازش درخواست، سرور تابع callback را در کلاینت فراخوانی می کند. با فراخوانی تابع callback، سرویس گیرنده متوجه می شود که پاسخ آماده است و پاسخ را برای تکمیل فرآیند پردازشی خود استفاده می نماید.

استفاده از روش سرکشی (polling)

در این روش ، کلاینت درخواستی را به سرور ارسال می کند. سرور تاییدیه بابت دریافت درخواست برای کلاینت ارسال می کند. کلاینت به کار خود ادامه خواهد داد و در فواصل زمانی معینی از سرور برای وضعیت درخواست استعلام می کند تا زمانی که سرور درخواست را انجام و پاسخ را ارسال نماید.

استفاده از message broker

در این روش، فرستنده پیام ها را به یک صف (queue) می فرستد، و گیرنده پیام را از صف می گیرد.در واقع فرستنده و گیرنده مستقیماً به یکدیگر متصل نیستند و از طریق یک صف پیام به هم متصل می شوند . ضمن اینکه آنها نیازی به اتصال همزمان به صف را ندارند چراکه فرستنده پیام ها را به صف می فرستد وmessage broker پیام ها موجود در صف را تا زمانی که گیرنده پیام ها ی خود را بازیابی کند ذخیره می نماید. مزیت اصلی استفاده از این متد اینست که درجه بالایی از جداسازی (decoupling) بین فرستنده و گیرنده را فراهم می کند که این مزیت ما را قادر می سازد تا به عملکرد بالا ، مقیاس پذیری و قابلیت های دیگری که امروزه در معماری های مدرن (مانند معماری میکروسرویس) از اهمیت ویژه ای برخوردارند دست پیدا کنیم.