من اشکان کیمیا قلم از گروه میربزرگی هستم و در این مقاله استفاده از معماری مونولیت به جای میکروسرویس و مزایا و معایب استفاده از میکروسرویس توسط شرکت ها را بررسی میکنیم :
در نگاه اول همه جذب سرعت توسعه بالا و امکان پیاده سازی جداگانه بخش های مختلف با استفاده از میکروسرویس می شوند اما یکسری نکات وجود دارند که در پشت صحنه هزینه پروژه را برای شرکت ها افزایش میدهند .در زیر به تعدادی از آن ها میپردازیم :
سینک نگه داشتن داده در میکروسرویس چالش برانگیر میشود. الگوی پیشنهادی در همچین شرایطی استفاده از دیتابیس های مختلف برای هر میکروسرویس می باشد .دلیل پیشنهاد این الگو کم شدن وابستگی تیم ها به یکدیگر وامکان کار کردن مجزا بدون اختلال می باشد .
اما چه اتفاقی میوفته وقتی که 2میکروسرویسی که قرار بوده به صورت سینک کار کنند به مشکل بخورند ؟
به عنوان مثال یکیشون دیتا رو آپدیت بکنه ولی اون یکی موفق نشه ؟ همچین نمونه ای باعث نا هماهنگی در دیتا می شود .
پیدا کردن دیتای ناسازگار داخل سرویس ها کاری بسیار سخت و زمان بر است و علاوه بر این نیازمند کسی می باشد که تجربه کار داخل چند سرویس را داشته باشد.پس نتیجه میگیریم که در همچین شرایطی یکی از اصول اصلی میکروسرویس که جدا بودن هر سرویس و اختصاص داشتن هر سرویس به یک تیم می باشد را زیر پا گذاشته ایم .
اما اگر از معماری مونولیت استفاده کرده بودیم میتوانستیم با قرار دادن جفت این اعمال با داده در داخل یک ترنزکشن درگیر حل کردن همچین مشکلی نشویم .
آماده سازی ویژگی های مختلف داخل معماری مونولیت در مقایسه با میکروسرویس زمان کمتری نیاز دارد . اگرچه که در یک سرویس به مشکل بر نمیخوریم ولی در مواردی که چندین سرویس داریم و باید با یکدیگر تعامل داشته باشند شرایط بسیار پیچیده تر از یک مونولیت میشود.
در مونولیت میتوانیم با آماده سازی متد های عمومی کار را بسیار استاندارد و عمومی جلو ببریم ولی در میکروسرویس شما محکوم به صدا کردن متد های عمومی همان میکروسرویس هستید . در نتیجه علاوه بر همه ی کارها باید API یا Messaging System اختصاصی ارتباط بین سرویس ها را هم پیاده کنید .
لذت سپردن کار به تیم های مجزا در میکروسرویس را بیشتراز هر کسی شرکت های خیلی بزرگ لمس میکنند .
البته که هر موقع حرف از میکروسرویس می شود همه به این ویژگی اشاره میکنند اما این واقعیت را در نظر نمیگیرند که شما نیازمند تعدادی نیرو برای هر میکروسرویس می باشید و باید زمان کافی داشته باشند که سرعت توسعه و خوانایی کد افزایش یابد .
اکثر استارت آپ ها همچین پتانسیلی ندارند و در شروع کار که نیروی کافی وجود ندارد نیازمند نیروهایی می شوند که باید بر روی همه ی سرویس ها کار کنند که کار بسیار سختی است .
یکی از دلایل خیلی مهم استفاده از میکروسرویس ها توانایی اجرای سرویس های مختلف بر روی سرور های مختلف می باشد .انتخاب زیر ساخت مناسب برای هر سرویس میتواند هزینه را به شکل زیادی کاهش دهد اما باید یه این نکته توجه کرد که پیاده سازی ، مانیتورینگ و کانفیگ کردن یک مونولیت اپلیکیشن در مقایسه با یک میکروسرویس کار بسیار آسون تری هستش .
طبق تعاریف چون سرویس ها وابستگی کمی به یکدیگر دارند، امکان ادامه کار در صورت از کار افتادن سرویس های دیگر هم وجود دارد.
اما تقریبا در موارد بسیار کمی ما شاهد وابستگی کم با وجود بزرگ شدن پروژه و زیاد بودن کاربران هستیم .
هرچه تعداد بخش های معماری نرم افزار شما بیشتر شود امکان خطا داشتن هم بالاتر میرود.
در پایان باید به این نکته اشاره کنیم که هدف از این مقاله بد جلوه دادن میکروسرویس نمی باشد . هدف اصلی،برآورد هزینه ی میکروسرویس برای یک شرکت ،نیاز به نیروی حرفه ای در طراحی میکروسرویس و عدم نیاز به میکروسرویس در هر پروژه ای است .
اکثر شرکت ها با پیاده سازی مونولیت هزینه کمتری می کنند .زمان و انرژیتون رو در شروع استارت آپ صرف پیاده سازی میکروسرویس نکنید .
در آخر اگر جایی نیاز به توضیح بیشتر بود حتماً به ما ایمیل بزنید و ما رو خوش حال کنید.
سایت ما رو سر بزنید :
