میکروسرویس ها چیست؟ معماری نرم افزار بعدی شما

میکروسرویس ها کدهای یکپارچه را به قطعات مجزا تقسیم می کنند که نگهداری آنها آسان تر است. در اینجا یک مرور کلی و نگاهی به مزایا و معایب مهاجرت به معماری میکروسرویس ها آورده شده است.

• میکروسرویسها چیست؟
• معماری میکروسرویس چیست؟
• Microservices در مقابل معماری یکپارچه
• منظور ما از “microservice” چیست؟
• Microservices در مقابل SOA و خدمات وب
• نحوه ارتباط میکروسرویس ها
• مزایا و معایب میکروسرویس ها
• الگوهای طراحی میکروسرویس
• خدمات میکرو با Docker و Kubernetes
• خدمات میکرو با AWS و Azure

تقریباً هر سیستم رایانه ای چندین کار را با استفاده از منابع مشترک انجام می دهد. یکی از پرسش‌های همیشگی برنامه‌نویسی رایانه این است که بیت‌های کدی که این وظایف را انجام می‌دهند تا چه حد باید به هم متصل شوند. یکی از پاسخ ها معماری میکروسرویس ها است که شامل تکه های گسسته ای از عملکرد است که با سایر تکه های گسسته برای ایجاد یک سیستم بزرگتر در تعامل است. هر قطعه یک میکروسرویس است.

اگرچه ایده اجزای متصل جدید نیست، میکروسرویس ها به عنوان پایه ای طبیعی برای برنامه های کاربردی مبتنی بر ابر محبوبیت پیدا کرده اند. معماری میکروسرویس‌ها همچنین با فلسفه توسعه همخوانی دارد، که ارائه عملکردهای جدید را به سرعت و به طور مداوم تشویق می‌کند.

این مقاله شما را با میکروسرویس ها، از جمله مزایا و معایب مهاجرت به معماری میکروسرویس ها آشنا می کند.

microservices چیست؟

«میکرو» در میکروسرویس ها به کاربردهای کوچک دلالت دارد. این گاهی اوقات درست است، اما یک راه بهتر برای فکر کردن در مورد آنها این است که آنها باید فقط به اندازه نیاز برای انجام یک کار خاص یا برای حل یک مشکل خاص باشند. این مشکل باید مفهومی باشد نه فنی. اسناد Microsoft Azure به خوبی توضیح می‌دهد: «سرویس‌های ریز باید بر اساس قابلیت‌های تجاری طراحی شوند، نه لایه‌های افقی مانند دسترسی به داده یا پیام‌رسانی».

خرید سرویس‌ها با سایر میکروسرویس‌ها و کاربران خارجی از طریق API نسبتاً پایدار برای ایجاد برنامه‌های کاربردی بزرگ‌تر ارتباط برقرار می‌کنند. بنابراین، عملکرد داخلی یک میکروسرویس منفرد را می توان بدون تأثیر بر بقیه سیستم بهینه سازی کرد یا به طور اساسی ارتقا داد. تقسیم بندی عملکردهای خاص یک برنامه بزرگتر به قطعات کد گسسته و مستقل، ایجاد خطوط لوله CI/CD (ادغام پیوسته و تحویل مداوم) را در قلب devops آسان تر می کند. APIهای خوب تعریف شده همچنین آزمایش خودکار میکروسرویس ها را آسان تر می کند.

معماری میکروسرویس چیست؟

شما اغلب می شنوید که در مورد میکروسرویس ها در قالب معماری میکروسرویس صحبت می شود. این عبارت نه تنها خود میکروسرویس‌ها، بلکه زیرساخت‌های مورد نیاز برای پشتیبانی از آنها را شامل می‌شود، از جمله:

• قطعات اتوماتیک برای مدیریت خدمات و کشف، و همچنین شکست و انعطاف پذیری. (ما به صورت لحظه ای درباره برخی از پلتفرم های محبوب تر برای این اهداف بحث خواهیم کرد.)
• روشی ساده برای مسیریابی ارتباطات بین سرویس ها.
• یک دروازه API که ارتباط بین میکروسرویس ها و دنیای خارج را مدیریت می کند.

