تفاوت معماری Monolithic و Microservice

?Microservices vs Monolith: Which Architecture is the Best Choice

07 اردیبهشت 1400
تفاوت معماری Monolithic و Microservice

تفاوت معماری Monolithic و Microservice

یکی از بزرگترین دغدغه های برنامه نویسان در سطح enterprise (شرکت های بین المللی و بسیار بزرگ) عدم دستیابی به مقیاس پذیری بالا بود. زمانی که در رابطه با پروژه های کوچک یا متوسط یا حتی بزرگ صحبت می کنیم مسئله مقیاس دهی آنچنان عجیب و سخت نیست اما برخی اوقات برنامه نویسی در سطح enterprise انجام می شود یعنی شرکت هایی با ترافیک بسیار بالا (میلیون ها کاربر). در سال ۲۰۰۵ آقای دکتر Peter Rogers برای اولین بار از کلمه microservices استفاده کرد و بعد ها در سال ۲۰۱۱ به صورت عملی تری از آن رونمایی شد.

معماری Monolithic چیست؟

معماری Monolithic همان روش عادی و سنتی طراحی وب و مقیاس دهی به برنامه ها است. ما می توانیم برنامه های وب را در تئوری به سه بخش اصلی تقسیم کنیم:

  • بخش front-end که نمای ظاهری وب سایت است و معمولا با زبان های HTML و CSS و JavaScript نوشته می شود.
  • بخش back-end که همان سرور وب سایت است و معمولا با زبان هایی مانند PHP یا Node.js یا Python یا Java و غیره نوشته می شود.
  • پایگاه داده که محل ذخیره داده های برنامه ما است.

این سه بخش به شدت به یکدیگر وابسته و دائما در تعامل هستند بنابراین طراحی پیش فرض ما monolithic (مونولیتیک) می باشد؛ یعنی برنامه ما به صورت «یک کل» و «یک واحد مستقل» خواهد بود و این سه بخش (front-end و back-end و database) هیچ گاه از هم جدا نمی شوند.

مزایا و معایب طراحی Monolithic

در طراحی مونولوتیک هر سه بخش اصلی برنامه های تحت وب به صورت یکجا قرار دارند بنابراین یک سورس کد بزرگ دارند. این نوع طراحی مزایای زیر را دارد:

  • برنامه های مونولیتیک در یک قالب هستند، بنابراین نیازی به نگرانی از جهت کارکرد قسمت های مختلف برنامه نیست. ما می دانیم که قسمت های مختلف برنامه حتما با یکدیگر تعامل دارند و از هیچ نظری (سازگاری، همکاری، تعامل و غیره) مشکلی نخواهیم داشت.
  • اشکال زدایی (debug) و تست کردن برنامه های مونولیتیک بسیار ساده است. از آنجایی که این دسته از برنامه ها یک «کلِ واحد» هستند اجرای تست های جامع روی آن بسیار ساده تر از microservice ها می باشد. این مسئله به اشکال زدایی و تست منحصر نمی شود بلکه هر عملیاتی شبیه به آنها مانند monitoring (تحت نظر گرفتن برنامه و منابع مصرفی آن) نیز بسیار ساده تر خواهد بود.
  • deploy کردن برنامه های مونولیتیک بسیار آسان است چرا که برنامه شما از قطعات جداگانه ساخته نشده است و نیازی به deploy کردن بخش های مختلف به صورت جداگانه ندارید. deploy کردن یعنی بهره برداری کامل از برنامه عملیاتی شدن برنامه شما! به زبان ساده تر به قرار دادن برنامه روی سرور و دسترسی عموم مردم به آن، deploy می گوییم.
  • توسعه آسان تر یکی از مزیت های دیگر معماری مونولیتیک می باشد. از آنجایی که معماری مونولیتیک سال های زیادی است که به عنوان استاندارد پیش فرض در طراحی وب تثبیت شده است تمام تیم های توسعه و توسعه دهندگان با این نوع معماری آشنا هستند و می توانند به راحتی برنامه شما را توسعه بدهند.

