خانه / microservices / Say No to No Monolith

Say No to No Monolith

Say No to “No Monolith”

Packages Principals

با بیشتر شدن تمایل و گرایش به مایکروسرویس ها، و برشمردن مزایای و مقایسه آن با سیستم های مونولیت، یک جنبشی بوجود آمده که در صورت و هر شرایطی سعی در نه گفتن به مونولیت ها دارد(No monoliths). باید توجه داشت که این دیدگاه رادیکال بسیار خطرناک میتواند باشد. There is no Silver bullet دست بر قضا در مورد مایکروسرویس ها بیش از مورد دیگری صادق می باشد. مونولیت به خودی خود گزینه و انتخاب بد یا نامناسبی نیست.
همانطور که قبلا هم بیان کردم در مایکروسرویس ها ما با سرویس هایی سروکار داریم که هر کدام از این سرویس ها autonomous بوده و می توانند بدون وابستگی به سایر سرویس ها توسعه ریلیز و دیپلوی شوند
به بیان دیگر مایکروسرویس ها برابر است با مجموعه از مونولیت های با ابعاد کوچکتر. که باید تمامی نگرانی ها از بابت مونولیت ها رو اکنون به ازای چندین مونولیت در مقیاس دیگر داشته باشیم.
یک مونولیت با ساختار ماژولار خوب و مناسب که براحتی قابلیت maintenance داشته باشد میتواند در توسعه سیستم های پیچیده گزینه مناسبی باشد(که به این موضوع در فرصتی دیگر پرداخته خواهد شد). با توجه به اهمیت ماژولار بودن در این پست به بررسی اصل پکیچ سازی مختصرا پرداخته شده است. همچنین باید گفت که متن زیر نه در تقبیح و نکوهش مونولیت ها می باشد و نه مایکروسرویس ها.

 

Package Principles روشی است جهت سازماندهی و دسته بندی کلاس ها، در یک سیستم پیچیده نرم افزاری بمنظور اینکه بر آنها مدیریت بهتر و مناسب تری داشته باشیم.
این اصل در دو مورد مهم به ما کمک میکند:
۱-چه کلاس(هایی) باید در چه پکیچی قرار بگیرند(Package Cohesion)
۲-ارتباط این پکیچ ها با یکدیگر به چه صورت هست(Package Coupling)
نکته ی دیگر اینکه Package Principles هم چنین شامل software package metricهای مختلف جهت کمک به مشخص کردن ساختار وابستگی های پکیچ ها و موارد از این دست می باشند.

 

Principles of package cohesion
1. Reuse-release equivalence principle (REP)
بصورت خلاصه REP بیان می کند که پکیچ ها باید از کلاس هایی متشکل شوند که قابلیت استفاده مجدد را دارا هستند. همچنین این کلاس ها باید دارای یک رابطه منطقی با یکدیگر جهت قرار گرفتن در یک پکیچ مشابه باشند. در نتیجه کلاس هایی که از هدف و ماهیت پکیچ بدور هستند، نباید درون پکیچ قرار کنند. به بیان ساده تر REP میگوید یک پکیچ متشکل است از کلاس هایی به هم مرتبط که دارای قابلیت استفاده مجدد و مفید بودن را دارا هستند.
2. Common-reuse principle (CRP)
اصل CRP عنوان می کند که کلاس هایی که تمایل به استفاده مجدد با هم; دارند باید در یک پکیچ قرار بگیرند. این روشی که کمک میکند که راحت تر متوجه شویم که چه کلاس هایی متعلق به چه پکیچ هایی هستند.
3. Common-closure principle (CCP)
اصل CCP به نوعی بیانی است از اصل SRP، که تاکید دارد بر این موضوع که هر پکیچ نباید بیش از یک دلیل برای تغییر داشته باشد. هنگامی که تغییراتی که در یک برنامه رخ میدهد، وابسته به تعداد پکیچ ها باشد، حالت ایده ال بدین صورت هست که به ازای هر پکیچ یک دلیل باشد و نه مجموعه ای از دلایل. در صورتی که کلاس هایی که دارای وابستگی صفت و سخت(tight coupling) با یکدیگر هستند در یک پکیچ قرار بگیرند، به این امر کمک می کند
Principles of package coupling

1. Acyclic dependencies principle (ADP)

در چرخه تولید سیستم با تعداد زیادی توسعه دهنده و تیم، نیاز میباشد که همکاری و یکپارچه سازی در چرخه های انتشار کوتاه مدت رخ بدهد.
ADP بیان می کند که در ساختار وابستگی ها نباید چرخه ای وجود داشته باشد. که در نتیجه در صورتی که ریلیزی توسط شخص یا تیمی رخ دهد سایر تیم ها میتوانند خود را با آن مطابقت دهند.
2. Stable-dependencies principle (SDP)

این اصل بیان کننده ی این موضوع می باشد که Package ای که دارای ماهیت فرار و پر تغییر می باشد، نبایستی وابسته به Package ای باشد که به ندرت و به سختی تغییر می کند.
بیانی دیگر از این اصل بدین صورت می باشد که
Less stable code should depends upon more stable code.

3. Stable-abstractions principle (SAP)

پکیچ ها را بر اساس ماهیت و طبیعت و ارتباط آنها در دنیای واقعی طراحی کنید.
اصل SAP بیانگر این مساله می باشد که پکیچی که دارای ماهیت پایدار یا stable می باشد باید انتزاع شود. این مورد کمک می کند که پکیچی که تمایل به پایداری دارد را بتوان راحت در صورت نیاز گسترش داد. و پایداری این پکیچ مانعی برای گسترش آن نمی باشد.
SAP
همچنین عنوان میدارد که پکیچ های غیر پایدار یا unstable نباید abstract باشند چرا که unstable بودن آنها به کدهای درون آنها اجازه میدهد به راحتی تغییر کنند.

درباره ی masoud@admin

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

ملزومات مایکروسرویس

ملزومات مایکروسرویس آقای مارتین فاولر مقاله ای تحت عنوان MicroservicePrerequisites دارند که در اون به بررسی یک …

Microservices: Lessons from the Frontline

خانم ژامک دهقانی از مشاورین ارشد thoughtworks  و با نگاه و تمرکز بر روی معماری سیستم …

3 دیدگاه

  1. عاااالی بود
    من هر خط رو میخوندم فقط لذت میبردم. مدتهاست دنبال همچین مطالبی میگشتم.
    پایان نامه من روی هماهنگی میکروسرویس ها با استفاده از reo که یک زبان معماری فرماله هست

    دنبال یکسری چالش ها میگردم که reo بتونه حلش رو راحتتر کنه
    امیدوارم این مطلب خیلی بتونه کمک کننده باشه

  2. ممنون که ترجمه هاتون رو در اختیار همه قرار میدید

پاسخ دهید

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

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

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

پیوستن بستن