API Gateway

مقدمه

ابتدا می‌خواهیم API Gateway را به زبان ساده شرح دهیم. API Gateway یکی از ابزارهای API Management است که بین کلاینت و مجموعه‌ای از سرویس‌ها‌ی back-end می‌نشیند. API Gateway جلوی API می‌نشیند و تنها راه ورودی APIهای back-end و میکروسرویس‌ها می‌باشد. API Gateway با نشستن در جلوی API مانند یک محافظ تامین‌کننده‌ی امنیت، مقیاس‌پذیری و در دسترس‌پذیری عمل می‌کند. به عبارتی API Gateway مانند یک پروکسی معکوس عمل می‌کند، به این‌صورت که تمام سرویس‌های لازم برای API های فراخوانی شده را تجمیع کرده و در قالب یک نتیجه‌ی مناسب به کاربر بر می‌گرداند.

نقش یک API Gateway در API Management

یک API Gateway جزئی از API Management است. API Gateway تمام درخواست‌ها را یکی کرده و به سیستم API Management‌ می‌دهد. این‌که API Gateway چه کار می‌کند به پیاده‌سازی آن بستگی دارد. به طور کلی کارهایی مانند اعتبارسنجی (Authentication)، پایش (Monitoring)، تحلیل و کارهای دیگر انجام می‌دهد. [1]

تعریف API Gateway در قالب یک مثال

اگر هنوز متوجه نشده‌اید که API Gateway دقیقا چه کار می‌کند، این مثال را دنبال کنید. فرض کنید می‌خواهیم یک فروشگاه اینترنتی مانند آمازون راه‌اندازی کنیم و در حال طراحی صفحه‌ی مشاهده‌ی جزئیات یک محصول می‌باشیم. اول از همه باید دو نسخه از رابط کاربری این صفحه داشته باشیم. یکی برای کاربران web-application و دیگری برای کاربران اندروید و آیفون. علاوه بر این مورد، در این صفحه اطلاعات زیادی را می‌توانیم به نمایش بگذاریم. برای مثال فرض کنید این محصول یک کتاب است. اطلاعاتی که می‌توانیم در صفحه‌ی مشاهده‌ی اطلاعات یک کتاب مشاهده کنیم، مواردی مانند اطلاعات پایه‌ای کتاب مانند عنوان، نویسنده، قیمت و غیره، در دسترس بودن یا نبودنش، گزینه‌های خرید، کتاب‌های مشابه، کتاب‌هایی که خریداران این کتاب خریده‌اند، نظرات و دیدگاه‌ها و موارد دیگر.

اگر فرض کنیم این فروشگاه از الگوی معماری میکروسرویس استفاده می‌کند، آن‌گاه این اطلاعات در سرویس‌های مختلفی پخش شده‌اند. برای مثال سرویس Product Info که اطلاعات پایه‌ای کتاب مانند عنوان، نویسنده، قیمت و غیره را ارائه می‌دهد.

در حال حاضر می‌دانیم که کاربران با یک فراخوانی REST برای مثال GET api.company.com/productdetails/productId به این صفحه و تمام اطلاعات آن دسترسی دارند.

مساله

چگونه کاربران به این سرویس‌ها دسترسی داشته باشند؟

نکاتی که باید مورد توجه قرار گیرند

• همان‌طور که در مثال شرح داده شد، کلاینت برای مشاهده‌ی اطلاعات یک محصول نیاز به فراخوانی چندین سرویس دارد. به همین دلیل ریزدانگی API‌ و نیاز کلاینت هم‌خوانی ندارد. کلاینت نباید مجبور شود که برای یک نیاز خود چندین سرویس را خود فراخوانی کند.
• کلاینت‌های مختلف اطلاعات مختلفی می‌خواهند. کاربرانی که از یک مرورگر اطلاعات را مشاهده می‌کنند با کاربرانی که از یک تلفن همراه وصل شده‌اند، متفاوتند.
• عملکرد شبکه برای کاربران مختلف با انواع مختلف شبکه متفاوت است.
• ممکن است سرویس‌ها در طول زمان تغییر کنند و این باید از دید کلاینت‌ها مخفی بماند.
• ممکن است سرویس‌ها از پروتکل‌های مختلفی استفاده کنند که همگی سازگاری لازم را نداشته باشند. [4]

