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