معماری میکروسرویس: مزایا و معایب

میکروسرویس ها روشی برای شکستن یک برنامه بزرگ به ماژول هایی با جفت آزاد هستند که از طریق یک API ساده با یکدیگر ارتباط برقرار می کنند. اخیراً فقط افراد گنگ در مورد میکروسرویس ها صحبت نمی کنند. این روز به روز محبوب تر می شود. به نظر می‌رسد سبک معماری مدولار به‌ویژه برای محیط‌های مبتنی بر ابر مناسب است و محبوبیت آن در حال افزایش است. قبل از اینکه به جزئیات بپردازیم، بیایید نگاهی پرنده به همه چیز داشته باشیم . بنابراین: میکروسرویس ها راهی برای تقسیم یک پروژه بزرگ به ماژول های کوچک، مستقل و آزادانه هستند. ماژول های مستقل مسئولیت وظایف کاملاً مشخص و مجزا را بر عهده دارند و از طریق یک API ساده و قابل دسترس با یکدیگر ارتباط برقرار می کنند. به عبارت دیگر، میکروسرویس ها به سادگی یک سبک معماری متفاوت برای طراحی اپلیکیشن های پیچیده و عمدتا تحت وب هستند. اما چه چیز بدی در مورد راه حل های معماری موجود مانند SOA (معماری سرویس گرا) وجود دارد؟ به نظر می رسد اکثر راه حل های مدرن سازمانی که با استفاده از SOA نوشته شده اند بسیار خوب کار می کنند. شاید این زمان خوبی باشد تا در مورد برخی از چالش هایی که این روزها صنعت با آن مواجه است صحبت کنیم... اجازه دهید با یک مثال ساده شروع کنیم. فرض کنید باید یک برنامه کلاسیک نوشته شده در جاوا را اجرا کنم. ابتدا رابط کاربری و سپس لایه منطق تجاری را با چندین مؤلفه که با رابط کاربری تعامل خواهند داشت و در نهایت لایه پایگاه داده را توسعه خواهم داد که برای پایگاه داده پایدار قابل دسترسی خواهد بود. حالا با توجه به اینکه میخواهم اپلیکیشن را اجرا کنم، یک WAR/EAR/JAR میسازم و روی یک سرور (مانند JBoss، Tomcat یا WebLogic) نصب می کنم. از آنجایی که این کار به صورت یکپارچه انجام می شود، من یک برنامه یکپارچه دریافت می کنم، یعنی همه اجزا در یک مکان هستند ... مثال در تصویر: به احتمال زیاد، شما قبلاً با این رویکرد آشنا هستید و از آن استفاده کرده اید، اما ایده این است که از این مثال استفاده کنید تا نشان دهید توسعه دهندگان با استفاده از این راه حل معماری با چه چالش هایی روبرو خواهند بود. کاربرد یکپارچه: چالش ها را به چالش می کشد

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

در عین حال، ما آماده‌ایم تا معنای میکروسرویس‌ها را در نظر بگیریم و درک کنیم، یعنی اینکه چگونه می‌توان از آنها برای بازگرداندن انعطاف‌پذیری از دست رفته با سبک SOA استفاده کرد. خدا ریزخدمات برای نجات یکی از مهمترین ویژگی ها در هر راه حل معماری، مقیاس پذیری است. در حالی که برای اولین بار مشغول یادگیری میکروسرویس بودم، دیدم که همه چیز بسیار شبیه به نقل قول های کتاب "هنر مقیاس پذیری" است. این یک شروع عالی و مکانی برای بحث است. این کتاب مدل به اصطلاح "مکعب مقیاس پذیری" را تعریف می کند که یک سیستم مقیاس پذیری سه بعدی را توصیف می کند: همانطور که می بینید، محور X "مقیاس بندی افقی" را توصیف می کند (که دیدیم برای معماری های یکپارچه نیز موجود است)، محور Y نشان دهنده مقیاس بندی به معنای جداسازی اجزای مختلف خدمات است . ایده محور Z زمانی درک می شود که داده ها تقسیم شوند و برنامه درخواست ها را دقیقاً به جایی که داده ها قرار دارند ارسال می کند. یعنی همه یک جا نیستند. ایده محور Y همان چیزی است که با جزئیات بیشتر روی آن تمرکز خواهیم کرد. این محور یک تجزیه عملکردی را نشان می دهد . در این استراتژی می توان عملکردهای مختلفی را به عنوان خدمات مستقل در نظر گرفت. بنابراین، با نصب کل برنامه تنها زمانی که همه چیز انجام شده است، توسعه دهندگان می توانند خدمات جداگانه را مستقل از یکدیگر نصب کنند و منتظر نمانند تا دیگران کار روی ماژول های خود را به پایان برسانند. این نه تنها زمان توسعه را بهبود می بخشد، بلکه انعطاف پذیری را برای تغییر و سیم کشی مجدد بدون نیاز به نگرانی در مورد بقیه اجزای برنامه ارائه می دهد. بیایید این نمودار را با نمودار یکپارچه قبلی مقایسه کنیم: میکروسرویس‌ها: مزایا به نظر می‌رسد مزایای میکروسرویس‌ها برای متقاعد کردن توسعه‌دهندگان سازمانی مانند آمازون، نتفلیکس، ای‌بی برای شروع استفاده از این رویکرد کافی است. برخلاف کاربردهای معماری یکپارچه، میکروسرویس ها:

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