دو راه‌حل برای این مساله ارائه می‌دهیم و به بررسی هر دو می‌پردازیم.

راه‌حل اول: فراخوانی تمام سرویس‌ها توسط کاربر

فرض کنیم در راه‌حل اول کاربر می‌تواند هر کدام از سرویس‌های میکروسرویس‌ها را مستقیما فراخوانی کند. کاربر برای مشاهده‌ی صفحه‌ی اطلاعات یک کتاب همه‌ی سرویس‌ها را از میکروسرویس مربوطه با url‌ مربوطه فراخوانی می‌کند. هر url هم به load balancer میکروسرویس نگاشت می‌شوند که این بالانسر درخواست‌ها را بین نمونه‌های در دسترس توزیع می‌کند.

متاسفانه این راه‌حل چالش‌ها و محدودیت‌های زیادی دارد. نکته‌ی اول که در قسمت قبلی ذکر شد و باید مورد توجه قرار گیرد نقض شده است. یعنی کاربر برای مشاهده‌ی یک محصول لازم است تا چندین سرویس را خود فراخوانی کند. در این مثال خاص کاربر باید ۷ سرویس را فراخوانی کند. در برنامه‌های پیچیده‌تر لازم است تا سرویس‌های بسیار بیشتری را فراخوانی کند. نکته‌ی سوم از قسمت قبلی هم نقض می‌شود. شاید این راه‌حل با در نظر نگرفتن مشکل قبلی برای کابرانی که از طریق LAN به اینترنت متصل شده‌اند مناسب باشد ولی برای کاربرانی که از طریق اینترنت همراه متصل شده‌اند عملا غیرقابل پیاده‌سازی خواهد بود. از طرفی این رویکرد کد سمت کاربر را بسیار پیچیده‌تر خواهد کرد.

مساله‌ی بعدی مشکل‌تر شدن ریفکتور کردن سرویس‌ها می‌باشد. اگر بعد از مدتی تصمیم به تغییر سرویس‌ها گرفتیم به دلیل درگیری مستقیم کاربر با سرویس‌ها این کار بسیار دشوار خواهد بود. این مشکل ناقض نکته‌ی چهارم در قسمت قبلی است.

به دلیل این مشکلات و محدودیت‌ها، این راه‌حل به نظر منطقی نیست.[4]

راه‌حل دوم: API Gateway

راه‌حل دوم پیاده‌سازی یک API Gateway است که یک نقطه‌ی ورود برای همه‌ی کلاینت‌ها می‌باشد. این راه‌حل معماری داخلی را از دید کاربر مخفی می‌کند. همان‌طور که قبلا گفتیم، API Gateway تمام درخواست‌های کلاینت را تجمیع کرده و یک نتیجه برای مثال یک صفحه‌ی مشاهده‌ی اطلاعات یک محصول را برمی‌گرداند. API Gateway‌ علاوه‌بر هدایت درخواست‌ها، ترجمه‌ی پروتکل‌ها می‌تواند مسئولیت‌های دیگری مانند اعتبارسنجی، پایش، load balancing، ذخیره در حافظه‌ی نهان و غیره داشته باشد.

به جای این‌که یک API مناسب برای همه‌ی کاربران بنویسیم، API Gateway می‌تواند APIهای موردنیاز، متناسب و خاص هر کاربر را ارائه دهد.

تمام درخواست‌ها ابتدا از API Gateway‌ عبور می‌کنند. سپس API Gateway‌ آن‌ها را به میکروسرویس مربوطه هدایت می‌کند. گاهی API Gateway‌ یک درخواست را به چندین میکروسرویس می‌فرستد و نتایج را تجمیع کرده و برمی‌گرداند.

