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

حرکت به سمت میکروسرویس 

دلیل حرکت به سمت میکروسرویس به علت مدیریت آسان و سرعت رشد و قابلیت توسعه دهندگی بالا است .

تعداد نفرات کمتر برای ایجاد امکانات جدید بیشتر و ایجاد تغییرات و پیاده سازی سریع و ساده تر را بر شمرد.  

همچنین امکان Deploy بر روی چندین سرور  load balancing و نگه داری آسان را دارا می باشد و در روند توسعه با کاهش  Downtime های سخت افزاری و نرم افزاری رو به رو هستیم 

میکروسرویس  رشد و توسعه نرم افزار را شامل نمی شود بلکه انقلابی در زمینه های DevOps در پیاده سازی و نگهداری و تست و استقرار دائمی  (CI/CD) در محیط های ابری (Cloud) به پا کرده است .

در این میان  Nginx رابطه مستقیم و قوی را با micro service بازی می کند . با توانایی این وب سرویس (Nginx) در  پیاده سازی reverse proxy نقش عمده ای را در تکامل میکروسرویس و cloud بازی میکند .

در مورد اینکه وب سرور NGINX چیست؟ میتوانید مطالعه کاملتری داشته باشید

اینجانب قصد دارم که طی چندین مقاله در جلسات مختلف به ادامه این بحث و تاریخچه و  پیدایش microservice و  مفاهیم پرکاربرد با موضوعیت های زیر بپردازم

• Introduction to Microservices 
• Using an API Gateway
• Inter-Process Communication 
• Service Discovery
• Event-Driven Data Management for Microservices
• Choosing a Microservices Deployment Strategy
• Refactoring a Monolith into Microservices

Introduction to Microservices (مقدمه ای بر میکروسرویس ها)

اصطلاح میکروسرویس برای اولین بار توسط دکتر پیتر راجرز در سال 2005 ابداع شد و در ابتدا به عنوان "خدمات میکرو وب" شناخته می شد. محرک اصلی پشت «micro web services» در آن زمان این بود که طرح‌های «یکپارچه(monolithic)» بزرگ را به چندین مؤلفه/فرآیند مستقل تقسیم کند تا پایگاه کد(CodeBase) را دقیق‌تر و قابل مدیریت‌تر کند.

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

تعریف ساده برای میکروسرویس

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

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

یک میکروسرویس معمولا کوچک است و شاید شامل هزاران خط کد باشد و این در مقابل یک سیستم یکپارچه یا همان مونولیت(monolith) که شامل صدها هزار خط کد هستند بسیار کوچک و ناچیز است.

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

نکته: یک میکروسرویس معمولاً تعداد کمی از مسئولیت های مرتبط را انجام می دهد.

در نگهداری بهتر است ارسال، آپلود یا push پروژه روی گیت لب gitlab را کامل بدانید

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

نکته: میکروسرویس‌ها فقط در صورت لزوم به صورت همزمان ارتباط برقرار می کنند.

این معماری ذاتا مربوط به «میکرو یا کوچک بودن» نیست. البته آن‌ها معمولا از معماری یکپارچه کوچک‌تر هستند. اندازه در این معماری یک واحد نسبی است و هیچ استاندارد دقیقی برای سازمان‌دهی و دسته‌بندی این نوع از معماری وجود ندارد.

روش معماری میکروسرویس‌ها یک رویکرد برای توسعه اپلیکیشن‌ها به صورت سرویس‌های کوچک است که هرکدام در قسمت پردازش خود اجرا می‌شوند و معمولا از طریق یک مکانیزم سبک مانند یک HTTP resource API ارتباط برقرار می‌کنند. این سرویس‌ها براساس سازگاری‌ها و قابلیت‌های مربوط به لایه business ایجاد می‌شوند. 

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

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

مقیاس پذیری - فرآیندهای فردی در معماری میکروسرویس ها می توانند برای برآورده کردن خواسته های خود مقیاس پذیر شوند. برنامه های کوچک‌تر می توانند هم به صورت افقی(horizontally) (با افزودن نمونه های بیشتر) و هم به صورت عمودی(vertically) (با افزایش منابع موجود برای هر نمونه) مقیاس پذیر شوند.

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

