تا به حال از خود پرسیده اید فیس بوک چطور به چند میلیارد کاربر خدمات ارائه میکند؟
روزانه چند میلیارد استوری در اینستاگرام به اشتراک گذاشته می شود؟ چند میلیارد لایک در اینستاگرام ثبت می شود؟
و یا حتی در پروژه های داخل کشور هم اگر بررسی کنیم پروژه های بزرگی وجود دارد که دارند به کاربران میلیونی خدمات ارائه می دهند.
تصور کنید بازی استقلال و پرسپولیس در روز غیر تعطیل و ساعت 14:00 برگذار شود، به نظر شما چند میلیون نفر از طریق اینترنت و آنلاین این بازی را مشاهده می کنند؟
و یا در بلک فرایدی دیجی کالا روزانه چند میلیون بازدید کننده دارد؟ و چند هزار ثبت سفارش دارد؟
اگر بررسی کنیم این اعداد خیلی بالاست. به نظر شما با همان معماری سنتی و مونولیتیکی که تا به حال استفاده می کرده ایم میتوانیم به این نیازها پاسخ بدهیم؟
خیر، اگر فیس بوک ، اوبر و دیگر بزرگان صنعت نرم افزار می توانستند با همان معماری سنتی و مونولیتیک در این حد بزرگ شوند هیچ وقت معماری میکروسرویس به وجود نمی آمد.
اگر قصد دارید نرم افزاری توسعه بدهید که بتواند به میلیون ها کاربر خدمات ارائه کند. پیش نیازهای دارید که معماری مونولیتیک نمی تواند آن نیازهای شما را به خوبی رفع کند و باید از معماری میکروسرویس استفاده کنید.
اگر با معماری میکروسرویس آشنا نیستید توصیه می کنیم دوره رایگان آموزش میکروسرویس را در سایت باگتو مشاهده نمایید در این دوره بصورت کامل و جامع معماری میکروسرویس را تعریف کردیم و تمام ابعاد آن را بیان کردیم.
میکروسرویس یک معماری جدید برای توسعه نرم افزار می باشد. در این معماری نرم افزار را به بخش های کوچک و مستقلی تقسیم می کنیم که هر کدام از این سرویس ها دیتابیس اختصاصی خود را دارند و از طریق api و یا Message broker ها با هم ارتباط برقرار می کنند.
چون ما نرم افزار بزرگ را تقسیم می کنیم به بخش های کوچک تری ، Scale و توسعه نرم افزار هم ساده تر انجام می شود. و اگر بخشی از نرم افزار دچار اختلال شود برای دیگر بخش ها مشکلی به وجود نمی آید.
برای درک بهتر موضوع تصور کنید یک پروژه نرم افزاری فروشگاه آنلاین موبایل داریم. اگر بخواهیم این پروژه را تبدیل به معماری میکروسرویس کنیم می توانیم تقسیم بندی هایی انجام دهیم و این پروژه را به چند بخش کاملا مجزا تبدیل کنیم.
به عنوان مثال برای پروژه فروشگاه آنلاین موبایل میتوانیم سرویس های زیر را داشته باشیم:
1- سرویس محصولات
در این سرویس مدیریت محصولات و نمایش اطلاعات هر محصول در سایت را پیاده سازی می کنیم
2- سرویس سبد خرید
در این سرویس Api های مورد نیاز برای ایجاد سبد خرید را پیاده سازی می کنیم.
3- سرویس تخفیف
در این سرویس Api های مورد نیاز برای مدیریت کدهای تخفیف و اعمال کد تخفیف بر روی سبد خرید را پیاده سازی می کنیم
4- سرویس سفارش
در این سرویس Api ها مربوط به مدیریت سفارشات و فرایند های مورد نیاز برای ثبت سفارش را پیاده سازی می کنیم
هر کدام از این سرویس ها کاملا مستقل از هم توسعه داده می شوند.
می توانند تیم اختصاصی خود را داشته باشند.
هرکدام می توانند زبان برنامه نویسی اختصاصی خود را داشته باشند
هر کدام از سرویس ها باید دیتابیس اختصاصی خود را داشته باشند و نباید یک دیتابیس مشترک بین همه سرویس ها ایجاد کنیم.
چون سرویس ها جدای از هم هستند می توانند به صورت مستقل از هم توسعه داده بشوند.
هر کدام از سرویس ها می توانند به صورت مستقل Scale شوند.
میکروسرویس یک اصطلاح تقریباً جدیدی است که وارد دنیای معماری نرم‌افزار شده است و بسیاری از مهندسین نرم‌افزار هنوز از این معماری استفاده نمی‌کنند.
ما در چند سال اخیر مشاهده می‌کنیم این سبک از معماری به یک سبک پیش‌فرض برای ساخت برنامه‌های سازمانی تبدیل شده است. در پروژه های داخل ایران هم داریم میبینیم که خیلی از پروژه ها از معماری میکروسرویس استفاده می کنند.
متأسفانه، اطلاعات زیادی وجود ندارد که نشان دهد سبک معماری میکروسرویس چیست و چگونه باید آن را انجام دهند تا دیگران کاملاً واضح از مزایای این معماری مطلع شوند تا بتوانند از مزایای این معماری بهره ببرند و در پروژه های خود استفاده کنند.
ما در دوره رایگان آموزش میکروسرویس این معماری را به‌صورت کامل آموزش داده‌ایم شما در این دوره یک دید کلی و بسیار جامع از این معماری به دست می‌آورید و بعد در دوره پیشرفته آموزش میکروسرویس که با عنوان دوره ستارگان میکروسرویس در سایت قرار دارد نحوه پیاده‌سازی معماری میکروسرویس در Asp.net Core را آموزش می‌بینید.
برای اینکه مفهوم معماری میکروسرویس برای شما بهتر جا بی افتد ابتدا لازم است با معماری یکپارچه یا مونولتیک آشنا شوید.
معماری مونولتیک یک برنامه یکپارچه است که تمامی مواردنیاز پروژه به‌صورت یکپارچه کنار هم قرار می‌گیرد و توسعه داده می‌شود و درنهایت به دست مشتری می‌رسد.
این معماری داری ۳ بخش مجزا است
( اینجام اون تصویر سه لایه )
1- User interface
این بخش که ui پروژه است که با استفاده از html ,css نوشته می‌شود و یا ممکن است خروجی web APIها باشد که با JSON و یا XML نوشته شده باشد و در اختیار کاربر نهایی قرار می‌گیرد.
2- Business logice
در این بخش از منطق تجاری برنامه پیاده‌سازی می‌شود
3- Data Base Access
4- وظیفه این لایه ایجاد ارتباط با دیتابیس است، و کار ذخیره و بازیابی داده در دیتابیس را بر عهده دارد این لایه توسط لایه Business logice مورداستفاده قرار می‌گیرد.
?
با گذشت زمان، حفظ یک ساختار ماژولار خوب اغلب دشوار است، و حفظ تغییراتی که فقط باید روی یک ماژول در آن ماژول تأثیر بگذارد، سخت‌تر می‌شود و scale کردن به جای بخشی از آن که به منابع بیشتری نیاز دارد، به مقیاس بندی کل برنامه نیاز دارد.
این ناامیدی‌ها از معماری مونولتیک منجر به پیدایش سبک معماری میکروسرویس شده است با معماری میکروسرویس برنامه‌هایی کاربردی به‌عنوان یک مجموعه خدمات را میتوانیم ایجاد کنیم علاوه بر این که سرویس‌ها به طور مستقل قابل استقرار و مقیاس‌پذیری هستند، هر سرویس همچنین یک مرز ماژول ثابت هم دارد، حتی اجازه می‌دهد تا سرویس‌های مختلف به زبان‌های برنامه‌نویسی مختلف نوشته شوند. آنها همچنین می‌توانند توسط تیم‌های مختلف مدیریت شوند
معماری Microservices هر یک از عملکردهای یک برنامه کاربردی را به‌عنوان یک سرویس مستقل در نظر می‌گیرد که می‌تواند تغییر، به‌روز یا حذف شود بدون اینکه بر بقیه برنامه تأثیر بگذارد. برنامه‌ها به طور سنتی به‌عنوان نرم‌افزارهای یکپارچه ساخته می‌شدند. افزودن ویژگی‌های جدید نیازمند پیکربندی مجدد و به‌روزرسانی همه چیز از فرایند و ارتباطات گرفته تا امنیت در برنامه است.
برنامه‌های کاربردی یکپارچه سنتی دارای چرخه عمر طولانی هستند، به‌ندرت به‌روز می‌شوند و تغییرات معمولاً بر کل برنامه تأثیر می‌گذارد. این فرایند پرهزینه و دست‌وپاگیر پیشرفت و به‌روزرسانی در توسعه برنامه‌های کاربردی سازمانی را به تأخیر می‌اندازد. معماری میکروسرویس برای حل این مشکل طراحی شده است. همه سرویس‌ها به‌صورت جداگانه ایجاد می‌شوند و به طور جداگانه از یکدیگر مستقر می‌شوند. این سبک معماری امکان مقیاس‌بندی خدمات را بر اساس نیازهای تجاری خاص فراهم میکند. سرویس‌ها را می‌توان به‌سرعت بدون تأثیرگذاری بر سایر بخش‌های برنامه تغییر داد. تحویل مداوم یکی از مزایای میکروسرویس‌ها است.
معماری میکروسرویس دارای ویژگی‌های زیر است:
• برنامه به اجزای ماژولار و آزادانه تقسیم می‌شود
• برنامه را می‌توان در مراکز داده توزیع کرد.
• برای افزودن ویژگی‌های جدید فقط باید آن سرویس‌های مربوطه به‌روزرسانی شود
• سرویس‌های شبکه باید به‌صورت نرم‌افزاری تعریف شده و به‌صورت فابریک برای اتصال هر میکروسرویس اجرا شوند
1- محدود به یک تکنولوژی نیستند
2- ساختار مناسبی برای scale دارند
3- Deployment ساده
4- قابلیت جایگزینی
5- تحویل سریع فیچر به مارکت
6- داشتن تیم با بهره‌وری بالا
استفاده از میکروسرویس‌ها چالش‌های مخصوص به خودش را دارد که با مدیریت آنها می‌توانید به بهترین شکل از آنها بهره ببرید.
در مقاله مزایا و معایب میکروسرویس ها بصورت مفصل تر به این موضوع پرداخته ایم.
چه زمانی از میکروسرویس‌ها استفاده کنیم؟
در نهایت، هر شرکت بزرگی می‌تواند در استفاده از معماری میکروسرویس‌ها سود ببرد، اگر برنامه‌هایی داشته باشد که نیاز به به‌روزرسانی‌های مکرر دارند، الگوهای ترافیکی پویا را دارند می‌توانند از این معماری استفاده کنند.
چون هر پروژه و هر برنامه‌ای که طراحی و پیاده‌سازی می‌شود با هم متفاوت است معیار مشخص و خط‌کشی‌شده‌ای وجود ندارد که ما از آن استفاده کنیم و همه سرویس‌ها را بر آن اساس مرزبندی کنیم.
1- ما باید مرزبندی میکروسرویس‌ها را بر مبنای اتصال سست (lose coupling) قرار بدهیم
یعنی تغییرات در یک سرویس نیاز به تغییر در سرویس‌های دیگر نباشد.
2- در طراحی سرویس‌ها باید به سمت high cohesion حرکت کنیم.
این به چه معناست؟
در high cohesion عملیات‌ها و رفتارهای مرتبط رو در کنار هم قرار دهیم این کار باعث می‌شود برای یک عملیات خاص چندین سرویس درگیر نشوند زیرا وقت زیادی از تیم می‌گیرد و در هنگام انتشار بر روی سرور باید چندین سرویس را deploy کنیم و بسیاری از مزیت‌های میکروسرویس‌ها رو از دست می‌دهیم.
3- استفاده از مفهوم bounded context
مفهوم bounded context که یکی از بخش‌های ddd است که توسط اریک ایوانز ارائه شد است.
با استفاده از این مفهوم ما فضای مسئله که یک فضای بزرگ است رو به مفاهیم کوچک‌تر تقسیم می‌کنیم که راحت‌تر بتونیم برنامه رو جلو ببریم.
خصوصیاتی که هر bounded context باید داشته باشد که بتوان به‌عنوان یک مفهوم مستقل آن را جدا کنیم.
مستقل باشد
تکنولوژی‌ها و معماری‌های خاص خودش را داشته باشد
دیتابیس اختصاصی داشته باشد
تیم برنامه‌نویسی مخصوص به خودش را داشته باشد
این خصوصیات که برای bounded contextها ارائه شده است تقریباً همان خصوصیاتی هستند که برای سرویس‌ها میتوانیم در نظر بگیریم، بنابراین میتوانیم هر bounded context را در یک سرویس قرار دهیم.
جداکردن سرویس‌ها و مشخص‌کردن مرز بین آنها کار ساده‌ای نیست شما باید زمان زیادی صرف کنید تا بتوانید به‌خوبی سرویس‌ها را از هم جدا کنید زیرا درست انجام‌دادن این کار روند کار شما را در آینده تسریع می‌بخشد و باعث می‌شود مشکلات کمتری پیش بیاید و بعداً مجبور نباشید که دوباره این مرزها را تغییر دهید.
شرکت‌های رسانه‌های اجتماعی مانند فیس‌بوک و توییتر آمازون، ارائه‌دهنده رسانه‌ای مانند نتفلیکس، خدمات تاکسی آنلاین مانند Uber و Lyft، و بسیاری از بزرگ‌ترین شرکت‌های خدمات مالی جهان، همگی از میکروسرویس‌ها استفاده می‌کنند. این روند باعث شده است که شرکت‌ها از معماری یکپارچه به برنامه‌های کاربردی میکروسرویس حرکت کنند، استانداردهای جدیدی را برای فناوری کانتینر تعیین کنند و مزایای استفاده از این طرح معماری را اثبات کنند.
در ایران نیز شرکت های بزرگ مانند دیجی‌کالا، اسنپ، ورزش 3 و ...، از معماری میکروسرویس استفاده می‌کنند.
معماری میکروسرویس به سازمان‌ها اجازه می‌دهند تا برنامه‌ها را به حوزه‌های جداگانه‌ای که توسط گروه‌های جداگانه مدیریت می‌شوند، تقسیم کنند. این نوع از معماری برای ساخت برنامه‌های کاربردی با مقیاس بالا است. این مورد یکی از دلایل اساسی روی‌آوردن کسب‌وکارها به ابر عمومی برای ارائه برنامه‌های میکروسرویس است، زیرا زیرساخت‌های اولیه برای برنامه‌های یکپارچه قدیمی بهینه‌تر شده است، اگرچه لزوماً این‌طور نیست. نسل جدیدی از فروشندگان فناوری تصمیم گرفتند تا برای هر دو راه‌حل ارائه دهند. تفکیک مسئولیت‌های کار مستقل را روی خدمات فردی تقویت میکند که تأثیری بر توسعه دهندگان در گروه‌های دیگر که روی همان برنامه کار می‌کنند، ندارد.