یک مثال بسیار خوب برای API Gateway‌ ، API Gateway‌ نتفلیکس می‌باشد. سرویس استریم نتفلیکس بر روی دستگاه‌های متنوعی مانند تلویزیون‌ها، تلفن‌همراه‌های هوشمند، سیستم‌های بازی، تبلت‌ها و غیره در دسترس است. در ابتدا نتفلیکس سعی داشت از one-size-fits-all API استفاده کند ولی بعدها متوجه شدند که به دلیل تعداد زیاد دستگاه‌ها و نیازهای یکتای هریک این روش مناسب نیست. نتفلیکس امروزه از API Gateway استفاده می‌کند که API خاص هر دستگاه را فراهم می‌کند. API Gateway‌نتفلیکس روزانه چندین میلیارد درخواست را پاسخ می‌دهد. [4]

مزایا و معایب API Gateway

همان‌طور که می‌دانید استفاده از API GateWay هم مزایا و معایب خود را دارد.

مزایا

• مخفی کردن ساختار درونی برنامه از دید کاربر
• فراهم ساختن API‌ بهینه و متناسب برای هر کاربر
• کاهش تعداد رفت و برگشت‌ها برای هر درخواست کاربر
• کاهش پیچیدگی کد سمت کاربر
• سهولت استفاده از برنامه برای کلاینت با فراخوانی چندین سرویس با استفاده از API Gateway
• افزایش امنیت. هر بار که سرویس‌ها از طریق API Gateway‌ فراخوانی می‌شوند از طریق IPهای خصوصی فراخوانی می‌شوند که این باعث جلوگیری از حملات می‌شود.

معایب

• افزایش پیچیدگی. به هر حال API Gateway‌ باید پیاده‌سازی و اجرا شود.
• افزایش ریسک گلوگاه شدن API Gateway هنگام آپدیت کردن سرویس‌ها
• افزایش زمان پاسخ سرویس‌ها به دلیل عبور از API Gateway البته این زمان برای بسیاری از برنامه‌ها مهم نیست.

چالش‌ها

• چگونگی پیاده‌سازی یک API Gateway

با وجود معایب و چالش‌های API Gateway، این ابزار برای رفع مشکل موجود منطقی به نظر می‌آید.

معرفی ابزارها و فناوریهای متن‌باز

• مورد اول: Kong Gateway
  این API Gateway محبوب‌ترین API Gateway متن‌باز و بر پایه‌ی ابر می‌باشد. با زبان Lua و با استفاده از Nginx‌ نوشته شده است. شرکت‌هایی مانند Cisco، Samsung و غیره از Kong Gateway استفاده می‌کنند. برخی از فیچرهایی که Kong Gateway پیشنهاد می‌کند عبارتند از اعتبارسنجی، کنترل ترافیک، تحلیل، ثبت لاگ و بدون سرور بودن. [5]
• مورد دوم: Apache APISIX
  این API Gateway در آزمایشگاه ZhiLui‌ چین متولد شد و سپس وارد دنیای Apache‌ شد و متن‌باز شد. به گفته‌ی معاون پروژه، Ming Wen، این API Gateway بسیاری از چالش‌های cloud-native و میکروسرویس‌ها را حل می‌کند. Apache APISIX بر پایه‌ی Nginx و etcd می‌باشد. [5]

نمونه‌های API Gateway‌ زیادی وجود دارد که ما فقط به ذکر دو مورد از آن‌ها بسنده کردیم.

معرفی شرکت‌های ایرانی ارائه دهنده‌ی API Gateway

یکی از شرکت‌های ایرانی که API Gateway همراه اول را ارائه داده است، شرکت تجارت ایران گستر رایکا می‌باشد.

این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.

مراجع

[1] https://www.redhat.com/en/topics/api/what-does-an-api-gateway-do

[2] https://www.axway.com/en/products/api-management/gateway

[3] https://microservices.io/patterns/apigateway.html

[4] https://www.nginx.com/blog/building-microservices-using-an-api-gateway/

[5] https://geekflare.com/api-gateway/