با اینکه مزیت های بالا قابل توجه هستند اما معایب جدی نیز متوجه این نوع طراحی می باشد:

  • درک سورس کد: سورس کد برنامه های مونولیتیک یکجا نوشته می شود بنابراین خواندن این سورس کد در برنامه های بسیار بزرگ مشکل خواهد شد. توجه کنید که برنامه های بزرگ را مقیاس دهی می کنیم بنابراین درک کدها در این حالت دو چندان سخت خواهد بود.
  • ایجاد تغییرات: از آنجایی که سورس کد برنامه های مونولیتیک به صورت یکجا نوشته می شود، ایجاد تغییرات و به روز رسانی ها در آن بسیار سخت خواهد بود چرا که حجم عظیمی از کدها به هم وابسته هستند و ایجاد هر تغییر در یک نقطه از برنامه، روی دیگر بخش های برنامه نیز تاثیر می گذارد. مسئله اینجاست که این تاثیر می تواند مانند یک زنجیره از واکنش های غیر منتظره عمل کرده و یک تغییر کوچک باعث بهم ریختن تمام سیستم شود. این موضوع باعث می شود که نیاز به همکاری در بخش های مختلف تیم توسعه افزایش زیادی پیدا کند که به خودی خود فرآیند ایجاد تغییرات و توسعه را نیز کُند می کند.
  • مقیاس پذیری: شما نمی توانید بخش های مختلف برنامه های مونولیتیک را به صورت جداگانه مقیاس دهی کنید، بلکه فقط می توانید کل مقیاس داده و ارتقا دهید.
  • انطباق با تکنولوژی های جدید: همانطور که می دانید هر از چند گاهی در حوزه طراحی وب تکنولوژی های جدیدی معرفی می شوند. اگر برنامه شما معماری مونولیتیک داشته باشد انطباق با این تکنولوژی های جدید سخت خواهد بود چرا که مجبور می شوید تمام برنامه را بازنویسی کنید. مثلا اگر از HTML ساده استفاده می کردید و حالا می خواهید از React استفاده نمایید باید کدهای سمت سرور را نیز تغییر بدهید و کار به بازنویسی کل پروژه می رسد.

معماری Microservices چیست؟

معماری microservice، برخلاف معماری monolithic که برنامه را به عنوان یک «کلِ واحد» در نظر می گرفت، برنامه شما به به بخش های مختلف و کوچکتری تقسیم می کند. در این نوع معماری هر پروسه از برنامه شما به عنوان یک سرویس جداگانه در نظر گرفته می شود بنابراین هر کدام از این سرویس ها منطق و پایگاه داده خودشان را دارند و کار خاص خودشان را انجام می دهند. در نظر داشته باشید که در این تعریف وقتی از «بخش های کوچکتر» صحبت می کنیم، منظورمان ماژول هایی مستقل است که به صورت جداگانه deploy می شوند و به یکدیگر هیچ نیازی ندارند اما برای تشکیل یک برنامه بزرگ تر از طریق API با یکدیگر تعاملات خودشان را دارند.

طراحی microservice در یک تصویر
طراحی microservice در یک تصویر

مزایای استفاده از معماری Microservices

