مقدمه مقدماتی

معماری Microservices به یک الگوی غالب برای ساخت سیستم های نرم افزاری مقیاس پذیر، مستقل و انعطاف پذیر تبدیل شده است، با این حال، تغییر از برنامه های تکlithic برای خدمات توزیع شده پیچیدگی های جدید را معرفی می کند - اتصال بین خدمات، مرزهای نامشخص و مشکل در تست و استقرار، استفاده از اصول SOLID برای طراحی خدمات میکروسرویس ها به این چالش های طراحی شی گرا، هنگامی که هر دستورالعمل های کاربردی را سازگار می کنند و خدمات ساده تر، و خدمات.

اصول SOLID چیست؟

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

اصل مسئولیت (SRP)

یک کلاس یا ماژول باید یک داشته باشد و تنها یک دلیل برای تغییر در خدمات میکرو، این بدان معنی است که هر سرویس باید دارای یک قابلیت کسب و کار یا زیر دامنه باشد.به عنوان مثال، یک سرویس مدیریت سفارش باید تنها رویدادهای چرخه عمر را اداره کند، نه پردازش پرداخت یا ردیابی موجودی.این باعث کاهش شعاع تغییرات و ایجاد خدمات به طور مستقل قابل اجرا است.

Open/Closed Principle (OCP)

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

اصل اساسی مقررات آزاد (LSP)

اشیاء در یک سوپرکلاس باید با اشیاء یک طبقه جایگزین شوند بدون اینکه بر درستی برنامه تأثیر بگذارند.برای خدمات میکرو، LSP تضمین می کند که پیاده سازی های مختلف یک رابط خدمات (به عنوان مثال، یک دروازه پرداخت که می تواند از Stripe به PayPal تغییر کند) به طور مداوم رفتار می کنند و می توانند بدون شکستن مصرف کنندگان مبادله شوند.

اصل Segregation (ISP)

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

اصل عدم وابستگی (DIP)

بسته به Abstractions، نه در خدمات میکروسرویس ها، خدمات باید به رابط های انتزاعی مانند کارگزار پیام، دروازه های API یا مش های خدمات به جای ارجاع سخت به خدمات دیگر بستگی داشته باشد.این امکان می دهد پیاده سازی های مبادله، معرفی مدار شکستن، یا اضافه کردن لایه های Caching بدون تغییر منطق کسب و کار.

چرا اصول SOLID در Microservices مهم هستند

Microservices به طور ذاتی نیاز به مرزهای روشن، اتصال شل و انسجام بالا دارد. اصول SOLID یک چارچوب ثابت برای دستیابی به این کیفیت ها فراهم می کند بدون آنها، تیم ها اغلب به ضد مواد مخدر مانند "مستندون توزیع شده" سقوط می کنند، جایی که خدمات به طور محکم از طریق پایگاه های داده های مشترک یا API های چت همراه هستند. اعمال SOLID جلوگیری از این با اجرای نگرانی های جدایی در سطح معماری.

علاوه بر این، با افزایش تعداد خدمات، هزینه تغییرات به طور چشمگیری افزایش می یابد اگر وابستگی ها مدیریت نشوند. SOLID اصول وابستگی ها را روشن و غیر قابل قبول نگه می دارند، به تیم ها اجازه می دهد تا به طور مستقل خدمات را تکامل دهند.این به طور مستقیم با اهداف میکروسرویس ها هماهنگ می شود: قابلیت استقرار مستقل، مقیاس پذیری و انعطاف پذیری.

مزایای استفاده از اصول SOLID در Microservices

قابلیت پذیری پیشرفته

هنگامی که هر سرویس مسئولیتی واحد دارد، تغییر یک سرویس به ندرت بر دیگران تأثیر می گذارد، اضافه کردن یک گام جدید تایید کاربر به سرویس احراز هویت نیازمند تغییراتی در سرویس پروفایل کاربر نیست، این انزوا به طور چشمگیری دامنه تست های بازگشتی و خطرات استقرار را کاهش می دهد. تیم ها می توانند به روز رسانی ها را به خدمات فردی در کادر خود آزاد کنند، چرخه های تحویل سریع.

بهبود مقیاس پذیری

خدمات طراحی شده با SRP و ISP به طور طبیعی دانه های بیشتری هستند.این دانه به سازمان ها اجازه می دهد تا تنها اجزایی را که تقاضای بالاتری دارند، مقیاس کنند، به عنوان مثال، یک پلت فرم جریان ویدیو ممکن است سرویس رمزگذاری آن را به طور مستقل از سرویس جستجوی متاداده آن مقیاس کند، زیرا وابستگی ها معکوس (DIP)، مقیاس پذیری خدمات نیاز به مقیاس بالا یا پایین بودن آن ندارد.

انعطاف پذیری و قابلیت پذیری بیشتر

جداسازی رابط تضمین می کند که خدمات تنها آنچه مصرف کنندگان نیاز دارند را به حداقل می رساند و باعث می شود که این رابط ها در چندین مصرف کننده قابل استفاده مجدد باشند، به عنوان مثال، یک سرویس اطلاع رسانی با رابط های جداگانه برای ایمیل، SMS و اعلان های فشار می تواند بدون تغییر، صورتحساب و خدمات حساب بدون نیاز به تغییرات استفاده شود. Open / اصل بسته بیشتر امکان اضافه کردن کانال های اطلاع رسانی جدید (به عنوان مثال، رابط کاربری موجود) را بدون تغییر رابط کاربری فراهم می کند.

