- معماری نرم افزار
- 1401-04-15
- 538
- 0
معماری میکروسرویس رویکردی است که در آن یک برنامه واحد از بسیاری از سرویس های کوچکتر و مستقل که به هم پیوند خورده اند و قابل استفاده هستند، تشکیل شده است. امروزه در هر مناقصه و انتخاب محصولی عنوان زیر ساخت و معماری میکروسرویس مشاهده میگردد. با توجه به ابعاد مختلف از این مفهوم و گاها اشتباه برداشت نامناسب از آن بر آن شدیم مطلبیم در این خصوص منتشر کنیم. بر اساس مطالعات مختلف بر آن شدیم تا به ترجمه از یک سایت رسمی مثل IBM روی آوریم:
منبع:
https://www.ibm.com/cloud/learn/microservices
میکروسرویس (یا معماری میکروسرویس) یک رویکرد معماری بومی ابری است که در آن یک برنامه واحد از بسیاری از اجزای کوچکتر یا خدمات کوچک به هم پیوسته و مستقل استفاده میکند. این خدمات به طور معمول دارای
در حالی که بسیاری از بحث ها در مورد میکروسرویس در مورد تعاریف و ویژگی های معماری بوده است، ارزش آنها را میتوان بیشتر از طریق مزایای نسبتاً ساده تجاری و سازمانی درک کرد:
همچنین ممکن است میکروسرویس با آنچه نیستند بهتر توضیح داده شوند. دو مقایسه ای که بیشتر با معماری میکروسرویس انجام میشود معماری یکپارچه و معماری سرویس گرا (SOA) است.
مقاله "SOA در مقابل میکروسرویس ها: تفاوت چیست؟" وارد جزئیات بیشتر می شود.
میکروسرویس ها احتمالاً به همان اندازه در بین مدیران اجرایی و رهبران پروژه محبوب هستند که در میان توسعه دهندگان نیز. این یکی از ویژگیهای غیرعادیتر میکروسرویسها است، زیرا شور و شوق معماری معمولاً برای تیمهای توسعه نرمافزار بسیار بالاست است. دلیل این امر، این است که میکروسرویسها روشی را که بسیاری از رهبران کسب وکار میخواهند تیمها و فرآیندهای توسعه خود را ساختاردهی و اجرا کنند، بهتر اجرایی میکند.
به عبارت دیگر، میکروسرویس ها یک مدل معماری هستند که یک ساختار عملیاتی مورد نظر را بهتر تسهیل میکنند. در نظرسنجی اخیر IBM از بیش از 1200 توسعهدهنده و مدیران فناوری اطلاعات، 87 درصد از کاربران میکروسرویس موافق بودند که پذیرش میکروسرویسها ارزش هزینه و تلاش را دارد. با استفاده از ابزار تعاملی زیر میتوانید دیدگاههای بیشتری در مورد مزایا و چالشهای میکروسرویسها کشف کنید.
منبع: 'Microservices in the enterprise 2021: Real benefits, worth the challenges.'
در اینجا فقط چند مورد از مزایای سازمانی میکروسرویسها آورده شده است.
شاید مهمترین ویژگی میکروسرویسها این باشد که چون سرویسها کوچکتر هستند و بهطور مستقل قابل استقرار هستند، دیگر نیازی به انجام فرآیند تست و تولید پیچیده برای تغییر یک خط کد یا اضافه کردن یک ویژگی جدید در برنامه نیست.
میکروسرویس ها به سازمان ها قول میدهند که پادزهری برای ناامیدی های مرتبط با تغییرات کوچک که زمان زیادی را صرف میکند، داشته باشند. همچنین نیازی به دکترای علوم کامپیوتر برای دیدن یا درک ارزش رویکردی که سرعت و چابکی را بهتر تسهیل میکند، نداشته باشند.
اما سرعت تنها ارزش طراحی خدمات به این روش نیست. یک مدل سازمانی رایج در حال ظهور، گرد هم آوردن تیم های متقابل عملکردی پیرامون یک مشکل تجاری، خدمات یا محصول است. مدل میکروسرویسها کاملاً با این روند مطابقت دارد، زیرا سازمان را قادر میسازد تا تیمهای کوچک و متقابلی را حول یک سرویس یا مجموعهای از خدمات ایجاد کند و آنها به شیوهای چابک کار کند.
میکروسرویس ها همچنین درجه خوبی از ایزوله سازی خطا و انعطاف پذیری بهتر را در برنامه ها ایجاد میکند. اندازه کوچک خدمات، همراه با مرزها و الگوهای ارتباطی واضح بین آنها، درک کدهای پایه و کمک سریع به آن را برای اعضای تیم جدید آسانتر میکند. (یک مزیت واضح از نظر سرعت و روحیه کارکنان)
در الگوهای معماری سنتی n-tier، یک برنامه کاربردی معمولاً یک stack مشترک با یک پایگاه داده بزرگ و رابطه ای که از کل برنامه پشتیبانی می کند، به اشتراک میگذارد. این رویکرد چندین اشکال آشکار دارد که مهمترین آنها این است که هر جزء از یک برنامه کاربردی باید (حتی اگر ابزار واضح و بهتری برای کار برای مولفه خاص وجود داشته باشد) یک پشته، مدل داده و پایگاه داده مشترک داشته باشد،. این باعث ایجاد معماری بد میشود، و برای توسعه دهندگانی که دائماً از وجود راه حل بهتر و کارآمدتر برای ساخت این مؤلفه ها آگاه هستند، خسته کننده است.
در مقابل، در یک مدل میکروسرویس، مؤلفهها بهطور مستقل مستقر میشوند و از طریق ترکیبی از REST، جریان رویداد و واسطههای پیام ارتباط برقرار میکنند. بنابراین این امکان وجود دارد که stack هر سرویس جداگانه برای آن سرویس بهینه شود. فناوری دائماً تغییر میکند و برنامهای که از چندین سرویس کوچکتر تشکیل شده باشد، با در دسترس شدن فناوری مطلوبتر، بسیار آسانتر و کمهزینهتر است.
با میکروسرویسها، میتوان تک سرویسهای را بهصورت جداگانه توسعه و مقیاس پذیر کرد. مزیت حاصل آشکار است. به زیرساخت کمتری نسبت به برنامه های کاربردی یکپارچه نیاز دارند، زیرا آنها فقط به اندازه و مقیاس مورد نیاز از یک برنامه کاربردی و نه همه آن را نیاز دارند.
مزایای قابل توجه میکروسرویس ها با چالش های قابل توجهی همراه است. حرکت از مدل یکپارچه به مدل میکروسرویسها به معنای پیچیدگی مدیریتی بسیار بیشتری است. (خدمات بسیار بیشتری که توسط تیم های بسیار بیشتری ایجاد شده و در مکان های بسیار بیشتری مستقر شده اند.) مشکلات در یک سرویس می تواند باعث بروز مشکلاتی در سرویس های دیگر و یا ناشی از آن باشد. دادههای ثبتنام (که برای نظارت و حل مشکل استفاده میشود) حجم بیشتری دارد و میتواند در بین سرویسها ناسازگار باشد. نسخه های جدید می توانند مشکلات سازگاری با عقب را ایجاد کنند. برنامهها شامل اتصالات شبکه بیشتری میشوند، که به معنای فرصتهای بیشتر برای تأخیر و مشکلات اتصال است. رویکرد DevOps همانطور که در زیر خواهید خواند، می تواند بسیاری از این مسائل را برطرف کند، اما پذیرش DevOps چالش های خاص خود را دارد.
با این وجود، این چالشها باعث نمیشود افراد غیرمتخصص از پذیرش میکروسرویسها (یا پذیرندگان از تعمیق تعهدات میکروسرویسها) جلوگیری کنند. دادههای نظرسنجی جدید آیبیام نشان میدهد که 56 درصد از غیرکاربران فعلی احتمالاً یا به احتمال زیاد در طی دو سال آینده از ریزسرویسها استفاده میکنند و 78 درصد از کاربران فعلی میکروسرویسها احتمالاً زمان، پول و تلاشی را که در میکروسرویسها سرمایهگذاری کردهاند افزایش خواهند داد. شکل 1 را ببینید).
شکل 1: میکروسرویس ها اینجا هستند تا بمانند. در طی دو سال آینده، 56 درصد از غیرکاربران احتمالاً میکروسرویس ها را اتخاذ خواهند کرد، 78 درصد از کاربران سرمایه گذاری خود را در میکروسرویس ها افزایش خواهند داد و 59 درصد برنامه های کاربردی تخفیف با میکروسرویس ها ایجاد خواهند شد. (منبع: "سرویس های خرد در سازمان 2021: مزایای واقعی، ارزش چالش ها را دارد.")
معماری میکروسرویسها اغلب بهعنوان بهینهسازی شده برای DevOps و یکپارچهسازی مداوم/تحویل پیوسته (CI/CD) توصیف میشود. همچنین درک دلیل آن در زمینه سرویسهای کوچکی که میتوانند مکرراً توسعه داده شوند، آسان است.
اما راه دیگری برای نگاه کردن به رابطه بین میکروسرویس ها و DevOps این است که معماری میکروسرویس ها برای موفقیت در واقع به DevOps نیاز دارند. در حالی که کاربردهای یکپارچه دارای طیف وسیعی از اشکالات هستند که قبلاً در این مقاله مورد بحث قرار گرفت، لیکن آنها از مزایای این که اولا یک سیستم توزیع پیچیده با قطعات متحرک متعدد ندارند و همچنین و پشتههای فناوری غیر مستقل و ناهمگون نیز ندارند، بهره میبرند. در مقابل، با توجه به افزایش عظیم پیچیدگی، قطعات متحرک و وابستگیهایی که با میکروسرویسها همراه است، نزدیک شدن به ریزسرویسها بدون سرمایهگذاری قابل توجه در استقرار، نظارت و اتوماسیون چرخه عمر غیرعاقلانه است.
آندریا کرافورد در ویدیوی زیر به بررسی عمیقتر DevOps میپردازد:
در حالی که تقریباً هر ابزار یا زبان مدرنی را می توان در معماری میکروسرویس استفاده کرد، تعداد انگشت شماری از ابزارهای اصلی وجود دارند که برای میکروسرویس ها ضروری و مرزی شده اند:
یکی از عناصر کلیدی یک میکروسرویس این است که به طور کلی بسیار کوچک است. (هیچ مقدار دلخواه کدی وجود ندارد که تعیین کند چیزی یک میکروسرویس است یا نه، اما micro دقیقاً در نام آن وجود دارد.)
زمانی که داکر در سال 2013 عصر کانتینر مدرن را آغاز کرد، مدل محاسباتی را نیز معرفی کرد که بیشترین ارتباط را با میکروسرویس ها داشت. از آنجایی که کانتینرهای جداگانه سربار سیستم عامل خود را ندارند، نسبت به ماشینهای مجازی سنتی وزن کمتر و سبکتری دارند و میتوانند با سرعت بیشتری بالا و پایین بچرخند، و این باعث میشود که آنها را با خدمات کوچکتر و سبکتر موجود در معماریهای میکروسرویس مطابقت کاملی داشته باشند.
با گسترش خدمات و کانتینرها، سازماندهی و مدیریت گروه های بزرگ کانتینرها به سرعت به یکی از چالش های حیاتی تبدیل شد. Kubernetes، یک پلتفرم ارکستراسیون کانتینر منبع باز، به عنوان یکی از محبوب ترین راه حل های ارکستراسیون ظاهر شده است. زیرا این کار را به خوبی انجام می دهد.
در ویدئوی Kubernetes Explained ، سای ونام نمای جامعی از همه چیزهای Kubernetes ارائه می دهد:
میکروسرویسها اغلب از طریق API ارتباط برقرار میکنند. در حالی که این درست است که client و سرویسها میتوانند مستقیماً با یکدیگر ارتباط برقرار کنند، دروازههای API اغلب یک لایه واسطه مفید هستند، به خصوص که تعداد سرویسها در یک برنامه در طول زمان افزایش مییابد. یک دروازه API به عنوان یک پروکسی معکوس برای مشتریان با مسیریابی درخواستها، توزیع درخواستها به چندین سرویس و ارائه امنیت و احراز هویت اضافی عمل میکند.
فناوریهای متعددی وجود دارد که میتوان از آنها برای پیادهسازی دروازههای API استفاده کرد، از جمله پلتفرمهای مدیریت API، اما اگر معماری میکروسرویسها با استفاده از کانتینرها و Kubernetes پیادهسازی شود، دروازه معمولاً با استفاده از Ingress یا اخیراً Istio پیادهسازی میشود.
در حالی که بهترین روش ممکن است طراحی خدمات بدون تابعیت باشد، با این وجود دولت وجود دارد و خدمات باید از آن آگاه باشند. و در حالی که فراخوانی API اغلب روشی مؤثر برای ایجاد حالت اولیه برای یک سرویس خاص است، اما روش مؤثری برای بهروز ماندن نیست. یک نظرسنجی مداوم، "آیا ما هنوز آنجا هستیم؟" رویکرد به روز نگه داشتن خدمات به سادگی عملی نیست.
درعوض، لازم است تماسهای API ایجادکننده حالت را با پیامرسانی یا جریان رویداد همراه کنید تا سرویسها بتوانند تغییرات را در حالت پخش کنند و سایر طرفهای علاقهمند بتوانند آن تغییرات را گوش داده و بر اساس آن تنظیم کنند. این شغل احتمالاً برای یک کارگزار پیام همه منظوره مناسب است، اما مواردی وجود دارد که یک پلتفرم پخش رویداد، مانند آپاچی کافکا، ممکن است مناسب باشد. و با ترکیب میکروسرویسها با معماری رویداد محور، توسعهدهندگان میتوانند سیستمهای توزیعشده، بسیار مقیاسپذیر، مقاوم به خطا و توسعهپذیر بسازند که میتوانند مقادیر بسیار زیادی از رویدادها یا اطلاعات را در زمان واقعی مصرف و پردازش کنند.
معماریهای بدون سرور برخی از الگوهای اصلی ابر و میکروسرویسها را به نتیجه منطقی خود میرسانند. در مورد بدون سرور، واحد اجرا فقط یک سرویس کوچک نیست، بلکه یک تابع است که اغلب می تواند فقط چند خط کد باشد. خطی که یک عملکرد بدون سرور را از یک میکروسرویس جدا می کند، خطی مبهم است، اما معمولاً توابع حتی کوچکتر از یک میکروسرویس درک می شوند.
جایی که ساختارهای بدون سرور و پلتفرمهای توابع بهعنوان سرویس (FaaS) با میکروسرویسها شباهت دارند، این است که هر دو علاقهمند به ایجاد واحدهای کوچکتر از استقرار و مقیاسبندی دقیق با تقاضا هستند.
ریزسرویسها لزوماً منحصراً به رایانش ابری مربوط نیستند، اما چند دلیل مهم وجود دارد که چرا آنها اغلب با هم ترکیب میشوند. دلایلی که فراتر از میکروسرویسها است که یک سبک معماری محبوب برای برنامههای جدید و ابر یک مقصد میزبانی محبوب برای برنامههای جدید است.
از جمله مزایای اصلی معماری میکروسرویس ها، استفاده و مزایای هزینه مرتبط با استقرار و مقیاس بندی اجزا به صورت جداگانه است. در حالی که این مزایا هنوز تا حدی در زیرساختهای داخلی وجود دارد، ترکیب اجزای کوچک و مستقل مقیاسپذیر همراه با زیرساختهای درخواستی و پرداخت به ازای استفاده، جایی است که بهینهسازی هزینه واقعی را میتوان یافت.
ثانیا، و شاید مهمتر از آن، یکی دیگر از مزایای اصلی میکروسرویس ها این است که هر جزء جداگانه می تواند پشته ای را که به بهترین وجه برای کار خاص خود مناسب است، اتخاذ کند. وقتی خودتان آن را مدیریت می کنید، تکثیر پشته می تواند منجر به پیچیدگی و هزینه های جدی شود، اما مصرف پشته پشتیبان به عنوان خدمات ابری می تواند چالش های مدیریتی را به طور چشمگیری به حداقل برساند. به عبارت دیگر، اگرچه راه اندازی زیرساخت های میکروسرویس خود غیرممکن نیست، اما توصیه نمی شود، به خصوص زمانی که تازه شروع به کار کرده اید.
در معماری میکروسرویسها، الگوهای طراحی، ارتباطات و یکپارچهسازی مشترک و مفید بسیاری وجود دارد که به رفع برخی از چالشها و فرصتهای رایجتر کمک میکند، از جمله موارد زیر:
این الگو یک لایه بین تجربه کاربر و منابعی که تجربه با آنها تماس می گیرد قرار می دهد. برای مثال، اپلیکیشنی که روی دسکتاپ استفاده میشود، دارای محدودیتهای اندازه، نمایش و عملکرد متفاوتی نسبت به یک دستگاه تلفن همراه خواهد بود. الگوی BFF به توسعهدهندگان اجازه میدهد تا با استفاده از بهترین گزینهها برای آن رابط، به جای تلاش برای پشتیبانی از یک بکاند عمومی که با هر رابطی کار میکند اما ممکن است بر عملکرد ظاهری تأثیر منفی بگذارد، یک نوع پشتیبان را برای هر رابط کاربری ایجاد و پشتیبانی کنند.
موجودیت شیئی است که با هویتش متمایز می شود. به عنوان مثال، در یک سایت تجارت الکترونیک، یک شیء محصول ممکن است با نام، نوع و قیمت محصول متمایز شود. جمع مجموعه ای از موجودیت های مرتبط است که باید به عنوان یک واحد در نظر گرفته شوند. بنابراین، برای سایت تجارت الکترونیک، یک سفارش مجموعه ای (مجموعه) از محصولات (موجودات) است که توسط یک خریدار سفارش داده شده است. این الگوها برای طبقه بندی داده ها به روش های معنی دار استفاده میشوند.
این الگوها به برنامهها و سرویسها کمک میکنند یکدیگر را پیدا کنند. در معماری میکروسرویسها، نمونههای سرویس بهدلیل مقیاسپذیری، ارتقاء، خرابی سرویس و حتی خاتمه سرویس بهطور پویا تغییر میکنند. این الگوها مکانیسمهای کشف را برای مقابله با این گذرا فراهم میکنند. متعادلسازی بار ممکن است از الگوهای کشف سرویس با استفاده از بررسیهای سلامت و خرابیهای سرویس بهعنوان محرکهایی برای تعادل مجدد ترافیک استفاده کند.
به الگوهای آداپتور فکر کنید که در مورد آداپتورهای دوشاخه ای که هنگام سفر به کشور دیگری استفاده می کنید، فکر می کنید. هدف الگوهای آداپتور کمک به ترجمه روابط بین کلاس ها یا اشیایی است که در غیر این صورت ناسازگار هستند. برنامهای که به APIهای شخص ثالث متکی است ممکن است نیاز به استفاده از الگوی آداپتور داشته باشد تا اطمینان حاصل شود که برنامه و APIها میتوانند با هم ارتباط برقرار کنند.
این الگوها به مدیریت بازآفرینی یک برنامه یکپارچه در برنامههای میکروسرویس کمک میکنند. نام رنگارنگ به این اشاره دارد که چگونه یک درخت انگور (میکروسرویس) به آرامی و در طول زمان از درخت سبقت می گیرد و آن را خفه می کند (یک کاربرد یکپارچه).
می توانید در لینک «نحوه استفاده از الگوهای توسعه با میکروسرویس ها (قسمت 4)» درباره این الگوها بیشتر بدانید. اگر می خواهید در مورد سایر الگوهای کد میکروسرویس ها بیاموزید، برنامه نویس IBM نیز اطلاعات زیادی را ارائه می دهد.
در حالی که الگوهای زیادی برای انجام خوب ریزسرویس ها وجود دارد، تعداد قابل توجهی از الگوها وجود دارد که می تواند به سرعت هر تیم توسعه را با مشکل مواجه کند. برخی از این موارد - که به عنوان میکروسرویسها «نمیشود» تعریف میشوند - به شرح زیر است:
به طور دقیق تر، با میکروسرویس ها شروع نکنید. میکروسرویسها راهی برای مدیریت پیچیدگی هستند، زمانی که برنامهها بیش از حد بزرگ و غیرقابل استفاده شوند و بهراحتی بهروزرسانی و نگهداری شوند. تنها زمانی که احساس کردید درد و پیچیدگی یکپارچه شروع به خزش کردید، ارزش این را دارد که چگونه آن برنامه را به خدمات کوچکتر تبدیل کنید. تا زمانی که آن درد را احساس نکنید، واقعاً یک توسعه یکپارچهای ندارید که نیاز به بازسازی داشته باشد.
ساختن میکروسرویسها به معنای ساختن سیستمهای توزیعشده است و سیستمهای توزیعشده سخت هستند (و بهویژه اگر انتخابهایی داشته باشید که کار را سختتر میکنند سختتر هم میشوند). تلاش برای انجام ریزسرویسها بدون الف) استقرار و اتوماسیون نظارت مناسب یا ب) خدمات ابری مدیریت شده برای پشتیبانی از زیرساختهای گسترده و ناهمگن شما، مشکلات غیرضروری زیادی را می طلبد. از دردسر خود را نجات دهید تا بتوانید وقت خود را صرف نگرانی در مورد وضعیت کنید.
اگر با «میکرو» در میکروسرویسها زیاده روی کنید، به راحتی میتوانید با سربار و پیچیدگی مواجه شوید که از دستاوردهای کلی معماری میکروسرویس بیشتر است. بهتر است به سمت سرویسهای بزرگتر متمایل شوید و تنها زمانی آنها را از هم جدا کنید که ویژگیهایی را ایجاد کنند که میکروسرویسها آنها را حل میکنند – یعنی اینکه اجرای تغییرات سخت و کند میشود، یک مدل داده مشترک بیش از حد پیچیده میشود، یا اینکه بخشهای مختلف خدمات نیازهای بار/مقیاس متفاوتی دارند.
میکروسرویسها و معماری سرویسمحور (SOA) اغلب با یکدیگر ترکیب میشوند، زیرا در ابتداییترین سطح خود، هر دو علاقهمند به ساخت اجزای جداگانه قابل استفاده مجدد هستند که میتوانند توسط برنامههای کاربردی دیگر مصرف شوند. تفاوت بین میکروسرویس ها و SOA در این است که پروژه های میکروسرویس معمولاً شامل بازسازی یک برنامه کاربردی می شوند تا مدیریت آن آسان تر باشد، در حالی که SOA به تغییر نحوه عملکرد خدمات فناوری اطلاعات در سطح سازمانی مربوط می شود. یک پروژه میکروسرویس که به یک پروژه SOA تبدیل میشود، احتمالاً تحت وزن خود کمانش میکند.
نتفلیکس یکی از پیشگامان اولیه معماری میکروسرویس ها هنگام ساخت و مدیریت برنامه ای بود که یک سوم کل ترافیک اینترنت را به خود اختصاص می داد - نوعی طوفان کامل که آنها را ملزم به ساخت تعداد زیادی کد سفارشی کرد. خدماتی که برای برنامه متوسط غیر ضروری هستند. خیلی بهتر است با سرعتی که می توانید شروع کنید، از پیچیدگی اجتناب کنید و تا آنجا که ممکن است از ابزارهای آماده استفاده کنید.
ثبت دیدگاه جدید
0 دیدگاه
نشانی ایمیل شما منتشر نخواهد شد. بخشهای موردنیاز علامتگذاری شدهاند *