خانه / microservices / Service Discovery Strategies in Microservices

Service Discovery Strategies in Microservices

Service Discovery in Microservice Architecture

یکی از مزیت های اصلی معماری و تفکر مایکروسرویس شکستن یک برنامه بزرگ به بخش و قسمت های کوچک تر(سرویس یا مایکروسرویس) و ترکیب این بخش ها جهت رسیدن به توان عملیاتی برنامه اصلی می باشد. به عنوان مثالی فرض نمایید شما یک برنامه فروش آنلاین بلیط هواپیما مثل http://Alibaba.Ir یا فروش هتل شبیه http://Jabama.Ir را دارید؛ که در برهه هایی از زمان مثل روزها و دوره های تعطیلات با در خواست سفارش بیش از حد معمول مواجهید. و نیازمند این می باشید که جهت پاسخگویی به این حجم زیاد سفارشات اقدام به Scale کردن برنامه با ایجاد کپی های بیشتری از برنامه ی خود پشت یک Load balancer نمائید؛ اما در حالتی که برنامه ی شما یک برنامه مونولیت بوده؛ شما مجبور خواهید بود که جهت Scale کردن فقط سرویس سفارش کپی هایی از کل برنامه ایجاد نمائید؛ اما چه بهتر می بود اگر می توانستیم برای اینکار فقط سرویس سفارش را Scale می کردیم. در واقع بجای مقیاس کردن عمودی برنامه؛ برنامه را بصورت افقی مقیاس می کردیم؛ مقیاس کردن افقی از طریق ایجاد کپی هایی از سرویس ها یکی از مزیت هایی است که معماری مایکروسرویس به ما می دهد.

در معماری مایکروسرویس ما با سرویس های مختلفی سروکار داریم که گاها و بسته به نیاز از هرکدام از این سرویس ها ممکن است چندین کپی مختلف نیز وجود داشته باشد. این سرویس ها جهت تکمیل use caseها برنامه نیازمند این می باشند که باهم صحبت داشته باشند تا بتوانند به درخواست های رسیده پاسخ دهند. مثلا ممکن است Ordering Service با Shipping Service صحبت کند و Shipping Service نیز خود با Inventory Service صحبت کند و این زنجیره ادامه داشته باشد.یکی از نیازمندیهای اساسی در اینجا داشتن آدرس سرویس های مختلف برنامه می باشد. تا بتوان بهنگام نیاز به سرویس مورد نظر دسترسی داشت. یکی از راه های ساده برای اینکار قرار دادن آدرس این سرویس ها در فایل کانفیگ و لود کردن آدرس این سرویس ها از فایل کانفیگ می باشد. این سناریوی ساده در حالتی که تعداد سرویس ها کم باشد می تواند بخوبی عمل کند؛ اما در صورتی که تعداد سرویس ها زیاد باشد و یا اینکه آدرس سرویس ها در شبکه بصورت داینامیک تغییر کند؛ و یا اینکه کپی های مختلفی از سرویس ها داشته باشیم؛ و همچنین در محیط cloud-based؛ این سناریو ساده دیگر نمی تواند پاسخگو باشد.Service Discovery سعی در حل این مشکل و پاسخ این سوال است که هر سرویس چه آدرسی دارد؛ و وضعیت سرویس ها از لحاظ سلامت به چه صورت است.

 

دو استراتژی مختلف در مبحث Service Discovery وجود دارد. Client Discovery و Server Discovery. که در ادامه به توضیح این دو استراتژی و مزیت ها و معایب آنها خواهم پرداخت. در ادامه از کلمه Client جهت اشاره به Consumer سرویس ها استفاده خواهم نمود؛ یعنی بخشی که قصد استفاده از سرویس ها را دارد.

  • The Client-Side Discovery Pattern

در این الگو Client مسئول اصلی تعیین محل شبکه هر instance سرویس می باشد. همچنین بدیهی است که وظیفه load balancing درخواست بین هر سرویس نیز بر عهده خود Client می باشد. Client با کوئری گرفتن از یک Registry یا Service Repository لیستی از سرویس ها را دریافت می کند. registry هم اصطلاحا به بخشی گفته می شود که اطلاعات سرویس ها درون آن ذخیره می شود. پس از اینکه Client لیستی از Instance های یک سرویس را از Registry دریافت نمود؛ به کمک یک الگوریتم load balancer یکی از Instance ها را انتخاب و اقدام به ارسال درخواست به سمت آن خواهد نمود.


