ابتدای کار اجازه دهید در رابطه با هر کدام از این مفاهیم به خوبی آشنا شویم و بدانیم که مفهوم «Monolith» یا یکپارچه و «Microservice» یا میکروسرویس چیست.
معماری یکپارچه یا Monolith به عنوان یک سیستم بزرگ ایجاد شده و دارای یک روش کدنویسی کلی است. معماری یکپارچه همه کارها را در یک بار انجام می‌دهد و تا نهایت به تغییراتی که اتفاق می‌افتد توجهی نمی‌کند. از دیگر طرف ماجرا، معماری میکروسرویس‌ها شیوه‌ای برای ایجاد اپلیکیشن‌ها با استفاده از سرویس‌های کوچکی است که هر کدام ممکن است روش کدنویسی متفاوتی از یکدیگر داشته باشند. این سرویس‌ها برای انجام کارهای منحصر به فردی ایجاد می‌شوند و هر کدام از این سرویس‌های کوچک به صورت مستقل توسعه و تحویل داده می‌شوند.
حالت معمولی که توسعه‌دهندگان از ابتدای کار پیش گرفته‌اند، حالت یکپارچه بوده است. استفاده از این تکنیک برای زمانی که مهلت ارائه پروژه کم است و تیم شما بسیار خبره نیستند بسیار مفید خواهد بود. اما آیا این حالت همیشه درست است. یکی از دوستان برنامه‌نویس خوب من که در انجام پروژه‌های مختلف شرکتی همکاری داشته است، اخیرا به این نتیجه رسیده که حالت یکپارچه یا همان Monolith الزاما همیشه خوب نیست.
در پروژه آخری که آن‌ها داشتند، اپلیکیشن یکپارچه‌شان را به معماری میکروسیستم‌های نسبتا بزرگی تقسیم کردند. بعد از چند ماه آزمایش و کار کردن آن‌ها متوجه شدند که چه اشتباه بزرگی انجام داده و با چه مصیبت‌هایی همراه هستند. به همین دلیل این تجربه باعث شد که پروژه‌های جدیدشان را با احتیاط بیشتری جلو ببرند.
درک کردن انتخاب‌ها
برای اینکه بین این دو گزینه موجود انتخاب کنیم، ابتدا باید به صورت درست منظورمان از monolith و microservice را بیان کرده و درک خوبی از آن‌ها را پیدا کنیم.
Zachary Crockett یکی از مدیران تکنولوژی می گوید: «معماری‌های سیستمی روی یک طیف قرار دارند... وقتی در رابطه با میکروسرویس‌ها صحبت می‌شود، مردم روی یک طرف این طیف تمرکز می‌کنند: اپلیکیشن‌های کوچک بسیاری که پیغام‌های بسیاری را بین همدیگر رد و بلد می‌کنند. در طرف دیگر ماجرا شما با یک طیف واحد و عظیم سر و کار دارید که کارهای بسیاری را به صورت واحد انجام می‌دهد. برای تمام سیستم‌های واقعی معماری‌های مبتنی بر سرویس مختلفی امکان پذیر است».
تعریف Monolith یا یکپارچه
یک اپلیکیشن یکپارچه به عنوان یک اپلیکیشن واحد و تک ایجاد می‌شود. معمولا یک اپلیکیشن یکپارچه شامل سه بخش می‌شود: یک بانک اطلاعاتی، یک رابط کاربری مربوط به مشتری (HTML و یا قسمت‌هایی از جاوااسکریپت که در مرورگر اجرا می‌شود) و اپلیکیشن مربوط به قسمت سرور. قسمت سرور اپلیکیشن درخواست‌های HTTP را مدیریت می‌کند، داده‌ها را از بانک اطلاعاتی دریافت و بروزرسانی می‌کند و با کمک قسمت رابط کاربری آن‌ها را به مرورگر برگشت می‌دهد.
در یک اپلیکیشن یکپارچه، قسمت رابط کاربری، سرور، کارهای پس زمینه و... همگی براساس یک کد نوشته و توسعه داده می‌شوند. در نتیجه: اگر توسعه‌دهنده‌ای بخواهد که تغییر یا بروزرسانی انجام دهد آن‌ها نیاز خواهند داشت که همه چیز را از ابتدای امر ایجاد و توسعه دهند.
برخلاف چیزی که فکر می‌کنید، این سیستم معماری کهنه و تاریخ مصرف گذشته نیست. در برخی از موقعیت‌ها استفاده از سیستم معماری یکپارچه ایده‌آل و مناسب است. Steven Czerwinski یکی از توسعه‌دهندگان می‌گوید که بدلیل وجود تیم کوچکی از توسعه‌دهندگان در پروژه خودش، استفاده از معماری یکپارچه بسیار مناسب‌تر از حالتی بود که همه چیز را به سرویس‌های کوچکتری تقسیم کنیم.
وقتی روند معماری یکپارچه را پیش می‌گیرید، باید مفاهیم زیر را در نظر داشته باشید:
فواید Monolith
- نگرانی کمتر در رابطه با قطعی‌ها: بیشتر اپلیکیشن‌ها دارای تعدادی قطعی‌ها و قسمت‌های متفاوت از یکدیگر هستند. به عنوان مثال عملیات وارد شدن، ویژگی‌های امنیتی، محافظت‌ها و... . یکی از بزرگ‌ترین مزیت‌های این معماری آن است که به دلیل وجود تمام این نکات در یک اپلیکیشن، مشاهده کردن اختلالات در این زمینه‌ها بسیار ساده‌تر خواهد بود.
- وجود عملیات‌های کمتر: داشتن یک اپلیکیشن بزرگ بدان معناست که تنها یک اپلیکیشن برای تست کردن، نظارت و وارد شدن وجود دارد. به همین دلیل عملیات‌های کمتری انجام می‌شود. نگه‌داری از این سیستم‌ها پیچیده‌گی کمتری نیز دارد.
- کارایی: از آنجایی که دسترسی به حافظه اشتراکی سریع‌تر از ارتباطات داخل پردازش سریع‌تر است، بنابراین کارایی در این معماری نیز بیشتر است.
معایب Monolith
- محکم به هم بسته بودن: در این سیستم معماری همه چیز به شدت با همدیگر ارتباط دارند و به همین دلیل جدا کردن آن‌ها کار سختی است. بنابراین وقتی بخواهید قسمتی را به صورت مستقل توسعه و یا نگه‌داری کنید کار سختی است.
- درک سخت‌تر: معماری Monolithic درک‌پذیری سخت‌تری دارد، به این دلیل که وقتی مشکلی اتفاق می‌افتد ممکن است پیدا کردن آن در یک قسمت سخت باشد.
تعریف Microservices
قبل از هر چیزی باید بگوییم که این معماری ذاتا مربوط به «میکرو یا کوچک بودن» نیست. البته آن‌ها معمولا از معماری یکپارچه کوچک‌تر هستند. اندازه در این معماری یک واحد نسبی است و هیچ استاندارد دقیقی برای سازمان‌دهی و دسته‌بندی این نوع از معماری وجود ندارد.
روش معماری میکروسرویس‌ها یک رویکرد برای توسعه اپلیکیشن‌ها به صورت سرویس‌های کوچک است که هرکدام در قسمت پردازش خود اجرا می‌شوند و معمولا از طریق یک مکانیزم سبک مانند یک HTTP resource API ارتباط برقرار می‌کنند. این سرویس‌ها براساس سازگارهای و قابلیت‌های مربوط به لایه business ایجاد می‌شوند.
اگر قصد دارید از این معماری استفاده کنید، باید فواید و معایب زیر را در نظر بگیرید:
فواید Microservices
- سازمان‌دهی بهتر: معماری میکروسرویس‌ها معمولا بهتر دسته‌بندی و سازمان‌دهی می‌شوند. این بدان دلیل است که هر میکروسرویس یک کار منحصر به فرد را انجام می‌دهد و کاری به دیگر اجزا ندارد.
- جداسازی شده: سرویس‌های از هم جداشده برای برآورده کردن نیازهای مربوط به اپلیکیشن‌های دیگر قابلیت تغییر و پیکربندی مجدد ساده‌تری را ارائه می‌دهند. آن‌ها همچنین در یک سیستم یکپارچه بزرگ‌تر قابلیت تحویل قسمت‌های منحصر به فرد را به صورت سریع‌تری ارائه می‌دهند.
- کارایی: بسته به موقعیت درست میکروسرویس‌ها همچنین می‌توانند مزیت‌های خوبی را در زمینه کارایی ارائه دهند. برای مثال وقتی قرار است از یک قسمت منحصر به فرد باری دیگر در اپلیکیشن استفاده کرد، جدا کردن آن قسمت از دیگر اجزا کار ساده‌ای خواهد بود.
- اشتباهات کمتر: میکروسرویس‌ها به شما قابلیت توسعه موازی را می‌دهند. به همین دلیل احتمال انجام اشتباهات در این حالت کمتر می‌شود.
معایب Microservices:
- نگرانی قطع شدن در ارتباط با هر سرویس: همانطور که شما یک معماری میکروسرویس جدید را ایجاد می‌کنید، ممکن است با قطع شدن‌های مختلفی مواجه شوید که در زمان طراحی سیستم با آن‌ها برخورد نکرده‌اید. شما یا مجبور هستید که تمام این موارد را دوباره بررسی کنید و یا اینکه می‌توانید در یک لایه دیگر از سرویس‌ها با آن‌ها تعامل داشته باشید.
- انجام عملیات‌های بیشتر: میکروسرویس‌ها به صورت مکرر روی ماشین مجازی یا کانتینر خودشان اجرا می‌شوند. به همین دلیل میزان بیشتری را اشغال کرده و نیاز به کارهای بیشتری برای انجام دادن هستند. این وظایف معمولا توسط یک ابزار مدیریت خودکارسازی می‌شوند.
تصمیم درست را برای سازمان‌تان بگیرید
مزایا و معایب گفته شده در این مطلب می‌تواند یک چهارچوب را برای بحث کردن در ارتباط با انتخاب یک سیستم در زمان جلسات تیمی فراهم آورد. برای اینکه بتوانید این موارد را به صورت کارآمد اعمال کنید من یکسری مصاحبه را با مدیران ارشد فناوری شرکت‌های مختلف تشکیل دادم تا بتوانیم بهترین تصمیم را برای یک سازمان بگیریم.
آیا شما در یک قلمرو مشابه هستید؟
ابتدای امر خود و تیم‌تان را ارزیابی کنید. ببینید آیا با هیچ کدام از این سیستم‌ها آشنایی دارید. اگر قابلیت استفاده از یک مورد به صورت آماده در شما وجود دارد پس بهتر است انتخاب امن‌تری را برای پروژه داشته باشید.
آیا تیم‌تان آماده است؟
تیم‌تان با میکروسرویس‌ها تجربه کاری دارد؟ اگر تیم‌تان در سال‌های آینده چهار برابر شوند آیا باز هم میکروسرویس‌ها برای‌شان ایده‌آل خواهد بود؟ ارزیابی کردن این موارد برای به موفقیت رسیدن تیم‌تان حیاتی است.
زیرساخت‌تان به چه صورت است؟
در حقیقت برای اینکه معماری میکروسرویس‌ها برای‌تان به درستی کار کند نیاز به یک زیرساخت مبتنی بر ابر دارید.
در غیر اینصورت تصور کنید که برای هر سرویس کوچکی یک بانک اطلاعاتی یا نمونه از آن را داشته باشید بدین صورت کار واقعا پیچیده می‌شود.
ریسک‌های تجاری را بررسی کنید
ممکن است فکر کنید که معماری میکروسرویس‌ها برای یک استارتاپ بسیار عالی است. اما میکروسرویس‌ها همراه با ریسک‌های تجاری نیز هستند. در این رابطه David Strauss می‌گوید:
«بسیاری از تیم‌ها پروژه‌شان را بارها از ابتدای کار ایجاد می‌کنند، همه می‌خواهند استارتاپ‌شان عالی و بسیار منحصر به فرد باشد به همین دلیل براساس میکروسرویس‌ها پیش می‌روند و واقعیت را بگویم این موضوع بسیاری از اوقات به صورت اشتباه ادامه پیدا می‌کند.»
او همچنین ادامه داد که در این شرایط ممکن است چیزهایی نیاز به بزرگ شدن و توسعه دارند که احتمالا در قدم اول به آن‌ها نیازی نیست.
محتوا مهم است
بسیاری از مدیران ارشدی که با آن‌ها صحبت کردم با هر دو معماری آشنایی کامل داشتند و می‌دانستند که باید براساس شرایط تصمیم درست گرفته شود. به همین دلیل من سناریوهای زیر را آماده کردم که درک بهتر و بیشتری از شرایط داشته باشیم.
چه زمانی با معماری Monolith کار کنیم؟
در اینجا سه سناریو برای زمانی که می‌خواهید پروژه بعدی‌تان را با Monolith پیاده‌سازی کنید وجود دارد:
- تیم‌تان در مرحله تاسیس است: تیم‌تان کوچک است، اعضای آن در بین ۲ تا ۵ نفر است. به همین دلیل شما قابلیت انجام کارهای مختلف را در یک معماری میکروسرویس مانند ندارید.
- شما در حال ایجاد یک محصول ثابت نشده هستید: آیا مشغول یک محصول ثابت نشده در بازار هستید؟ اگر این یک ایده جدید است و می‌خواهید که بارها و بارها آن‌ها را ارزیابی کنید بنابراین معماری یکپارچه به شما سرعت بیشتری را برای انجام کارهای تکراری می‌دهد. چنین ایده‌ای برای یادگیری نیز به همین شکل است.
- شما تجربه‌ای در استفاده از میکروسرویس‌ها ندارید: اگر تیم‌تان تجربه‌ای در استفاده از میکروسرویس‌ها را ندارد، بنابراین باید با معماری یکپارچه پیش بروید.
چه زمانی با معماری Microservices کار کنیم؟
در اینجا سه سناریو برای زمانی که می‌خواهید پروژه بعدی‌تان را با Microservices پیاده‌سازی کنید وجود دارد:
- شما نیازمند یک تحویل سرویس مستقلی به سرعت هستید: میکروسرویس‌ها به شما قابلیت تحویل سریع سرویس‌ها و قسمت‌های منحصر به فرد و مختلف یک سیستم بزرگ را می‌دهند. البته این موضوع در اصل به تعداد افراد موجود در تیم توسعه‌تان بستگی دارد.
- می‌خواهید یک قسمت از پلتفرم‌تان بسیار کارآمد باشد: اگر بخواهید قسمتی از یک پلتفرم را به صورت منحصر به فرد با یک زبان دیگر و یا یک سطح بهتر از کارایی ایجاد کنید، بنابراین استفاده از معماری میکروسرویس‌ها برای‌تان کاربری خواهد بود.
- برنامه شما در پی رشد تیم‌تان است: شروع کار با میکروسرویس‌ها از تیم‌تان بدین شکل کار می‌کشد که در ابتدا آن‌ها باید سرویس‌های کوچک مستقلی را ایجاد کنند. بر همین اساس تیم‌تان بسیار سریع‌تر گروه‌بندی شده و قابلیت توسعه و رشد آن بیشتر می‌شود.
معماری یکپارچه نمرده است و معماری میکروسرویس‌ها نیز برای همه پروژه‌ها عالی نیست. تنها بدلیل استفاده بیشتر از میکروسرویس‌ها سعی نکنید که به سمت آن معماری بروید. بجای این سعی کنید به نیازهای‌تان توجه داشته باشید.
دیدگاه و پرسش
در حال دریافت نظرات از سرور، لطفا منتظر بمانید
در حال دریافت نظرات از سرور، لطفا منتظر بمانید