امروزه با افزایش تقاضا برای برنامه های کاربردی بزرگ، مفهومی به نام میکروسرویس ها در صنعت توسعه نرم افزار توسعه یافته است، زیرا توسعه دهندگان چاره ای جز توسعه سیستم های تجاری بزرگ با استفاده از معماری میکروسرویس ها ندارند. در ظاهر، مفهوم میکروسرویس ها ممکن است کمی پیچیده به نظر برسد، اما در واقعیت اصلا اینطور نیست، و در این پست به چیستی، چرایی آن و مزایا و معایب استفاده از میکروسرویس ها می پردازیم.
معماری یکپارچه چیست؟
برای درک ماهیت میکروسرویس ها، ابتدا باید ببینیم معماری یکپارچه چگونه کار می کند. به طور کلی در این نوع معماری سه لایه زیر عناوین زیر داریم:
- مدل (منطق برنامه)
- مشاهده (خروجی برنامه)
- کنترلر (رابط بین خروجی ها و منطق برنامه)
مشکلات معماری یکپارچه
این نوع معماری که به معماری MVC نیز معروف است دارای معایب متعددی است. به عبارت دیگر، تمامی لایه ها (مدل ها، نماها و کنترلرها) تحت پرچم یک پلتفرم مدیریت می شوند و ارتباط بسیار نزدیکی با یکدیگر دارند، بنابراین جابجایی مدل یک اپلیکیشن نوشته شده در معماری MVC کار آسانی نیست. و در پروژه دیگری از آن استفاده کنید.
اما در معماری MVC کدها ماژولار هستند و نسبت به گذشته که همه فایل ها در یک پوشه ذخیره می شدند و اصلا مفهومی به نام ماژول وجود نداشت وضعیت خیلی بهتر است اما همانطور که گفته شد هر ماژولی به آن نیاز داشت. به ماژول های دیگر به طور کلی مشکلات مربوط به معماری یکپارچه را می توان به دسته های زیر تقسیم کرد:
- از آنجایی که دیگر یک کد منبع اصلی وجود ندارد، همه اعضای تیم، از توسعه دهندگان فرانت اند گرفته تا برنامه نویسان سمت سرور، باید با کد منبع یکسان کار کنند. باید پیکربندی و شروع به کار روی پروژه خود کنید.
- یک تغییر کوچک در یکی از ماژول ها می تواند عملکرد ماژول های دیگر را تحت تاثیر قرار دهد.
- درست است که در این نوع معماری مفهومی به نام MVC داریم، اما به مرور زمان این سه لایه به قدری با هم ادغام می شوند که ایجاد مرز مشخص بین آنها دشوار خواهد بود.
- کل معماری نرم افزار باید تغییر کند تا اجزای آن با معماری جدیدتر و بهینه تر جایگزین نشوند.
- تنوع فناوری ها اعم از زبان های برنامه نویسی، بانک های اطلاعاتی مختلف، کتابخانه ها و فریم ورک ها وجود ندارد و اگر چنین باشد، ارتباط بین آنها بسیار مشکل خواهد بود.
- و یک اشکال در یکی از ماژول ها می تواند کل پروژه را تحت الشعاع قرار دهد.
اینجاست که میکروسرویس ها وارد عمل می شوند و مزایای آنها باعث شده است که شرکت های بزرگی مانند آمازون یا نتفلیکس از میکروسرویس ها استفاده کنند.
معماری میکروسرویس چیست؟
میکروسرویس روشی برای تقسیم یک برنامه (نرم افزار) به بخش ها یا خدمات کوچک، سبک، مستقل و قابل مدیریت است. به عبارت دیگر Microservice یک معماری توسعه نرم افزاری به اصطلاح توزیع شده است.
حال می توان این سوال را مطرح کرد که سرویس های مختلف یک اپلیکیشن مجهز به معماری میکروسرویس چگونه با یکدیگر ارتباط برقرار می کنند؟ برای پاسخ به این سوال، همانطور که در تصویر بالا نشان داده شده است، این ارتباط با درخواست های HTTP و یک سری API های RESTful برقرار می شود.
آشنایی با معماری سرویس گرا.
سوال دیگری در اینجا مطرح می شود و آن اینکه با چنین تفاسیری تفاوت چندانی بین معماری سرویس گرا یا به اختصار SOA و میکروسرویس وجود ندارد، در پاسخ به این سوال می توان گفت که میکروسرویس نوعی SOA (معماری سرویس) است که در گذشته دهه ها بسیار محبوب بود، اما در عین حال، میکروسرویس ها نسبت به معماری مبتنی بر سرویس انعطاف پذیرتر هستند، زیرا به راحتی می توان یک سرویس یا ماژول را از یک پروژه گرفت و در پروژه دیگری بدون پیکربندی خاص استفاده کرد، اما هنوز هم معماری SOA است. در یک معماری به اصطلاح یکپارچه اجرا شده است.
به عبارت دیگر، در معماری SOA، ما کامپوننت ها یا ماژول هایی داریم که به اجزای دیگر خدمات ارائه می دهند و اگرچه این کامپوننت ها ممکن است برای یک برنامه خاص منحصر به فرد باشند، از سوی دیگر، در معماری میکروسرویس، این اجزا کاملا مستقل هستند. خدماتی وجود دارد که می توان آنها را به صورت جداگانه اجرا کرد. نکته دیگری که در رابطه با تفاوت این دو معماری نرم افزار باید مورد توجه قرار گیرد اندازه ماژول ها است. به عبارت دیگر میکروسرویس ها بسیار کوچک هستند و همین موضوع مدیریت آنها را بسیار آسان می کند.
مزایای استفاده از میکروسرویس ها
امروزه اعتدال به یک مزیت رقابتی در همه صنایع تبدیل شده است. از مبلمان IKEA گرفته تا ماژول‌های موبایل و اسباب‌بازی‌های LEGO، ایده پشت میکروسرویس‌ها این است که به توسعه‌دهندگان اجازه می‌دهند تا برنامه‌های کاربردی خود را بر روی اجزا یا خدمات مستقل بسازند و به راحتی آنها را تغییر دهند. و به روز رسانی ها را می توان بدون بازنویسی کل برنامه اجرا کرد. به طور کلی، مهمترین مزایای استفاده از معماری میکروسرویس ها عبارتند از:
- بر خلاف معماری یکپارچه، خدمات در یک برنامه کاربردی با استفاده از معماری میکروسرویس ها هرگز بر اساس معماری MVC تقسیم نمی شوند، بلکه بر اساس کاری که انجام می دهند به بخش های مختلف تقسیم می شوند. به عبارت دیگر، سرویسی مانند آپلود فایل شامل بخش هایی مانند رابط کاربری، مدل های مربوط به پایگاه داده، کنترل کننده، سیستم لاگ و غیره است.
- یکی دیگر از مزایای میکروسرویس ها این است که ما مجبور نیستیم در طول پروژه فقط از یک زبان برنامه نویسی یا فناوری استفاده کنیم. یعنی با توجه به اینکه امروزه برخی از زبان‌های برنامه‌نویسی برای حوزه‌های خاصی تخصصی‌تر شده‌اند و استفاده از زبانی که برای یک کار خاص طراحی شده است، عملکرد برنامه ما را با استفاده از میکروسرویس‌ها افزایش می‌دهد، ما می‌توانیم از چندین زبان بسته به نوع خدمات ما برنامه نویسی و فن آوری های مختلف را می خواهیم و به بالاترین بهره وری می رسیم.
- علاوه بر موارد فوق، میکروسرویس ها را مقیاس پذیر می نامند. ماهیت مستقل ماژول های مختلف یک میکروسرویس به ما این توانایی را می دهد که از یک زبان خاص، یک پایگاه داده خاص و یک سرور خاص برای توسعه برنامه مورد نظر خود استفاده کنیم و در صورت نیاز فقط منابع همان پلتفرم را به روز کنیم.
معایب استفاده از میکروسرویس ها
تا اینجا به مزایای میکروسرویس ها پرداختیم، اما باید توجه داشته باشیم که این نوع معماری توسعه اپلیکیشن دارای نقاط ضعفی نیز می باشد که برخی از مهمترین آنها عبارتند از:
- از آنجایی که هر سرویس وظیفه انجام وظیفه خاصی را بر عهده دارد، در یک برنامه بسیار بزرگ تعداد بی نهایت سرویس خواهیم داشت و بنابراین ارتباط بین این سرویس ها و از همه مهمتر نظارت بر آنها بسیار دشوار خواهد بود (برخی داده ها نشان می دهد که یک سرویس مانند نتفلیکس صدها سرویس مختلف دارد).
- سرویس ها برای رفع نیازهای خود با سایر سرویس ها تماس می گیرند و بر آنها نظارت می کنند که روند عیب یابی را بسیار دشوار می کند.
- هر سرویس لاگین مخصوص به خود را دارد، بنابراین سیستم ردیابی متمرکزی برای مشاهده لاگ ها وجود ندارد و در چنین شرایطی نیاز به سیستم مدیریت لاگ متمرکز خواهد بود.
- به دلیل اتصال سرویس ها از طریق API، تعداد درخواست ها بیشتر از معماری یکپارچه خواهد بود.
- استقرار دستی برنامه هایی که با استفاده از معماری میکروسرویس طراحی شده اند دشوار است و در چنین شرایطی به ابزارهای اتوماسیون پیشرفته نیاز خواهد بود.
- نسخه سازی میکروسرویس ها باید جدا از یکدیگر انجام شود و در اینجا مشخص شود که مثلاً کدام سرویس نسخه A با کدام سرویس نسخه Z پیاده سازی شود.
- مستندسازی این برنامه ها بسیار مشکل است زیرا به دلیل مستقل بودن هر ماژول، خدمات باید به خوبی مستند باشد.
- با توجه به اینکه می توان از بسیاری از زبان های برنامه نویسی و فناوری های مختلف در چنین برنامه هایی استفاده کرد، هزینه نگهداری چنین سیستم هایی گاهی افزایش می یابد، به عنوان مثال نیاز به استخدام توسعه دهندگان زبان های مختلف داریم.
- امروزه بسیاری از برنامه ها نیاز به حذف یا به روز رسانی بسیاری از رکوردهای پایگاه داده به طور همزمان دارند. در چنین مواردی، با توجه به اینکه در یک معماری تنها یک پایگاه داده وجود دارد، این کار به راحتی انجام می شود، اما در میکروسرویس ها، چنین وقفه ها یا به روز رسانی ها دشوار است، زیرا ممکن است یکی از سرویس ها رکوردی در پایگاه داده داشته باشد. آنها می خواهند با یکدیگر در یک سرویس متفاوت با یک سرور خاص در سرور دیگری همگام شوند.
چه زمانی به میکروسرویس تغییر دهید؟
در مرحله بعد بیان می کنیم که اگر مربوط به اپلیکیشن شما باشد، وقت آن رسیده است که میکروسرویس ها یکی از گزینه های پیش روی شما باشند.
- اگر کد پروژه شما به اندازه کافی بزرگ باشد که بتواند آن را به صورت محلی کامپایل کند، مانند قرار دادن کل پروژه در یک IDE، کار دلهره آور و غیرقابل توضیحی است.ساخت برخی پروژه های بزرگ که به صورت یکپارچه نوشته می شوند، گاهی ده ها دقیقه طول می کشد.
- معماری یکپارچه مستلزم آن است که تمام منابع سیستم به یکباره ارتقا یابد، اما تنها بخشی از نرم افزار نیاز به توسعه دارد. اگر نیازی به نصب نسخه به این روش ندارید.
- اگر توسعه دهندگان با هم نباشند و نتوانند به طور مستقل روی پروژه کار کنند.
تصمیم
موضوع معماری میکروسرویس بسیار گسترده است و زمانی که می خواهیم وارد این حوزه شویم لازم است که با مفاهیمی مانند Continuous Integration، Continuous Deploymnet، Containers و همچنین ابزارهای استقرار خودکار آشنایی داشته باشیم. وارد این حوزه شوید یا خیر.
