معایب معماری میکروسرویس ها

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

معماری میکروسرویس برای توسعه برنامه کاربردی در فضای ابری، یک رویکرد معماری است که یک برنامه نرم افزاری را به عنوان مجموعه ای از خدمات کوچک (“میکرو”) می سازد که به طور آزاد مرتبط هستند. هر سرویس در معماری نشان دهنده یک قابلیت یا عملکرد تجاری خاص است، مانند افزودن یک آیتم موجودی به یک پایگاه داده یا بررسی اعتبار مشتریان جدید. آنها معمولاً به عنوان یک فرآیند جداگانه عمل می کنند و از طریق API یا پروتکل های سبک با سایر سرویس ها ارتباط برقرار می کنند.

خدمات میکرو از معماری سرویس‌محور و نیاز به ساخت برنامه‌های کاربردی بهتر پدید آمدند. به چند دلیل خوب، این محبوب ترین رویکرد برای ساخت برنامه های کاربردی جدید است. من استفاده از معماری میکروسرویس را دوست دارم زیرا کوپلینگ و جداسازی آزاد را ارائه می دهد.

مزایای میکروسرویس ها

سرویس‌ها طوری طراحی شده‌اند که به‌صورت آزاد وصل شوند. آنها می توانند به طور مستقل بدون وابستگی مستقیم به جزئیات پیاده سازی داخلی موجود در سایر سرویس ها عمل کنند. آن‌ها به تیم‌ها اجازه می‌دهند تا خدمات را به تنهایی توسعه، استقرار و مقیاس‌بندی کنند و چابکی بهتری را ارتقا دهند. مزایای اضافی افزایش انعطاف پذیری است زیرا آنها به طور مستقل اجرا می شوند.

این نشان دهنده مزایای استقلال و انزوا است که مستقیماً با اتصال شل مرتبط است. هر سرویس را می توان به طور مستقل توسعه، آزمایش، استقرار و مقیاس بندی کرد.

راستش را بخواهید، زمانی که در صحنه ظاهر شد، انقلابی نبود. این بیشتر تحولی از بهترین شیوه های معماری بود که در دهه ۱۹۷۰ با توسعه ساختاریافته، سپس توسعه شی گرا، توسعه مبتنی بر مؤلفه، استفاده از خدمات و ریزسرویس ها آغاز شد. هر رویکرد بر روش های زیر تأثیر می گذارد. امیدواریم در این راه، چیزها را بهبود ببخشیم.

معایب میکروسرویس ها

البته، هیچ ناهار رایگان در حال توسعه نیست. هر رویکرد، ابزار، زبان و معماری مزایا و معایبی دارد که باید در نظر بگیرید. این گاهی اوقات در هیاهو گم می شود. بیایید برخی از جنبه های منفی معماری میکروسرویس ها را بررسی کنیم.

بزرگترین آنها پیچیدگی است. میکروسرویس ها در مقایسه با معماری های یکپارچه تر، سطح پیچیدگی بالاتری را معرفی می کنند. سیستم ها به خدمات متعددی تقسیم می شوند. معماری پیچیده تر می شود و درک تعاملات بین سرویس های مختلف می تواند چالش برانگیز باشد.

وقتی در نظر بگیرید که ما با سیستم‌های توزیع‌شده پیچیده به‌عنوان پلت‌فرم‌هایی که میکروسرویس‌ها در آن مستقر می‌شوند نیز سر و کار داریم، این امر حتی سخت‌تر می‌شود. این محصول فرعی ساخت و استقرار چند ابری در تقریباً همه شرکت‌ها است.

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

مدیریت داده نیز پیچیده‌تر است. ریزسرویس ها ممکن است پایگاه داده یا ذخیره داده های خود را داشته باشند که سازگاری داده ها را در سرویس های مختلف پیچیده می کند. معمولاً برای حفظ یکپارچگی داده‌ها به تلاش بیشتری نیاز دارد که شرکت‌ها تا زمانی که آسیب نبیند نمی‌فهمند. این قابل حل است، اما منابع بسیار بیشتری از آنچه که اکثر آنها می فهمند نیاز دارد.

وابستگی به خدمات ممکن است دردناک باشد. از آنجایی که میکروسرویس ها از طریق API ها تعامل دارند، تغییرات در یک سرویس ممکن است پیامدهایی برای سرویس های دیگر داشته باشد. نتیجه؟ چالش‌های نسخه‌سازی و مشکلات احتمالی سازگاری، به‌ویژه در هنگام ارتقا یا تغییرات سرویس.

در نهایت، سربار منابع. اجرای چندین نمونه میکروسرویس، منابع بیشتری را نسبت به یک برنامه یکپارچه برای اکثر برنامه‌های کاربردی مستقر شده مصرف می‌کند. این می تواند هزینه های زیرساخت را افزایش دهد، به خصوص اگر به طور موثر مدیریت نشود. اکثر آنها نیستند.

اکنون کجا؟

متوجه شده‌ام که توسعه‌دهندگان و معماران ابری به معماری میکروسرویس‌ها با شور و شوق مذهبی نزدیک می‌شوند. البته، آنها رویکرد مناسبی برای همه برنامه ها نیستند و در بسیاری از موارد، به یک نیروی مناسب تبدیل می شوند. وقتی برنامه‌هایی را که قبلاً به ابر منتقل شده‌اند یا در حال انتقال به ابر هستند، مدرن می‌کنند، به منابع بسیار بیشتری از آنچه باید نیاز دارند. این به دلیل بسیاری از معایبی است که ذکر کردم.

گفته شد، آنها اغلب معماری نمونه ای برای استفاده هستند. با این حال، شما باید بسیاری از مبادلات را قبل از تعهد به آن در نظر گرفته باشید و باید روی الزامات اصلی برنامه تمرکز کنید. متأسفانه، ما به چیزهای زیادی که باید باشیم توجه نمی کنیم و به دلیل عدم تطابق رویکردها با الزامات اصلی برنامه، با ناکارآمدی مواجه می شویم.

خدمات ریز، مانند هر رویکرد دیگری، باید فقط در زمینه در نظر گرفته شود، همچنین هدف این معماری را در نظر داشته باشد، چه زمانی باید استفاده شود و چه زمانی نباید استفاده شود.