خانه / microservices / مایکروسرویس ها و چالشی نا تمام به نام اندازه

مایکروسرویس ها و چالشی نا تمام به نام اندازه

بزرگی سرویس ها در معماری مایکروسرویس ها

در سبک معماری مایکروسرویس ها ما با سرویس های مستقلی سروکار داریم که ضمن داشتن استقلال در کل چرخه ی زندگی خود یک ویژگی مهم را با خود یدک می کشند. ویژگی ای که به جهت اهمیت بخشی از نام این سبک معماری شده است. مایکرو یا کوچک.

مایکرو( به انگلیسی Micro ˈmīkrō با تلفظ مایکرو) به معنی بسیار کوچک است.( extremely small) ضمن اینکه مسئله شکستن سیستم به سرویس های کوچک و سپس ترکیب این سرویس ها در این سبک معماری بسیار با اهمیت می باشد، نباید از این بعد نیز غافل شد.

معیارهای متفاوت و مختلفی و گاها جالبی جهت اندازه گیری سایز یک مایکروسرویس در نظر گرفته می شود. معیارهایی کم ارزشی مثل تعداد خط کد که مثلا تعداد خط کد 100 یا 1000 یا اعداد مشابه نیز در این بین وجود دارد. با توجه به پارادایم های مختلف برنامه نویسی مثل OOP یا Functional و یا نوع زبان برنامه نویسی مورد اشتفاده مثلا Scripting language مشخص است که خیلی نمی توان بر این معیار تکیه کرد.

 

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

بصورت ضمنی در این رویکرد معماری یک سرویس نباید بیش از دو Aggregate  را مدیریت کند و شامل شود.

بخاطر داشته باشیم که یکی از معیارهای مهم جهت تفکیک سرویس ها در اینجا این است که هر سرویس یک و تنها یک مسئولیت را انجام دهد و تنها یک دلیل جهت تغییر داشته باشد. همان Single Responsibility در سطح سرویس ها. تعداد Aggregate  بیشتر یعنی مسئولیت بیشتر و دلیل برای تغییر بیشتر،

مورد بعدی میزان حافظه ی ذهنی توسعه دهنده هست. غالبا ذهن می تواند تعداد کمی از Aggregate ای از موجودیت ها را بصورت کامل و شفاف بخاطر بسپارد. و بیش از این تعداد احتمالا توسعه دهنده را جهت بخاطر سپاری و یا در صورت نیاز هنگام از سر نویسی سرویس دچار نوعی شک  خواهد کرد. به عبارتی تعداد بیشتر Aggregate ها یعنی فراموشی بیشتر +  زمان بیشتر(بیش از یکی دو روز یا نهایت یک هفته) جهت از سر نوشتن سرویس.

موارد بالاهمگی Design Smell  در طراحی مایکروسرویس ها محسوب می شود.

 

 

درباره ی masoud@admin

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

Consumer Driven Contract Testing

Consumer Driven Contract Testing     با داشتن یک API با دوجین استفاده کننده(Consumer) که …

مایکروسرویس ها و چالشی بنام DRY

مایکروسرویس ها و چالشی بنام DRY یکی از بخش های مهم بهنگام مهاجرت از یک …

پاسخ دهید

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

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

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

پیوستن بستن