میکروسرویس چیست
فهرست مطالب
آخرین به روزرسانی در 29/07/2022
در این مقاله قصد داریم به صورت کامل و کاربردی در رابطه با میکروسرویس ها توضیح دهیم.
میکروسرویس ها یکی از مهم ترین مفاهیم دنیای آی تی و نرم افزار می باشد.
در ادامه ی این مقاله ما در رابطه با مفهوم و کارایی میکروسرویس ها ، دلایل ساخت میکروسرویس ها و همچنین مزایا ، معایب و … صحبت خواهیم کرد.
با ما همراه باشید.
تاریخچه ی میکروسرویس ها
اصطلاح میکروسرویس ها برای اولین بار توسط دکتر پیتر راجرز در سال 2005 ابداع شد و در ابتدا به عنوان خدمات میکرو وب شناخته می شد.
محرک اصلی پشت «micro web services» در آن زمان، تجزیه طرحهای «یکپارچه» بزرگ منفرد به اجزا یا فرآیندهای مستقل چندگانه بود، در نتیجه پایگاه کد را دقیقتر و قابل مدیریتتر ساخت.
برنامه های کاربردی مدولار و توزیع شده به چندین دهه قبل برمی گردد.
و از این نظر میکروسرویس ها مفهوم جدیدی نیستند.
با این حال، آنچه میکروسرویس ها را محبوب کرد، اصول حاکم بر نحوه طراحی و نحوه مصرف آنها بود.
در حالی که سیستم های توزیع شده مرسوم آن دوره بر پروتکل های ارتباطی اختصاصی متکی بودند، میکروسرویس ها از استانداردهای بازی مانند HTTP، REST، XML و JSON بهره بردند.
میکروسرویس چیست
میکروسرویس یک سرویس توزیع شده کوچک و بدون اتصال است.
این بخشی از یک معماری میکروسرویس گستردهتر است، که شامل مجموعهای از میکروسرویسهای با جفت آزاد است که برای حل یک هدف مشترک با هم کار میکنند.
مجموعه ای از میکروسرویس ها را می توان به عنوان یک سیستم در نظر گرفت.
نمودار زیر یک مدل مرجع بسیار ساده برای معماری میکروسرویس است.
این یک سیستم فرضی متشکل از چندین سرویس گرانول را نشان میدهد که به صورت همزمان ، از طریق تماسهای API داخلی یا ناهمزمان ، از طریق ارسال پیام با کمک یک واسطه پیام، ارتباط برقرار میکنند.
کل استقرار در یک مرز سیستم فرضی قرار دارد.
سیستمهای خارجی (External systems) (کاربران، برنامهها، B2B partners و …) میتوانند با میکروسرویسها فقط از طریق مجموعهای از APIهای خارجی تعامل داشته باشند ؛
که معمولاً به عنوان API gateway شناخته میشوند.
خدمات داخل boundary می توانند آزادانه خدمات external را در صورت لزوم مصرف کنند.
در سادهترین شکل ، آنها به ساخت یک برنامه کاربردی بهعنوان مجموعهای از سرویسهای کوچک کمک میکنند که هرکدام در فرآیند خود اجرا میشوند و بهطور مستقل قابل اجرا هستند.
این سرویس ها ممکن است به زبان های برنامه نویسی مختلف نوشته شده باشند و ممکن است از تکنیک های ذخیره سازی داده های متفاوتی استفاده کنند.
در حالی که این منجر به توسعه سیستمهایی میشود که مقیاسپذیر و انعطافپذیر هستند، نیاز به تغییری پویا دارد.
میکروسرویس ها اغلب از طریق API ها به هم متصل می شوند و می توانند از بسیاری از ابزارها و راه حل هایی استفاده کنند که در اکوسیستم RESTful و وب سرویس رشد کرده اند.
آزمایش این API ها می تواند به اعتبار بخشیدن به جریان داده ها و اطلاعات در سراسر استقرار میکروسرویس شما کمک کند.
میکروسرویس ها به عنوان راه حلی برای چالش های مقیاس پذیری با معماری های یکپارچه تکامل یافته اند.
یک برنامه میکروسرویس معمولاً کوچک است در مقایسه با یک “monolith” معمولاً یک برنامه کاربردی است که صدها هزار خط کد را شامل می شود.
البته این فقط یک مقایسه تقریبی برگرفته شده از مشاهدات تجربی است.
هیچ چیزی دلالت بر این ندارد که یک میکروسرویس باید کوچک باشد یا اینکه یک monolith بزرگ است.
چیزی که به طور کلی آنها را از هم متمایز می کند، تعداد مسئولیت هایی است که توسعه دهندگان تمایل دارند به آنها بپردازند.
یک میکروسرویس معمولاً تعداد کمی از مسئولیت های مرتبط را انجام می دهد.
به عنوان مثال، پرداختن به پردازش سفارش.
یک میکروسرویس دیگر ممکن است مسئول حمل و نقل باشد.
دیگری ممکن است از سیستم پرداخت مراقبت کند.
در مجموع، این میکروسرویس ها ممکن است به عنوان یک سیستم تجارت الکترونیک کامل عمل کنند.
(نمونه ای از آن در زیر نشان داده شده است.)
این یک تفکیک از یک پلتفرم تجارت الکترونیک ساده اما کاربردی است.
هر میکروسرویس در تصویر نقش خاصی را ایفا می کند و مراقبت کامل از یک دامنه جدا شده ، مانند سبد خرید ، موجودی ، سفارش ، پرداخت ها ، حمل و نقل ، گزارش و سفارش پشتیبان تامین کننده را ایفا می کند.
سرویس سبد خرید بهعنوان یک BFF سبک (بک اندی برای فرانت اند) عمل میکند، که بهعنوان یک API gateway عمل میکند تا برنامه مشتری را از منطق تجاری لازم برای انجام سفارشات جدا کند.
ریزسرویس ها
ریزسرویس ها فقط در مواقع ضروری به صورت همزمان ارتباط برقرار می کنند.
به عنوان مثال ، خدمات ثبت سفارش ، موجودی و پرداختها را قبل از ثبت ناهمزمان سفارش با انتشار رویدادی در موضوع Kafka بررسی میکند.
ما میخواهیم موجودی کالا و چک پرداختی همزمان باشد ، زیرا شکست هر یک از چکها باید از پیشرفت سفارش جلوگیری کند.
هنگامی که یک سفارش ثبت می شود ، ادامه ی پروسه ی انجام عملیات می تواند کاملا ناهمزمان باشد.
واقعاً مهم نیست که سفارش چه زمانی ارسال میشود یا اینکه سفارش پشتیبان در پشت صحنه آغاز شده است ؛ هیچ یک از این اقدامات بر پروسه ی پرداخت مشتری تأثیر نمیگذارد.
در نتیجه ، اگر سرویس سفارش پشتیبان تأمینکننده موقتاً قطع شود یا خدمات حمل و نقل به هر دلیلی عقبافتاده باشد، بقیه سیستم میتواند به صورت عادی کار کند، البته تا زمانی که قطعی رفع نشود، سفارشهای برگشتی با تأمینکنندگان ما ارسال نمیشود.
دلایل ساخت میکروسرویس ها
برای درک اینکه چرا باید در این مسیر گام برداریم، چالش های معمولی را در برنامه های monolithic در نظر بگیرید :
۱- برای هر تغییر، کل برنامه بدون توجه به بزرگ یا کوچک بودن تغییر، نیاز به بازسازی و باز استقرار مجدد دارد.
زمان ساخت ۱۵ تا ۳۰ دقیقه برای برنامه های بزرگ غیر معمول نیست.
۲- یک تغییر کوچک در یک بخش از یک برنامه، پتانسیل شکستن کل سیستم را دارد.
۳- با افزایش اندازه برنامه، قسمتهای آن بیشتر در هم تنیده میشوند و درک و نگهداری پایگاه کد دشوار میشود.
۴- برنامه های کاربردی بزرگ ، معمولاً حافظه بیشتری مصرف می کنند و به قدرت محاسباتی بیشتری نیاز دارند.
در نتیجه باید روی سرورهای بزرگ با ظرفیت منابع کافی میزبانی شوند.
این همچنین توانایی آنها را در مقیاس بندی محدود می کند.
۵- آنها همچنین تمایل دارند زمان راه اندازی کندی داشته باشند، که ایده آل نیست، با توجه به اینکه حتی کوچکترین تغییرات نیز مستلزم جابجایی کامل هستند.
آنها کمتر برای Cloud مناسب هستند و نمی توانند به راحتی از محاسبات زودگذر مانند نمونه های نقطه ای استفاده کنند.
۶- یک فناوری واحد برای پیاده سازی کل برنامه استفاده می شود، که اغلب مصالحه ای بین عمومیت و نیازهای حوزه های خاص برنامه است.
جاوا و دات نت احتمالاً کاندیدای یکپارچه هستند ، زیرا جزو بهترین زبانهای «همهجانبه (all-rounder)» هستند، نه به این دلیل که در هر کار خاصی به طرز شگفتانگیزی خوب هستند.
برخی از ویژگی های میکروسرویس
ساخته شده برای Business
سبک میکروسرویس ها معمولاً بر اساس قابلیت ها و اولویت های تجاری سازماندهی می شود.
بر خلاف رویکرد monolithic development approach ، که در آن تیمهای مختلف تمرکز خاصی بر مثلاً رابطهای کاربری ، پایگاههای داده ، technology layers یا منطق سمت سرور دارند ؛ معماری میکروسرویس از تیمهای چندکاره استفاده میکند.
مسئولیت هر تیم تولید محصولات خاص بر اساس یک یا چند individual services است که از طریق message bus در ارتباط هستند.
در میکروسرویسها، یک تیم مالک محصول در طول lifetime است.
مسیریابی ساده
میکروسرویسها تا حدودی مانند سیستم کلاسیک یونیکس عمل میکنند : درخواستها را دریافت میکنند، آنها را پردازش میکنند و بر اساس آن پاسخ تولید میکنند.
این برخلاف بسیاری از محصولات دیگر مانند ESB ها (Enterprise Service Buses) است که در آن از سیستم های با فناوری پیشرفته برای message routing ، choreography و اعمال applying business استفاده می شود.
غیر متمرکز
از آنجایی که ریزسرویسها شامل انواع فناوریها و پلتفرمها میشوند، روشهای قدیمی مدیریت متمرکز بهینه نیستند.
زیرا توسعه دهندگان آن تلاش می کنند تا ابزارهای مفیدی تولید کنند که می تواند توسط دیگران برای حل همان مشکلات استفاده شود.
درست مانند decentralized governance ، معماری میکروسرویس نیز از مدیریت غیرمتمرکز داده حمایت می کند.
سیستم های یکپارچه از یک پایگاه داده منطقی واحد در برنامه های مختلف استفاده می کنند.
در یک برنامه میکروسرویس، هر سرویس معمولا پایگاه داده منحصر به فرد خود را مدیریت می کند.
مزایای میکروسرویس
۱- مقیاس پذیری :
فرآیندهای فردی در معماری میکروسرویس ها می توانند برای برآورده کردن خواسته های خود مقیاس شوند.
برنامه های کوچکتر می توانند هم به صورت افقی (با افزودن نمونه های بیشتر) و هم به صورت عمودی (با افزایش منابع موجود برای هر نمونه) مقیاس شوند.
۲- Modular بودن :
مزیت آشکار داشتن برنامه های کوچکتر و مستقل این است که جداسازی فیزیکی بین فرآیندها شما را وادار می کند تا به جفت شدن در خط مقدم طراحی خود بپردازید.
هر برنامه ای مسئول انجام مسئولیت های کمتری است که منجر به کد فشرده تر و منسجم تر می شود.
ممکن است استدلال شود که monolith ها میتوانند به شکل مدولار، با در نظر گرفتن جفت و انسجام طراحی شوند.
با این حال، ماهیت در فرآیند monolith ها به این معنی است که توسعه دهندگان آزادند تا مرزهای “soft” را در برنامه اتصال کوتاه کرده و کپسولاسیون را بشکنند، اغلب بدون اینکه متوجه شوند.
۳- تنوع فنی :
برنامه های کاربردی میکروسرویس واحدهای مستقلی هستند که از طریق استانداردهای باز ارتباط برقرار می کنند.
این بدان معناست که انتخابهای فناوری پشت اجرای میکروسرویسها در مقایسه با monolith بسیار کمتر اهمیت دارند.
یعنی انتخاب ها برای میکروسرویس مورد نظر اهمیت دارند، اما به بقیه سیستم مربوط نمی شوند.
دیدن یک معماری میکروسرویس منفرد با ترکیبی از فناوریها ، جاوا ، Node.js برای API gateway ها و نگرانیهای presentation ، و پایتون برای گزارشدهی و تجزیه و تحلیل ، غیرمعمول نیست.
۴- Opportunities for experimentation :
یک میکروسرویس مستقل است و ممکن است جدا از سایر میکروسرویس ها طراحی و توسعه یابد.
و این باعث می شود که پایگاه داده خود را جدا از سایرین داشته باشد.
می توان آن را به زبانی ساخت که برای هدفش مناسب است.
این استقلال به تیم اجازه میدهد تا با خیال راحت فنآوریها ، رویکردها و فرآیندهای جدید را آزمایش کند و با شکست سریع ، در صورت شکست یکی از آزمایشها، هزینههای کاهش آن نسبتاً کم باشد.
۵- migration را آسان می کند :
همه ما روی سیستمهای نرمافزاری یکپارچه بزرگی کار کردهایم که بر اساس فناوری دو دههای ساخته شدهاند و بهروزرسانی آن بسیار دشوار و پرخطر است.
این مورد به ندرت در مورد میکروسرویس ها رخ می دهد. بازسازي پايههاي كد كوچكتر آسانتر است و حتي ميكروسرويسهاي انفرادي كه بد نوشته شدهاند، بقيه سيستم را نگه نميدارند.
۶- انعطاف پذیری و در دسترس بودن
وقتی یکپارچه پایین می آید ، کسب و کار متوقف می شود.
البته، همین امر را میتوان در مورد ریزسرویسهای با طراحی ضعیف و قوی جفت شده با وابستگیهای متقابل پیچیده نیز گفت.
با این حال، معماری میکروسرویسهای خوب بر اتصال آزاد تأکید دارد، جایی که سرویسها مستقل هستند، کاملاً وابستگیهای خود را دارند و ارتباطات همزمان (مسدودکننده) را به حداقل میرسانند. هنگامی که یک میکروسرویس از کار می افتد، همواره بر بخشی از سیستم تأثیر می گذارد و کاربران خاصی را تحت تأثیر قرار می دهد، اما معمولاً به سایر بخش های سیستم اجازه کار می دهد.
محدودیت های میکروسرویس
۱- سادگی Atomic versioning :
پایگاه کد در یک repository ، همراه با تمام تگ ها و branche های مرتبط زندگی میکند.
وقتی نسخه ای را بررسی می کنید، می توانید نسبتاً مطمئن باشید که همه مؤلفه ها سازگار هستند و می توانند با خیال راحت با هم مستقر شوند.
میکروسرویس ها به طور مستقل توسعه می یابند و در repository های جداگانه قرار می گیرند.
اما آنها هنوز باید ارتباط برقرار کنند.
پیگیری نسخه ها و اطمینان از سازگاری زمانی که سرویس ها نسخه مشترکی ندارند بسیار دشوارتر است.
همان چالش هایی که برای کد اعمال می شود، در مورد پیکربندی نیز اعمال می شود.
۲- Deployment automation :
وقتی یک برنامه کاربردی را در یک جفت سرور یک بار در ماه اجرا میکنید.
این فرآیند یک فاجعه برای معماری های میکروسرویس به همراه دارد.
هنگامی که تیم شما ناوگانی متشکل از ده ها میکروسرویس را اداره می کند که به طور معمول دستخوش تغییر می شوند ، فرآیندهای دستی آن را قطع نمی کند.
در واقع میکروسرویس ها به فلسفه توسعه یافته DevOps و فرآیندها و زیرساخت های CI/CD نیاز دارند.
۳- اشکال زدایی
اشکال زدایی تعاملات بین اجزای یک سیستم زمانی که در یک فرآیند با هم ارتباط برقرار می کنند بسیار ساده تر است، به خصوص زمانی که یک جزء به سادگی یک متد را روی دیگری فراخوانی می کند.
این معمولاً فقط مربوط به اتصال یک دیباگر به process ، گام برداشتن در فراخوانی متد و تماشای متغیرها است.
هیچ معادل ساده ای برای این در میکروسرویس ها وجود ندارد.
ردیابی و تجمیع ارتباطات خدماتی بسیار دشوار است و به ابزار، زیرساخت و پیچیدگی بیشتری نیاز دارد.
شما قطعا نمی خواهید خود را در وسط یک قطعی سیستم در معماری میکروسرویس ها بیابید.
۴- سازگاری داده ها :
یک monolith که بر روی یک پایگاه داده رابطه ای منفرد کار می کند از مزایای ACID برخوردار است.
به عبارت دیگر معاملات ، تراکنش ها در سیستم های توزیع شده شکل بسیار متفاوتی به خود می گیرند.
به طور کلی، دستیابی به achieve بسیار دشوارتر است، به خصوص با توجه به انواع خرابی هایی که در سیستم های توزیع شده رخ می دهد.
۵- آزمایش کردن
یک مونولیت را می توان به راحتی به عنوان یک سیستم کامل آزمایش کرد ، چه به صورت دستی یا (ترجیحا) با یک مجموعه تست خودکار.
آزمایش یک میکروسرویس منفرد ، تصویر کلی را نشان نمیدهد : حتی اگر یک سرویس مطابق مشخصات خود عمل کند ، به این معنی نیست که کل سیستم مطابق طراحی کار خواهد کرد.
تنها راه برای اطمینان ، اجرای تست های پیچیده تر integration (یکپارچه سازی) و پایان به انتها (یا پذیرش) است.
SOA در مقابل Microservices
معماری سرویس گرا (SOA) در چند سال اول این قرن ظهور کرد ، و با معماری میکروسرویس (که توسط برخی به اختصار MSA نامیده می شود) شباهت های زیادی دارد.
با این حال، SOA یک چارچوب گستردهتر است و میتواند به معنای طیف گستردهای از چیزها باشد.
برخی از طرفداران میکروسرویس ها تگ SOA را به طور کلی رد می کنند، در حالی که برخی دیگر میکروسرویس ها را به سادگی یک شکل ایده آل و تصفیه شده SOA می دانند.
به عنوان مثال، مدل معمولی SOA معمولاً دارای ESB های وابسته بیشتری است، با میکروسرویس ها از مکانیسم های پیام رسانی سریع تر استفاده می کنند.
SOA همچنین بر برنامهنویسی ضروری تمرکز دارد، در حالی که معماری میکروسرویسها بر سبک برنامهنویسی واکنشگرا متمرکز است.
علاوه بر این، مدلهای SOA تمایل به داشتن یک پایگاه داده رابطهای بزرگتر دارند، در حالی که میکروسرویسها اغلب از پایگاههای داده NoSQL یا micro-SQL (که میتوانند به پایگاههای داده معمولی متصل شوند) استفاده میکنند.
اما تفاوت واقعی در وهله اول مربوط به روش های معماری مورد استفاده برای رسیدن به مجموعه یکپارچه از خدمات است.
از آنجایی که همه چیز در دنیای دیجیتال تغییر میکند، تکنیکهای توسعه چابک که میتوانند با خواستههای تکامل نرمافزار همگام شوند بسیار ارزشمند هستند.
بیشتر روشهای مورد استفاده در معماری میکروسرویسها از توسعهدهندگانی است که برنامههای نرمافزاری را برای سازمانهای سازمانی بزرگ ایجاد کردهاند و میدانند که کاربران نهایی امروزی انتظار تجربههای پویا و در عین حال ثابت را در طیف وسیعی از دستگاهها دارند.
برنامه های کاربردی مبتنی بر accessible cloud ، سازگار، ماژولار و سریع در دسترس تقاضای زیادی دارند.
و این باعث شده است که بسیاری از توسعه دهندگان رویکرد خود را تغییر دهند.
نمونه هایی از فریم ورک های میکروسرویس برای جاوا
چندین فریمورک میکروسرویس وجود دارد که می توانید برای توسعه جاوا از آنها استفاده کنید.
برخی از این موارد عبارتند از:
Spring Boot :
این احتمالاً بهترین فریم ورک میکروسرویس جاوا است که در بالای زبانها برای Inversion of Control ، برنامهنویسی Aspect-Oriented و … کار میکند.
Jersey :
این چارچوب منبع باز از API های JAX-RS در جاوا پشتیبانی می کند و استفاده از آن بسیار آسان است.
Swagger :
در documenting API به شما کمک می کند و همچنین یک پورتال توسعه به شما می دهد که به کاربران اجازه می دهد API های شما را آزمایش کنند.
موارد دیگری که می توانید در نظر بگیرید عبارتند از: Dropwizard، Ninja Web Framework، Play Framework، RestExpress، Restlet، Restx و Spark Framework.
نمونه ای دیگر از میکروسرویس (برنامه سبد خرید)
هنگامی که یک برنامه سبد خرید را باز می کنید، تنها چیزی که می بینید فقط یک وب سایت است.
اما در پشت صحنه اپلیکیشن سبد خرید سرویسی برای پذیرش پرداخت ، سرویس خدمات مشتری و … دارد.
فرض کنید توسعه دهندگان این برنامه آن را در یک چارچوب یکپارچه ایجاد کرده اند.
به نمودار زیر مراجعه کنید:
بنابراین، تمام ویژگیها در یک پایگاه کد واحد قرار میگیرند و تحت یک پایگاه داده زیربنایی قرار میگیرند.
حال، فرض کنید که یک نام تجاری جدید در بازار وجود دارد و توسعه دهندگان می خواهند تمام جزئیات نام تجاری را در این برنامه قرار دهند.
سپس، آنها نه تنها باید روی سرویس برای تگ های جدید دوباره کار کنند، بلکه باید سیستم کامل را مجدداً قالببندی کنند و بر این اساس آن را مستقر کنند.
برای جلوگیری از چنین چالش هایی، توسعه دهندگان این اپلیکیشن تصمیم گرفتند تا اپلیکیشن خود را از معماری یکپارچه به معماری جدیدتر تغییر دهند.
برای درک معماری کاربرد سبد خرید به نمودار زیر مراجعه کنید.
این بدان معنی است که توسعه دهندگان یک میکروسرویس وب، یک میکروسرویس منطقی یا یک میکروسرویس پایگاه داده ایجاد نمی کنند.
در عوض، آنها میکروسرویس های جداگانه ای برای جستجو ، توصیه ها ، خدمات مشتری و … ایجاد می کنند.
این نوع معماری برای برنامه نه تنها به توسعه دهندگان کمک می کند تا بر تمام چالش های موجود در معماری قبلی غلبه کنند، بلکه کمک می کند تا برنامه سبد خرید به راحتی ساخته شود، به کار گرفته شود و توسعه یابد.
جمع بندی
به طور خلاصه، اصطلاح “microservices” مخفف یک الگوی معماری جایگزین است که سیستم های پیچیده ای را از خدمات کوچک و granular تشکیل می دهد.
با تقسیم مشکل به تکههای کوچکتر ، معماری میکروسرویس تعمیر و نگهداری نرمافزار را ساده میکند، امکان مقیاسپذیری بهبود یافته را فراهم میکند و در نهایت به راهحلهای قویتر و پایدارتر منجر میشود.
میکروسرویس ها نیز بدون چالش نیستند ؛ به عنوان مثال اطمینان از سازگاری داده ها در یک سیستم توزیع شده بسیار دشوارتر است
با این حال، نمیتوان از مزایای آن چشمپوشی کرد و اگر سازمان شما هنوز انتقال خود را به میکروسرویسها آغاز نکرده است، به احتمال زیاد به زودی این کار را انجام خواهد داد.
مهرسا امینی
برنامه نویس ، انیماتور ، سئوکار
زندگي در حين گرفتن چيزهايي از تو موقعيت هاي جديدي را مي بخشد