در این قسمت از سری آموزش کامل طراحی معماری نرم افزاری مایکروسرویس ها از وبسایت پرووید در رابطه با سه موضوع بسیار مهم در طراحی موفق معماری مایکروسرویس ها صحبت خواهیم کرد. این سه مقوله شامل؛ اندازه، حوزه و قابلیت‌های پیاده‌سازی شده در هر مایکروسرویس می شود.
یکی از موضوعات بسیار مهم در طراحی موفق معماری مایکروسرویس، انتخاب صحیح اندازه، حوزه و قابلیت‌های یک مایکروسرویس می باشد. اگر از همان ابتدای کار قصد دارید که یک نرم افزار را با معماری مایکروسرویس ها ایجاد کنید و یا حتی یک سری از سرویس ها یا اپلیکیشن‌ها را به مایکروسرویس تبدیل خواهید کرد، نیاز داریم که در رابطه با این سه مقوله به صورت جدی فکر کنید. این که اندازه و حوزه و قابلیت های پیاده سازی شده در یک مایکروسرویس به چه شکل ایجاد شده اند، در موفقیت یا شکست یک نرم افزار با این معماری تأثیر بسیار زیادی دارند. شاید به جرأت بتوان گفت که یکی از مهمترین مسائل و دشوارترین تصمیماتی که در طراحی معماری مایکروسرویس ها و پیاده سازی آن ها می بایست گرفته شود، فکر کردن و تصمیم گیری در رابطه با همین سه مقوله است. در ادامه برخی از مفاهیم اساسی و کلیدی و البته تعدادی از کج فهمی ها در رابطه با این مقوله ها را بررسی خواهیم کرد:
یکی از موضوعات مهم برای کسب موفقیت در پیاده سازی معماری مایکروسرویس ها، توجه کردن به برخی از اصول و استانداردهای است که در ادامه در رابطه با آنها صحبت خواهیم کرد.
یکی از مهمترین اصول که باید در معماری مایکروسرویس ها به آن توجه کرد، اصل SRP و یا همان single responsibility principle یا اصل تک وظیفه ای می باشد که یکی از اصول پنجگانه SOLID به حساب می‌آید. اهمیت اصل SRP در معماری مایکروسرویس ها به این معناست که حوزه تجاری و یا اصطلاحاً business scope یک مایکروسرویس می بایست بسیار محدود و متمرکز باشد و بر روی پیاده سازی یک نیازمندی تمرکز کرده باشد. این موضوع به ما کمک می‌کند تا در توسعه و تحویل یک مایکروسرویس به صورت چابک عمل کنیم.
علاوه بر این، موضوع در فاز طراحی می بایست boundary و یا مرزهای مایکروسرویس ها را به صورت صحیح تشخیص داده و آنها را بر اساس قابلیت های تجاری مورد نیاز، پیاده سازی کنیم. این موضوع در طراحی دامنه محور و یا domain driven design تحت عنوان bounded context شناخته می‌شود.
مورد بعدی که در طراحی و معماری صحیح مایکروسرویس ها می تواند بسیار مؤثر باشد، مستقل بودن و چابک بودن آنها در توسعه و البته deploy کردن می باشد. می بایست بر روی scope و یا حوزه یک مایکروسرویس تمرکز کرد و نه لزوماً تلاش به کوچکتر کردن آن مایکروسرویس نمود.
یکی دیگر از مواردی که می بایست به عنوان یک روش کلی از آن استفاده کنید؛ این است که در ابتدا، مرزهای سرویس ها را نسبتاً گسترده تر در نظر بگیرید و سپس رفته رفته با اعمال refactoring هایی، بر روی نیازمندی های تجاری تمرکز کنید.
در مثال هایی که در قسمت های قبلی از این آموزش خدمت شما عرض شد، ما توانستیم که یک اپلیکیشن monolith را به یک معماری مایکروسرویس با ۴ سرویس مختلف با نام‌های inventory و accounting و shipping و store تقسیم کنیم. هر کدام از این مایکروسرویس ها بر روی یک حوزه تجاری متمرکز و محدود تمرکز کرده اند. بنابراین، هر کدام از سرویس ها کاملاً از دیگر سرویس‌ها decouple گردیده اند. این موضوع باعث می‌شود که مایکروسرویس ها در توسعه و استقرار و یا به عبارت دیگر؛ development و deployment کاملاً مستقل و به صورت چابک عمل کنند.
منبع: وبسایت پرووید
