هنگامی که وظیفه طراحی یک اپلیکیشن را بر عهده دارید، یکی از اولین سوالاتی که احتمالا به ذهن شما خطور می کند این است که آیا یک میکروسرویس طراحی کنید یا یک مونولیت.

عواقب این تصمیم به ظاهر ساده و بی ضرر به طور بالقوه قابل توجه است و اغلب به طور کامل در مورد آنها فکر نمی شود. یک تصمیم اشتباه می تواند بسیار پرهزینه باشد، نه تنها از نظر مالی، بلکه با توجه به زمان مورد نیاز برای توسعه برنامه و زمان مورد نیاز برای استقرار هرگونه تغییر در آینده نیز گران است.

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

این مقاله تفاوت‌های بین مونولیت‌ها و میکروسرویس‌ها و همچنین برخی اکتشافی‌ها را توضیح می‌دهد تا به شما در تصمیم‌گیری درباره نحوه انتخاب بین این دو معماری کمک کند.

فهرست مطالب

Monoliths vs Microservices: An Analogy

مونولیت چیست؟

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

مدیریت داده ها در میکروسرویس ها

جداسازی پایگاه داده در میکروسرویس ها

نحوه انتخاب بین یکپارچه و میکروسرویس

چرا باید با یک مونولیت شروع کنید؟

چرا باید با میکروسرویس شروع کنید؟

معماری ترکیبی - یک زمین میانه

آوردن آن با هم

Monoliths vs Microservices: An Analogy

قبل از اینکه به جزئیات فنی یکپارچه ها و میکروسرویس ها بپردازیم، اجازه دهید به سرعت تفاوت بین این دو معماری را با استفاده از یک قیاس توضیح دهیم.

معماری یکپارچه مانند یک رستوران معمولی است که در آن انواع غذاها در یک آشپزخانه بزرگ تهیه می شود و منوی واحدی برای انتخاب میهمانان ارائه می شود.

درست همانطور که رستوران همه چیز را از پیش غذا گرفته تا دسر را در یک مکان ارائه می دهد، یک مونولیت شامل همه عملکردها در یک پایگاه کد است.

معماری میکروسرویس مانند یک فودکورت است که از چندین غرفه کوچک و تخصصی تشکیل شده است که هر کدام نوع متفاوتی از غذا را سرو می کنند. در اینجا، می توانید غذاهایی را از غرفه های مختلف انتخاب و انتخاب کنید، که هر کدام به طرز ماهرانه ای منوی خود را آماده می کنند.

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

مشتریان می توانند ظروف را از هر غرفه ای انتخاب و انتخاب کنند، همانطور که می توانند از میکروسرویس های مختلف برای ایجاد یک برنامه کاربردی جامع استفاده کنند. هر سرویس مستقل است و از طریق رابط های ساده و کاملاً تعریف شده با سرویس های دیگر ارتباط برقرار می کند.

مونولیت چیست؟

در یک مونولیت، تمام کدهای مورد نیاز برای تمام ویژگی های برنامه در یک پایگاه کد واحد قرار دارند و به صورت یک واحد مستقر می شوند.

بیایید به عنوان مثال به یک برنامه تجارت الکترونیک نگاه کنیم. برخی از ویژگی های مهم یک اپلیکیشن تجارت الکترونیکی عبارتند از:

خدمات جستجوی محصول : فهرست های محصول، توضیحات، موجودی، قیمت ها و دسته ها را مدیریت می کند. مسئول ارائه اطلاعات به روز در مورد محصولات به سایر خدمات و کاربران است.

خدمات پرداخت : پردازش پرداخت ها و تراکنش ها را انجام می دهد. با درگاه های پرداخت خارجی تعامل دارد و گزینه های پرداخت امنی را برای مشتریان فراهم می کند.

خدمات مدیریت سفارش : چرخه عمر سفارشات مشتری را از زمان ایجاد تا تکمیل مدیریت می کند. این شامل رسیدگی به پردازش سفارش، به‌روزرسانی وضعیت و لغو سفارش است.