آزمون پذیری بهتر

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

تحمل خطا و انعطاف پذیری

با تشویق به DIP، خدمات وابسته به کانال های ارتباطی انتزاعی مانند صف پیام یا پروکسی های مش خدمات می باشد.این انتزاعها می توانند retries، timeouts، breakers مدار و فله بدون تغییر منطق خدمات را اجرا کنند.به عنوان مثال، یک سرویس سفارش که رویدادهای پرداخت را از طریق یک کارگزار پیام (DIP) ارسال می کند به عملکرد حتی اگر خدمات پرداخت به طور موقت، به عنوان پردازش حوادث بعدی.

ساده تر کردن Onboarding و Team Autonomy

هنگامی که خدمات از SRP و ISP پیروی می کنند، مسئولیت های آنها روشن و محدود است. توسعه دهندگان جدید می توانند به سرعت هدف یک سرویس را درک کنند. تیم ها می توانند مجموعه ای از خدمات مرتبط را بدون نیاز به دانش عمیق از دیگران داشته باشند.این امر انواع تیم های مستقل و متقابل را که خدمات میکرو وعده می دهند، قادر می سازد.

کاربرد عملی SOLID در Microservices

تعریف خدمات Boundaries با SRP

با حذف دامنه خود را به زمینه های محدود شده شروع کنید.هر زمینه به عنوان یک سرویس تبدیل می شود.به عنوان مثال، در یک سیستم تجارت الکترونیک، ایجاد خدمات جداگانه برای کاتالوگ، سبد، سفارش، پرداخت، محموله ها و بررسی ها.هر سرویس دارای داده ها و قوانین تجاری آن است.

طراحی رابط های پایدار با OCP و ISP

تعاریف رابط (قراردادها) با استفاده از protobuf، OpenAPI یا AsyncAPI. اطمینان حاصل کنید که این رابط ها نسخه برداری شده و غیر قابل تنظیم هستند، به عنوان مثال، یک رویداد "سفارش ایجاد شده" باید شامل زمینه هایی باشد که شما در مورد آن مطمئن هستید، اما اجازه دهید زمینه های آینده از طریق ویژگی های اختیاری از تجزیه و تحلیل تغییرات با اضافه کردن نقاط جدید یا انواع پیام به جای تغییر آنهایی که در حال حاضر هستند.

تضمین جایگزین شدن با LSP

هنگامی که خدمات متعدد همان رابط را پیاده سازی می کنند (به عنوان مثال، آداپتورهای دروازه پرداخت چندگانه)، تست های ادغام را استاندارد کنید که هر پیاده سازی را به رفتار مورد انتظار تأیید می کند (به عنوان مثال، پذیرش پرداخت یک موفقیت یا شکست با کدهای خطای ثابت) این باعث می شود دروازه های مبادله امن باشد.

عدم رعایت وابستگی ها با پیام رسانی و خدمات مش

به جای سرویس A که یک تماس مستقیم HTTP را به سرویس B می دهد، یک رویداد را به یک کارگزار پیام (Kafka، RabbitMQ) ارسال کرده و یا از یک سرویس (Istio، Linkerd) استفاده کنید. این سرویس می تواند دوباره کار کند، زمان بندی و سیاست های مسدود کننده مدار. منطق کسب و کار در داخل سرویس A همچنان یک آگنوستیک برای شبکه اصلی است.

چالش ها و ملاحظات

اعمال اصول SOLID در میکروسرویس ها بدون چالش نیست.بیش از حد گزارش (ISP بیش از حد تهاجمی) می تواند منجر به رابط های چت و خدمات بسیار زیاد شود، افزایش سربار عملیاتی به طور مشابه، سخت SRP ممکن است باعث ایجاد میکروسرویس ها برای هر واحد کوچک کار، منجر به " تعادل خدمات" می شود.

چالش دیگر نسخه برداری و سازگاری معکوس است، پس از OCP نیاز به سیاست های دقیق تخریب مانند registries طرح (Confluent Schema Registry Registry Registry Registry Registry Registry Registry، Apicurio) می تواند به مدیریت سطح سازگاری کمک کند.

در نهایت، فرهنگ تیم و هماهنگی سازمانی مهم است بدون مالکیت و ارتباطات روشن، حتی خدمات SOLID به خوبی تعریف شده می تواند به شدت از طریق عادت های سازمانی همراه شود (به عنوان مثال، پایگاه های داده مشترک یا کتابخانه های مشترک) یکپارچه سازی مداوم و شیوه های DevOps باید از استقرار مستقل پشتیبانی کنند.

نتیجه گیری

اتخاذ اصول SOLID در معماری میکروسرویس ها یک گلوله نقره نیست؛ بلکه یک راهنمای قدرتمند برای سیستم های ساختمانی است که قابل نگهداری، مقیاس پذیر و انعطاف پذیر هستند.با تمرکز بر مسئولیت های روشن، قراردادهای پایدار، جایگزینی، رابط های ریز و در وابستگی ها، تیم ها می توانند از بسیاری از مشکلات رایج سیستم های توزیع شده جلوگیری کنند. [۱۰]