خانه / DevOps / Service Registration in Microservice

Service Registration in Microservice

Service Registry
در پست قبلی در باره ی یکی از جنبه های مهم معماری های سرویس گرا از جمله مایکروسرویس؛ یعنی Service Discovery صحبت کردم. در آنجا در مورد ضرورت نیاز به Service Discovery؛ انواع مکانیزم های بکارگیری آن بهمراه مزیت ها و معایب هر روش صحبت شد. یکی از نکات مهم که Service Discovery Patterns بحث رجیستر کردن سرویس ها می باشد که پیش نیاز اساسی Service Discovery نیز می باشد. در این پست در مورد رجیستر کردن سرویس ها صحبت به میان خواهد آمد.

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

سرویس های مختلف و زیادی وجود دارند که می توان از آنها جهت مخزن سرویس ها استفاده کرد؛ هر کدام از این سرویس ها دارای معماری و ساختار مختص به خود بوده و امکانات مختلف جهت ارتباط با آنها نیز وجود دارد؛ مثلا از طریق DNS query یا بصورت استفاده از HTTP API و … . به عنوان مثالی Consul یکی از این ابزارهای فوق العاده است که امکانات بسیاری از جمله Service Registering/Discovering انواع مکانیزم Health Choking و … را هم از طریق API و هم از طریق DNS query را به کاربر می دهد. بهنگام بالا آمدن سرویس براحتی می توان از طریق ارسال یک POST request اقدام به رجیستر کردن سرویس نمود. همچنین تنظیمات بررسی در دسترس بودن سرویس نیز در Consul قابل انجام است. همچنین می توان براحتی بهنگام نیاز به صدا زدن سرویس از طریق یک GET request براحتی لیست تمامی نمونه های سرویس مورد نظر بهمراه وضعیت آنها را گرفت و بر اساس مکانیزم های load balancing اقدام به انتخاب یک سرویس و استفاده از آن نمود. به عنوان یک مثال ساده از استفاده از این سرویس می توانید اینجا را ببینید.

روش های مختلفی جهت رجیستر نمودن یک سرویس وجود دارد. یکی از این الگوها بدین صورت می باشد؛ که خود سرویس اقدام به رجیستر نمودن خود نماید. که این روش به عنوان self-registration pattern نیز معروف می باشد. روش دیگر بدین صورت می باشد که کامپوننتی دیگر عملیات register نمودن instance ها مختلف سرویس ها را بر عهده دارد؛ که به این روش نیز third-party registration pattern می گویند.

  1. Self-Registration Pattern

همانطور که بالا گفته شد؛ در این روش هر instance سرویس مسئول register و deregister نمودن خود را در service registry بر عهده دارد. در صورت نیاز جهت بررسی در دسترس بودن ممکن است سرویس نیاز باشد که درخواست های heartbeat را در بازه های زمانی بمنظور اینکه registration آن expire نشود نیز ارسال می کند. این روشی که سرویس Netflix Eureka استفاده می کند. در برخی سرویس ها از جمله Consul بررسی در دسترس بودن سرویس ها با خود Service Registrar می باشد. بدین صورت که با ارسال درخواست هایی به سمت سرویس و چک کردن پاسخ اقدام به این کار می کند.

 


مزیت ها:

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

معایب:

مهمترین عیب این روش tight coupling ای هست که میان سرویس ها و service registry بوجود میاد.

همچنین در صورتی که سرویس ها بزبان های مختلفی نوشته شده باشند؛ باید اقدام به پیاده سازی کد registration توی زبانهای مختلف کنید.

  1. Third-Party Registration Pattern

این متد جهت از بین بردن معایب ذکر شده در بالا می باشد. در انجا مسئولیت register شدن و deregister شدن نمونه های سرویس های از عهده ی آنها برداشته شده. و کامپوننت دیگری در سیستم بنام service registrar این نقش را به عهده می گیرد. Service registrar از طریق چک کردن تغییرات سرویس های در حال اجرا از طریق poll کردن محیط و یا از طریق گوش دادن به event ها خاص اینکار را انجام می دهد. به محض اینکه متوجه شود که service instance جدید در دسترس می باشد اقدام به register کردن آن می کند. همچنین در صورت terminate شدن instance اقدام به پاک کردن آن می کند.

 

یکی از service registrar های خیلی خود Registrator می باشد. این سرویس براحتی می تواند تمامی سرویس هایی که در محیط Docker وجود دارد را register یا در صورت نیاز Deregister نماید. نکته ی مهمتر در مورد این سرویس پشتیبانی از service registry ها مختلفی از جمله etcd؛ Consul؛ Eureka  … می باشد.
نکته ی حائز اهمیت دیگر در مورد این روش اینکه برخی از محیط ها توسعه بصورت built-in دارای service registrar می باشند. به عنوان مثالی می توان به Autoscaling Group اشاره کرد. تمامی نمونه های EC2 که ایجاد می شود بصورت اتوماتیک درون ELB در این محیط توسعه مهیا شده توسط این گروه ثبت خواهد شد.

مزایا:

یکی از مزیت های مشهود این روش نسبت به روش قبلی از بین بردن وابستگی موجود میان service instance ها و service registry می باشد. دیگه نیازی نیست که service registration code رو برای تمامی سرویس هایی که ممکن بود به زبانهای مختلفی نیز نوشته شده باشند را پیاده سازی کنیم. بلکه مدیریت register و Deregister نمودن سرویس ها در این روش بصورت متمرکز توسط service registrar انجام می شود.

معایب:

اگر محیط های توسعه ای که بصورت built-in سرویس registrar رو ارائه میدن در نظر نگیریم یکی از عیب های اصلی این روش بحث maintain کردن registrar service هست؛ چرا که این سرویس نیز با توجه به ماهیت خود تبدیل می شود به یکی از سرویس هایی که نیاز هست بصورت high available باشد.

درباره ی masoud@admin

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

مقایسه سه Pattern مهم مشتق شده از MV* بنام MVC و MVP و MVVM

مقایسه سه Pattern مهم مشتق شده از MV* بنام MVC و MVP و MVVM MVC …

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

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

پاسخ دهید

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

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

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

پیوستن بستن