خدمات توصیه : توصیه‌های محصول شخصی‌شده را بر اساس سابقه جستجو و خریدهای گذشته به کاربران ارائه می‌دهد.

در یک برنامه یکپارچه، کد این ویژگی‌ها در یک پایگاه کد واحد قرار می‌گیرد و به‌عنوان یک واحد واحد مستقر می‌شود. این در تصویر زیر نشان داده شده است که در آن برنامه در یک سرور واحد با یک پایگاه داده جداگانه مستقر شده است.

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

حتی در یک معماری یکپارچه، برنامه می تواند کپی شده و در چندین سرور مستقر شود، با یک متعادل کننده بار که ترافیک را بین سرورها توزیع می کند. این در زیر نشان داده شده است:

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

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

بر خلاف یک معماری یکپارچه، که در آن تمام اجزای برنامه کاملاً یکپارچه شده و به عنوان یک واحد واحد مستقر شده‌اند، یک معماری میکروسرویس برنامه را به سرویس‌های کوچک‌تر و مستقلاً قابل استقرار تجزیه می‌کند. هر سرویس فرآیند خود را اجرا می‌کند و با سرویس‌های دیگر از طریق شبکه ارتباط برقرار می‌کند، معمولاً با استفاده از HTTP/REST ، RPC یا صف‌های پیام.

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

در زیر برخی از تفاوت های کلیدی بین برنامه تجارت الکترونیکی یکپارچه و میکروسرویس وجود دارد:

در معماری میکروسرویس، هر ویژگی برنامه در یک پایگاه کد جداگانه قرار دارد. این جداسازی تضمین می‌کند که ما سرویس‌های قابل استقرار مستقلی داریم که در حوزه‌های تجاری (سرویس جستجوی محصول، سرویس پرداخت، سرویس مدیریت سفارش و سرویس توصیه‌ای) مدل‌سازی شده‌اند.

داشتن یک پایگاه کد جداگانه برای هر سرویس تضمین می کند:

استقرار ساده: با هر سرویس در پایگاه کد خود، می توان آن را مستقل از سایرین به روز کرد، آزمایش کرد و مستقر کرد.

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

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

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

هر سرویس پایگاه داده مخصوص به خود را دارد (در صورت نیاز به پایگاه داده). این تضمین می کند:

هر میکروسرویس می تواند مستقل از سایر سرویس ها اجرا شود. اگر هر سرویس از یک پایگاه داده استفاده کند (همانطور که در یک برنامه کاربردی یکپارچه وجود دارد)، خرابی پایگاه داده کل برنامه را از بین می برد.

پایگاه داده ها را می توان به طور مستقل در صورت نیاز مقیاس بندی کرد. برخی از پایگاه های داده شلوغ تر از سایرین خواهند بود، پس داشتن انعطاف پذیری برای مقیاس بندی مستقل آنها مفید است.

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

یک API Gateway در مقابل سرویس ها قرار دارد. این به عنوان واسطه بین کاربران و بسیاری از خدماتی که ممکن است نیاز به دسترسی داشته باشند عمل می کند. API Gateway مجوز و احراز هویت ، مسیریابی درخواست و محدود کردن نرخ را کنترل می کند.

مدیریت داده ها در میکروسرویس ها

مدیریت داده ها بین سرویس ها پیچیده ترین بخش معماری میکروسرویس است. ارتباط بین سرویس ها یا همزمان یا ناهمزمان است.

ارتباط همزمان: خدمات به طور مستقیم با یکدیگر ارتباط برقرار می کنند. این یک رویکرد ساده است، به راحتی قابل درک و پیاده سازی است.

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

ارتباطات ناهمزمان: سرویس ها منتظر پاسخ مستقیم سرویس دیگری نیستند. در عوض، آنها از طریق رویدادها یا پیام ها با استفاده از یک واسطه پیام ارتباط برقرار می کنند.

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

درک و پیاده سازی ارتباطات همزمان ساده تر است، اما فاقد تحمل خطا است.

جداسازی پایگاه داده در میکروسرویس ها