میکروسرویس ها: ویژگی های نصب و مجازی سازی اکنون می دانیم که میکروسرویس ها چیستند. و بزرگترین مزیت این است که توسط بیش از یک آرشیو WAR/EAR/JAR نصب شده است. اما چگونه نصب می شود؟ بهترین راه برای نصب میکروسرویس ها در داخل ظروف. کانتینر یک سیستم عامل مجازی کاملاً پیکربندی شده با محیط لازم پیکربندی شده است که به جداسازی دسترسی به منابع سیستم سخت افزاری که کانتینر روی آن نصب شده است کمک می کند. معروف ترین راه حل موجود در بازار البته Docker است . ماشین‌های مجازی از IaaS (زیرساخت به عنوان سرویس) مانند AWS نیز می‌توانند برای نصب میکروسرویس‌ها خوب کار کنند، اما میکروسرویس‌های نسبتاً سبک وزن ممکن است از همه منابع موجود در ماشین مجازی استفاده نکنند که می‌تواند سودآوری استفاده را کاهش دهد. همچنین می توانید میکروسرویس های خود را با استفاده از بسته OSGI (Open Service Gateway Initiative) نصب کنید. در این مورد، همه میکروسرویس ها در یک JVM اجرا می شوند، اما این شامل مسائل مبادله ای بین کنترل و جداسازی است. Microservices: معایب فقط به این دلیل که "این همه چیز جالب است" و "ما قبلاً این را ندیده‌ایم" به این معنی نیست که هیچ مضراتی وجود ندارد. در زیر لیستی از مناطق احتمالی درد که معماری میکروسرویس با خود به همراه دارد آورده شده است:

• توسعه سیستم های توزیع شده می تواند دشوار باشد. منظور من از این است که همه مؤلفه‌ها اکنون سرویس‌های مستقلی هستند - شما باید با دقت درخواست‌هایی را که بین ماژول‌ها ارسال می‌شوند رسیدگی کنید. ممکن است سناریویی وجود داشته باشد که در آن یک ماژول پاسخ نمی‌دهد و شما را مجبور می‌کند کد اضافی بنویسید تا از خراب شدن سیستم جلوگیری کنید. اگر تماس های راه دور حساس به تأخیر باشند، این می تواند دشوارتر باشد .
• پایگاه داده های متعدد و مدیریت تراکنش می تواند دردسر واقعی باشد.
• آزمایش برنامه های میکروسرویس می تواند دست و پا گیر باشد. با استفاده از یک اپلیکیشن یکپارچه، فقط باید آرشیو WAR/EAR/JAR را روی سرور اجرا کنیم و از اتصال آن به پایگاه داده مطمئن شویم. و در میکروسرویس ها، قبل از شروع آزمایش، هر سرویس جداگانه باید شروع شود.
• نصب برنامه ها می تواند مشکل باشد. آنها ممکن است نیاز به هماهنگی در مورد چندین سرویس داشته باشند که ممکن است به آسانی نصب یک کانتینر جنگی نباشد.

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