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

میکروسرویس‌ روشی به منظور تقسیم‌بندی کردن یک اپلیکیشن (نرم‌افزار) به بخش‌ها یا سرویس‌های کوچک، سبُک، مستقل از یکدیگر و قابل‌مدیریت است. به عبارت دیگر، میکروسرویس یک معماری توسعهٔ‌ نرم‌افزار به اصطلاح Distributed است.

همان‌طور که در تصویر فوق مشاهده می‌شود، این نوع سرویس‌ها صرفاً به منظور هندل کردن یک تَسک خاص طراحی می‌شوند. به طور مثال، یک سرویس صرفاً وظیفهٔ مدیریت کاربران را دارا است و سرویس دیگر فقط و فقط برای بخش جستجوی سایت کاربرد دارد و با توجه به اینکه میکروسرویس‌ها مجزا و مستقل از یکدیگر هستند، به راحتی قادر خواهیم بود تا آن‌ها را با زبان‌های برنامه‌نویسی مختلفی نوشته و برای ذخیره‌سازی داده‌های مرتبط با آن‌ها نیز از سیستم‌های مدیریت دیتابیس مختلفی استفاده کنیم (به عبارت دیگر، جاهایی که نیاز به ذخیره‌سازی سنتی داده‌ها داریم می‌توانیم از MySQL استفاده کنیم و جاهایی دیگر هم به خاطر ساختار غیرقابل پیش‌بینی دیتای خود می‌توانیم به استفاده از دیتابیس‌های به اصطلاح NoSQL بپردازیم.)

حال ممکن است این پرسش مطرح شود که سرویس‌های مختلف یک اپلیکیشن با معماری میکروسرویس چگونه با یکدیگر ارتباط برقرار می‌کنند؟ در پاسخ به این سؤال باید گفت، همان‌طور که در تصویر فوق مشخص است، با استفاده از ریکوئست‌هایی از جنس HTTP و یکسری API به اصطلاح RESTful این ارتباط برقرار خواهد شد (برای آشنایی بیشتر با این اصطلاح،‌ به آموزش API چیست؟ مراجعه نمایید.)

آشنایی با معماری Service Oriented Architecture
اینجا سؤال دیگری به ذهن می‌رسد و آن هم اینکه با این تفاسیر تفاوت چندانی مابین Service Oriented Architecture یا به اختصار SOA با Microservice وجود ندارد که در پاسخ به این سؤال هم می‌توان گفت که Microservice نوعی SOA (معماری مبتنی بر سرویس) است که طی ده‌های گذشته خیلی مطرح بوده است اما در عین حال میکروسرویس نسبت به معماری مبتنی بر سرویس انعطاف‌پذیرتر است چرا که به سادگی می‌توان یک سرویس یا ماژول را از پروژه‌ای برداشت و بدون پیکره‌بندی خاصی آن را در پروژه‌ٔ دیگری استفاده کرد اما این در حالی است که معماری SOA داخل یک معماری اصطلاحاً Monolithic پیاده‌سازی می‌شود.

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

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

در تصویر سمت چپ می‌بینیم که معماری Monolithic به گونه‌ای است که ارتباط تنگاتنگی مابین ماژول‌های مختلف اپلیکیشن وجود دارد که اصطلاحاً گفته می‌شود Tightly Coupled است و در صورتی که بخواهیم تغییری در یکی از بخش‌ها دهیم با مشکل مواجه خواهیم شد و همین مسئله Continous Deployment یا به اختصار CD را دشوار می‌سازد. در تصویر وسط که نشانگر معماری SOA است، می‌بینیم که اوضاع نسبت به معماری Monolithic به مراتب بهتر بوده به طوری می‌توانیم اپلیکیشن را به بخش‌های مجزا از یکدیگر تقسیم‌بندی کنیم اما در عین حال، هر بخش زیر چتر پلتفرم اصلی قرار دارد و در تصویر سمت راست هم که معماری Microservice در آن به تصویر کشیده شده است،‌ بر خلاف دو معماری دیگر می‌بینیم که هر ماژول کاملاً مستقل از دیگر ماژول‌ها است که اصطلاحاً گفته می‌شود Loosely Coupled است و همچون یک پیراشکی، می‌توان آن را به تنهایی میل کرد!

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

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

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

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

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

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

– با توجه به اینکه سرویس‌ها برای برطرف کردن نیازهای خود دیگر سرویس‌ها را کال (فراخوانی) می‌کنند، رصد کردن آن‌ها و بالتبع فرایند دیباگینگ بسیار دشوار خواهد شد.

– هر سرویس لاگ‌گیری اختصاصی خود را دارا است و از همین روی هیچ سیستم مانیتورینگ مرکزی برای بررسی لاگ‌ها وجود ندارد و در چنین شرایطی نیاز به یک سیستم مدیریت لاگ مرکزی وجود خواهد داشت.

– با توجه به اینکه ارتباط سرویس‌ها با یکدیگر از طریق API است، تعداد رکوئست‌ها نسبت به یک معماری مونولیتیک به مراتب بیشتر خواهد بود.

– دیپلوی کردن اپلیکیشن‌هایی که با استفاده از معماری میکروسرویس طراحی شده‌اند به صورت دستی مشکل است و در چنین شرایطی نیاز به ابزارهای اتوماسیون پیشرفته خواهد بود.

– ورژن‌بندی میکروسرویس‌ها باید به صورت مجزا از یکدیگر صورت گیرد و اینجا است که نیاز داریم تا مشخص کنیم به طور مثال کدام ورژن سرویس A با کدام ورژن سرویس Z باید دیپلوی شود.

– مستندات‌سازی چنین اپلیکیشن‌هایی مشکل‌تر است چرا که با توجه به ماهیت مستقل هر ماژول، سرویس‌ها باید به صورت کامل مستندسازی شوند.

– با توجه به اینکه ممکن است از چندین زبان‌ برنامه‌نویسی و تکنولوژی مختلف در چنین اپلیکیشن‌هایی استفاده شود، هزینهٔ نگهداری چنین سیستم‌ها گاهی‌ اوقات زیاد می‌شود به طوری که مثلاً نیاز به استخدام دولوپر زبان‌های مختلف خواهیم داشت.

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

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

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

– صرفاً برخی بخش‌های اپلیکیشن نیاز به توسعه دارند و این در حالی است که در معماری مونولیتیک شما باید به یک باره کل منابع سیستمی خود را ارتقاء دهید و این در صورتی است که ممکن است اصلاً نیاز به ارتقاء به این شکل نباشد.

– چنانچه دولوپرها در کنار یکدیگر نیستند و نمی‌توانند به صورت مستقل از یکدیگر روی پروژه کار کنند.

جمع‌بندی
مبحث معماری میکروسرویس بسیار گسترده است و زمانی که بخواهیم وارد این حوزه شویم، نیاز است تا با مفاهیمی همچون Continuous Integration ،‌Continuous Deploymnet ،Container و همچنین ابزارهای دیپلوی خودکار نیز آشنا شویم اما آشنایی در همین حدی که در این پست صورت گرفت، برای هر دولوپری فارغ از اینکه بخواهد وارد این حوزه شود یا خیر، ضروری است (چنانچه علاقمند به مباحث مرتبط با میکروسرویس‌ها هستید، می‌توانید به پادکست مصاحبه با علی مقدم: رهبر فنی شرکت Cisco در رادیو فول‌استک مراجعه نمایید.)

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