هدف کلی، معماری است که در برابر شکست مقاوم است و می‌تواند برای برآورده کردن نیازهای در حال تغییر بدون نیاز به بازسازی کامل تکامل یابد.

Microservices در مقابل معماری یکپارچه

قبل از اینکه میکروسرویس داشته باشیم، فقط یک سبک معماری داشتیم و آن یکپارچه بود. به اصطلاح معماری یکپارچه، یک رترونیم برای برنامه‌ای است که تمام کدها در یک باینری بزرگ هستند. فایل اجرایی.

معماری یکپارچه جای خود را دارد. در حالی که یک برنامه یکپارچه به طور کلی مقیاس‌سازی سخت‌تر و بهبود آن سخت‌تر است از میکروسرویس‌ها، همچنین اینطور نیست. به همان اندازه نیاز به مدیریت دارد هنگامی که صحبت از ذخیره سازی داده می شود، برنامه های یکپارچه نیز ساده تر هستند. اجزای منفرد در معماری میکروسرویس ها به طور کلی مسئول حفظ داده های خود هستند، بنابراین هر میکروسرویس به پایگاه داده خود نیاز دارد. یک برنامه یکپارچه فقط از یک پایگاه داده برای تمام عملیات داده خود استفاده می کند.

منظور ما از “microservice” چیست؟

بیایید برای لحظه ای از بیانیه قبلی من که میکروسرویس ها باید یک کار خاص را انجام دهند، پشتیبان بگیریم. گفتن این موضوع آسان است، اما ترسیم این تقسیمات کاربردی سخت تر از آن چیزی است که به نظر می رسد. تجزیه و تحلیل دامنه و طراحی مبتنی بر دامنه، رویکردهای نظری هستند که به شما کمک می‌کنند وظایف تصویر بزرگ را به مشکلات فردی که یک میکروسرویس می‌تواند حل کند، جدا کنید. مجموعه‌ای از پست‌های وبلاگی درخشان از مایکروسافت توضیح می‌دهد این فرآیند. اولین قدم ایجاد یک مدل انتزاعی از دامنه کسب و کار شما است که می توانید از آن برای کشف زمینه های محدود آن عملکرد گروه استفاده کنید.

یک برنامه حمل و نقل را به عنوان مثال در نظر بگیرید. یک شی فیزیکی در دنیای واقعی هم قیمت و هم مقصد دارد، بنابراین ممکن است یک زمینه محدود برای حساب‌ها و دیگری برای حمل و نقل داشته باشید. هر میکروسرویسی که ایجاد می‌کنید باید به طور کامل در یک زمینه محدود وجود داشته باشد، اگرچه برخی از زمینه‌های محدود ممکن است بیش از یک میکروسرویس را دربر گیرند.

Microservices در مقابل SOA و خدمات وب

اگر مدتی در اطراف بوده اید، ایده برنامه های کوچک فردی که با هم کار می کنند ممکن است شما را یاد SOA (معماری سرویس گرا) و وب سرویس ها بیاندازد. اینها دو کلمه کلیدی مربوط به روزهای پر سر و صدا وب ۲.۰ در اوایل دهه ۲۰۰۰ هستند. در حالی که از یک نظر واقعاً هیچ چیز جدیدی در زیر نور خورشید وجود ندارد، تفاوت های مهمی بین این سه رویکرد وجود دارد:

• SOA در مقابل میکروسرویس‌ها: در معماری سرویس‌گرا، اجزای منفرد به‌طور نسبتاً محکمی به هم متصل می‌شوند و اغلب دارایی‌هایی مانند ذخیره‌سازی را به اشتراک می‌گذارند و از طریق یک نرم‌افزار تخصصی به نام ارتباط برقرار می‌کنند. اتوبوس ذخیره سازی سازمانی. میکروسرویس‌ها مستقل‌تر هستند، منابع کمتری را به اشتراک می‌گذارند و از طریق پروتکل‌های سبک‌تر ارتباط برقرار می‌کنند. گاهی اوقات میکروسرویس ها نوعی SOA یا جانشین مفهوم SOA در نظر گرفته می شوند.
• خدمات وب در مقابل میکروسرویس ها: وب سرویس مجموعه ای از قابلیت های عمومی است که سایر برنامه ها می توانند از طریق وب به آن دسترسی داشته باشند. احتمالاً رایج‌ترین نمونه Google Maps است که برخی از فروشگاه‌ها آن را در وب‌سایت خود تعبیه می‌کنند تا مسیرهایی را برای مشتریان ارائه دهند. برخلاف میکروسرویس ها، وب سرویس ها لزوماً به سرویس های دیگر متصل نمی شوند. آن‌ها نسبت به معماری میکروسرویس‌ها ضعیف‌تر به هم متصل هستند.

