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

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

تاریخچه میکروسرویس: دنیا قبل از میکروسرویس به چه صورت بود؟

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

ریشه‌ها

در دهه ۲۰۰۰، معماری SOA (Service-Oriented Architecture) مطرح شد که سیستم‌ها را به سرویس‌های مستقل تقسیم می‌کرد. با این حال، این سرویس‌ها اغلب بزرگ و پیچیده بودند و انعطاف‌پذیری لازم برای توسعه سریع را فراهم نمی‌کردند.

شکل‌گیری میکرو سرویس

اوایل دهه ۲۰۱۰، شرکت‌هایی مانند Netflix و Amazon برای حل مشکلات مقیاس‌پذیری و توسعه سریع، سیستم‌های یکپارچه خود را به مجموعه‌ای از سرویس‌های کوچک، مستقل و قابل استقرار جداگانه تقسیم کردند. در سال ۲۰۱۴، Martin Fowler و James Lewis با انتشار مقاله‌ای رسمی، اصطلاح «میکرو سرویس» را تثبیت و چارچوب فکری آن را توضیح دادند.

دلیل فراگیری

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

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

چالش‌ها و محدودیت‌های میکروسرویس

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

اما ممکن است به این فکر کنید که زیاد شدن حجم کدها در طول دوران توسعه نرم افزار و تغییرات آن چه مشکلی می‌تواند داشته باشد؟ در ادامه به چند مورد از این مشکلات خواهیم پرداخت.

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

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

در نتیجه این عدم توانایی شناخت درست و صحیح باعث می‌شود رفع خطاهای موجود یا اضافه کردن یک ویژگی جدید هم بسیار سخت و هم بسیار پیچیده باشد. نکته اصلی در این شرایط این است که با گذشت زمان این مشکل به شکل نمایی بیشتر و بیشتر می‌شود. هر چقدر فهم کد سخت‌تر بشود احتمال اشتباه بیشتر و احتمال پیدا کردن اشتباه‌ها کمتر و توان رفع آنها هم کمتر می‌شود، در نهایت به سورس کدی خواهیم رسید که اصطلاحا به اون big ball of mud می‌گوییم.

مشکل دوم: پایین آمدن سرعت توسعه نرم افزار

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

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

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

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

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

مشکل پنجم: انتشار مشکلات

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

مشکل ششم: عدم توانایی در به کارگیری ابزارها و تکنولوژی‌های جدید 

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

در حال حاضر در یکی از شرکت‌های بزرگ درگیر مشاوره در یک پروژه ERP هستم که سال‌ها پیش و با تکنولوژی سال ۲۰۰۵ توسعه داده شده است در این ابزار از ۰.Net Framework 2 استفاده شده و برای توسعه وب هم از ASP.NET Web Form استفاده شده است و اینقدر سیستم بزرگ و پیچیده شده که در طی این سال‌ها کسی جرات دست زدن به سیستم و تغییر تکنولوژی را نداشته است.

در صورتی که خودتان جای یکی از مدیران پروژه و شرکت بگذارید چقدر احتمال دارد قبول کنید که ثمره ۱۵ سال توسعه یک تیم برنامه نویسی دور ریخته بشود و یک پروژه جدید استارت زده شود؟ به نظرتان در این ۱۵ سال که یک تیم ۱۵-۲۰ نفره به طور میانگین درگیر این پروژه بوده است چقدر هزینه تولید همچین ابزاری شده است؟ آیا تغییر تکنولوژی با این شرایط امکان پذیر هست؟

خوب به نظر میرسه کم کم داریم به پایان دنیا نزدیک می‌شیم. اما واقعا راه حلی برای این مشکلات نیست؟

مزایای میکروسرویس‌

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

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

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

تعامل و استقلال:

یکی از اصلی‌ترین اهداف میکروسرویس، ارائه‌ی سرویس‌هایی است که مستقل و قابل مدیریت هستند. این موضوع باعث می‌شود تیم‌های توسعه بتوانند با سرعت بیشتری واحدهای کد را توسعه، تست و انتشار دهند.

قابلیت اطمینان:

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

مقیاس‌پذیری:

سرویس‌ها می‌توانند به صورت مستقل از یکدیگر مقیاس‌بندی شوند، که این امکان را می‌دهد تا منابع را برای سرویس‌هایی که نیاز به بار بیشتری دارند، اختصاص داد.

آنچه میکروسرویس می‌خواهد ارائه دهد، سازمان‌هایی پویا، قابل تغییر و با قابلیت پاسخ‌گویی بالا به نیازهای مشتری است.

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

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

پیچیدگی سیستم:

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

نیاز به توسعه موازی:

در پروژه‌هایی که تیم‌های متعدد باید به صورت همزمان روی ویژگی‌های مختلف کار کنند، میکروسرویس‌ها می‌توانند فرآیند را ساده‌تر و سریع‌تر کنند.

زبان‌ها و فناوری‌های مختلف:

اگر نیاز به استفاده از زبان‌ها و فناوری‌های مختلف در یک پروژه دارید، میکروسرویس این امکان را می‌دهد که هر سرویس با زبان و فناوری مناسب خود نوشته شود.