در معماری میکروسرویس، جلوگیری از دسترسی مستقیم سرویس‌ها به پایگاه‌های داده سایر سرویس‌ها، یک روش استاندارد است. شما معمولاً این کار را انجام می دهید تا مطمئن شوید که هر سرویس می تواند طرح داده های خود را به طور مستقل مدیریت کند، بدون اینکه روی سایر سرویس ها تأثیر بگذارد.

با نگاهی به مثال تجارت الکترونیکی خود، فرض کنید سرویس پرداخت تصمیم گرفته است طرح داده خود را تغییر دهد و نام ستونی به نام "مبلغ" را به "order_value" تغییر دهد، زیرا "مقدار" می تواند یک اصطلاح کاملا مبهم باشد. اگر سرویس مدیریت سفارش مستقیماً پایگاه داده سرویس پرداخت را پرس و جو می کرد، هرگونه درخواست مستقیم SQL از سرویس مدیریت سفارش به پایگاه داده سرویس پرداخت در این ستون به دلیل این تغییر طرح با شکست مواجه می شد.

برای مدیریت این وابستگی ها و تغییرات به طور ایمن و کارآمد، سرویس ها باید از طریق API ها تعامل داشته باشند تا از طریق دسترسی مستقیم به پایگاه داده. با ارائه یک API به عنوان یک رابط، سرویس پرداخت می تواند پیچیدگی های مدل داده زیربنایی خود را انتزاعی کند.

به عنوان مثال، صرف نظر از اینکه نام فیلد پایگاه داده "مقدار" یا "order_value" باشد، API می تواند پارامتری به نام "payment_amount" را نمایش دهد. این به سرویس پرداخت اجازه می دهد تا به صورت داخلی «payment_amount» را به هر طرحی که پایگاه داده فعلی استفاده می کند، ترسیم کند.

نحوه انتخاب بین یکپارچه و میکروسرویس

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

میکروسرویس ها در شرکت های بزرگ فناوری جدیدتر و محبوب تر هستند. اکثر کتاب ها و وبلاگ های فنی، معماری این شرکت های بزرگ را پوشش می دهند.

اما مشکلات مهندسی شرکت‌های بزرگ که در مقیاس بزرگ فعالیت می‌کنند لزوماً همان مشکلات مهندسی نیست که شرکت‌های کوچکتر با آن مواجه هستند.

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

می‌توانید ببینید که استارت‌آپ‌های دیگر چه می‌کنند، یا غول‌های فناوری امروزی در زمانی که بسیار کوچک‌تر بودند چه می‌کردند. به عنوان مثال، Etsy، Netflix و Uber همگی قبل از مهاجرت به معماری میکروسرویس به عنوان یکپارچه شروع کردند.

چرا باید با مونولیت شروع کنید؟

ایجاد یک برنامه کاربردی باید به یک دلیل و یک دلیل به تنهایی انجام شود: ساخت چیزی که مردم بخواهند از آن استفاده کنند. کاربران برنامه شما اهمیتی نمی دهند که از میکروسرویس یا مونولیت استفاده می کنید. آنها اهمیت می دهند که شما برای آنها مشکلی را حل می کنید.

به نقل از پل گراهام :

برنامه اولیه تقریباً همه شکسته است. اگر شرکت‌ها به برنامه‌های اولیه خود پایبند باشند، مایکروسافت زبان‌های برنامه‌نویسی را می‌فروشد و اپل بردهای مدار چاپی را می‌فروشد. در هر دو مورد، مشتریان آن‌ها به آن‌ها می‌گفتند که کسب‌وکارشان چیست و آن‌ها آنقدر باهوش بودند که گوش کنند».

بدون شک نیازی به صرف زمان زیادی برای طراحی و اجرای یک معماری میکروسرویس بسیار پیچیده نیست، زمانی که شما حتی مطمئن نیستید که چیزی را می سازید که مردم می خواهند از آن استفاده کنند.

پس ، چرا باید هنگام ساخت یک برنامه با یک مونولیت شروع کنید؟

