طراحی صحیح مایکروسرویس ها: اندازه و حوزه و قابلیت ها

در این قسمت از سری آموزش کامل طراحی معماری نرم افزاری مایکروسرویس ها از وبسایت پرووید در رابطه با سه موضوع بسیار مهم در طراحی موفق معماری مایکروسرویس ها صحبت خواهیم کرد. این سه مقوله شامل؛ اندازه و حوزه و قابلیت‌های پیاده‌سازی شده در هر مایکروسرویس می شود. ضمناً در همین قسمت توصیه می‌کنیم که در صورت تمایل، از بسته ی آموزش ویدئویی معماری مایکروسرویس ها در نرم افزار استفاده کنید.یکی از موضوعات بسیار مهم در طراحی موفق معماری مایکروسرویس، انتخاب صحیح اندازه، حوزه و قابلیت‌های یک مایکروسرویس می باشد. اگر از همان ابتدای کار قصد دارید که یک نرم افزار را با معماری مایکروسرویس ها ایجاد کنید و یا حتی یک سری از سرویس ها یا اپلیکیشن‌ها را به مایکروسرویس تبدیل خواهید کرد، نیاز داریم که در رابطه با این سه مقوله به صورت جدی فکر کنید. این که اندازه و حوزه و قابلیت های پیاده سازی شده در یک مایکروسرویس به چه شکل ایجاد شده اند، در موفقیت یا شکست یک نرم افزار با این معماری تاثیر بسیار زیادی دارند. شاید به توان به جرات گفت که یکی از مهم‌ترین مسائل و دشوارترین تصمیماتی که در طراحی معماری مایکروسرویس ها و پیاده سازی آن ها می بایست گرفته شود، فکر کردن و تصمیم گیری در رابطه با همین سه مقوله است. در ادامه برخی از مفاهیم اساسی و کلیدی و البته تعدادی از کج فهمی ها در رابطه با این مقوله ها را بررسی خواهیم کرد:تعداد خطوط کد و یا حتی تعداد اعضای برنامه نویس که در یک تیم توسعه وجود دارند، معیارهای خوبی برای مشخص کردن اندازه یک مایکروسرویس نیستند. اغلب دیده شده است که تعداد خطوط کد درون یک مایکروسرویس به عنوان یک معیار برای اندازه گیری کردن سایز یک مایکروسرویس مورد استفاده قرار می‌گیرد. این معیارها کاملاً غیرکاربردی و غیر اساسی هستند. چراکه به سادگی می‌توان سرویس‌های را ایجاد کرد که خطوط کد کمی داشته باشند اما بسیاری از اصول معماری مایکروسرویس ها را نقض کنند.کلمه ماکرو که در زبان انگلیسی به معنی کوچک است ممکن است یک واژه سردرگم کننده باشد. بسیاری از برنامه نویسان فکر می کنند که به دلیل استفاده از واژه ماکرو، می‌بایست تلاش کنند تا یک مایکروسرویس را حتی الامکان به کوچکترین اندازه ممکن تبدیل کنند. این نیز یک درک کاملاً اشتباه است.در فضای سرویس های وب و یا معماری سرویس گرا که در قسمت های قبل از آن صحبت کردیم، سرویس ها اغلب در دانه بندی های متفاوت و متنوع پیاده‌سازی می‌شوند. به عبارت دیگر؛ برخی از سرویس ها ممکن است فقط تعداد اندکی از قابلیت ها را در خود جای داده باشند و برخی دیگر تعداد بیشتری از نیازمندی های تجاری را در خود پیاده سازی کردند. داشتن وب سرویس ها و ایجاد کردن دوباره آنها به عنوان مایکروسرویس ها، لزوما نمی‌تواند به شما مزیت های معماری مایکروسرویس ها را بدهد. ضمناً در رابطه با معماری سرویس گرا توصیه می کنیم از بسته ی آموزش ویدئویی برنامه نویسی سرویس گرا WCF RIA Services استفاده کنید.یکی از موضوعات مهم برای کسب موفقیت در پیاده سازی معماری مایکروسرویس ها، توجه کردن به برخی از اصول و استانداردهای است که در ادامه در رابطه با آنها صحبت خواهیم کرد.استانداردها در پیاده سازی معماری میکروسرویس هایکی از مهمترین اصول که باید در معماری مایکروسرویس ها به آن توجه کرد، اصل SRP و یا همان single responsibility principle یا اصل تک وظیفه ای می باشد که یکی از اصول پنجگانه SOLID به حساب می‌آید. در رابطه با اصول پنجگانه SOLID می توانید از آموزش ویدئویی اصول سالید (SOLID) در برنامه نویسی شی گرا و بسته ی آموزش ویدئویی اصول SOLID در طراحی شی گرا استفاده کنید. اهمیت اصل SRP در معماری مایکروسرویس ها به این معناست که حوزه تجاری و یا اصطلاحاً business scope یک مایکروسرویس می بایست بسیار محدود و متمرکز باشد. و بر روی پیاده سازی یک نیازمندی تمرکز کرده باشد. این موضوع به ما کمک می‌کند تا در توسعه و تحویل یک مایکروسرویس به صورت چابک عمل کنیم.علاوه بر این موضوع در فاز طراحی می بایست boundary و یا مرزهای مایکروسرویس ها را به صورت صحیح تشخیص داده و آنها را بر اساس قابلیت های تجاری مورد نیاز، پیاده سازی کنیم. این موضوع در طراحی دامنه محور و یا domain driven design تحت عنوان bounded context شناخته می‌شود. ضمناً در رابطه با domain driven design می توانید از بسته ی آموزش ویدئویی اصول طراحی نرم افزار Domain Driven Design و بسته ی آموزش ویدئویی کاربردی طراحی نرم افزار Domain Driven Design استفاده کنید.مورد بعدی که در طراحی و معماری صحیح مایکروسرویس ها می تواند بسیار موثر باشد، مستقل بودن و چابک بودن آنها در توسعه و البته deploy کردن می باشد. می بایست بر روی scope و یا حوزه یک مایکروسرویس تمرکز کرد و نه لزوما تلاش به کوچکتر کردن آن مایکروسرویس نمود.یکی دیگر از مواردی که می بایست به عنوان یک روش کلی از آن استفاده کنید؛ این است که در ابتدا، مرزهای سرویس ها را نسبتاً گسترده تر در نظر بگیرید و سپس رفته رفته با اعمال refactoring هایی، بر روی نیازمندی های تجاری تمرکز کنید. ضمناً در رابطه با refactoring توصیه می‌کنیم از بسته ی آموزش ویدئویی ریفکتورینگ در سی شارپ و بسته ی آموزش ویدئویی کدنویسی تمیز: نوشتن کد برای انسان ها استفاده نمایید.در مثال هایی که در قسمت های قبلی از این آموزش خدمت شما عرض شد، ما توانستیم که یک اپلیکیشن monolith را به یک معماری مایکروسرویس با ۴ سرویس مختلف با نام‌های inventory و accounting و shipping و store تقسیم کنیم. هر کدام از این مایکروسرویس ها بر روی یک حوزه تجاری متمرکز و محدود تمرکز کرده اند. بنابراین هر کدام از سرویس ها کاملا از دیگر سرویس‌ها decouple گردیده اند. در رابطه با coupling و cohesion می توانید از بررسی مفاهیم Cohesion و Coupling در توسعه نرم افزار استفاده کنید. این موضوع باعث می‌شود که مایکروسرویس ها در توسعه و استقرار و یا به عبارت دیگر؛ development و deployment کاملاً مستقل و به صورت چابک عمل کنند.