آدرس شبکه هر Instance بهنگام Startup آن سرویس در Registry به ثبت می رسد و بهنگام terminate شدن از Registry حذف خواهد شد. همچنین مکانیزم هایی از جمله heartbeat نیز بصورت دوره ی زمانی نیاز می باشد تا از صحت و سلامت و در دسترس بودن سرویس های موجود اطمینان حاصل شود.

Netflix OSS یکی از نمونه های خیلی خوب Client-Side discovery می باشد.

مزیت ها:

یکی از مزیت های اصلی این روش سادگی آن می باشد؛ و همانطور که ملاحضه فرمودید بجز قمست Service Registry برای پیاده سازی این روش هیچ بخش یا قسمت اضافه ای نیاز نیست که به سیستم اضافه شود. همچنین همانطور که در بالا گفته شد؛ با توجه به اینکه load balancing در اینجا بر عهده ی خود Client ها می باشد؛ هر Client می تواند بر اساس شرایط تصمیم های مناسب جهت توضیع بار درخواست ها بین سرویس ها را انجام دهد.

معایب:

یکی از اصلی ترین معایب این روش tight coupling ای هست که در اینجا بین Client و Service Registry بوجود می آید. و اینکه نیاز می باشد که یکسری کدها بین تمامی Client تکرار شود؛ مثلا می توان به الگوریتم های load balancing در اینجا اشاره کرد.

 

  • The Server‑Side Discovery Pattern

رویکرد دیگر استفاده از استراتژی Server-Side می باشد. در این رویکرد هر Client بهنگام نیاز به صحبت با هر سرویس درخواست خود را تحویل load balancer می دهد. Load balancer پس از دریافت درخواست؛ ابتدا اقدام به کوئری گرفتن از Registry جهت دریافت instance های در دسترس از سرویس مذکور را می کند. و سپس بر اساس الگوریتم های توزیع بار اقدام به انتخاب یکی از instance و ارسال درخواست به آن خواهد نمود. مجدد بحث Service Registry همانند استراتژی قبل در اینجا نیز مطرح می باشد.


یکی از مثال های خوب AWS Elastic Load Balancer می باشد که از این الگو استفاده می نماید.

مزایا:

یکی از مشهودترین مزیت های این روش نسبت به الگوی قبلی متمرکز شدن الگوریتم load balancing در یک بخش؛ بجای تکرار شدن آن به ازای تمامی Client ها می باشد. در این روش هر Client بدن توجه به آدرس سرویس ها و در دسترس بودن آنها براحتی درخواست خود را به load balancer می فرستد. و این امر باعث می شود که نیاز به پیاده سازی service discovery در تمام Client ها که ممکن است پلت فرم های مختلفی داشته و به زبان های متفاوتی نیز نوشته شده باشند مرتفع شود. و نکته ی دیگر برخی محیط ها و فریمورک ها از جمله AWS نیز مکانیزم های مختلفی برای Service Register شدن و … را نیز ارائه می دهند.

معایب:

از معایب اصلی این روش تبدیل شدن load balancer به گلوگاه سیستم می باشد؛ که باید بصورت high available باشد که نیاز به توجه و اهمیت دادن ویژه به این سرویس می باشد.

در پایین Service Discovery های مختلف لیست شده است:

نکته ی آخر اینکه برای رجیستر شدن سرویس ها نیز الگوهای متفاوتی وجود دارد که در این پست در مورد آن توضیح داده شده است.

درباره ی masoud@admin

همچنین ببینید

مایکروسرویس ها و ادامه چرخه ی تسلسل اجایل

مایکروسرویس ها و ادامه چرخه ی تسلسل اجایل هرچند تفکر و ایده ی ورای Microservices …

مایکروسرویس از زبان حضرت حافظ

#Microservice should be considered a #journey, not a #destination. It should be implemented #incrementally through …

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

در تلگرام هم همراه شما هستم

اگر علاقمند به معماری نرم افزار و مبحث محبوب مایکروسرویس هستید؛ در کانال با ما همراه باشید. اطلاعات مفید زیادی در این کانال انتظار شما را می کشند. فقط کافیست دکمه ی پیوستن را بفشارید.

پیوستن بستن