معماری میکروسرویس ها ( Microservices Architecture ) ، رویکرد و روشی است که در آن یک اپلیکیشن واحد ، از تعداد زیادی سرویس های کوچک تر که خود آزاد و مستقل هستند تشکیل می شود .
میکروسرویس ها ( معماری میکروسرویس ها ) یک رویکرد معماری native ابری می باشد که یک اپلیکیشن واحد از تعداد زیادی سرویس های کوچک تر که خود مستقل و آزاد هستند تشکیل شده است که این سرویس ها معمولا دارای ویژگی های زیر می باشند :
با اینکه بیشتر بحث مربوط به میکروسرویس ها ، حول محور تعاریف و ویژگی های مروبط به این معماری نرم افزاری می چرخد ، می توان ارزش میکروسرویس ها را از طریق مزایای تجاری و سازمانی به خوبی متوجه شد:
همچنین از طریق مقایسه معماری میکروسرویس ها با معماری های دیگر میتوان به درک بهتری از این معماری نرم افزاری رسید . برای مثال می توان دو معماری میکروسرویس ها و معماری یکپارچه را مورد مقایسه قرار داد . تفاوت میان معماری میکروسرویس ها و معماری یکپارچه این است که در میکروسرویس ها ، یک اپلیکیشن به تعداد زیادی سرویس کوچک تر که خود مستقل هستند تقسیم می شود ولی در معماری یکپارچه این گونه نیست و اپلیکیشن یک واحد بزرگ است و به نحوی که در میکروسرویس ها داریم ، قابل تقسیم نیست .
میکروسرویس ها همانقدر که در بین توسعه دهندگان نرم افزار محبوبیت دارند ، در میان مدیران اجرایی و مدیران پروژه ها نیز محبوب هستند . این خود یکی از ویژگی های خاص میکروسرویس ها می باشد زیرا معمولا دغدغه و بحث های مربوط به معماری مورد استفاده برای نرم افزار ، در تیم های توسعه نرم افزار قرار دارد . زیرا میکرو سرویس ها ، روش و رویکردی را که خیلی از مدیران بیزینس ها در نظر دارند تا تیم ها و پروسه توسعه خود را بر اساس آن پیاده سازی کنند ، را بهتر منعکس می کنند .
به عبارت دیگر ، میکروسرویس ها یک معماری هستند که یک مدل عملیاتی مورد نظر را بهتر تسهیل و آسان میکنند . در نظرسنجی که اخیرا در سال 2021 شرکت IBM ( که یکی از شرکت های عظیم تکنولوژی می باشد ) درباره میکروسرویس ها از حدود 1200 توسعه دهنده و مدیر فناوری اطلاعات انجام داده است ، حدود 87 درصد از کاربرانی که از میکروسرویس ها استفاده می کنند ، تایید کرده اند و موافق هستند که رفتن به سمت معماری میکروسرویس ها و پذیرش این معماری ، ارزش هزینه و تلاش مورد نیازش را دارد .
گسترش مستقلانه
احتمالا مهمترین ویژگی معماری میکروسرویس ها این باشد که چون سرویس ها کوچک تر هستند ، برای تغییر یک خط کد یا اضافه کردن امکانات جدید ، نیازی به تصمیم گیری های عظیم وجود ندارد و تغییرات ساده تر و سریع تر می توانند انجام پذیرند .
میکروسرویس ها در سازمان ها این قابلیت را ایجاد میکنند که بسیاری از مشکلاتی و دغدغه های مربوط به اینکه یک تغییر کوچک ، هزینه زمانی بسیاری را در پی خواهد داشت ، را کاهش دهند و این موضوع که رویکردی که سرعت و چابک بودن ( Agile ) را تسهیل کند ، بسیار ارزشمند است ، کاملا واضح می باشد .
ولی سرعت ، تنها مزیت طراحی سرویس ها از طریق این معماری نیست . یکی از مدل های سازمانی در حال رایج و ترند شدن این است که تیم های مختلف ، حول یک مشکل بیزینسی یا سرویس یا محصول گرد هم جمع شوند. مدل میکروسرویس ها به خوبی با این مدل و روند مطابقت می کند. چون سازمان ها را قادر می سازد تا تیم های کوچک و متقابلی را حول یک سرویس یا مجموعه ای از سرویس ها جمع کند و آن ها را با شیوه ای چابک و Agile ، به کار گیرد .
اینکه این در میکروسرویس ها ، سرویس ها به هم وابسته نیستند ، باعث می شود که ایزوله سازی خطا و انعطاف پذیری بهتری در اپلیکیشن ایجاد شود . کوچک بودن سرویس ها به همراه مشخص بودن حدود و مرز های آن ها و همچنین واضح بودن نحوه ارتباط آن ها با هم ، باعث می شود که اعضای جدید که وارد تیم می شوند ، کد ها را بتوانند بهتر درک کنند و سریع تر بتوانند در پروژه مشارکت داشته باشند . ( نمونه ای واضح از مزایای میکروسرویس ها در زمینه سرعت و روحیه اعضای تیم )
ابزار مناسب برای کار
در معماری های سنتی ، معمولا یک اپلیکیشن ، یک سری تکنولوژی یا درواقع stack مشترک را به همراه یک پایگاه داده رابطه ای بزرگ که از کل اپلیکیشن پشتیبانی می کند را شامل می شود . این رویکرد چندین مشکل دارد . مشخص ترین مشکل این رویکرد آن است که تمام قسمت های اپلیکیشن باید از همان تکنولوژی مشترک و مدل داده و پایگاه داده استفاده کنند حتی با اینکه ابزار های مناسب تری برای کار برخی از قسمت ها وجود داشته باشد . این باعث ایجاد یک معماری بد می شود و همچنین برای توسعه دهنده هایی که آگاه به این موضوع هستند که ابراز ها و راه ها و رویکرد های بهتر و بهینه تری برای ساخت قسمت هایی از اپلیکیشن وجود دارد ، آزار دهنده می باشد .
در مقابل ، در یک مدل میکروسرویس ها ، قسمت ها مختلف اپلیکیشن به صورت مستقل گسترش داده می شوند و از طریق ترکیبی از REST API ها و Message Broker ها و Event Streaming ها ارتباط بر قرار میکنند . بنابراین امکان این وجود دارد که برای هر بخش و قسمت ، تکنولوژی و Stack و رویکرد مناسب و بهینه برای آن قسمت را در گسترش آن به کار ببریم . تکنولوژی هرلحظه و هر زمان در حال تغییر می باشد و قطعا اپلیکیشنی که از قسمت ها و سرویس های کوچک و مستقل تشکیل شده باشد ، توسعه آن با تکنولوژی های جدید و مورد نظر ، آسان تر و کم هزینه تر خواهد بود .
چالش های موجود
میکروسرویس ها با اینکه مزایای زیادی دارند ولی این مزایا چالش هایی را به همراه خود دارد . انتقال از معماری یکپارچه به معماری میکروسرویس ها به معنای پیچیدگی بیشتر در مدیریت ، سرویس های بیشتر که توسط تیم های بیشتری در مکان های بیشتری ساخته شده اند می باشد . مشکل در یکی از سرویس ها می تواند در سرویس های دیگر مشکل ایجاد کند یا اینکه خود نتیجه مشکل در یک سرویس دیگر بوده باشد . لاگ کردن داده ها ( که برای مانیتورینگ و بررسی مشکلات استفاده می شود ) ارزش بیشتری پیدا می کند . نسخه های جدید می توانند مشکل سازگاری با نسخه های قبلی را ایجاد کند .
اپلیکیشین ها شامل اتصالات شبکه بیشتری خواهند بود که به این معنی است فرصت بیشتری برای مشکلات مربوط به تاخیر و اتصالات ایجاد خواهد شد. استفاده از راهکار DevOps می تواند بسیاری از این مشکلات را تحت پوشش قرار دهد ولی خود این راه کار ، چالش های مربوط به خود را دارد !
با این حال ، این چالش ها باعث نمی شود که حرکت به سمت این معماری با توجه به مزایای زیادی که دارد ، متوقف شود و افرادی را که هنوز از این معماری استفاده نکرده اند را از حرکت به سمت آن باز نمی دارد . همچنین افرادی را که از این معماری استفاده میکنند را از ادامه استفاده و عمیق تر شدن باز نمی دارد .
در نظرسنجی اخیر شرکت IBM ، داده ها نشان می دهد که 56 درصد کابرانی که از میکروسرویس ها استفاده نمی کنند ، شاید یا به احتمال زیاد در طی دو سال آینده از معماری میکروسرویس ها استفاده خواهند کرد و 78 درصد از کاربران فعلی که در حال استفاده از این معماری هستند ، احتمالا زمان و منابع مالی و تلاش بیشتری را در این زمینه سرمایه گذاری خواهند کرد .
معماری میکروسرویس ها به طور معمول ، تحت عنوان بهینه سازی شده برای DevOps و CI/CD مطرح می شوند که در چون سرویس های کوچک می توانند به طور مکرر مورد گسترش و توسعه قرار گیرند ، درک این عنوان واضح است . (منظور از CI/CD عبارت Continuous integration / Continuous Delivery می باشد )
اما اگر بخواهیم از زاویه دیگری به رابطه بین میکروسرویس ها و DevOps نگاه کنیم ، درواقع می توان گفت که معماری میکروسرویس ها برای موفق بودن ، به DevOps نیاز دارد . با اینکه اپلیکیشن هایی با معماری یکپارچه مشکلاتی را دارند که قبلا در همین مقاله به آن اشاره شد ، یکی از مزیت های آن ها این است که این اپلیکیشن ها ، سیستم های توزیع شده با قسمت های مختلف که هر کدام تکنولوژی و stack خاص و مستقل خود را دارند، نیستند .
در مقابل ، با توجه به افزایش در پیچیدگی ، قسمت های مستقل و وابستگی های مربوط به میکروسرویس ها ، استفاده کردن از این معماری و نزدیک شدن به آن بدون توجه و سرمایه گذاری قابل قیاس در توسعه و استقرار و نظارت و مانیتورینگ و اتوماسیون چرخه حیات ( Lifecycle ) کار غیر عقلانی و به دور از اندیشه می باشد .
با اینکه تقریبا هر زبان و ابزار مدرنی را میتوان در این معماری مورد استفاده قرار داد ، ولی یکسری از ابزار های مهم و کاربردی وجود دارند که برای استفاده از این معماری ، نقش پایه و اساسی دارند :
استفاده از Container ها ، Docker و Kubernetes
یکی از ویژگی های کلیدی یک میکروسرویس این است که به طور کلی ، بسیار کوچک است . ( البته هیچ مقدار دلخواهی از کد یا تعداد خطوط کد وجود ندارد که تعیین کند که مثلا یک سرویس ، میکروسرویس به حساب می آید یا نه ، ولی همانطور که در طول این مقاله مشاهده کردید ، عبارت "میکرو" در نام این معماری وجود دارد )
هنگامی که داکر در سال 2013 ، عصر کانتینر های مدرن را اغاز کرد ، همچنین یک مدل محاسباتی را معرفی کرد که ارتباط زیادی با میکروسرویس ها داشت . چون کانتینر های مفرد و مجزا ، سربار سیستم عامل خود را ندارند ، نسبت به VM ها یا همان ماشین های مجازی ( Virtual Machines ) سنتی ، سبک تر و کم حجم تر هستند و عملکرد سریع تری خواهند داشت . این منجر به این است که با سرویس های کوچک تر و سبک تر موجود در معاری میکروسرویس ها ارتباط و مطابقت کاملی داشته باشند .
با افزایش سرویس ها و کانتینر ها ، مدیریت گروه های عظیم کانتینر ها ، سریعا تبدیل یه یکی از چالش های مهم و حیاتی شد . Kubernetes که یک پلتفرم متن باز مدیریت کانتینر ها می باشد ، به عنوان یکی از محبوب ترین راه حل های مدیریت کانتینر ها مورد استفاده قرار میگیرد و این کار را به خوبی انجام می دهد .
استفاده از API ها
میکروسرویس ها معمولا برای ارتباط با یک دیگر از API ها استفاده می کنند. درحالی که این درست است که کلاینت ها و سرویس ها میتوانند با یکدگیر مستقیما ارتباط برقرار کنند ، استفاده از API ها معمولا یک لایه واسطه ای مفید می باشد ، به خصوص زمانی که تعداد سرویس های موجود در یکی اپلیکیشن در طول زمان افزایش و رشد پیدا می کند . استفاده از API ، برای کلاینت ها نقش یک پراکسی معکوس را از طریق مسیردهی ریکوئست ها ، ارسال ریکوئست ها به چندین سرویس و همچنین ایجاد امنیت و احراز هویت بیشتر ، ایفا می کند.
تکنولوژی ها و فناوری های متعددی برای پیاده سازی API ها وجود دارد ، شامل پلتفرم های مدیریت API . ولی اگر معماری میکروسرویس ها توسط کانتینر ها و Kubernetes پیاده سازی شده باشد ، دروازه یا Gateway مربوط به API از طریق Ingress یا Istio پیاده سازی خواهد شد .
پیام رسانی و استریم رویداد ها ( Messaging and Event Streaming )
میکروسرویس های بدون حالت یا Stateless ، هیچ حالتی را در سرویس ها به هنگام فراخوانی ، حفظ نمی کنند . آن ها درخواست را دریافت می کنند ، سپس پردازش میکنند و سپس یک پاسخ را بر می گردانند بدون اینکه هیچ اطلاعاتی را ذخیره کنند . ولی میکروسرویس حالت دار یا Stateful ، وقتی مثلا یک ریکوئست را دریافت میکنند ، اطلاعات مربوط به آن ریکوئست را در حافظه خود ذخیره میکنند که این ممکن است محدودیت ها و مشکلاتی را ایجاد کند . مثلا فرض کنید که 3 میکروسرویس Stateful داریم و یک درخواست به این سرویس ها ارسال می شود و میکروسرویس شماره 1 درخواست را پردازش میکند و ادامه می دهد . حال اطلاعات مربوط به آن در خواست در میکروسرویس شماره 1 ذخیره شده است و اگر درخواست بعدی مرتبط با درخواست قبلی بوده باشد ( مثلا بخش هایی از یک تراکنش بوده باشند ) این درخواست جدید فقط می تواند توسط میکروسرویس شماره 1 مورد پردازش قرار گیرد زیرا اطلاعات مربوط به درخواست اول ، در این میکروسرویس وجود دارد . این با استفاده از میکروسرویس های Stateful است . ولی اگر از میکروسرویس های Stateless استفاده کنیم ، اطلاعات مربوط به مثلا ریکوئست ها میتواند در یک پایگاه داده مرکزی به منظور ذخیره سازی این اطلاعات ذخیره شود و در نتیجه میکروسرویس ها به این داده ها دسترسی دارند و محدودیتی که با Stateful ها داشتیم ، از بین می رود .
در حالی که ممکن است بهترین راهکار ، طراحی سرویس های Stateless باشد ، ولی سرویس های Stateful هم وجود دارند . و همچنین در حالی که استفاده از API ها معمولا یک روش موثر در ایجاد و مدیریت حالت اولیه یک سرویس است ، یک راه کار موثر برای بروز و up to date بودن نیست .
لازم است که فراخوانی های API را با سیستم های Messaging و Event Steaming همراه کنیم تا سرویس ها بتوانند این تغییرات را به گونه ای ذخیره کنند که سایر سرویس ها بتوانند به این تغییرات گوش داده و در صورت نیاز تغییرات لازم را ایجاد کنند . برای این کار از Message Broker ها مانند RabbitMQ استفاده می کنیم . البته مواردی هم وجود دارد که سیستم های Event Streaming مانند Apache Kafka شاید گزینه مناسب تری باشند.
با ترکیب میکروسرویس ها با معماری Event Driven یا مبتنی بر رویداد ، توسعه دهنده ها می توانند سیستم های توزیع شده ، قابل گسترش ، مقاوم نسبت به خطا و توسعه پذیر ایجاد کنند که می تواند مقادیر بسیار زیادی از رویداد ها یا اطلاعات را به صورت Real Time مورد مصرف و پردازش قرار دهد .
معماری Serverless
معماری Serverless بعضی از پترن ها و الگو های اصلی و مرکزی میکروسرویس ها و Cloud را به نتایج منطقی خود نزدیک میکند. در این معماری ، واحد اجرایی فقط یک سرویس کوچک نیست ، بلکه یک تابع است که معمولا می تواند از چند خط کد تشکیل شده باشد . مرز و خط جدا کننده توابع Serverless و میکروسرویس ، زیاد واضح نیست ولی به طور معمول ، مفهوم توابع این است که از میکروسرویس ها کوچک تر باشند .
جایی که معماری Serverless و پتلفرم های " توابع به عنوان سرویس " یا (FaaS) ها با میکروسرویس ها شباهت دارند آن جا است که هر دو آن ها در تلاش برای ساخت واحد های کوچک تر شامل توسعه و Deploy هستند
میکروسرویس ها لزوما مربوط به رایانش ابری نمی شوند ، ولی چندین دلیل مهم وجود دارد که بیان می کند چرا اغلب ، این دو باهم ترکیب می شوند . دلایلی که فراتر از این هستند که میکروسرویس ها یک استایل معماری جدید و محبوب برای اپلیکیشن ها است و همچنین فضای ابری یک میزبان محبوب و جدید برای اپلیکیشن های جدید است .
از جمله مزایای معماری میکروسرویس ها ، استفاده و هزینه های مربوط به توسعه و deploy کردن قسمت های مجزا و مفرد در این معماری می باشد . با اینکه این مزایا با استفاده از فضاها و زیر ساخت های غیر ابری موجود در محل ( غیر ابری ) وجود دارند ولی ترکیب بخش های کوچک ، مستقل و قابل گسترش ، با زیر ساخت های ابری که دارای ویژگی های پرداخت به ازای استفاده ( pay-per-use ) و پرداخت به میزان تقاضا ( on-demand ) جایی است که دقیقا بهینه سازی واقعی و اصلی در هزینه ها ایجاد می شود .
همچنین شاید نکته مهم تر این باشد که یکی دیگر از مزایای میکروسرویس ها این است که هر بخش مستقل ( هر Component ) می تواند از فناوری و تکنولوژی و Stack ای که کار آن بخش را به بهترین نحو انجام می دهد بهره بگیرد و استفاده کند . افزایش تنوع فناوری های مورد استفاده وقتی که خودمان آن ها را کنترل کنیم می تواند پیچیدگی های جدی و اساسی ایجاد کند . ولی استفاده از فناوری های مختلف به کمک سرویس های ابری می تواند به طور قابل ملاحظه ای این چالش های مدیریتی را کاهش دهد . یه عبارت دیگر با این که غیر ممکن نیست که زیر ساخت میکروسرویس های خود را ، خودتان مدیریت و پیاده سازی کنید ، ولی با توجه به وجود فضاهای ابری ، این روشی نیست که قابل توصیه کردن باشد به خصوص زمانی که ابتدای کار هستید و شروع به کار می کنید .
در معماری میکروسرویس ها ، تعداد زیادی الگو های طراحی ، ارتباط و ادغام کردن وجود دارد که مفید و کاربردی هستند و چالش هایی را که معمولا در این معماری با آن ها روبرو می شویم را پوشش می دهند .
در حالی که الگو های بسیاری وجود دارد که انجام آن ها در معماری میکروسرویس ها ، باعث می شود از بسیاری از مشکلات معمول جلو گیری شود ، ولی نباید هایی هم وجود دارد که از انجام آن ها باید پرهیز کرد که این موارد می توانند هر تیم توسعه ای را سریعا وارد مشکل کنند :
معماری میکروسرویس ها ( Microservices Architecture ) معماری است که نسبت به معماری های سنتی و یکپارچه ، زمانی که پیچیدگی های اپلیکیشن های یکپارچه و سنتی زیاد می شود و عملا نگهداری و توسعه اپلیکیشن با مشکل مواجه می شود ، می تواند مزایای بسیار زیادی هم از نظر فنی و هم از نظر سازمانی و بیزینسی داشته باشد و هزینه های مربوط به بخش های مالی و زمانی و نیروی توسعه ( توسعه دهنده ها ) را کاهش دهد و باعث شود تا بهینگی افزایش یابد و تمرکز بر روی موارد اصلی افزایش یابد .
پ . ن : بعضی مفاهیم موجود در این مقاله ، خود نیاز به یک مقاله جداگانه و مطالعه دقیق دارند و توضیح آن ها در این مقاله نمی گنجد . مثلا برای Docker و Kubernetes ، سیستم های Message Broker ، معماری هایی مانند Serverless و همچنین چالش های مربوط به DevOps ، نیاز به مطالعه دقیق و جداگانه هست و این مفاهیم به یکدیگر وابسته هستند .
منابع پیشنهادی برای مطالعه بیشتر در زمینه معماری میکروسرویس ها :
منبع :
