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

معماری Microservices - گونه‌ای از معماری سرویس‌محور (SOA) - یک رویکرد توسعه‌یافته است که از دنیای طراحی دامنه‌محور پدید آمده است:محاسبات کارآمد را امکان پذیر می کندبه ساخت برنامه های کاربردی ارتجاعی کمک می کندبا این حال، مانند هر رویکرد دیگری برای توسعه برنامه، معماری میکروسرویس ها چالش های خاص خود را دارد. همچنین موارد استفاده ای وجود دارد که سازمان ها متوجه افزایش پیچیدگی و تلاش برای توسعه برنامه های کاربردی با چارچوب میکروسرویس می شوند.این مقاله به این چالش‌ها می‌پردازد، از جمله زمانی که نباید از میکروسرویس‌ها استفاده کنید. بیا یک نگاهی بیندازیم.بررسی اجمالی میکروسرویس هارویکرد میکروسرویس به معنای طراحی و توسعه یک برنامه کاربردی به عنوان گروهی از سرویس‌های مرتبط با هم است که برای دستیابی به یک هدف تجاری اعلام‌شده، با یکدیگر ارتباط برقرار می‌کنند.الگوی رو به افزایش نرخ پذیرش گسترده‌تر تأیید می‌کند که موارد استفاده متعددی وجود دارد که در آن کسب‌وکارها از استفاده از میکروسرویس‌ها برای توسعه و استقرار برنامه‌ها سود می‌برند. از این گذشته، میکروسرویس ها اغلب اولین قدم برای پذیرش فرهنگ DevOps در نظر گرفته می شوند که این امکان را فراهم می کند:اتوماسیونمقیاس پذیری بهبود یافتهمدیریت پذیریچابکیتحویل و استقرار سریعتربه همین دلیل، معماری میکروسرویس معمولاً اولین انتخاب برای مشاغلی است که به دنبال بازنویسی برنامه های کاربردی قدیمی برای استفاده از زبان های برنامه نویسی مدرن و پشته فناوری هستند.با وجود تمام این مزایا، ممکن است تعجب کنید که چه چالش هایی می تواند باشد.چالش های معماری میکروسرویس هااکنون، بیایید به رایج‌ترین چالش‌های شرکت‌ها یا تیم‌های محصول که میکروسرویس‌ها را اتخاذ می‌کنند، بپردازیم.طرحدر مقایسه با اپلیکیشن‌های یکپارچه، سازمان‌ها هنگام طراحی میکروسرویس‌ها با پیچیدگی‌های بیشتری روبرو هستند. با استفاده از میکروسرویس برای اولین بار، ممکن است در تعیین موارد زیر مشکل داشته باشید:اندازه هر میکروسرویسمرزها و نقاط اتصال بهینه بین هر میکروسرویسچارچوبی برای ادغام خدماتطراحی میکروسرویس ها مستلزم ایجاد آنها در یک زمینه محدود است. بنابراین، هر میکروسرویس باید یک مسئولیت خاص را روشن، کپسوله و تعریف کند.برای انجام این کار برای هر مسئولیت/عملکرد، توسعه‌دهندگان معمولاً هنگام مدل‌سازی دامنه از نمای داده محور استفاده می‌کنند. این رویکرد چالش خاص خود را ایجاد می کند - بدون منطق، داده ها بی معنی هستند.امنیتمیکروسرویس ها اغلب در محیط های چند ابری مستقر می شوند که منجر به افزایش ریسک و از دست دادن کنترل و دید اجزای برنامه می شود و در نتیجه نقاط آسیب پذیر بیشتری ایجاد می شود. با ترکیب این چالش، هر میکروسرویس از طریق لایه‌های زیرساختی مختلف با دیگران ارتباط برقرار می‌کند و آزمایش این آسیب‌پذیری‌ها را سخت‌تر می‌کند.امنیت داده در چارچوب مبتنی بر ریزسرویس نیز یک نگرانی برجسته است. به این ترتیب، داده‌ها در چنین چارچوبی توزیع می‌شوند و حفظ محرمانگی، یکپارچگی و حریم خصوصی داده‌های کاربر را به یک تمرین دشوار تبدیل می‌کند.با توجه به چارچوب توزیع شده آن، تنظیم کنترل های دسترسی و اجرای احراز هویت ایمن برای سرویس های فردی نه تنها یک چالش فنی ایجاد می کند، بلکه سطح حمله را نیز به میزان قابل توجهی افزایش می دهد.آزمایش کردنمرحله آزمایش هر چرخه عمر توسعه نرم افزار (SDLC) به طور فزاینده ای برای برنامه های کاربردی مبتنی بر میکروسرویس پیچیده است. با توجه به ماهیت مستقل هر میکروسرویس، شما باید خدمات جداگانه را به طور مستقل آزمایش کنید.با تشدید این پیچیدگی، تیم‌های توسعه همچنین باید خدمات و وابستگی‌های متقابل آنها را در برنامه‌های آزمایشی یکپارچه کنند.افزایش پیچیدگی عملیاتیتیم هر میکروسرویس معمولاً وظیفه تصمیم گیری درباره فناوری استفاده و مدیریت آن را دارد. از آنجایی که هر سرویس باید به طور مستقل مستقر و اجرا شود، حفظ عملیات ممکن است یک قوطی از کرم ها را برای کسانی که آماده نیستند باز کند.در اینجا چند چالش وجود دارد:اشکال سنتی نظارت ممکن است برای یک برنامه مبتنی بر میکروسرویس کار نکنند. سناریویی را در نظر بگیرید که در آن یک درخواست از رابط کاربری قبل از رسیدن به سرویسی که می تواند درخواست آن را برآورده کند، چندین سرویس را طی می کند. نتیجه این پیمایش یک مسیر پیچیده از خدمات است، و بدون ابزار نظارتی مناسب، شناسایی علت اصلی یک مشکل نه تنها دشوار است، بلکه اغلب غیرممکن است.مقیاس پذیری یکی دیگر از چالش های عملیاتی مرتبط با معماری میکروسرویس ها است. اگرچه مقیاس پذیری میکروسرویس ها اغلب به عنوان یک مزیت معرفی می شود، مقیاس موفقیت آمیز برنامه های کاربردی مبتنی بر میکروسرویس چالش برانگیز است.بهینه سازی و مقیاس بندی نیاز به هماهنگی پیچیده تری دارد. در یک چارچوب معمولی میکروسرویس، یک برنامه کاربردی به سرویس‌های مستقل کوچک‌تر تقسیم می‌شود که در سرورهای جداگانه میزبانی و مستقر می‌شوند. این معماری نیاز به هماهنگی اجزای جداگانه دارد، که چالش دیگری است به ویژه زمانی که شما یک جهش ناگهانی در استفاده از برنامه را تجربه می کنید.تحمل خطا برای هر سرویس مورد نیاز است. کسب‌وکارها به ریزسرویس‌های خود نیاز دارند که به اندازه کافی انعطاف‌پذیر باشند تا در برابر شکست‌های داخلی و خارجی مقاومت کنند. در یک برنامه کاربردی مبتنی بر میکروسرویس، خرابی یک جزء می تواند کل سیستم را تحت تأثیر قرار دهد. بنابراین، چارچوبی که استفاده می‌کنید باید تحمل خطا را برای هر سرویس در نظر بگیرد تا از طراحی اطمینان حاصل شود که از شکست کل یک برنامه در صورت قطعی سرویس فردی جلوگیری می‌کند.ارتباطمیکروسرویس های مستقر به طور مستقل به عنوان برنامه های کاربردی مستقل مینیاتوری عمل می کنند که با یکدیگر ارتباط برقرار می کنند. برای رسیدن به این هدف، باید لایه‌های زیرساختی را پیکربندی کنید که اشتراک‌گذاری منابع را در بین سرویس‌ها فعال می‌کند.یک پیکربندی ضعیف ممکن است منجر به موارد زیر شود:افزایش تاخیرکاهش سرعت تماس با سرویس های مختلفدر این شرایط، شما یک برنامه غیر بهینه با زمان پاسخ آهسته دارید.چه زمانی از میکروسرویس ها استفاده نکنیدهر سازمانی که به یک چارچوب جدید تغییر می‌کند، باید برای اطمینان از تناسب مناسب، بررسی‌های لازم را انجام دهد.هنگام کاوش در میکروسرویس ها، این سه موقعیت همیشه به شما کمک می کند تا تصمیم بگیرید چه زمانی از معماری میکروسرویس برای برنامه انتخابی خود صرف نظر کنید.دامنه تعریف شده شما نامشخص/نامشخص استبه یاد داشته باشید که میکروسرویس ها را در یک زمینه محدود ایجاد می کنید. بنابراین، اگر تجزیه نیازمندی‌های کسب‌وکار شما به حوزه‌های خاص از نظر منطقی پیچیده باشد، ایجاد ریزسرویس‌های با اندازه مناسب برای شما به همان اندازه دشوار خواهد بود.چالش طراحی یک وسیله ارتباطی مناسب در میان سرویس‌های مختلف را به آن اضافه کنید – این پیچیدگی احتمالاً برای شما بسیار زیاد است که نمی‌توانید حداکثر مزایا را در میکروسرویس‌ها متوجه شوید.همچنین آینده را در نظر بگیرید. اگر مطمئن نیستید که دامنه برنامه شما در سال‌های آتی ثابت باقی می‌ماند، عاقلانه است که از رویکرد میکروسرویس‌محور استفاده نکنید.بهره وری بهبود یافته تضمین نشده استبرای تکرار، ایده پذیرش Microservices پذیرش فرهنگ DevOps است که به نوبه خود:از اتوماسیون استفاده می کندهزینه و تلاش را کاهش می دهدبهره وری عملیاتی را به ارمغان می آوردبررسی های لازم را انجام دهید تا بررسی کنید که آیا انتقال به یک چارچوب میکروسرویس واقعا به دستیابی به این اهداف کمک می کند. هیچ سازمانی نمی‌خواهد پیچیدگی‌ها و تلاش‌ها را صرفاً برای اتخاذ یک فرهنگ بدون دستیابی به کارایی بهبود یافته اضافه کند.اندازه برنامه کوچک یا غیر پیچیده استهنگامی که اندازه برنامه شما نیاز به تقسیم آن به اجزای کوچکتر را توجیه نمی کند، استفاده از چارچوب میکروسرویس ممکن است ایده آل نباشد. نیازی به تجزیه بیشتر برنامه هایی که در حال حاضر به اندازه کافی کوچک هستند وجود ندارد.به یاد داشته باشید که ایده استفاده از یک فریم ورک میکروسرویس، تجزیه یک برنامه پیچیده به مجموعه ای از خدمات مختلف و کوچکتر است. وقتی یک کد برنامه از قبل به اندازه کافی کوچک و ساده است – نه پیچیده – انتقال آن به یک چارچوب میکروسرویس تنها پیچیدگی‌هایی را اضافه می‌کند.آیا میکروسرویس ها برای من مناسب هستند؟در حالی که اتخاذ یک معماری میکروسرویس تحویل سریع‌تر و کیفیت نرم‌افزار را بهبود می‌بخشد، کسب‌وکارها باید به دقت در مورد انتخاب این رویکرد فکر کنند. مزایای انتقال از مدل یکپارچه به ریزسرویس ده ها سکه است - اما هنوز چالش هایی وجود دارد که باید در نظر گرفت.قانون کلی برای انتخاب میکروسرویس ها:اگر معایب استفاده از میکروسرویس ها بیشتر از مزایا باشد، و/یا مزایا در مقایسه با تلاش و هزینه صرف شده ناچیز باشد، میکروسرویس ها احتمالاً رویکرد مناسبی برای برنامه کاربردی نیستند.