چرا از میکروسرویس نباید استفاده کنیم و راه جایگزین چیست؟

درود خدمت دوستان . چون در پست دیگه این بحث به وجود اومد بنده هم به عنوان یک تازه وارد در زمینه برنامه نویسی برام جالب شد دلایل رو بدونم

بخشی از پست در اینجا هست

که یک مطلب نیز منتشر شد

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

حالا یک سوال نرم افزار های بزرگ یا وب سرویس های بزرگ چه راه حل هایی برای این کار دارند جز میکروسرویس و مستقل کردن دیتابیس ها کش ها و همینطور تنظیم و بخش بندی مناسب پروژه هاشون

امید وارم نظرات شما عزیزان در این مطلب درج بشه تا بنده و افرادی هم سطح بنده بتونند استفاده کنند .

2 Likes

سو برداشت نشه … میکرو سرویس بد نیست … تو این پست هم ک دادم ببینید … مشکلاتش گفته شده و در آخر نتیجه گیری خوبی کرده . . ک میکروسرویس برا کیا مناسبه و برا کی مناسب نیست …

و نتیجه هم اینجور هست ک … میکرو برای تیم های کوچیک و تیم هایی ک از تکنولوژی واحد استفاده میکنن و میتونن تیم ورک خوبی رو شکل بدن … مناسب نیست … …

آپشن های دیگه ای هم هستن تو اسکیل های بزرگ … مثل serverless ک نمونش amazon lambda هستش…

این مقیاس ک صحبت میکنیم درباره “نرم افزار بزرگ” میشه فیس بوک و خود آمازون … ک وقتی تیم به اون حد رسید … میشه معماری رو میکروسرویسی کرد … اما استفادش تو مقیاس شخصی و تیم کوچیک … مشکلات زیادی رو بوجود میاره

3 Likes

نه بنده دقیقا صحبت شما درک کردم منظور من این هم نیست که کلا دیگه نباید استفاده بشه .

ببنید یکی از دلایلی که بنده سعی کردم از اون استفاده کنم یعنی میکروسرویس این بوده که ممکن بود موارد زیر پیش بیاد

۱. نمی خواستم یک دیتابیسم انقدر درگیر بشه که برای کار های دیگه نتونه خدمات بده
۲. امکان داره من هر سرویس رو بعدا می بردم روی یک سرور
۳. و همینطور جنبه آموزشی برای خودم .

جایگزین چی هست وقتی پروژه ای ۲ الی ۳ سال طول می کشه کامل بشه و امکان داره کاربران زیادی رو داشته باشه جایگزین میکرسوریس چیست .

اگر تصویری که در اون پست قرار دادم شما در یک سیستم یک پارچه چطور رفتار می کردید مثلا ۳ تا دیتابیس کانتینر می ساختید بجای هر دیتابیس برای هر میکروسرویس ؟

یا قسمت کشینگ کاربران با کشینگ مثلا سیستم مدیریت محتوا کلا جداست مثلا شما می آیید دوتا کانتینر ردیس درست می کنید ؟

اگر بشه مدل های تصویری خوبی مدنظرتون هست هم قرار بدید ممنون می شم
تا قشنگ درک کنمش مخصوصا سیستم هایی که درخواست روشون نیازه

2 Likes

اگر به من باشه … و اگر با متدولوژی هایی مثل اسکرام اجایل آشنا باشید … چند سال وقت نمیزاریم روی یه پروژه … و با معماری مونولیتیک شروع میکنیم … تا بازار رو از دست ندیم و یه پروتوتایپ بیاریم بالا سریعا…

از لحاظ رفع سربار و یا بهینه بودن هم میکرو با مونو تفاوت زیادی نداره … اینها صرفا برای دولوپ هستن ک حائز اهمیت هستن …

فرض کنید یه ۱۰ نفر cppکار با تجربه به تیم تون برای یه بخش پردازشی وارد میشن … خب از اینها نمیشه انتظار داشت الیکزیر درک کنن یا بتونن بزنن … و اینجا شما apiمیدید بهشون… تا اونها کارشونو مستقلن انجام بدن و به سیستم شما جوین بشن .
… در نهایت توی مونو … با تکرار اپ روی نود های دیگه (کلاسترینگ) و لود بالانسر ها … میزان منابع و پهنا جبران میشه .

مدل تصویر چندتایی سراغ داشتم از تفاوت ها و مشابهت ها و اصولی بودن معماری … ک الان تو دسترسم نیست … شب براتون قرار میدم …

3 Likes

به نظر من میکرو سرویس ها به شکلی که الان وجود داره (‌همه سرویس ها با یه web API باهم در ارتباط هستند) کلا ناکارامد هست و مشکلات زبادی داره. در مورد جایگزین هم بستگی به پروژه و مورد استفاده داره اما در کل خیلی خیلی فکر می کنم متدلوژی هایی مثل lambda، kapa و reactive برای طراحی نرم افزار کارامد هستند البته تغییرات زیادی روشون نیاز هست. برای مثال یه نگاهی به Apache Samza و Commander Pattern بندازین. امثال اینها زیادن البته.

برای پروژه های کوچیک هم نباید زودتر از موعد درگیر این مسائل شد. خوبه که گوشه ذهن باشه و با توجه به نیاز آینده پیش برید اما از یه سیستم یکپارچه کوچیک شروع کنین خیلی بهتره

4 Likes
3 Likes

این مقاله رو وقت کردید بخونید ضرر نداره.