مزایای معماری میکروسرویس ها نسب به معماری یکپارچه (مانلیتیک) چیست؟ توسعه دهندگان برای مواجهه با «مقیاس پذیری و مشکلات نگهداری» سعی میکنند تا از ساختار یکپارچه به سمت ساختار میکروسرویس حرکت کنند. اما واقعا ضرورتی در این کار وجود دارد؟ معماری میکروسرویس، چه مشکلاتی را میتواند حل کند؟ در این مطلب از اَپی اِکو به بررسی مزایای معماری میکروسرویس با ترجمه مقاله‌ای از rubygarage می‌پردازیم.
مقیاس پذیری سرویس، یک دغدغه مهم در آینده!
برخی توسعه دهندگان، از اول به فکر ساختار میکروسرویس نیستند. شاید به دلیل ارزانتر بودن، سرعت بیشتر و نیاز به مهارت کمتر «مدل مانلیتیک» آن را ترجیح دهند. گرچه، در زمان ارائه محصول و یا ارتقاء آن، توسعه دهنده باید با مسائل مختلفی دست و پنجه نرم کند. مانند کاری که تیم Airbnb کرد.
باتوجه به فروشگاه آنلاین بزرگی مانند Airbnb ، که با ساختار مانلیتیک متکی بر رابی و رایلز بنا شده، در ابتدا، این ساختار بسیار مفید واقع شد.
طبق تحقیقات جسیکا تای – به عنوان یک توسعه گر در Airbnb – با توجه مرجوعیات و غیره، تاخیر در کدگذاری محصولات، به ۱۵ ساعت در هفته رسید. اوج کار، زمانی بود که پلتفرم به ۵۰۰،۰۰۰ خط کدگذاری شده رسید بود. در این زمان، Airbnb متوجه شد که مشکل اصلی، ساختار یکپارچه های است که با سرویس مانیلیتیک خود، در کدگذاری دچار مشکل است. وقتی مشکلی ایجاد میشد، بررسی آن در هر کد، کار آسانی نبود، در نتیجه مسئول هر کد باید به بررسی آن کد و واکاوی مشکل میپرداخت.
Airbnb تصمیم گرفت که سیستم درهم و پیوسته خود را به بخش های کوچکتر و گسسته تقسیم کند تا مدیریت آن آسان تر شود. طبعا در این روند، افزودن سرویسهای جدید کار آسانی بود. آنها از سیستم یکپارچه به سیستم میکروسرویس مهاجرت کردند.
امروزه Airbnb، هر هفته ۳،۵۰۰ ساختار میکروسرویس ارائه می کند که مشتمل بر ۱۰۰۰ نرم افزار مهندسی است (بجای ۲۰۰ تا در هفته) و صفحات تولیدات آنها به بیش از ۱۰ برابر رسید که با ۱۰۰ درصد کاربرهای فعال و تولیدات ۱۰۰ درصدی همراه است.
عملکرد سریع تر، از مزایای معماری میکروسرویس !
همانطور که می دانید هر میکروسرویس، به صورت «جداگانه» کار کرده و با تکنولوژیهای مجزا قابل نوشتن هستند. این نکته در مورد ساختار میکروسرویس، از اهمیت بالایی برخوردار است.
ساختار میکروسرویس، این اجازه را به آمازون داد تا تیم ساختاری سه لایه ای خود را (UI، دیتابیس و تیم مهندسان) به تیم کوچکتر و مفیدتری تبدیل کند که متناسب با قابلیت تیم، به تولیدات ادامه دهند. تیم های کوچک، مسئول هر سرویس، ساخت و اداره آن می باشند.
هر تیم در آمازون، از قانون «دو پیتزا» پیروی می کند: هر دو پیتزا باید بتواند یک تیم را سیر کند. این قانون توسط مدیر آمازون، جف بزوس ابداع شد.
ارتقاء مقیاس پذیری
از مزایای معماری میکروسرویس نسبت به ساختار به هم پیوسته مانلیتیک، این است که به بخش های مختلف اجازه میدهد تا در هر میزانی، سرویس ارائه کنند. در حالی که ساختار مانیلیتیک، تنها میتواند کل نرم افزار را مقیاس بندی کند. انعطاف پذیری میکروسرویس، به سیستم اجازه میدهد تا با سرعت بیشتری، بدون نیاز به افزایش بیش از حد منابع، گسترش پیدا کند.
این دقیقا همانی بود که نتفیلیکس در رویارویی با گسترش بیشتر کابران – در مقیاس بندی سریعتر- احتیاج داشت. در این شرایط، ساعت ها و حتی روزها طول می کشید تا تیم آن، ظرفیت مرکز داده ها را افزایش دهند. با ساختار میکروسرویس، صدها سرور مجزا برای درخواست های سرویس ها، میتوانند بهطور همزمان راه اندازی شوند، به این معنی که تیم میتواند در صورت نیاز، در کمتر از چند دقیقا، ظرفیت خود را افزایش و یا کاهش دهد.
به تعبیر آدرین کاکروفت (معمار ساختار ابری نتفیلیکس)، افزایش سیستم باید همراه با افزایش مدیریت آن باشد، که این اتفاق به طور همزمان، ثبات کل سیستم را نیز گارانتی می کند. طبعا شناسایی و حل مشکل در یک سیستم کار راحتتر و به همین شکل، از دست دادن یک سیستم خیلی بهتر از از دست دادن کل سیستم است. اما این، تنها مشکلی نبود که نتفیلیکس با مهاجرت به ساختار میکروسرویس آن را رفع کرد.
همکاری مستقل تیمهای اجرایی
زمانی که کاکروفت، دلیل مهاجرت نتفیلیکس به معماری میکروسرویس را توضیح میداد، به این نکته اشاره کرد که یک تیم محتوی بیش از ۲۵ نفر، طبعا در همکاری برای یک محصول مشخص، دچار مشکل می شوند. تیم نتفیلیکس حتی بیشتر از ۲۵ نفر بود و مدیریت آن کار دشواری بود.
با تقسیم سیستم یکپارچه به سرویس های مجزا و کوچکتر، نتفیلیکس هم به ۳۰ تیم مهندسی کوچکتر تقسیم شد که اکنون، هرکدام به صورت مجزا در حال فعالیت می باشند.
انعطاف پذیری اجزا یکی از مزایای معماری میکروسرویس
تولیدات ساختار یکپارچه، در هنگام جابجایی با محصولات کاربردی تر و یا تغییر، دارای سختی بیشتری می باشند. وقتی مهندسان قصد اصلاح برخی از آنان را داشته باشند، ممکن است دچار تاثیرات موجی، باگ و یا خطا در کل سیستم شوند.
این عیب در سیستم های یکپارچه وجود داشت که باعث شد گاردین، ساختار وب سایت خود را از یکپارچه به میکروسرویس تغییر دهد. ساختار میکروسرویس جدید به دلیل فعالیت مستقل، این امکان را فراهم می کند تا مهندسان شرایط جابجایی، افزودن و حذف سرویس های مختلف را بدون تاثیر بر دیگر سیستم ها داشته باشند.
امروزه، گاردین میتواند متناسب با نیاز خود، به آسانی بخشی را به وب سایت خود افزوده و یا حذف کند. این امر، در بخش رویدادها، از اهمیت بالایی برخوردار است. زمانی که رویدادی به اتمام میرسد، توسعه گرها میتوانند به آسانی آن را حذف کنند، بدون اینکه به دیگر بخش ها آسیبی برساند و یا ساختار اصلی سایت را تغییر دهند. بنابراین، گاردین توانست تا توانایی خود را در جایگذاری و تجهیز سیستم خود، با مهاجرت به ساختار میکروسرویس، ارتقا دهد.
افزایش رضایتمندی مشتریان !
برای خرده فروش بزرگی مانند وال‌مارت، بازه زمانی پاسخ دهی، نقش مهمی در موفقیت آن بازی می کند. زمانی که شرکت به ۶ میلیون بازدید از صفحات خود رسید، مهندسان آن به این نتیجه رسیدند که ساختار یکپارچه، توان پاسخ به این رشد را ندارد و بدتر از آن، زمان مورد نیازی بود که آن ها برای پاسخگویی احتیاج داشتند. این همان دلیلی است که در سال ۲۰۱۲، وال‌مارت تصمیم گرفت تا به سیستم میکروسرویس مهاجرت کند.
نتایج آن شگفت انگیز بود. بازه زمانی پاسخ دهی به حداقل رسیده بود. وال‌مارت، با عدم استفاده از سخت افزارهای گران قیمت و مهاجرت به سرورهای مجازی، توانست تا مخارج خود را تا سقف ۵۰ درصد کاهش دهد.
ساختار میکروسرویس، برای تولیدات در حال رشد و تیم حرفه ای، راه حل مناسبی است. اگر همچنان، برای مهاجرت به ساختار میکروسرویس دچار تردید هستید، به توضیحات زیر سر بزنید. این توضیحات محتوی بسیاری از دیگر مزایای این ساختار می باشند.
آماده ی درک بهتر از معماری میکروسرویس هستید؟
ساختار میکروسرویس به مهندسین این اجازه را می دهد که از بیشتر مشکلات اساسی نرم افزار یکپارچه گذر کنند و اثرگذاری تولیدات شما را به حداکثر برسانند. پس از مطالعه ی این مقاله، شما نباید بپرسید که چرا باید به ساختار میکروسرویس مهاجرت کرد، تنها باید بپرسید چگونه باید به این ساختار مهاجرت کنیم.
اِی پی آی (API) چیست؟!
منبع: rubygarage.org
مزایای معماری میکروسرویس
نویسنده: داریا آر – شانزدهم آپریل ۲۰۱۹
مترجم: حمیدرضا نقلی