تضمین عملکرد:

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

توزیع جغرافیایی:

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

نیاز به ارتقاء مستقل:

اگر می‌خواهید قسمت‌هایی از برنامه خود را بدون تأثیر گذاری بر سایر قسمت‌ها به‌روز کنید، معماری میکروسرویس این امکان را فراهم می‌کند.

بزرگ‌ترین استفاده‌کنندگان معماری میکروسرویس در دنیا

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

• Netflix: یکی از اولین و بزرگ‌ترین استفاده‌کنندگان معماری میکروسرویس، Netflix است. با توجه به میلیون‌ها کاربر در سراسر دنیا، این شرکت از میکروسرویس‌ها برای پشتیبانی از تقاضای روزانه خود استفاده می‌کند.
• Amazon : Amazon با تجزیه سیستم‌های خود به میکروسرویس‌ها، توانمندی مدیریت ترافیک بالایی را کسب کرده و به کاربران خود خدمات مستمری ارائه می‌دهد.
• Uber: با توجه به نیاز به سرعت و پاسخ‌گویی فوری، اوبر سیستم‌های خود را بر مبنای میکروسرویس طراحی کرده است.
• Spotify: این شرکت موسیقی با استفاده از معماری میکروسرویس، توانمندی توسعه سریع و مقیاس‌پذیری خود را افزایش داده است.

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

فناوری‌ها و نرم‌افزارهای مورد نیاز برای پیاده‌سازی میکروسرویس‌ها

API Gateway چیست؟

ارتباط بین سرویس ها

تکنولوژی‌های ارتباطی

در میکروسرویس‌ها برای برقراری ارتباط بین سرویس‌ها و کلاینت‌ها تکنولوژی‌های متنوعی وجود دارد که بسته به نوع تعامل Sync یا Async و یک‌به‌یک یا یک‌به‌چند انتخاب می‌شوند؛ روش‌های Async معمولاً از Messaging استفاده می‌کنند که شامل ارسال پیام با Header و بدنه پیام از طریق کانال‌های Point-to-Point یا Publish-Subscribe است و مزایایی مانند جداسازی کامل کلاینت از سرویس، عدم نیاز به همزمانی سرویس و کلاینت و نمایان شدن ماهیت IPC دارد، اما پیچیدگی‌های عملیاتی و پیاده‌سازی و نیاز به نگهداری زیرساخت را نیز به همراه دارد. در روش‌های Sync، Request/Response رایج است که با پروتکل‌هایی مانند REST یا Thrift پیاده‌سازی می‌شود؛ REST مبتنی بر Resourceها و HTTP است و مزایایی مثل سادگی، تست‌پذیری و سازگاری با زیرساخت‌ها دارد، اما محدودیت‌هایی چون نیاز به همزمانی کلاینت و سرویس، وابستگی به آدرس دقیق سرویس و پشتیبانی صرف از Request/Response دارد. انتخاب فرمت پیام‌ها نیز مهم است؛ قالب‌های متنی مانند JSON و XML خوانا اما کم‌بهره‌ور و قالب‌های باینری مثل Avro یا Protocol Buffer سریع و بهینه هستند، بنابراین بسته به نیازمندی‌های سیستم و شرایط عملیاتی باید فناوری و قالب مناسب ارتباط بین سرویس‌ها انتخاب شود.

آشنایی با Service Discovery

مدیریت داده‌ها در میکروسرویس

در میکروسرویس‌ها هر سرویس داده‌های خود را به صورت مستقل نگهداری می‌کند و دسترسی به داده‌های سرویس‌های دیگر تنها از طریق API امکان‌پذیر است، که مزایایی مثل استقلال، توزیع‌پذیری و استفاده از DB Engineهای مختلف (Polyglot Persistence) دارد اما چالش‌هایی مثل تراکنش‌های توزیع شده و همزمانی داده‌ها ایجاد می‌کند. برای حل این مشکلات معمولاً از Eventها استفاده می‌شود، به طوری که هر تغییر مهم در داده‌ها یک Event تولید می‌کند و سایر سرویس‌ها با دریافت آن داده‌های داخلی خود را به‌روزرسانی می‌کنند، روشی که eventual consistency، materialized view و تراکنش‌های چندمرحله‌ای را ممکن می‌کند اما پیچیدگی فنی، نیاز به rollback و احتمال دریافت دوباره Eventها از معایب آن است. برای حفظ atomicity می‌توان از جدول Event در تراکنش محلی، Transaction Log یا Event Sourcing استفاده کرد، به طوری که در Event Sourcing وقایع رخ‌داده روی Entityها ذخیره می‌شوند و وضعیت نهایی از روی این وقایع بازسازی می‌شود؛ این روش تاریخچه کامل داده‌ها را فراهم می‌کند اما پیچیدگی پیاده‌سازی، زمان‌بر بودن پردازش و دشواری جستجو از محدودیت‌های آن است و معمولاً با CQRS ترکیب می‌شود.

آشنایی با روش‌های انتشار در میکروسرویس‌ها

میکروسرویس را انتخاب کنم یا نه؟

جمع بندی 

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