در یک معماری میکروسرویس هر کاربر احتمالا با بیش از یک سرویس فرانت اند در ارتباط است. با در نظر گرفتن این موضوع، بخش فرانت چطور با سرویس مورد نظر خود ارتباط برقرار می کند؟ اگر سرویس های جدید معرفی شوند و یا سرویس های کنونی تغییر کنند چه اتفاقی خواهد افتاد؟ یک کامپوننت API Gateway به ما کمک می کند تا به راحتی چالش‌های فوق را مدیریت کنیم.
یک API Gateway کامپوننتی است که بین بخش فرانت و سرویس های برنامه مستقر می شود و به عنوان یک VPN معکوس عمل کرده و درخواست ها را از بخش فرانت به سرویس ها روت میکند. همچنین می تواند کار های دیگری از قبیل احراز هویت، SSL Termination و محدود کرد تعداد پاسخدهی را انجام دهد. اگر از این کامپوننت برای مدیریت درخواست های کاربر استفاده نشود، کاربر مجبور است تا مستقیما با سرویس های سمت فرانت در ارتباط باشد و یک به یک به این سرویس ها درخواست ارسال کند. در حالی که آشکار شدن سرویس ها برای بخش فرانت می تواند مشکلاتی را در بر داشته باشد که به شرح زیر است:
یک Gateway با کاهش میزان وابستگی بین کلاینت و سرویس ها به حل این مشکلات کمک می کند. یک Gateway می تواند کار های بسیار متفاوتی انجام دهد که نیاز به دونستن همه ی آنها نیست. این توابع به الگو های طراحی زیر دسته بندی می شوند.
Gateway Routing :
از Gateway به عنوان یک پراکسی معکوس استفاده می کند تا درخواست ها را به یک یا چند سرویس بک اند مربوط کند. در این مسیریابی از مدل 7 لایه استفاده خواهد کرد. Gateway فقط یک اندپویت برای کلاینت ها به وجود می آورد تا بتواند وابستگی را بین کلایت و سرویس ها از بین ببرد.
Gateway Aggregation :
از Gateway برای تجمیع کردن چند درخواست به یک درخواست در این طراحی استفاده می شود. این الگو زمانی اعمال می شود که یک عملیات به چند سرویس بک اند درخواست می دهد. کلاینت یک درخواست را به سرور ارسال می کند و Gateway درخواست را تقسیم کرده و به سرویس های مورد نظر ارسال می کند. سپس پس از گرفتن نتیجه از سرویس ها آن ها را تجمیع کرده و به عنوان یک جواب به کلاینت ارسال می کند. این باعث از بین رفتن مشکل رفت و برگشت میان کلاینت و سرویس ها خواهد شد.
Gateway Offloading :
از Gateway استفاده می کند تا رویه های Offload را از سرویس ها برداشته و روی Gateway قرار دهد. این تجمیع رویه ها بر روی یک فضا بسیار کاربردی است زیرا از تکرار جلوگیری می کند و دیگر هر سرویس به طور جداگانه مسئول پیاده سازی این رویه ها نیست. این امر برای ویژگی هایی مانند احراز هویت که پیاده سازی نسبتا دشواری دارد خیلی اهمیت بالاتری دارد.
در زیر چند مثال از کاربری ای که می تواند به یک Gateway آفلود شود، آمده است:
Reverse Proxy Server:
دو برنامه ی پر کاربرد در سرور های پراکسی معکوس Nginx و HAProxy می باشند. این دو برنامه از ویژگی های مختلفی مانند load balancing, SSL و مسیریابی لایه 7 پشتیبانی میکنند. هر دوی این برنامه ها رایگان و متن باز هستند که با خرید اشتراک می توان از ویژگی های غنی تر و پشتیبانی آنها نیز استفاده کرد.NGINX و HAProxy هر دو برنامه های به بلوغ رسیده با ویژگی های متفاوت و کارایی بالایی هستند. میتوان آن ها را با افزونه هایی از سازنده های دیگر که به زبان Lua نوشته شده اند گسترش داد. NGINX همچنین کد نویسی تحت جاوا را با عنوان NGINX JavaScript پشتیبانی می کند.
Service mesh ingress controller:
اگر در سیستم مورد نظر از سرویس هایی مانند linkerd یا Istio استفاده می شود، از ویژگی هایی که توسط ingress controller برای چنین سرویس هایی فراهم شده میتوان استفاده کرد. به طور مثال Istio ingress controller از مسیریابی لایه 7، Http redirects، تلاش دوباره و ویژگی های دیگر استفاده می کند.
در این فصل به توضیح کوتاهی درباره ی دو ابزار متن باز NGINX و HAProxy برای پراکسی معکوس در API Gateway می پردازیم.
ابزار NGINX یک وب سرور و سرویسی متن باز می باشد که می تواند همچنین به عنوان یک پراکسی معکوس نیز مورد استفاده قرار بگیرد و این ابزار در سال 2004 منتشر شده است. این ابزار می تواند با مدیریت درخواست ها به سرویس ها عمل به عنوان یک پراکسی معکوس باعث افزایش کارایی سیستم شود. در سال 2011 نیز توسط یک تیم، NGINX Plus معرفی شد که با خرید اشترک می توان از سرویس های بیشتر و قدرتمند تری نیز برای NGINX استفاده کرد.
این ابزار اجازه ی نسبت دادن یک پردازه به یک کانکشن را نمی دهد، اما یک استخری از پردازه ها به وجود می آورد که میتواند درون شبکه میان کانشکن های متفاوت به اشتراک گذاشته شود. هر زمان که یک درخواست به وجود می آید، یک منبع برای انجام پردازه مورد نظرا تخصیص داده می شود. این روش باعث بهتر شدن بهروری در تخصیص منابع شده که میتوند کانکشن های پیچیده را مدیریت کند.
مزایا
معایب
Single entry point:
درون محیطی که از کانتینر ها تشکیل شده است، میتوان آن ها را هر زمان که مورد نیاز است ساخت و یا نابود کرد. اما داشتن single entry point رویکردی بهتر برای دستری به سرویس ها می باشد. NGINX رویکرد بهتری برای انجام به وسیله ی این رویکرد می باشد. میتوان از NGINX در سرور ها به میزان نیاز استفاده کرد که میزان ترافیک و لود سرور را با یک آی پی پایدار مسیریابی کرد. سرور NGINX درخواست کاربر را سپس از کاربر گرفته و به کانتینر مورد نظر ارسال می کند.
Caching:
سرور NGINX یک کش برای محتوای استاتیک و پویا فراهم می کند که کارایی را افزایش می دهد. مسیریابی هر درخواست به میکروسرویس مربوطه هزینه بر می باشد. که میتوان با اضافه کردن کش برای هر میکروسرویس داده های مورد نظر را برای مدت محدودی ذخیره کرد و میزان بار روی سخت افزار بک اند را کاهش داد. این امر باعث می شود از اپلیکیشن ها در زمان ترافیک بالا محافظت شود و به درستی کار خود را بدون مخاطره انجام دهند.
Multiple backend apps:
خوشه ی NGINX کمک می کند که ترافیک را برای اپلیکیشن های مختلف به صورت کارا مدیریت کنیم در نتیجه بسیاری از ارائه دهنده های ابری آن را ترجیح میدهند. سرور NGINX برای پراکسی کردن ترافیک ورودی هر اندپوینت HTTP می باشد که هر کدام از درخواست ها را به سرویس مربوطه وصل می کند. همچنین این امکان را به وجود می آورد که قوانین را بدون هیچگونه downtime تغییر دهیم و NGINX را برای اپلیکیشن های پیچیده نیز مورد استفاده قرار دهیم.
A/B testing:
سرور NGINX یک ویژگی A/B تستینگ درون خود دارد که به به روز رسانه اپلیکیشن های مایکرو سرویس کمک خواهد کرد. هر زمان که یک اپلیکیشن مایکروسرویس در برنامه شما منتشر شود، می توان ترافیک را میان مقصد های متفاوت تقسیم کرد و مسیریابی بسیاری از کاربران را به این اپلیکیشن جدید انجام داد. این ویژگی امکان مانیتور کردن ترافیک و اندازه گیری KPI های مختلف را برای بررسی ورژن های متفاوت برنامه فراهم می کند که ببینیم کدام یک عملکرد بهتری داشت اند.
Consolidated logging:
سرور NGINX با یک فرمت استاندارد لاگ HTTP موجود است. این ویژگی امکان این را فراهم می کند که تمام ترافیک روی فرانت اند NGINX ذخیره شود به جای آن که لاگ های متفاوتی برای هر میکروسرویس داشته باشیم و آن ها را بعدا به هم اضافه کنیم. در نتیجه استفاده از NGINX باعث کم کردن پیچیدگی درست کردن و مدیریت لاگ ها می شود.
Scalability and fault tolerance:
ویژگی های توازن بار، بررسی سلامت سیستم موجود در NGINX اجازه میدهد تا مقیاس سخت افزار سمت سرور را زیاد و کم کنیم که اضافه کردن و حذف کردن میکروسرویس ها تاثیری بر تجربه ی کاربر نداشته باشد. اگر نیاز باشد تا میکروسرویس های بیشتری به سیستم اضافه شوند فقط لازم است به NGINX اطلاع داده شود که یک ویژگی جدید به استخر توازن بار اضافه شده است. که در صورت خرابی این نمونه NGINX ترافیک را به سمت این نسخه هدایت نکند و تا رفع اشکال از استفاده ی آن جلوگیری شود.
Zero downtime:
سرویس NGINX کار بدون اختلال نرم افزار را تضمین می کند. به صورتی که می توان سیستم را به روز رسانی کرد و یا ارتقا داد بدون این که خللی در اجرای برنامه و تجربه ی کاربر به وجود بیاید و یا زمان downtime داشته باشیم.
Mitigate DoS attacks:
این سرویس به مدیریت تعداد بالای درخواست های زیاد ترافیکی HTTP شناخته شده است که ایمنی اپلیکشن را در زمان ترافیک بالا تضمین کند و همچنین درخواست ها را به درستی ارسال کند. NGINX به عنوان یک نوسان گیر برای برنامه عمل میکند و ترافیک را کنترل کرده و API ها و URL های آسیب پذیر را از درخواست های بیش از حد محافظت می کند. این امر میتواند توسط یک محدودیت همزمانی و صف کردن درخواست ها میسر شود که از فشار روی سرور جلوگیری میکند.
این ابزار بسیار شبیه به ابزار NGINX می باشد و به مدیریت درخواست های سرور اپلیکیشن برنامه می پردازد و ویژگی های کارامدی برای کنترل آن ها فراهم می کند.
در این بخش به معرفی شرکت های ایرانی در ارائه خدمات مدیریت API میپردازیم.
1- شرکت Vasl : سرویس مدیریت API سورنا
این شرکت ارائه دهنده سرویس های مدیریتی فروشگاه ها و شرکت ها و ارائه دهنده سرویس های مدیریتی API می باشد. با ارائه سرویس هایی مانند مانیتورینگ، امنیت و مدیریت درخواست های اپلیکیشن ها را فراهم می کند و باعث افزایش کیفیت و کارایی سایت میشود.
2-شرکت دانش بنیان پلتکو: پلفورم مدیریت API
این شرکت با ارائه پلفورمی یکپارچه برای خدمات اپلیکیشن های میکروسرویس باعث افزایش کنترل و عملکرد این سرویس ها میشود.
این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است
سایت پلتکو
سایت وصل
wikipedia
docs.microsoft
medium
youtube