مثل هر چیز دیگری در زندگی معماری های microservices و monolithic مزایا و معایب خود را دارند. ما در مورد نقاط قوت و ضعف معماری monolithic صحبت کرده ایم اما حالا نوبت به معماری microservices می رسد.

  • کامپوننت های مستقل: تمام سرویس های این معماری می توانند به صورت جداگانه به روز رسانی شده و deploy شوند. این استقلال بدان معنی است که اگر در یک سرویس باگ خاصی وجود داشته باشد، تمام برنامه از کار نمی افتد بلکه همان سرویس خاص دچار مشکل خواهد شد. نهایتا اضافه کردن قابلیت های جدید به این برنامه ها بسیار‌ آسان تر از برنامه هایی است که با معماری monolith نوشته شده اند.
  • درک ساده تر: طبیعتا برنامه هایی با معماری microservices دارای یک سورس کد واحد نیستند بلکه برای هر کدام از سرویس های مورد نظر یک سورس کد جداگانه داریم و این سورس کدها به صورت مستقیم به هم وابسته نیستند. این مسئله باعث می شود که خواندن کدها بسیار ساده تر باشد.
  • مقیاس پذیری بهتر: یکی از بهترین مزیت های برنامه هایی با معماری microservices این است که مقیاس پذیری آن ها بی نهایت است چرا که می توانیم هر کدام از سرویس ها را به صورت جداگانه ارتقاء بدهیم. این مسئله باعث صرفه جویی در منابع مالی ما می شود چرا که در معماری monolithic مجبور هستیم تمام برنامه را ارتقاء بدهیم حتی اگر نیازی به آن نداشته باشیم اما در microservices می توانیم فقط یک بخش خاص از برنامه را ارتقاء بدهیم. البته باید توجه داشت که یک سرور تا حدی می تواند ارتقاء داده شود و بالاخره به دیواری برخورد می کنیم اما microservices ها دیواری ندارند.
  • انعطاف در انتخاب تکنولوژی: از آنجایی که تعداد microservices بسیار زیاد است و انواع و اقسام خدمات برای شما موجود است، هیچ محدودیتی در انتخاب تکنولوژی ها وجود ندارد. همچنین از آنجایی که اکثر تعاملات برنامه شما از طریق API است، می توانید از هر تکنولوژی و پکیجی برای برنامه نویسی سایت خود استفاده کنید.
  • مقاومت بیشتر در برابر خطا: از آنجایی که هر کامپوننت برنامه مستقل است، ایجاد اشکال و خطا در یکی از آن ها دیگر بخش های برنامه را فلج نمی کند.

معایب استفاده از معماری Microservices

با اینکه معماری microservices مزایای بسیاری دارد اما معایب خاص خودش را نیز دارد که در این بخش به آن ها اشاره می کنیم:

  • پیچیدگی زیاد: از آنجایی که برنامه هایی با معماری Microservices کامپوننت هایی توزیع شده هستند شما باید اتصالات بین تک تک کامپوننت ها را برقرار کرده و پایگاه داده خود را نیز در نظر بگیرید. همچنین deploy کردن کامپوننت ها به صورت مجزا انجام می شود بنابراین برای داشتن یک وب سایت باید چندین عملیات deploy را انجام بدهید.
  • توزیع سیستم: توزیع سیستم در microservices ها به صورت دستی انجام می شود و نیاز به توجه بسیار زیادی دارد.
  • یکپارچه سازی سیستم: زمانی که یک برنامه را بر اساس microservices پیاده سازی می کنید، یکپارچه سازی آن کمی مشکل می شود چرا که تمام قطعات آن از هم جدا هستند. به طور مثال سیستم log، سیستم metrics (زیرنظر گرفتن عملکرد سیستم و سرعت پاسخ دهی آن)، اجرای تست های سلامت روی سیستم و امثال آن نیاز به هماهنگی بین تمام کامپوننت های سیستم دارند.
  • تست نویسی: اگر با microservices کار کرده باشید می دانید که نوشتن تست برای برنامه هایی که دائما از API های مختلف استفاده می کنند کار بسیار سخت تری است.

از کدام معماری استفاده کنم؟

بنابراین در صورتی که برنامه شما بزرگ نیست و می خواهید آن را سریعا راه بیندازید استفاده از معماری monolithic را پیشنهاد می کنم. به طور مثال معماری monolithic برای تیم های استارتاپ و تازه کار گزینه بسیار مناسبی است چرا که نیازی به دانش عمیق ندارد. همچنین برخی از اوقات برنامه شما آنچنان ساده است که نیازی به عملیات های سنگین و پیچیده ندارد بنابراین دردسرهای معماری microservices را ندارد. همچنین در نظر داشته باشید که ساخت برنامه های microservices نیاز به دانش فنی دارد و دست زدن به چنین کاری بدون داشتن تجربه کاری بسیار ریسکی محسوب می شود. بنابراین تا زمانی که برنامه شما پیچیده نیست و تا زمانی که دانش کافی برای مدیریت آن را ندارید بهتر است از معماری microservices دوری کنید.

نویسنده شوید

دیدگاه‌های شما

در این قسمت، به پرسش‌های تخصصی شما درباره‌ی محتوای مقاله پاسخ داده نمی‌شود. سوالات خود را اینجا بپرسید.