میکروسرویس از طراحی تا پیاده سازی قسمت اول

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

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

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

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

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

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

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

• 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) که شامل صدها هزار خط کد هستند بسیار کوچک و ناچیز است.

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

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

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

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

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

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

اکثر 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 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 نیز افزایش می‌یابد.