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

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

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

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

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

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

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

اینجانب قصد دارم که طی چندین مقاله در جلسات مختلف به ادامه این بحث و تاریخچه و  پیدایش 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) را دقیق‌تر و قابل مدیریت‌تر کند.

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

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

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

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

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

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

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

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

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

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

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

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

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

1. مقیاس پذیری:
   فرآیندهای فردی در معماری میکروسرویس ها می توانند برای برآورده کردن خواسته های خود مقیاس پذیر شوند. برنامه های کوچک‌تر می توانند هم به صورت افقی(horizontally) (با افزودن نمونه های بیشتر) و هم به صورت عمودی(vertically) (با افزایش منابع موجود برای هر نمونه) مقیاس پذیر شوند.
    
2. سازمان‌دهی بهتر:
   معماری میکروسرویس‌ها معمولا بهتر دسته‌بندی و سازمان‌دهی می‌شوند. این بدان دلیل است که هر microservice یک کار منحصر به فرد را انجام می‌دهد و کاری به دیگر اجزا ندارد.
    
3. ماژولار بودن(Modularity):
   مزیت آشکار داشتن برنامه های کوچک‌تر و مستقل این است که جدایی فیزیکی بین فرآیندها، شما را مجبور می‌کند تا به اتصال آن‌ها در ForeFront طراحی خود بپردازید. هر برنامه‌ مسئول انجام مسئولیت‌های کوچکی است که منجر به ایجاد کد فشرده‌تر و منسجم‌تر می‌شود.
    
4. جداسازی شده:
   سرویس‌های از هم جداشده برای برآورده کردن نیازهای مربوط به اپلیکیشن‌های دیگر قابلیت تغییر و پیکربندی مجدد ساده‌تری را ارائه می‌دهند. آن‌ها همچنین در یک سیستم یکپارچه بزرگ‌تر قابلیت تحویل قسمت‌های منحصر به فرد را به صورت سریع‌تری ارائه می‌دهند. 
    
5. تنوع فناوری به کار رفته در طراحی(Tech diversity):
   برنامه‌های کاربردی میکروسرویس واحدهای مستقلی هستند که از طریق استانداردهای باز ارتباط برقرار می‌کنند. این بدان معنی است که انتخاب‌ فناوری‌ها در پشت پرده پیاده‌سازی آنها در مقایسه با سیستم‌های یکپارچه یا مونولیت بسیار کمتر اهمیت دارند. یعنی انتخاب‌ها برای microservice مورد نظر، اهمیت دارند، اما به بقیه سیستم مربوط نمی‌شوند. یک معماری به صورت منفرد ممکن است که با ترکیبی از فناوری‌ها اجرا شده باشد. به عنوان مثال در یک معماری احتمال دارد که از جاوا و Go برای منطق تجاری استفاده شود، از Node.js برای API و از پایتون برای تجزیه و تحلیل.
    
6. فرصت هایی برای آزمایش:
   یک میکروسرویس مستقل است و ممکن است جدا از سایر بخش‌ها طراحی و توسعه یابد که پایگاه داده آن به طور مجزا باشد و می‌توان آن را به زبانی ساخت که برای هدفش مناسب است. این خودمختاری به تیم اجازه می‌دهد تا با خیال راحت فناوری‌ها، رویکردها و فرآیندهای جدید را آزمایش کند و در صورت شکست یکی از آزمایش‌ها، هزینه‌های آن نسبتا کاهش پیدا کند.
    
7. مهاجرت آسان به سایر تکنولوژی‌ها:
   اکثر ما روی سیستم‌های نرم‌افزاری یکپارچه بزرگی کار کرده‌ایم که بر اساس فناوری ساخته شده‌اند که قدمت دو دهه‌ای دارند و به‌روزرسانی آن بسیار دشوار و پرخطر است. من شخصاً به یاد می‌آورم که در سال 2018 روی پروژه‌ای کار می‌کردم که در آن تیم در هندل کردن پروژه با جاوای نسخه 6 گیر کرده بود - به دلیل وابستگی‌های پیچیده کتابخانه، فقدان تست‌های واحد مناسب و خطر مهاجرت به نسخه‌های بالاتر ناشی از آن، متوقف شد. این داستان به ندرت در مورد میکروسرویس‌ها رخ می‌دهد.
    
8. انعطاف پذیری و در دسترس بودن:
   وقتی یکپارچگی یک سیستم پایین بیاید، کسب و کار متوقف می شود. البته، همین امر را می‌توان در مورد میکروسرویس‌های با طراحی ضعیف و قوی جفت شده با وابستگی‌های متقابل پیچیده نیز گفت. با این حال، معماری microservice های خوب بر اتصالات سست تأکید می‌کند، جایی که سرویس‌ها مستقل هستند، کاملاً وابستگی‌های خود را دارند و ارتباطات همزمان (مسدودکننده) را به حداقل می‌رسانند. هنگامی که یک میکروسرویس از کار می‌افتد، همواره بر بخشی از سیستم تأثیر می‌گذارد و کاربران خاصی را تحت تأثیر قرار می‌دهد، اما معمولاً سایر بخش‌های سیستم بدون مشکل کار می‌کنند.

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

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

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

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

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

اکثر 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 انجام می دهد متفاوت از سایر بخش‌ها است. برخی از عملکردهای رایج آن عبارتند از احراز هویت(authentication)، مسیریابی(routing)، محدود کردن نرخ(rate limiting)، صورتحساب(billing)، نظارت(monitoring)، تجزیه و تحلیل(analytics)، خط‌مشی‌ها(policies)، هشدارها(alerts) و امنیت(security).

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

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

علاوه بر این، 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 شناخته می‌شود، زیرا این فرآیند با وجود فعال بودن، هیچ عملیات مفیدی را انجام نمی‌دهد.

رویکردهای 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 را نشان می دهد:

میکروسرویس در لاراول

لاراول یک چارچوب خوب برای ساخت میکروسرویس های مقیاس پذیر است. و اجازه می دهد برنامه ها حتی به صورت مستقل توسعه پیدا کنند. در ذیل یک پکیج خوب برای توسعه این مبحث در لاراول می بینید:

https://github.com/erayaydin/microservice-laravel