ماژولار بودن(Modularity) - مزیت آشکار داشتن برنامه های کوچک‌تر و مستقل این است که جدایی فیزیکی بین فرآیندها، شما را مجبور می‌کند تا به اتصال آن‌ها در ForeFront طراحی خود بپردازید. هر برنامه‌ مسئول انجام مسئولیت‌های کوچکی است که منجر به ایجاد کد فشرده‌تر و منسجم‌تر می‌شود.

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

تنوع فناوری به کار رفته در طراحی(Tech diversity) – برنامه‌های کاربردی میکروسرویس واحدهای مستقلی هستند که از طریق استانداردهای باز ارتباط برقرار می‌کنند. این بدان معنی است که انتخاب‌ فناوری‌ها در پشت پرده پیاده‌سازی میکروسرویس‌ها در مقایسه با سیستم‌های یکپارچه یا مونولیت بسیار کمتر اهمیت دارند. یعنی انتخاب‌ها برای میکروسرویس مورد نظر، اهمیت دارند، اما به بقیه سیستم مربوط نمی‌شوند. یک معماری میکروسرویس منفرد ممکن است که با ترکیبی از فناوری‌ها اجرا شده باشد. به عنوان مثال در یک میکروسرویس احتمال دارد که از جاوا و Go برای منطق تجاری استفاده شود، از Node.js برای API و از پایتون برای تجزیه و تحلیل.

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

مهاجرت آسان به سایر تکنولوژی‌ها - اکثر ما روی سیستم‌های نرم‌افزاری یکپارچه بزرگی کار کرده‌ایم که بر اساس فناوری ساخته شده‌اند که قدمت دو دهه‌ای دارند و به‌روزرسانی آن بسیار دشوار و پرخطر است. من شخصاً به یاد می‌آورم که در سال 2018 روی پروژه‌ای کار می‌کردم که در آن تیم در هندل کردن پروژه با جاوای نسخه 6 گیر کرده بود - به دلیل وابستگی‌های پیچیده کتابخانه، فقدان تست‌های واحد مناسب و خطر مهاجرت به نسخه‌های بالاتر ناشی از آن، متوقف شد. این داستان به ندرت در مورد میکروسرویس‌ها رخ می‌دهد.

انعطاف پذیری و در دسترس بودن - وقتی یکپارچگی یک سیستم پایین بیاید، کسب و کار متوقف می شود. البته، همین امر را می‌توان در مورد میکروسرویس‌های با طراحی ضعیف و قوی جفت شده با وابستگی‌های متقابل پیچیده نیز گفت. با این حال، معماری میکروسرویس‌های خوب بر اتصالات سست تأکید می‌کند، جایی که سرویس‌ها مستقل هستند، کاملاً وابستگی‌های خود را دارند و ارتباطات همزمان (مسدودکننده) را به حداقل می‌رسانند. هنگامی که یک میکروسرویس از کار می‌افتد، همواره بر بخشی از سیستم تأثیر می‌گذارد و کاربران خاصی را تحت تأثیر قرار می‌دهد، اما معمولاً سایر بخش‌های سیستم بدون مشکل کار می‌کنند.

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

میکروسرویس‌ها هم دارای معایبی هستند که باید آن‌ها را هم برای طراحی در نظر بگیریم. در زیر برخی از این معایب را برای شما لیست کرده‌ایم.

نگهداری و مدیریت دشوار -  زمانی که تعداد اپلیکیشن‌ها و کد آن افزایش می‌یابد، نگهداری و مدیریت صحیح آن به وظیفه دشواری تبدیل می‌شود.

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

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

انجام عملیات‌های بیشتر - میکروسرویس‌ها به صورت مکرر روی ماشین مجازی یا کانتینر خودشان اجرا می‌شوند. به همین دلیل میزان بیشتری را اشغال کرده و نیاز به کارهای بیشتری برای انجام دادن دارند. این وظایف معمولا توسط یک ابزار مدیریت خودکارسازی می‌شوند.

تست مداوم - تست‌های پایداری در سطح اپلیکیشن جهت تضمین این که ویژگی‌های جدید، کارکرد سرویس‌های موجود را از کار نمی‌اندازند، ضروری است.

استفاده از API Getway در میکروسرویس ها

API Getway یک ابزار مدیریت API است که بین یک کلاینت و مجموعه ای از خدمات BackEnd قرار می گیرد. یک API Getway به عنوان یک پروکسی معکوس عمل می کند تا همه تماس های Application Programming Interface (API) را بپذیرد، خدمات مختلف مورد نیاز برای انجام آنها را جمع آوری کند و نتیجه مناسب را برگرداند.

