میکروسرویس ها | Microservices

منبع تصویر : unsplash.comمعماری میکروسرویس ها ( Microservices Architecture ) ، رویکرد و روشی است که در آن یک اپلیکیشن واحد ، از تعداد زیادی سرویس های کوچک تر که خود آزاد و مستقل هستند تشکیل می شود .میکروسرویس ها چه هستند ؟میکروسرویس ها ( معماری میکروسرویس ها ) یک رویکرد معماری native ابری می باشد که یک اپلیکیشن واحد از تعداد زیادی سرویس های کوچک تر که خود مستقل و آزاد هستند تشکیل شده است که این سرویس ها معمولا دارای ویژگی های زیر می باشند :تکنولوژی های مخصوص خود را دارند که شامل پایگاه داده ها و مدل مدیریت داده می شود این سرویس ها با ترکیبی از REST API ها و Message Broker ها و Event Streaming ها باهم ارتباط برقرار می کنند ( که هر کدام از این موارد جزئیات بسیار فراوانی را شامل می شود )با اینکه بیشتر بحث مربوط به میکروسرویس ها ، حول محور تعاریف و ویژگی های مروبط به این معماری نرم افزاری می چرخد ، می توان ارزش میکروسرویس ها را از طریق مزایای تجاری و سازمانی به خوبی متوجه شد:کد های مربوط به نرم افزار بسیار ساده تر و راحت تر می توانند بروزرسانی و Update شوند و همچنین قابلیت ها و functionality های جدید را می توان بدون اینکه کل اپلیکیشن مورد دستکاری قرار بگیرد ، اضافه شوند.تیم ها میتوانند از زبان های برنامه نویسی و تکنولوژی های متفاوتی برای هر قسمت استفاده کنند . هر جزء و قسمت را می توان جدا و بدون وابستگی به اجزای دیگر ، گسترش داد که این خود باعث می شود تا هزینه ها و ضایعات مربوط به گسترش کل اپلیکیشن به صورت یک واحد ، کاهش یابد.همچنین از طریق مقایسه معماری میکروسرویس ها با معماری های دیگر میتوان به درک بهتری از این معماری نرم افزاری رسید . برای مثال می توان دو معماری میکروسرویس ها و معماری یکپارچه را مورد مقایسه قرار داد . تفاوت میان معماری میکروسرویس ها و معماری یکپارچه این است که در میکروسرویس ها ، یک اپلیکیشن به تعداد زیادی سرویس کوچک تر که خود مستقل هستند تقسیم می شود ولی در معماری یکپارچه این گونه نیست و اپلیکیشن یک واحد بزرگ است و به نحوی که در میکروسرویس ها داریم ، قابل تقسیم نیست . مزایای میکروسرویس ها برای سازمان ها میکروسرویس ها همانقدر که در بین توسعه دهندگان نرم افزار محبوبیت دارند ، در میان مدیران اجرایی و مدیران پروژه ها نیز محبوب هستند . این خود یکی از ویژگی های خاص میکروسرویس ها می باشد زیرا معمولا دغدغه و بحث های مربوط به معماری مورد استفاده برای نرم افزار ، در تیم های توسعه نرم افزار قرار دارد . زیرا میکرو سرویس ها ، روش و رویکردی را که خیلی از مدیران بیزینس ها در نظر دارند تا تیم ها و پروسه توسعه خود را بر اساس آن پیاده سازی کنند ، را بهتر منعکس می کنند .به عبارت دیگر ، میکروسرویس ها یک معماری هستند که یک مدل عملیاتی مورد نظر را بهتر تسهیل و آسان میکنند . در نظرسنجی که اخیرا در سال 2021 شرکت IBM ( که یکی از شرکت های عظیم تکنولوژی می باشد ) درباره میکروسرویس ها از حدود 1200 توسعه دهنده و مدیر فناوری اطلاعات انجام داده است ، حدود 87 درصد از کاربرانی که از میکروسرویس ها استفاده می کنند ، تایید کرده اند و موافق هستند که رفتن به سمت معماری میکروسرویس ها و پذیرش این معماری ، ارزش هزینه و تلاش مورد نیازش را دارد .گسترش مستقلانهاحتمالا مهمترین ویژگی معماری میکروسرویس ها این باشد که چون سرویس ها کوچک تر هستند ، برای تغییر یک خط کد یا اضافه کردن امکانات جدید ، نیازی به تصمیم گیری های عظیم وجود ندارد و تغییرات ساده تر و سریع تر می توانند انجام پذیرند .میکروسرویس ها در سازمان ها این قابلیت را ایجاد میکنند که بسیاری از مشکلاتی و دغدغه های مربوط به اینکه یک تغییر کوچک ، هزینه زمانی بسیاری را در پی خواهد داشت ، را کاهش دهند و این موضوع که رویکردی که سرعت و چابک بودن ( Agile ) را تسهیل کند ، بسیار ارزشمند است ، کاملا واضح می باشد . ولی سرعت ، تنها مزیت طراحی سرویس ها از طریق این معماری نیست . یکی از مدل های سازمانی در حال رایج و ترند شدن این است که تیم های مختلف ، حول یک مشکل بیزینسی یا سرویس یا محصول گرد هم جمع شوند. مدل میکروسرویس ها به خوبی با این مدل و روند مطابقت می کند. چون سازمان ها را قادر می سازد تا تیم های کوچک و متقابلی را حول یک سرویس یا مجموعه ای از سرویس ها جمع کند و آن ها را با شیوه ای چابک و Agile ، به کار گیرد . اینکه این در میکروسرویس ها ، سرویس ها به هم وابسته نیستند ، باعث می شود که ایزوله سازی خطا و انعطاف پذیری بهتری در اپلیکیشن ایجاد شود . کوچک بودن سرویس ها به همراه مشخص بودن حدود و مرز های آن ها و همچنین واضح بودن نحوه ارتباط آن ها با هم ، باعث می شود که اعضای جدید که وارد تیم می شوند ، کد ها را بتوانند بهتر درک کنند و سریع تر بتوانند در پروژه مشارکت داشته باشند . ( نمونه ای واضح از مزایای میکروسرویس ها در زمینه سرعت و روحیه اعضای تیم )ابزار مناسب برای کار در معماری های سنتی ، معمولا یک اپلیکیشن ، یک سری تکنولوژی یا درواقع stack مشترک را به همراه یک پایگاه داده رابطه ای بزرگ که از کل اپلیکیشن پشتیبانی می کند را شامل می شود . این رویکرد چندین مشکل دارد . مشخص ترین مشکل این رویکرد آن است که تمام قسمت های اپلیکیشن باید از همان تکنولوژی مشترک و مدل داده و پایگاه داده استفاده کنند حتی با اینکه ابزار های مناسب تری برای کار برخی از قسمت ها وجود داشته باشد . این باعث ایجاد یک معماری بد می شود و همچنین برای توسعه دهنده هایی که آگاه به این موضوع هستند که ابراز ها و راه ها و رویکرد های بهتر و بهینه تری برای ساخت قسمت هایی از اپلیکیشن وجود دارد ، آزار دهنده می باشد .در مقابل ، در یک مدل میکروسرویس ها ، قسمت ها مختلف اپلیکیشن به صورت مستقل گسترش داده می شوند و از طریق ترکیبی از REST API ها و Message Broker ها و Event Streaming ها ارتباط بر قرار میکنند . بنابراین امکان این وجود دارد که برای هر بخش و قسمت ، تکنولوژی و Stack و رویکرد مناسب و بهینه برای آن قسمت را در گسترش آن به کار ببریم . تکنولوژی هرلحظه و هر زمان در حال تغییر می باشد و قطعا اپلیکیشنی که از قسمت ها و سرویس های کوچک و مستقل تشکیل شده باشد ، توسعه آن با تکنولوژی های جدید و مورد نظر ، آسان تر و کم هزینه تر خواهد بود .چالش های موجودمیکروسرویس ها با اینکه مزایای زیادی دارند ولی این مزایا چالش هایی را به همراه خود دارد . انتقال از معماری یکپارچه به معماری میکروسرویس ها به معنای پیچیدگی بیشتر در مدیریت ، سرویس های بیشتر که توسط تیم های بیشتری در مکان های بیشتری ساخته شده اند می باشد . مشکل در یکی از سرویس ها می تواند در سرویس های دیگر مشکل ایجاد کند یا اینکه خود نتیجه مشکل در یک سرویس دیگر بوده باشد . لاگ کردن داده ها ( که برای مانیتورینگ و بررسی مشکلات استفاده می شود ) ارزش بیشتری پیدا می کند . نسخه های جدید می توانند مشکل سازگاری با نسخه های قبلی را ایجاد کند . اپلیکیشین ها شامل اتصالات شبکه بیشتری خواهند بود که به این معنی است فرصت بیشتری برای مشکلات مربوط به تاخیر و اتصالات ایجاد خواهد شد. استفاده از راهکار DevOps می تواند بسیاری از این مشکلات را تحت پوشش قرار دهد ولی خود این راه کار ، چالش های مربوط به خود را دارد !با این حال ، این چالش ها باعث نمی شود که حرکت به سمت این معماری با توجه به مزایای زیادی که دارد ، متوقف شود و افرادی را که هنوز از این معماری استفاده نکرده اند را از حرکت به سمت آن باز نمی دارد . همچنین افرادی را که از این معماری استفاده میکنند را از ادامه استفاده و عمیق تر شدن باز نمی دارد . در نظرسنجی اخیر شرکت IBM ، داده ها نشان می دهد که 56 درصد کابرانی که از میکروسرویس ها استفاده نمی کنند ، شاید یا به احتمال زیاد در طی دو سال آینده از معماری میکروسرویس ها استفاده خواهند کرد و 78 درصد از کاربران فعلی که در حال استفاده از این معماری هستند ، احتمالا زمان و منابع مالی و تلاش بیشتری را در این زمینه سرمایه گذاری خواهند کرد . میکروسرویس ها هم استفاده از DevOps را فعال تر می کنند و هم به آن نیاز دارند !معماری میکروسرویس ها به طور معمول ، تحت عنوان بهینه سازی شده برای 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 ای که کار آن بخش را به بهترین نحو انجام می دهد بهره بگیرد و استفاده کند . افزایش تنوع فناوری های مورد استفاده وقتی که خودمان آن ها را کنترل کنیم می تواند پیچیدگی های جدی و اساسی ایجاد کند . ولی استفاده از فناوری های مختلف به کمک سرویس های ابری می تواند به طور قابل ملاحظه ای این چالش های مدیریتی را کاهش دهد . یه عبارت دیگر با این که غیر ممکن نیست که زیر ساخت میکروسرویس های خود را ، خودتان مدیریت و پیاده سازی کنید ، ولی با توجه به وجود فضاهای ابری ، این روشی نیست که قابل توصیه کردن باشد به خصوص زمانی که ابتدای کار هستید و شروع به کار می کنید . الگو ها و Best Practice ها در میکروسرویس هادر معماری میکروسرویس ها ، تعداد زیادی الگو های طراحی ، ارتباط و ادغام کردن وجود دارد که مفید و کاربردی هستند و چالش هایی را که معمولا در این معماری با آن ها روبرو می شویم را پوشش می دهند . بک-اند برای فرانت-اند ( BFF یا Backend-for-frontend ) : این الگو یک لایه میان UX و منابع مورد استفاده ، قرار می دهد . برای مثال ، اپلیکیشنی که روی Desktop استفاده می شود ، اندازه صفحه نمایش و محدودیت های پرفرمونس متفاوتی نسبت به یک موبایل دارد . الگوی BFF به توسعه دهنده ها این امکان را می دهد که با استفاده از بهترین آپشن ها برای آن interface و رابط ، یک Backend به ازای هر نوع رابط کاربری ایجاد کنند . نه اینکه سعی کنند از یک Backend عمومی که برای همه رابط های کاربری کار میکند ولی در پرفرومنس Frontend تاثیر منفی دارد استفاده کنند .موجودیت و الگو های مجموع ( Entity and Aggregate Patterns ) : یک موجودیت ، یک شی است که با هویتش منحصر به فرد می شود . برای مثال در یک سایت فروشگاهی ، یک "محصول" ممکن است توسط نام و نوع و قیمتش متمایز شده باشد . یک aggregate یا تجمع ، مجموعه ای از موجودیت های مرتبط به هم است که به عنوان یک واحد باید با آن رفتار شود . مثلا در همین سایت فروشگاهی ، یک "سفارش" مجموعه ای ( تجمع - aggregate ) از محصولات ( موجودیت های محصول ) است که توسط یک کلاینت سفارش داده شده است . این الگو برای دسته بندی داده ها در راه های قابل فهم استفاده می شود . الگو های کشف سرویس ( Service Discovery Patterns ) : این الگو ها به اپلیکیشن ها و سرویس ها کمک میکنند که یک دیگر را پیدا کنند . در معماری میکروسرویس ها ، نمونه های سرویس ها به دلایلی مثل توسعه و ارتقاء ، خرابی سرویس و حتی از بین رفتن سرویس به صورت دینامیک و پویا ، تغییر می کنند . این الگو ها ، مکانسیم های کشف و پیدا کردن را برای مقابله با این ناپایداری ها فراهم می کنند . بالانس کردن Load و بار ممکن است از طریق مثلا بررسی های سلامتی و خرابی سرویس ها به عنوان محرک هایی برای تعادل مجدد ترافیک ، از این الگو ها استفاده استفاده کند . الگو های میکروسرویس های وفق دهنده - آداپتور ( Adapter Microservices Patterns ) : به این الگو های آداپتور همانگونه که به آداپتور های برق که در هنگام مسافرت به کشوری دیگر با خود میبرید ، فکر کنید. هدف و مقصود الگو های آداپتور و وفق دهنده ، کمک به ترجمه روابط میان اشیاء و کلاس هایی است که در غیر این صورت باهم ناسازگار هستند . مثلا اپلیکیشنی که متکی بر API های شخص ثالث ( یا همون third-party ) است ممکن است به این الگو های وفق دهنده ( آداپتور ) نیاز داشته باشد تا اپلیکیشن بتواند با آن API مورد نظر ، ارتباط داشته باشد . الگوی Strangler Application : این الگو ها به مدیریت refactor کردن و تبدیل کردن یک اپلیکیشن با ساختار و معماری یکپارچه به اپلیکیشنی با معماری میکروسرویس ها کمک میکنند . نام این الگو برمیگردد به اینکه چطور یک گیاه انگور ( میکروسرویس ) ، به آرامی و در طول زمان یک درخت ( اپلیکیشن با معماری یکپارچه ) را در بر می گیرد . نباید ها در میکروسرویس ها در حالی که الگو های بسیاری وجود دارد که انجام آن ها در معماری میکروسرویس ها ، باعث می شود از بسیاری از مشکلات معمول جلو گیری شود ، ولی نباید هایی هم وجود دارد که از انجام آن ها باید پرهیز کرد که این موارد می توانند هر تیم توسعه ای را سریعا وارد مشکل کنند :قانون اول میکروسرویس ها این است که ، با میکروسرویس شروع نکنید ! : معماری میکروسرویس ها یکی از راه های مدیریت اپلیکیشن به هنگامی است که که اپلیکیشن بسیار بزرگ می شود و عملا به سادگی نمی توان آن را نگه داری کرد و توسعه داد . فقط زمانی که شما می توانید حس کنید که این مشکل وجود دارد و یکپارچه بودن موجب درد و مشکل است ، استفاده از میکروسرویس ها ارزش پیدا می کند و شما باید در نظر بگیرید که آن زمان چطور این اپلیکیشن یکپارچه را به سرویس ها کوچک تر تبدیل کنید و به سمت معماری میکروسرویس ها حرکت کنید .معماری میکروسرویس ها را بدون DevOps و سرویس های ابری انجام ندهید : ساخت با استفاده از معماری میکروسرویس ها یعنی ساخت سیستم های توزیع شده ، و سیستم های توزیع شده مدیریت سختی دارند . استفاده از معماری میکروسرویس ها بدون استفاده از اتوماسیون های توسعه و مانیتورینگ و همچنین بدون استفاده از سرویس های ابری مدیریت شده که زیر ساخت های بزرگ و ناهمگن شما را پشتیبانی کنند ، باعث به وجود آمدن مشکلات زیادی است . تعداد زیادی میکروسرویس با کوچک کردن اندازه آن ها ایجاد نکنید : اگر در عبارت "میکرو" در میکروسرویس ها زیاده روی کنید ، دچار پیچیدگی و سربار های زیادی می شود که بسیاری از مزایای میکروسرویس ها را از بین خواهد برد . بهتر است از سرویس های بزرگ استفاده کنید و فقط زمانی آن ها را به بخش های کوچک تر تبدیل کنید که استفاده از میکروسرویس ها واقعا مفید و مزایای آن ها برای استفاده مشخص باشد . مثلا اگر انجام تغییرات سخت و کند شود ، یا یک مدل داده رایج بیش از حد پیچیده شود ، یا قسمت های مختلف سرویس نیاز های متفاوتی از نظر بار و مقیاس دارند . سعی نکنید مانند شرکت Netflix عمل کنید ! : شرکت Netflix یکی از شرکت های پیشرو در زمینه معماری میکروسرویس ها به هنگام ساخت و مدیریت اپلیکیشنی که تقریبا یک سوم ترافیک کل اینترنت را تشکیل می داد . نمونه کاملی از یک طوفان کامل که آن ها را مجبور به ساخت تعداد زیادی کد های Custom و سرویس های غیر ضروری برای یک برنامه متوسط کرد . توصیه می شود و بهتر است که با سرعت و گامی شروع کنید که قابل به هندل کردن و مدیریت آن باشید و از پیچیدگی های غیر ضروری اجتناب کنید و تا جای ممکن از ابزار های آماده استفاده کنید تا کار را راحت تر انجام دهید . نتیجه گیریمعماری میکروسرویس ها ( Microservices Architecture ) معماری است که نسبت به معماری های سنتی و یکپارچه ، زمانی که پیچیدگی های اپلیکیشن های یکپارچه و سنتی زیاد می شود و عملا نگهداری و توسعه اپلیکیشن با مشکل مواجه می شود ، می تواند مزایای بسیار زیادی هم از نظر فنی و هم از نظر سازمانی و بیزینسی داشته باشد و هزینه های مربوط به بخش های مالی و زمانی و نیروی توسعه ( توسعه دهنده ها ) را کاهش دهد و باعث شود تا بهینگی افزایش یابد و تمرکز بر روی موارد اصلی افزایش یابد . پ . ن : بعضی مفاهیم موجود در این مقاله ، خود نیاز به یک مقاله جداگانه و مطالعه دقیق دارند و توضیح آن ها در این مقاله نمی گنجد . مثلا برای Docker و Kubernetes ، سیستم های Message Broker ، معماری هایی مانند Serverless و همچنین چالش های مربوط به DevOps ، نیاز به مطالعه دقیق و جداگانه هست و این مفاهیم به یکدیگر وابسته هستند .منابع پیشنهادی برای مطالعه بیشتر در زمینه معماری میکروسرویس ها : کتاب Building Microservices ، نویسنده Sam Newman - ویرایش دوم - انتشارات O'Reilly کتاب Monolith to Microservices ، نویسنده Sam Newman - ویرایش اول - انتشارات O'Reillyمنبع :ibm.com/cloud