اصل ماجرا از این قرار است که میکروسرویس‌ها برای یک هدف واحد ایجاد شدن و اون هم چیزی نیست جز
توسعه راحت و سریع نرم‌افزارهای بزرگ!
برای اینکه معماری میکروسرویس‌ها را بهتر درک کنیم باید اول برویم سراغ معماری Monolithic همه‌ی افرادی که برنامه‌نویسی را شروع می‌کنند در آغاز هر آنچه را که آموزش می‌بینند؛ به صورت پیش‌فرض بر پایه‌ی معماری Monolithic است. (نوعی معماری که به معماری یکپارچه معروف است).
اما باید بدانید که در معماری میکروسرویس‌ها همه چیز فرق می‌کند!
در دنیای مایکروسرویس‌ها ما سرویس‌ها کوچک و گاها تک منظوره‌ای داریم که در کنار هم کارهای بزرگی انجام می‌دهند. معماری میکروسرویس به روش تقسیم یک نرم‌افزار به بخش‌های کوچک و کاملا مجزا از هم می‌گویند این سرویس‌های مستقل از هم که به صورت جداگانه مدیریت می‌شوند، ممکن است با زبان‌های برنامه‌نویسی مختلفی نوشته شده باشند. درواقع میکروسرویس، یک معماری توسعهٔ نرم‌افزار به اصطلاح Distributed است که برای ذخیره‌سازی اطلاعات و داده‌های مرتبط با آن‌ها باید از سیستم‌های مدیریت دیتابیس مختلف استفاده کنیم.
برای درک بهتر این موضوع بیایید با مثال جلو برویم. در اپلیکیشن‌های مسافربری نظیر اوبر (همون اسنپ و تپسی خودمان!) ما چند عضو متصل بهم داریم که کارهای مجزایی از هم انجام می‌دهند.
همه این اجزا یک هدف واحد دارند! رساندن سلامت مسافر به مقصد و دریافت وجه از او توسط راننده!
اعضای این مجموعه از این قبیل‌اند:
همگی این پنج سرویس، از نظر منطقی کاملا جداگانه عمل می‌کنند و هر یک از سرویس‌ها، دیتابیس، سورس‌کد و تیم‌های توسعه و پشتیبانی مجزایی دارند؛ حال اگر قرار بود ما تمام این سرویس‌ها را با معماری Monolithic بنویسیم و پیاده‌سازی کنیم، اتفاقی که می‌افتاد این بود که همگی یک سورس کد واحد داشتند و سیستم کاملا به صورت یکپارچه عمل می‌کرد. شکل زیر نمونه‌ای از عملکرد یک سرویس حمل‌ونقل است که پیشتر توضیح دادیم.
سوالی که در اینجا مطرح می‌شود این است که اگر این میکروسرویس‌ها قرار باشد مجزا و حتی با زبان‌های مختلفی نوشته شوند، چطور با یکدیگر ارتباط برقرار می‌کنند؟
چگونگی ارتباط اجزا بسیار راحت است! با کمک گرفتن از ریکوئست‌هایی از جنس HTTP و یکسری API به اصطلاح RESTful این ارتباط برقرار به سرعت برقرار خواهد شد.
خوبی کمک گرفتن از معماری میکروسرویس‌ها این است که با جداسازی بخش‌های مختلف از هم، شما به راحتی و بدون دست زدن به کل بدنه کار می‌توانید هر بخش را مستقل از دیگری تغییر دهید، حذف و یا به‌روزرسانی کنید. همچنین می‌توان در هر کدام از این مینی اپلیکیشن‌ها از ابزارهایی مناسب با نیاز همان قسمت استفاده کرد.
اما مهم‌ترین مزیت توسعه میکروسرویس‌ها استفاده بهینه و به‌اندازه از منابع است. در این روش هر مینی اپلیکیشن تنها به اندازه نیاز خود از منابع و امکانات استفاده خواهد کرد و در صورت نیاز بیشتر می‌توان منابع آن را افزایش داد یا یک سرویس خاص را در چند نسخه مختلف اجرا کرد.
اولین سوالی که شاید در مواجه با نام میکروسرویس‌ها برایتان پیش بیاید این است که میکروسرویس یعنی دقیقا چقدر کوچک؟ معیار این مقایسه دقیقا چه چیزی است؟ یک گربه در مقایسه با یک زنبور بزرگ به نظر می‌رسد درحالیکه همین گربه در مقایسه با فیل کوچک است! پس باید مشخص شود میکرو یعنی دقیقا چه اندازه؟
ایراد بعدی سختی برقراری ارتباط بین سرویس‌های مختلف و مابقی پیچیدگی‌های فنی است که ممکن است در هنگام توسعه یک سیستم بزرگ با آن روبه‌رو شویم.
همانطور که نصب و راه‌اندازی جداگانه هر سرویس می‌تواند مفید باشد، توانایی به‌وجود آوردن مشکلات زیاد ناشی از آن هم زیاد دور از دهن نخواهد بود. تصور کنید یک نرم‌افزار به 100 سرویس کوچک تقسیم شده که هر یک از آن‌ها باید جداگانه نصب و راه‌اندازی شود! و این یعنی خطا پشت خطا! مه رفع هر یک از این‌ها می‌تواند کاری بسیار زمان‌بر تلقی شود.
در حقیقت هدف از معماری میکروسرویس این بود تا برنامه‌نویسان درگیر تمام بخش‌های یک نرم‌افزار نباشند و یا اینکه تصور کنند تمامی بخش‌ها باید با یک زبان برنامه‌نویسی خاص نوشته شود. (قطعا مزیت این موضوع در نرم‌افزارهای بزرگ نمود بیشتری دارد)
در مطلب این‌بار ویرگول سعی کردیم درباره‌ی دو روش توسعه Monolith و میکروسرویس، مزایا و معایب میکروسرویس‌ها صحبت کنیم تا شما یک دید کلی نسبت به این موضوع پیدا کنید، حال اگر شما بیشتر مخاطب این دست مطالب هستید و می‌خواهید موضوعات بیشتری در این حیطه بخوانید حتما آن را با ما در میان بگذارید.
مطابق رسم همیشگی‌مان، نظرات‌تان را می‌بینم، می‌خوانم و پاسخ می‌دهم. پس لایک و کامنت یادتون نره!