از بک اند گفتیم بهتره برنامه نویس بک اند (Back End) کیست؟ را هم مطالعه کنید تا از این حوزه کاملا اطلاع داشته باشید

اکثر API های سازمانی از طریق API Getway مستقر(Deploy) می شوند. معمولا API Getway وظایف مشترکی را که در یک سیستم از سرویس های API استفاده می شود، مانند احراز هویت کاربر، محدود کردن نرخ و آمار انجام می‌دهد.

در ساده‌ترین حالت، یک سرویس API یک درخواست از راه دور را می پذیرد و یک پاسخ به آن برمی گرداند. اما در عمل هرگز به این سادگی نیست.

نگرانی‌های مختلف خود را هنگام میزبانی APIهای با مقیاس بزرگ را در نظر بگیرید:

• شما احتمالا نیاز دارید که از API های خود در برابر استفاده بیش از حد و سوء استفاده محافظت کنید، بنابراین باید از یک سرویس احراز هویت(authentication service) و محدودیت نرخ(rate limiting) استفاده کنید.
• شما می خواهید بدانید که دیگران چگونه از API های شما استفاده می‌کنند، بنابراین باید ابزارهای تجزیه و تحلیل و نظارت را به سیستم خود اضافه ‌کنید.
• اگر APIهای کسب درآمد دارید، نیاز دارید که به یک سیستم صدور صورت‌حساب(billing system) متصل شوید.
• ممکن است که شما یک معماری میکروسرویس را راه اندازی کرده باشید، در این صورت یک درخواست می‌تواند نیاز به تماس با ده‌ها برنامه جداگانه داشته باشد.
• با گذشت زمان، احتمالا نیاز داشته باشید که برخی از سرویس‌های API جدید اضافه ‌کنید و برخی دیگر را از رده خارج ‌کنید، اما مشتریان شما می‌خواهند همه سرویس‌های شما را در همان مکان قبلی پیدا کنند.

چالشی که شما در پیش رو دارید، ارائه یک تجربه ساده و قابل اعتماد در مقابل همه پیچیدگی‌های بالا به مشتریان‌تان است. یک API Getway راهی برای جدا کردن FrontEnd از BackEnd سیستم شما است.

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

در اینجا صحبت از api شد برای همین بهتر است API چیست؟ را مطالعه کنید

نقش API Getway در مدیریت API

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

کاری که API Getway انجام می دهد متفاوت از سایر بخش‌ها است. برخی از عملکردهای رایج آن عبارتند از احراز هویت(authentication)، مسیریابی(routing)، محدود کردن نرخ(rate limiting)، صورتحساب(billing)، نظارت(monitoring)، تجزیه و تحلیل(analytics)، خط‌مشی‌ها(policies)، هشدارها(alerts) و امنیت(security).

چگونه یک API Getway از DevOps و محیط‌های بدون سرور(serverless environments) پشتیبانی می‌کند؟

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

علاوه بر این، modern cloud development، از جمله serverless model، به APIها برای تامین زیرساخت بستگی دارد. شما می توانید توابع بدون سرور(serverless functions) را مستقر کرده و آنها را با استفاده از یک API Getway مدیریت کنید.

با افزایش پیچیدگی API و نیاز به استفاده بیشتر از آن‌ها، ارزش API Getway نیز افزایش می‌یابد.

ارتباطات بین فرآیندی (Inter-process Communication) چیست؟ و چرا در میکروسرویس اهمیت دارد

ارتباطات بین فرآیندی(Inter-process Communication) مکانیزمی است که توسط سیستم عامل ارائه می‌شود که به فرآیندها اجازه می‌دهد با یکدیگر ارتباط برقرار کنند. این ارتباط می‌تواند شامل فرآیندی باشد که به فرآیند دیگری اطلاع می‌دهد که رویدادی رخ داده یا داده‌ها از یک فرآیند به فرآیند دیگر منتقل شده‌اند.

دیاگرام زیر ارتباطات بین فرآیندی(Inter-process Communication) را نشان می دهد:

همگام سازی در Inter-process Communication

