میکروسرویس چیست؟

میکروسرویس‌ها یک سبک معماری مدرن برای توسعه نرم‌افزارهای مقیاس‌پذیر و ماژولار هستند که به‌جای یک اپلیکیشن یکپارچه (Monolith)، از مجموعه‌ای از سرویس‌های کوچک و مستقل تشکیل شده‌اند. هر سرویس در این معماری، به‌صورت loosely coupled (کم‌وابسته) طراحی می‌شود و مسئول مدیریت بخش مشخصی از منطق تجاری (Business Logic) سیستم است.

هر میکروسرویس معمولاً دارای دیتابیس مستقل، مدل داده اختصاصی، و چرخه توسعه جداگانه است. این سرویس‌ها از طریق پروتکل‌های سبک‌وزن مانند RESTful API یا سیستم‌های Event-Driven (مثل Kafka یا RabbitMQ) با یکدیگر ارتباط برقرار می‌کنند.

نکته مهم در معماری میکروسرویس این است که هر سرویس مانند یک Black Box عمل می‌کند؛ یعنی جزییات پیاده‌سازی داخلی آن برای سایر بخش‌ها پنهان است و تنها از طریق رابط‌های مشخص API در دسترس قرار می‌گیرد. این ویژگی باعث می‌شود تا تیم‌های توسعه بتوانند به‌صورت مستقل روی سرویس‌ها کار کنند، آن‌ها را به‌راحتی مقیاس‌پذیر کنند، یا حتی با تکنولوژی‌های مختلف پیاده‌سازی‌شان کنند.

مزایای استفاده از میکروسرویس‌ها

امروزه ماژولار بودن به یک مزیت رقابتی در هر صنعتی مبدل شده‌اند؛ از مبلمان IKEA گرفته تا گوشی‌های موبایل ماژولار و حتی اسباب‌بازی‌های LEGO و این در حالی است که ایدهٔ پشت میکروسرویس‌ها این است تا این امکان به دولوپرها داده شود تا اپلیکیشن‌های خود را بر مبنای اجزا یا سرویس‌هایی که مستقل از یکدیگر هستند و به سادگی قابل‌تغییر، حذف و به‌روزرسانی می‌باشند توسعه دهند بدون اینکه کل اپلیکیشن تحت‌الشعاع قرار گیرد. روی هم رفته، مهم‌ترین مزایای معماری میکروسرویس‌ عبارتند از:

• بر خلاف معماری مونولیتیک، در یک اپلیکیشنی که در آن از معماری میکروسرویس استفاده شده باشد سرویس‌ها هرگز بر اساس معماری MVC تقسیم‌بندی نمی‌شوند بلکه بر اساس کاری که انجام می‌دهند به بخش‌های مختلف تقسیم می‌شوند. به عبارت دیگر، یک سرویس همچون آپلود فایل شامل بخش‌هایی همچون رابط کاربری، مدل‌های مرتبط با دیتابیس، کنترلر، سیستم لاگینگ و ... خواهد بود (در چنین شرایطی، فرض کنیم دولوپر سرویسی تحت عنوان File Uploader می‌سازد و از آن پس به سادگی قادر خواهد بود سرویس مد نظر را در دیگر پروژه‌ها که کاربرد یکسانی دارند نیز استفاده کند.)
• یکی دیگر از مزیت‌های میکروسرویس‌ها این است که ما مجبور به استفاده از صرفاً یک زبان برنامه‌نویسی یا فناوری در کل پروژه نمی‌شویم. در واقع، با توجه به اینکه امروزه برخی زبان‌های برنامه‌نویسی برای حوزه‌های خاصی تخصصی‌تر هستند و استفاده از زبانی که اختصاصاً برای کار خاصی طراحی شده پرفورمنس اپلیکیشن ما را بالاتر می‌برد، با استفاده از میکروسرویس‌ها قادر خواهیم بود تا بسته به نوع سرویس مد نظر خود از چندین زبان برنامه‌نویسی و فناوری مختلف استفاده کرده و پرفورمنس را به حد اعلای خود برسانیم.
• علاوه بر موارد فوق، میکروسرویس‌ها اصطلاحاً Scalable (قابل‌توسعه) هستند. ماهیت مستقل ماژول‌های مختلف یک میکروسرویس این امکان را برای‌مان فراهم می‌آورند تا با استفاده از زبانی خاص، دیتابیسی خاص و همچنین سروری خاص به توسعهٔ اپلکیکشن مد نظر خود بپردازیم و در صورت نیاز صرفاً منابع همان پلتفرم را ارتقاء دهیم.