چگونگی ارتباط میکروسرویس ها

چیزی که اغلب در مورد معماری میکروسرویس ها می شنوید این است که آنها باید دارای نقطه پایانی هوشمند باشند. و لوله های گنگ. به عبارت دیگر، میکروسرویس‌ها باید از روش‌های ارتباطی نسبتاً ساده و تثبیت شده استفاده کنند.

به طور کلی، ارتباط بین میکروسرویس ها باید ناهمزمان، به این معنا که رشته های کد در انتظار پاسخ مسدود نمی شوند. (هنوز استفاده از پروتکل‌های ارتباطی همزمان مانند HTTP خوب است، اگرچه پروتکل‌های ناهمزمان مانند AMQP – پروتکل صف پیام پیشرفته – نیز متداول هستند.) این نوع کوپلینگ آزاد باعث می‌شود که معماری میکروسرویس‌ها در مواردی که اجزا یا بخش‌هایی از شبکه به طور جداگانه انجام می‌شود، انعطاف‌پذیرتر شود. شکست بخورد.

مزایا و معایب میکروسرویس ها

اکنون که متوجه معماری میکروسرویس شدید، اجازه دهید برخی از مزایای اصلی آن را خلاصه کنیم:

• چرخه عمر توسعه سریع: در معماری میکروسرویس‌ها، اجزای خدمات منفرد هر کدام چرخه عمر توسعه و به‌روزرسانی خاص خود را دارند و تیم نسبتاً کوچکی از توسعه‌دهندگان مسئول آن هستند. این بدان معناست که برنامه به‌عنوان یک کل می‌تواند به‌طور تدریجی، ویژگی به ویژگی، به جای اینکه کاربران منتظر یک به‌روزرسانی «بیگ بنگ» باشند، پیشرفت کند. این سبک توسعه چیزی است که devops و CI/CD را ممکن می‌کند.
• جداسازی سرویس: ایده جداسازی نگرانی‌ها یک اصل طراحی پایه علوم کامپیوتر داشتن ریزسرویس‌های مجزا که مجموعه‌ای از عملکردهای متمایز و منسجم را در بر می‌گیرد، باید نگهداری و استدلال آن سرویس‌ها را آسان‌تر کند. در سطح عملی تر، داشتن خدمات جدا از یکدیگر، ساخت بخش های مختلف یک برنامه کاربردی را با استفاده از زبان های مختلف ممکن می سازد، که می تواند در موقعیت های تخصصی مفید باشد. همچنین جداسازی و تشخیص عیوب را آسان‌تر می‌کند.
• مقیاس‌پذیری: اگر می‌خواهید برخی از جنبه‌های برنامه خود را افزایش دهید، معماری میکروسرویس به شما این امکان را می‌دهد که این کار را بدون وارد کردن کل پایگاه کد به داخل فرآیند انجام دهید. پلتفرم‌های هماهنگ‌سازی سرویس (در این مورد در یک لحظه بیشتر) می‌توانند از این مقیاس‌بندی برای شما مراقبت کنند، نمونه‌های متعددی از یک سرویس را در صورت نیاز مستقر کنند یا آن را به سخت‌افزار با عملکرد بالاتر منتقل کنند.
• استفاده مجدد: سرویسی که برای یک برنامه می‌سازید ممکن است برای برنامه‌های آینده مفید باشد. ایجاد کتابخانه ای از چنین خدماتی می تواند توسعه محصولات جدید را تسریع کند.
• ادغام خدمات شخص ثالث: از آنجایی که میکروسرویس ها از طریق APIهای استاندارد شده ارتباط برقرار می کنند، می توانید سرویس های توسعه یافته در جاهای دیگر – اعم از تجاری یا منبع باز – را در برنامه خود ادغام کنید.

چالش‌هایی نیز با میکروسرویس‌ها وجود دارد:

• پیچیدگی معماری: معماری میکروسرویس های توزیع شده دارای قطعات متحرک زیادی است. پلتفرم‌های ارکستراسیون خودکار مانند Kubernetes می‌توانند بخشی از زحمت مدیریت را از بین ببرند. از جنبه منفی، این پلتفرم ها اغلب دارای منحنی های یادگیری شیب دار هستند.
• مشکلات عملکرد: یک سیستم ارتباطی مبتنی بر API انعطاف‌پذیر است و توسعه آن آسان است، اما به سرعت ارتباطات بین فرآیندی در یک باینری یکپارچه نیست. یک پلت فرم ارکستراسیون به خودی خود یک زیرساخت سنگین است. برای برنامه‌های کاربردی، معاوضه در سهولت توسعه ارزش آن را دارد، اما فشار اضافی بر منابع محاسباتی می‌تواند ضرر داشته باشد.
• نگرانی‌ها همیشه به راحتی قابل تفکیک نیستند: در حالی که یک سیستم میکروسرویس ایده‌آل از میکروسرویس‌های کاملاً گسسته تشکیل شده است، در دنیای واقعی همه چیز چندان منظم نیست – به خصوص اگر زمان کافی نداشته باشید. یا منابعی برای طراحی کامل اپلیکیشن خود قبل از شروع ساخت آن. در عمل، ممکن است در نهایت عملکردهای مشابهی را در چندین سرویس پیاده‌سازی کنید، با تیم‌های جداگانه که تلاش‌ها را به صورت موازی تکرار می‌کنند. برخی از تراکنش‌های تجاری ممکن است به چندین سرویس ختم شوند، که نیاز به چندین تیم توسعه برای هماهنگی با یکدیگر دارد.
• نگرانی های امنیتی: برای یک هکر مخرب، یک باینری یکپارچه یک جعبه سیاه است که درک و حمله درونی آن دشوار است. معماری میکروسرویس سطح حمله بیشتری را فراهم می کند. برای مثال، تماس‌های API را می‌توان در حین انتقال رهگیری و اصلاح کرد.
• تغییر فرهنگ: در حالی که CI/CD و devops توسط بسیاری در صنعت de rigueur در نظر گرفته می‌شوند، هنوز تعداد زیادی مغازه وجود دارد که مطابق با آن شیوه ها حرکت به سمت خدمات ریز مستلزم تغییر سازمان‌های بزرگ برای این فروشگاه‌ها و توسعه‌دهندگان خواهد بود—شاید برای بهتر شدن، اما قطعاً در کوتاه مدت مخل.

مزایا و معایب میکروسرویس های بیشتر

این نکات و نقاط مقابل استفاده از میکروسرویس ها را از InfoWorld بررسی کنید: چرا باید از معماری میکروسرویس استفاده کنید و معایب معماری میکروسرویس.

الگوهای طراحی میکروسرویس

مهم نیست از چه زبانی برای توسعه میکروسرویس ها استفاده می کنید، با مشکلاتی روبرو خواهید شد که سایر توسعه دهندگان قبلاً با آن مواجه شده اند. الگوهای طراحی راه حل های رسمی و انتزاعی برای مشکلات تکرار شونده در علوم کامپیوتر هستند و تعدادی از آنها به طور خاص برای میکروسرویس ها هستند. Devopedia یک لیست عالی دارد، که شامل:

• رجیستری خدمات: برای اتصال مشتریان به نمونه‌های موجود میکروسرویس‌ها.
• Circuit Breaker: برای جلوگیری از تماس مکرر سرویس های ناموفق.
• بازگشت: برای ارائه جایگزینی برای سرویس ناموفق.
• Sidecar: برای ارائه خدمات کمکی به کانتینر اصلی، مانند ثبت گزارش، همگام سازی خدمات، یا نظارت.
• آداپتور: برای استاندارد کردن یا عادی کردن رابط بین ظرف اصلی و دنیای خارجی.
• سفیر: برای اتصال کانتینر اصلی به دنیای خارج، مانند پروکسی کردن اتصالات لوکال هاست به اتصالات خارجی.

Microservices با Docker و Kubernetes