همگام سازی(Synchronization) بخشی ضروری از Inter-process Communication است که یا توسط مکانیسم کنترل بین فرآیندی(inter-process control mechanism) ارائه می‌شود یا توسط فرآیندهای ارتباطی(communicating processes) مدیریت می‌شود.

برخی از متدهای ارائه همگام سازی(Synchronization) به شرح زیر است:

• Semaphore – Semaphore متغیری است که دسترسی به یک منبع مشترک را توسط چندین فرآیند کنترل می کند. به طور کلی دو نوع Semaphore داریم : binary semaphores و counting semaphores.
• Mutual Exclusion - Mutual Exclusion مستلزم آن است که تنها یک نخ(thread) فرآیند، بتواند در یک زمان وارد بخش بحرانی شود که برای همگام سازی بسیار مفید است.
• Barrier - یک Barrier اجازه رسیدگی به فرآیند‌های فردی را نمی دهد و باید همه فرآیندها وجود داشته باشند.
• Spinlock – Spinlock یک نوع قفل است. فرآیندهایی که سعی می‌کنند این قفل را بدست آورند در یک حلقه منتظر می‌مانند و بررسی می‌کنند که آیا قفل موجود است یا نه. این به عنوان busy waiting شناخته می‌شود، زیرا این فرآیند با وجود فعال بودن، هیچ عملیات مفیدی را انجام نمی‌دهد.

اگر به برنامه نویسی علاقمندید با آموزش لاراول (laravel) جامع و پروژه محور ساخت فروشگاه اینترنتی برای ورود به بازار کار آماده شوید

رویکردهای Inter-process Communication

رویکردهای مختلفی برای اجرای Inter-process Communication ارائه شده که به شرح زیر است:

• Pipe – Pipe یک کانال داده یک طرفه است. برای ایجاد یک کانال داده دو طرفه بین دو فرآیند می‌توان از دو Pipe استفاده کرد که از روش‌های ورودی و خروجی استاندارد استفاده می‌کند. Pipeها در تمام سیستم‌های POSIX و همچنین سیستم عامل‌های ویندوز استفاده می‌شوند.
• Socket – Socket نقطه پایانی برای ارسال یا دریافت داده در یک شبکه است، این برای داده‌های ارسال شده بین فرآیندهای روی یک رایانه یا داده‌های ارسال شده بین رایانه‌های مختلف در یک شبکه نیز صدق می‌کند. اکثر سیستم عامل‌ها از Socketها برای Inter-process Communication استفاده می‌کنند.
• File – File یک رکورد داده است که ممکن است بر روی یک دیسک ذخیره شده باشد یا در صورت تقاضا توسط کلاینت از طریق یک File Server به دست آید. چندین فرآیند می‌توانند در صورت نیاز به یک فایل دسترسی داشته باشند. همه سیستم عامل‌ها از File برای ذخیره سازی داده‌ها استفاده می‌کنند.
• Signal - Signalها در Inter-process Communication، کمتر مفید هستند. آنها پیام‌های سیستمی هستند که از یک فرآیند به فرآیند دیگر ارسال می‌شوند. به طور معمول، Signalها برای انتقال داده‌ها استفاده نمی‌شوند، بلکه برای دستورات از راه دور بین فرآیندها استفاده می‌شوند.
• Shared Memory - Shared Memory حافظه‌ای است که می‌توان به طور همزمان توسط چندین فرآیند به آن دسترسی داشت. این کار به گونه‌ای انجام می‌شود که فرآیندها بتوانند با یکدیگر ارتباط برقرار کنند. تمام سیستم‌های POSIX و همچنین سیستم عامل‌های ویندوز از Shared Memory استفاده می کنند.
• Message Queue – Multiple Processها می‌توانند داده‌ها را بدون اتصال به یکدیگر در Message Queue بخوانند و بنویسند. پیام‌ها تا زمانی که گیرنده آن‌ها را بازیابی کند، در صف ذخیره می‌شوند. Message Queueها برای Inter-process Communication کاملاً مفید هستند و توسط اکثر سیستم عامل‌ها استفاده می‌شوند.

در زیر دیاگرامی را برای شما آورده‌ایم که Message Queue و متد‌های Shared Memory در  Inter-process Communication را نشان می دهد:

گاهی نیاز است تست نویسی چیست؟ را بدانید و در پروژه های خود به صورت عملی پیاده سازی کنید.