سادگی : یکپارچه نیازی به پرداختن به پیچیدگی‌های یک سیستم توزیع‌شده، مانند تأخیر شبکه، ثبات داده‌ها یا ارتباطات بین سرویسی ندارد. این عدم پیچیدگی نه تنها فاز توسعه اولیه را روان‌تر می‌کند، بلکه هزینه‌های سربار را برای توسعه‌دهندگان جدید کاهش می‌دهد، زیرا می‌توانند بدون نیاز به درک پیچیدگی‌های یک سیستم توزیع‌شده، سریع‌تر مشارکت کنند.

سهولت تکرار : در مراحل اولیه یک محصول، تکرار سریع بر اساس بازخورد کاربر بسیار مهم است. جهت محصول هنوز در حال تغییر است و بر اساس ورودی کاربر، چرخش یا تنظیمات سریع ضروری است. دستیابی به این امر معمولاً با یک معماری یکپارچه ساده آسان تر است.

کم هزینه : اجرای یک برنامه یکپارچه می تواند در مراحل اولیه هزینه کمتری داشته باشد، زیرا معمولاً به زیرساخت کمتر و منابع کمتری نسبت به معماری میکروسرویس های توزیع شده نیاز دارد. این برای استارت‌آپ‌ها و کسب‌وکارهای کوچک که در آن‌ها پول کم است، بسیار مهم است.

شروع با یک مونولیت اغلب با واقعیت های عملی راه اندازی و تکرار در یک برنامه جدید هماهنگی بیشتری دارد.

چرا باید با میکروسرویس شروع کنید؟

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

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

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

معماری ترکیبی - یک زمین میانه

تعریف رسمی و آکادمیک میکروسرویس این است که یک سرویس مستقل قابل استقرار است که حول یک حوزه تجاری مدل شده است. طبق این تعریف، هر دامنه تجاری باید یک سرویس جداگانه باشد.

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

ما می توانیم انتخاب کنیم که خدمات جستجوی محصول به عنوان یک میکروسرویس حفظ شود. از آنجایی که افراد بیشتری برای محصولات جستجو می کنند تا خرید آنها، ممکن است بخواهیم این سرویس را مستقل از سایرین مقیاس کنیم.

همچنین، این سرویس به پایگاه داده جستجوی متن کامل اختصاصی خود مانند Elasticsearch یا Solr نیاز دارد. پایگاه داده های SQL برای جستجوی متن کامل و فیلتر محصول مناسب نیستند.

همچنین می‌توانیم سرویس توصیه‌ای را به‌عنوان یک میکروسرویس نگه داریم، زیرا این سرویس به زبانی متفاوت از سایر سرویس‌ها نوشته می‌شود. این سرویس همچنین به پایگاه داده گراف جداگانه خود مانند Neo4j برای کمک به ارائه توصیه هایی به کاربران در مورد خرید بر اساس جستجوها و خریدهای گذشته نیاز دارد.

ما با خدمات پرداخت و خدمات مدیریت سفارش باقی مانده ایم که می توانند به صورت یکپارچه ترکیب شوند. این در زیر نشان داده شده است.

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

آوردن آن با هم

در یک monolith، تمام کدهای مورد نیاز برای تمام ویژگی های یک برنامه کاربردی در یک پایگاه کد واحد قرار دارند و به صورت یک واحد مستقر می شوند. در معماری میکروسرویس، برنامه به اجزای کوچکتر و مستقل تقسیم می شود که هر کدام مسئول ویژگی ها یا عملکردهای خاصی هستند. هر میکروسرویس پایگاه کد مخصوص به خود را دارد و می تواند مستقل از سایرین مستقر شود.

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

مونولیت ها سادگی، سهولت تکرار و هزینه کم را ارائه می دهند. میکروسرویس ها مقیاس پذیری، انعطاف پذیری و پشته فناوری انعطاف پذیرتر را ارائه می دهند.

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

برای یک شرکت معتبرتر با نیازهای رو به رشد به مقیاس پذیری، انعطاف پذیری و انعطاف پذیری تکنولوژیکی، معماری میکروسرویس می تواند انتخاب بهتری باشد.

خبرکاو