آرین تاپ لرن

تاریخ انتشار:۱۱:۲۷ ۱۳۹۸/۱۲/۱۱

مقدمه

اگر از معماری Monolithic برای توسعه سرویس‌‌های خود استفاده کنیم، در انتها نیاز داریم برنامه‌ای را روی یک سرور نصب کنیم. یا اگر برنامه ما قرار باشد بار زیادی را تحمل کند، چندین سرور تهیه می‌کنیم و نرم‌افزار خود را روی چند سرور نصب می‌کنیم و به کمک یک Load Balancer بار را روی نمونه‌های مختلف توزیع می‌کنیم. هرچند همیشه کار به همین سادگی نیست اما در پیچیده‌ترین حالات هم معمولا توزیع نرم‌افزار‌های Monolithic ساده‌تر از میکروسرویس‌ها است.
در مقابل هنگامی که از معماری میکروسرویس استفاده می‌کنیم، برای یک برنامه ممکن است ده‌ها یا صد‌ها سرویس داشته باشیم. هر کدام از این سرویس‌ها ممکن است با زبان و فریمورکی خاص توسعه داده شده باشند. هر کدام از این مینی اپلیکیشن‌هایی که تولید می‌کنیم، اندازه‌های متفاوت، بار‌های متفاوت، درخواست‌های متفاوت و زیرساخت‌های نگهداری و مانیتورینگ متفاوتی‌هم ممکن است داشته باشند. ممکن است شما نیاز داشته باشید با توجه به تعداد درخواست‌هایی که برای هر سرویس ارسال می‌شود، تعداد متفاوتی نسخه از این سرویس را اجرا کنید. هر نسخه از این سرویس‌ها هم باید زیرساخت مناسبی از نظر CPU, Ram و ... در اختیار داشته باشند. در کنار همه این پیچیدگی‌ها نصب و راه اندازی نرم‌افزار ما باید سریع، مطمئن و مقرون به صرفه باشد. روش‌های متفاوتی برای دست‌یابی به این اهداف وجود دارد که در ادامه به بررسی این روش‌ها می‌پردازیم.

روش اول: نصب چند سرویس‌ مختلف به ازای هر میزبان

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

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

سرعت بالای نصب و راه اندازی یکی دیگر از مزایای استفاده از این روش است. شما می‌توانید به سادگی نسخه‌ای از نرم‌افزار را روی سرور‌های مختلف کپی می‌کنیم و برنامه را اجرا می‌کنیم. اگر انتخاب شما .NET باشد به سادگی Assemblyهای خود را روی سرور‌ها کپی می‌کنید. در مورد جاوا هم می‌توانید JAR یا WAR فایل‌های خود را روی سرور هدف کپی کنید و اگر از Node.Js استفاده کنید باید سورس برنامه‌های خود را روی سرور کپی کنید.

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

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

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

روش دوم: نصب یک سرویس به ازای هر میزبان:

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

• نصب هر سرویس روی یک ماشین مجازی:
  
  هنگامی که از این روش استفاده می‌کنیم، ابتدا از نرم‌افزار خود یک خروجی تهیه می‌کنیم و روی یک ماشین مجازی نصب می‌کنیم. سپس از ماشین‌ مجازی نسخه پشتیبان تهیه کرده و هر زمانی که نیاز به نصب یک نسخه جدید از سرویس داشته باشیم، نسخه ای جدید از ماشین مجازی را اجرا می‌کنیم. پیاده سازی این روش را در تصویر زیر مشاهده می‌کنید.

هنگامی انتخاب این سناریو از ابزارهای متفاوتی مثل teamcity, Octopus, Jenkins, Packer و ... می‌توانید استفاده کنید تا روال انتشار نرم افزار و نصب آن روی ماشین مجازی و تهیه Image از ماشین مجازی را به صورت اتوماتیک پیاده سازی کنید که بررسی این روش‌ها خارج از حوصله این مبحث است و در صورتی که تمایل داشته باشید می‌توانید مطالب تخصصی این حوزه را مطالعه نمایید.

بزرگترین مزیت استفاده از این روش ایزوله بودن کامل نسخه‌های اجرایی هر سرویس است. در این روش هر نسخه از سرویس مقدار ثابتی CPU, Ram و Hardدر اختیار دارد که نمی‌تواند از حدود مجاز خود تخطی کند.

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

اما در کنار این مزایا استفاده بد از منابع زیرساختی بزرگترین ضعف استفاده از این روش است. شما به ازای هر نسخه از نرم‌افزار خود باید هزینه‌هایی برای زیرساخت نرم افزاری مثل سیستم‌عامل و آنتی ویروس و ... در نظر بگیرید.

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

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

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

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

استفاده از این روش‌هم مزایا و معایب خاص خودش را دارد. اما مهم ترین مسئله این است که مزیای این روش بر معایب آن میچربد.

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

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

جمع بندی:

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

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

منبع:nikamooz