فناوری زیربنایی که بیش از همه به سمت ورود میکروسرویس به جریان اصلی رفته است کانتینرها است. یک کانتینر شبیه به یک نمونه ماشین مجازی (VM) است. با این حال، در حالی که یک VM شامل یک سیستم عامل کامل است، یک کانتینر فقط یک فضای کاربر مجزا است که از هسته سیستم عامل میزبان استفاده می کند، اما در غیر این صورت کد اجرا شده در داخل آن را مستقل نگه می دارد. کانتینرها بسیار کوچکتر از VMها هستند. آنها را می توان به سرعت و به راحتی، چه به صورت محلی یا در فضای ابری، مستقر کرد، و می توان آنها را به سمت بالا یا پایین چرخاند تا با تقاضا و منابع موجود مطابقت داشته باشد.

جذابیت کانتینرها برای میکروسرویس‌ها باید آشکار باشد: هر میکروسرویس جداگانه می‌تواند در کانتینر خود کار کند، که هزینه‌های سربار مدیریت خدمات را به میزان قابل توجهی کاهش می‌دهد. بیشتر پیاده‌سازی‌های کانتینر دارای ابزارهای هماهنگ‌سازی مکمل هستند که استقرار، مدیریت، مقیاس‌بندی، شبکه‌سازی و در دسترس بودن برنامه‌های مبتنی بر کانتینر را خودکار می‌کنند. این ترکیبی از میکروسرویس‌های کوچک با ساخت آسان و کانتینرهایی با قابلیت استقرار آسان است که فلسفه devops را ممکن می کند.

مفهوم کانتینر چندین پیاده‌سازی وجود دارد، اما محبوب‌ترین آنها Docker است که معمولاً با Kubernetes به‌عنوان پلتفرم ارکستراسیون جفت می‌شود.

سیستم های مبتنی بر کانتینر ذاتاً چند زبانه هستند: هر زبان برنامه نویسی که سیستم عامل از آن پشتیبانی می کند می تواند در یک کانتینر اجرا شود که به برنامه نویسان انعطاف پذیری می دهد. در واقع، یک مزیت بزرگ میکروسرویس ها این است که هر سرویس را می توان به هر زبانی نوشت که منطقی تر باشد – در واقع، تا زمانی که API های آن ثابت بماند، یک سرویس می تواند به طور کامل در یک زبان جدید بدون تأثیر بر سیستم به طور کلی بازسازی شود. . این ممکن است از پلتفرمی مانند Spring Cloud که بر پایه جاوا است جذاب تر باشد. (با این حال، توجه داشته باشید که این لزوماً یک یا یک انتخاب نیست، زیرا Spring Cloud را می توان ادغام کرد با Kubernetes.)

Microservices با AWS و Azure

مزایای استفاده از کانتینرها این است که می توان آنها را به راحتی در فضای ابری مستقر کرد، جایی که منابع محاسباتی انعطاف پذیر در دسترس هستند تا بتوانید کارایی برنامه خود را به حداکثر برسانید. همانطور که ممکن است تصور کنید، فروشندگان عمده ابر عمومی همه مشتاق هستند که شما از پلتفرم های آنها برای اجرای برنامه های مبتنی بر میکروسرویس خود استفاده کنید. برای اطلاعات بیشتر، منابع سه فروشنده بزرگ ابر، Amazon، مایکروسافت و Google.

آیا باید به میکروسرویس ها مهاجرت کنم؟

ارزش این را دارد که در نظر بگیرید که برای انتقال پایگاه کد خود به معماری میکروسرویس چه چیزی لازم است. از بسیاری جهات، انتقال عملکرد موجود می تواند پیچیده تر از ساختن یک برنامه کاربردی جدید مبتنی بر میکروسرویس ها از ابتدا باشد. از طرفی، به لطف ماهیت میکروسرویس ها، لازم نیست این کار را یکجا انجام دهید. می‌توانید سرویس‌های جداگانه‌ای بسازید که بخشی از عملکرد یکپارچه قدیمی شما را بر عهده بگیرد و بقیه آن را دست نخورده باقی بگذارد.

برای اطلاعات بیشتر در مورد سختی چنین مهاجرتی، از جمله بهترین شیوه ها، راهنمای InfoWorld را بررسی کنید، نحوه شروع کار با میکروسرویس های رویداد محور. و در سفرتان موفق باشید!