اگر با مفهوم API آشنا باشید، می‌دانید که در یک نرم‌افزار یا کلاینت برای ارتباط با سرور معمولاً از API برای برقراری ارتباط استفاده می‌شود. در یک نرم‌افزار با تغییراتی که طی مدت توسعه در آن رخ می‌دهد، به مرور تعداد API ها افزایش می‌یابد و اگر این نرم‌افزار در سطح یک سازمان باشد چه بسا که این API های زیاد، باعث پیچیدگی‌های سنگین یا ناهماهنگی بین API های مختلف برنامه شود. حتی ممکن است یکی از API ها دارای مشکل شود و این مورد به API های دیگر نیز آسیب برساند. در این جاست که استفاده از مفهومی به نام API Gateway اهمیت پیدا می‌کند.
گذرگاه API یا همان API Gateway یک ابزار مدیریت API است که بین کلاینت و سرویس‌های سرور یا backend قرار می‌گیرد. در واقع تمام ریکوئست‌های کلاینت به API Gateway فرستاده می‌شود و سپس این API Gateway است که تصمیم می‌گیرد این درخواست را به کدام سرویس از backend برساند. هم‌چنین این سرویس‌ها در صورت استفاده از معماری میکروسرویس ممکن است یک میکروسرویس در سامانه نرم‌افزاری باشد. معمولاً API Gateway در معماری میکروسرویس استفاده می‌شود.
هر وقت پاسخ آن سرویس آماده شود، API Gateway از سرویس مورد نظر پاسخ را دریافت می‌کند و به کلاینت می‌دهد. در تصویر ۱ شمایی از یک API Gateway را می‌بینید که با سرویس‌های مختلف backend در ارتباط است که البته خود این سرویس‌ها ممکن است با دیتابیس یا بخش‌های دیگر در ارتباط باشند. در واقع وقتی API Gateway داشته باشیم، هر دیوایسی که در سمت کلاینت باشد برای ارتباط با هر یک از سرویس‌های سرور باید از درِ API Gateway عبور کند و آن را استفاده کند نه اینکه برای هر سرویس API به طور جدا ارتباط برقرار کند. البته همیشه API Gateway به صورت یکتا نیست و ممکن است چند API Gateway داشته باشیم که البته معایب و مزایایی خواهد داشت که اکنون به بررسی آن‌ها نمی‌پردازیم.
در معماری میکروسرویس، API Gateway ها ریکوئست‌ها را از هر کلاینت دریافت می‌کنند و سپس آن را به سمت میکروسرویس مورد نظر می‌فرستند. در این بین باید به صورت مناسب مسیریابی کرده و در صورتی که چند سرویس برای ارائه آن خدمت موجود بود بهترین را انتخاب کند و نتیجه را به سمت کلاینت بفرستند.
بسیاری از شرکت‌ها مشکل مدیریت API دارند و هم‌چنین در کسب و کار خود نمی‌توانند یک دروازه برای API طراحی کنند تا توسعه دهندگان آن شرکت بتوانند به آسانی و بدون سر و کار داشتن با پیچیدگی‌های هر میکروسرویس به کار با سیستم بپردازند. هم‌چنین ممکن است در میکروسرویس‌های مختلف یک معماری نرم‌افزار، پروتکل‌های مختلفی مانند Http یا gPRC استفاده شود که در هر کدام از آن میکروسرویس‌ها به خوبی عمل کند اما وقتی کار به تجمیع و ارتباط این زیرسیستم‌ها با هم می‌رسد، مشکل آغاز می‌شود. با استفاده از API Gateway این مشکل نیز تا حد خوبی برطرف می‌شود چون توسعه دهنده با API Gateway سر و کار خواهد داشت و لازم نیست هر بار بین پروتکل‌ها و میکروسرویس‌های مختلف سوییچ کند.
در واقع وظیفه یک API Gateway این است که درخواست‌ها را در معماری‌ای مانند معماری میکروسرویس سازماندهی کند و یک تجربه مناسب برای تیم توسعه بسازد. API Gateway مانند یک مترجم عمل می‌کند که هر نوع ریکوئستی را گرفته و می‌تواند آن‌ها را حتی ترکیب کنند و به سمت هر یک از میکروسرویس‌ها بفرستد. با این عمل هم پیاده‌سازی در قسمت کلاینت به علت اینکه صرفاً با این دروازه برای API سروکار دارد، آسان‌تر می‌شود و پیچیدگی‌های کمتری خواهد داشت و هم میکروسرویس‌های مختلف نگران کار و هماهنگی و تطابق با انواع اپلیکیشن‌ها و نحوه استفاده آن‌ها از API نخواهند بود چون با وجود API Gateway می‌دانند که باید صرفاً با آن هماهنگ باشند و خود API Gateway به درخواست‌های کلاینت‌های مختلف رسیدگی خواهد کرد.
ممکن است از خود پرسیده باشید چرا باید یک پیچیدگی به معماری نرم‌افزار خود اضافه کنیم و API Gateway را بین کلاینت و سرویس‌های backend قرار دهیم.
مفهوم وجود API Gateway به تیم توسعه نرم‌افزار کمک می‌کند که API های مختلف را بدون نگرانی زیاد بسازند و بسیار آسان‌تر نگهداری کنند چرا که API Gateway به عنوان یک واسط بین کلاینت و تمام سرویس‌های backend قرار خواهد گرفت و تیم توسعه می‌دانند که تمام درخواست‌هایی که از سمت کلاینت فرستاده می‌شود حتماً از آن عبور خواهد کرد. واضح است که مدیریت API Gateway به عنوان یک واسط بسیار آسان‌تر از مدیریت API های متعدد خواهد بود. هم‌چنین استفاده از API Gateway جهت مدیریت ترافیک، مدیریت دسترسی کلاینت‌ها، مدیریت امنیت سرویس‌های backend و هم‌چنین مشاهده و مدیریت لاگ و مانیتورینگ ریکوئست‌های ارسال شده نیز بسیار مفید خواهد بود. به طور کلی مزایای API Gateway را در چند مورد زیر میتوان خلاصه کرد:
بله! همان‌طور که در مورد مزایا گفتیم، معایب و مشکلات API Gateway را نیز باید بدانیم. با یک مثال به بررسی معایب آن می‌پردازیم. ابتدا به تصویر ۲ نگاه کنید.
همان‌طور که دیدید، در backend سیستم نرم‌افزاری حداقل از لحاظ تعداد واحدهای برنامه به پیچیدگی‌های آن اضافه کرده‌ایم چرا که یک واحد به نام API Gateway اضافه شده است. این مشکل زمانی بیشتر مشخص می‌شود که سرویس‌های زیادی نداشته باشیم و از معماری میکروسرویس نیز استفاده نکرده باشیم. در این مواقع شاید استفاده از API Gateway بیشتر به پیچیدگی بیفزاید نه آن که کار را ساده‌تر کند و پیچیدگی را کمتر!
فرض کنید روزی این API Gateway دچار خرابی شود. احتمالاً می‌توانید تصور کنید چه مصیبتی به بار خواهد آورد چون تقریباً تمام کلاینت‌ها و اپلیکیشن‌ها پاسخ درستی دریافت نخواهند کرد. در واقع با استفاده از یک API Gateway یک نقطه شکست (single point of failure) ایجاد کرده‌ایم که اگر به هر دلیلی دارای مشکل شود، روی کل سیستم تاثیر منفی خواهد گذاشت.
هم‌چنین از معایب دیگر میتوان به کاهش سرعت پاسخگویی از سمت API اشاره کرد. گفتیم که همه ریکوئست‌ها قرار است از API Gateway رد شوند پس به ازای هر ریکوئستی که می‌آید باید یکبار به API Gateway فرستاده شود و خود API Gateway به سرویس API مورد نظر ریکوئست را بفرستد. سپس جواب را از آن API بگیرد و در نهایت پاسخ را برای کلاینتی که ریکوئست را ارسال کرده بفرستد. همان‌طور که دیدید به جای کار مستقیم با API ها، با API Gateway کار کردن احتمالاً میزان سرعت پاسخگویی را کم می‌کند. البته این مشکل را با استفاده از cache در API Gateway میتوان تا حدودی برطرف کرد.
به طور کلی معایب API Gateway را میتوان در چند مورد زیر خلاصه کرد:
در این بخش به معرفی دو نمونه از ابزارهای مرتبط با API Gateway می‌پردازیم.
ابزار Kong Gateway یکی از محبوب‌ترین ابزارهای متن‌باز ابری API Gateway است. این ابزار مبتنی بر پروکسی کار می‌کند و با زبان Lua و با استفاده از Nginx این سرویس راه اندازی شده است. به گفته خود توسعه دهندگان این ابزار در سایت آن، این ابزار برای کار با میکروسرویس‌ها و معماری‌های توزیع شده بهینه شده است. هم‌چنین در این ابزار میتوان با استفاده از راهنمای آن، پلاگین‌های مختلف جهت افزایش امکانات آن توسعه داد و به آن اضافه کرد. این ابزار رایگان و متن باز است که البته نسخه پولی آن نیز وجود دارد.
ابزار Tyk یک API Gateway متن‌باز و سبک‌وزن است که با زبان go توسعه داده شده است. این ابزار به صورت ابری می‌تواند کار کند و performance بالایی دارد. Tyk به دیتابیس redis نیاز دارد. این ابزار امکانات متعددی مثل امکان محدود کردن تعداد ریکوئست‌ها (rate limiting)، لاگ، مانیتورینگ و آنالیز درخواست‌ها، بررسی event ها، امکان استفاده از mock api قبل از release اصلی و موارد دیگری را در بر دارد. این ابزار به طور کامل متن باز است.
در این بخش به معرفی دو شرکت ارائه دهنده API Gateway در ایران می‌پردازیم.
این شرکت به کسب و کارهایی که قصد دارند به سمت معماری میکروسرویس حرکت کنند، زیرساخت‌هایی برای عرضه و مدیریت API به صورت یکپارچه می‌دهد. طبق گفته این شرکت، API Gateway های عرضه شده توسط آن به بیش از ۹ میلیارد درخواست از سازمان‌ها و کسب‌وکارهای مختلف پاسخ داده است. هم‌چنین این شرکت کمک می‌کند که معماری و زیرساخت کسب‌وکارهای مورد بازنگری و بازطراحی قرار بگیرد تا استفاده از سرویس‌های این شرکت با کمترین مشکل انجام شود. هم‌چنین این شرکت از سرویس‌هایی که ارائه می‌دهد به صورت کامل پشتیبانی می‌کند و به گفته خود در مقیاس ۳۷ میلیون کاربر سرویس‌دهی داشته است.
این شرکت با ابزار مدیریت API Gateway ای که دارد، به توسعه دهندگان اجازه می‌دهد که برنامه‌هایی هماهنگ با سامانه‌های داخلی سازمان طراحی نمایند. این پلتفرم برای مدیریت API ها، مواردی مانند تجزیه و تحلیل داده‌ها، کنترل دسترسی‌ها و محافظت از اطلاعات حساس را ارائه می‌دهد. هم‌چنین یکی دیگر از مزایای این شرکت، ایجاد یک راه حل برای مدیریت اکوسیستم‌ها و API های مبتنی بر اینترنت اشیا (IoT) است و تمامی خدمات برای حوزه اینترنت اشیا در API Gateway را نیز دربردارد. یکی دیگر از مواردی که این شرکت تضمین می‌کند، امکان هماهنگی پنل‌های مدیریت API Gateway با استفاده از دستگاه‌های مختلف است که با استفاده از هشدارها، گزارش‌ها و آمارها و ایجاد یک پنل پیشرفته، مدیریت API ها را برای کسب و کارها آسان‌تر می‌کند.
این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.