معایب استفاده از میکروسرویس‌ها

تا اینجای بحث از خوبی‌ها میکروسرویس‌ها گفتیم اما باید توجه داشته باشیم که این نوع معماری توسعهٔ اپلیکیشن نقاط ضعف خاص خود را هم دارا است که برخی از مهم‌ترین آن‌ها عبارتند از:

• از آنجا که هر سرویس مسئول انجام تَسک خاصی است، در اپلیکیشن‌ها بسیار بزرگ تعداد سرویس‌های بی‌شماری خواهیم داشت و از همین روی برقراری ارتباط مابین این سرویس‌ها و از همه مهم‌تر مانیتور کردن آن‌ها کاری بس دشوار خواهد بود (برخی داده‌ها حاکی از آنند که سرویسی همچون نتفلیکسن صدها سرویس مختلف دارد.)
• با توجه به اینکه سرویس‌ها برای برطرف کردن نیازهای خود دیگر سرویس‌ها را کال (فراخوانی) می‌کنند، رصد کردن آن‌ها و بالتبع فرایند دیباگینگ بسیار دشوار خواهد شد.
• هر سرویس لاگ‌گیری اختصاصی خود را دارا است و از همین روی هیچ سیستم مانیتورینگ مرکزی برای بررسی لاگ‌ها وجود ندارد و در چنین شرایطی نیاز به یک سیستم مدیریت لاگ مرکزی وجود خواهد داشت.
• با توجه به اینکه ارتباط سرویس‌ها با یکدیگر از طریق API است، تعداد رکوئست‌ها نسبت به یک معماری مونولیتیک به مراتب بیشتر خواهد بود.
• دیپلوی کردن اپلیکیشن‌هایی که با استفاده از معماری میکروسرویس طراحی شده‌اند به صورت دستی مشکل است و در چنین شرایطی نیاز به ابزارهای اتوماسیون پیشرفته خواهد بود.
• ورژن‌بندی میکروسرویس‌ها باید به صورت مجزا از یکدیگر صورت گیرد و اینجا است که نیاز داریم تا مشخص کنیم به طور مثال کدام ورژن سرویس A با کدام ورژن سرویس Z باید دیپلوی شود.
• مستندات‌سازی چنین اپلیکیشن‌هایی مشکل‌تر است چرا که با توجه به ماهیت مستقل هر ماژول، سرویس‌ها باید به صورت کامل مستندسازی شوند.
• با توجه به اینکه ممکن است از چندین زبان‌ برنامه‌نویسی و تکنولوژی مختلف در چنین اپلیکیشن‌هایی استفاده شود، هزینهٔ نگهداری چنین سیستم‌ها گاهی‌ اوقات زیاد می‌شود به طوری که مثلاً نیاز به استخدام دولوپر زبان‌های مختلف خواهیم داشت.

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

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

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

• چنانچه سورس‌کد پروژه‌ٔ شما آن‌قدر حجیم شده است که توسعهٔ آن به صورت لوکال، مثلاً لود کردن کل پروژه داخل یک IDE، کار دشواری شده است و نیاز به توضیح نیست که فرایند ‌بیلد کردن برخی از پروژه‌های بسیار بزرگ که به صورت مونولیتیک نوشته شده‌اند گاهی ده‌ها دقیقه به طول می‌انجامد.
• صرفاً برخی بخش‌های اپلیکیشن نیاز به توسعه دارند و این در حالی است که در معماری مونولیتیک شما باید به یک باره کل منابع سیستمی خود را ارتقاء دهید و این در صورتی است که ممکن است اصلاً نیاز به ارتقاء به این شکل نباشد.
• چنانچه دولوپرها در کنار یکدیگر نیستند و نمی‌توانند به صورت مستقل از یکدیگر روی پروژه کار کنند.