در این مقاله با مفهوم API Gateway آشنا شده و مزیت‌ها و معایت آن را بررسی می‌کنیم. همچنین گریزی به معماری مایکروسرویس زده و نقش API Gateway را در این معماری بررسی می‌کنیم. درنهایت به معرفی ابزارهای معروف این حوزه پرداخته و ویژگی‌های هرکدام را برمی‌شماریم.
در گذشته معمولا نرم‌افزارها به صورت monolithic توسعه داده می‌شدند. بدین صورت که ما یک فایل اجرایی برای نرم‌افزار داشتیم که تمامی API ها و endpoint را دارا بود و تمامی درخواست‌ها را پردازش می‌کرد. در چنین نرم‌افزاری هر تغییری نیازمند استقرار دوباره‌ی کل سیستم بود. همچینین تمامی کدهای سیستم به هم وابسته بودند و باهم اجرا می‌شدند. طبیعتا چنین نرم‌افزاری به صورت افقی مقیاس پذیر نیست و برای مقایس پذیری باید سرورها را قوی‌تر کنیم و به آن‌ها منابع اضافه کنیم. همچنین در چنین برنامه‌هایی تیم‌های مختلف نمی‌توانند قسمت‌های مختلف را به صورت مستقل پیش ببرند و همه‌ی قسمت‌های نرم‌افزار به هم couple می‌شود.
به دلایل گفته شده در بالا معماری مایکروسرویس به وجود آمد. در این معماری به جای اینکه یک برنامه‌ی بسیار بزرگ داشته باشیم، برنامه‌های کوچکی داریم که هر کدام وظیفه‌ی مشخصی دارند و به دیگر برنامه‌ها سرویس مشخصی را ارائه می‌دهند. این برنامه‌های اجرایی برای ارتباط با یکدیگر از API های مشخص و قبل تعیین شده استفاده می‌کنند. در این معماری به هرکدام یک از این برنامه‌های اجرایی یک مایکروسرویس گفته می‌شود.
هر مایکروسرویس API و protocol مخصوص به خود را دارد و دیگر مایکروسرویس‌ها از این طریق با این مایکروسرویس ارتباط برقرار می‌کنند. مزیت جداسازی قسمت‌های مختلف نرم‌افزار این است که هر قسمت از نرم‌افزار می‌تواند مستقلا توسعه داده شده و مسقر شود. همچنین برای بروزرسانی یا رفع خطا نیز لازم نیست کل سیستم را دوباره مسقر کنیم بلکه کافی است فقط مایکروسرویس مربوطه را بروزرسانی کنیم.
مزیت دیگر استفاده از معماری مایکروسرویس این است که سیستم به صورت افقی قابل مقایس پذیری می‌شود. هر مایکروسرویس را می‌توان روی سرورهای مجزا اجرا کرد و این مایکروسرویس ها فقط از طریق پروتوکل‌های مشخص شده و API های لازم باهم ارتباط برقرار کنند.
در معماری مایکروسرویس هر مولفه API های خودش را پیاده‌سازی می‌کند و دیگر مولفه‌ها برای گرفتن این اطلاعات باید به مایکروسرویس مشخص شده مراجعه کنند. در اینصورت کلاینت‌های برنامه نیز مجبورند به چندین آدرس و URL درخواست بزنند تا بتوانند عملیات خود را انجام دهند. برای مثال در یک برنامه‌ی نسبتا بزرگ، کلاینت برای نشان دادن یک صفحه ممکن است مجبور شود چند ده درخواست به آدرس‌های مختلف بزند تا تمامی اطلاعات را کسب کند. همچنین ممکن است مایکروسرویس‌های ما از تکنولوژی و پروتکل‌های متفاوتی استفاده کرده باشند. برای مثال کی مایکروسرویس از SOAP و دیگری از REST استفاده کرده باشد. در این صورت کلاینت مجبور است که بتواند با تمامی این پروتکل‌ها ارتباط برقرار کرده و درخواست لازم را به فرمت مورد نیاز خود تبدیل کند.
این امر سربار بسیار زیادی دارد و زمان بارگذاری برنامه را نیز به شدت افزایش می‌دهد. از طرفی اگر بخواهیم API هرکدام از مایکروسرویس‌ها را عوض کنیم یا تغییری در پروتکل آن‌ها بدهیم تمامی مشتریان از این تغییر با خبر شده و مجبوریم نسخه‌های کلایت جدیدی را به بازار عرضه کنیم.
علاوه بر موارد گفته شده در بالا ممکن است بعضی از endpoint های مایکروسرویس‌های ما خصوصی باشند و فقط برای استفاده از داخل کلاستر تعبیه شده باشند که در اینصورت ریسک لو رفتن یا مشخص شدن این API ها نیز زیاد است و خود نیاز به مدیریت دارد.
باتوجه به دلایل بالا لازم است تا مولفه‌ایی جدید به اسم API Gateway را اضافه کنیم تا درخواست‌های ورودی سیستم را مدیریت کرده و هر درخواست را به قسمت لازم بفرستد. API Gateway در واقع نقطه‌ی ورود به سیستم ما است و تمامی درخواست‌های دیگران از طریق این مولفه به کلاستر ما می‌رسد.
با استفاده از API Gateway کلاینت فقط لازم است که درخواست‌های خود را به API Gateway بزند و سپس این مولفه می‌تواند به مایکروسرویس‌های مختلف متصل شده و داده‌های لازم را جمع آوری کند و به سمت کلاینت بفرستد. همچنین کلاینت فقط باید پروتکل API Gateway را بلد باشد و لازم نیست تمامی پروتکل‌های استفاده شده توسط مایکروسرویس‌های مختلف را بلد باشد. با توجه به موارد گفته شده سربار استفاده از مایکروسرویس بسیار کمتر شده و کد کلاینت نیز کمتر و تمیزتر می‌شود.
مولفه‌ی API Gateway کاربردهای دیگری نیز دارد که در زیر به آن اشاره می‌کنیم.
از طریق API Gateway ما به راحتی می‌توانیم تعداد درخواست‌ها و latency هر مایکروسرویس را اندازه‌گیری و مانیتور کنیم. همچنین باتوجه به اینکه به کدام یک از مایکروسرویس‌ها درخواست بیشتری می‌آید می‌توانیم تعداد هر مولفه را کم یا زیاد کنیم.
استفاده از API Gateway باعث می‌شود که مدیریت Cross cutting concerns راحتتر شود. برای مثال کارهایی مثل چک کردن Authentication یا لاگ زدن را می‌توان فقط در API Gateway انجام و بدین صورت هر مایکروسرویس فقط روی بیزینس اصلی خودش تمرکز کند و نیازی به چک کردن لاگین یا لاگ زدن اطلاعات درخواست نداشته باشد.
مزیت دیگر استفاده از API Gateway تغییر پذیری ساده‌تر است. با استفاده از API Gateway ما می‌توانیم قسمت داخلی سیستم را از کاربر مخفی نگه داریم و به راحتی تغییر دهیم. برای مثال می‌توانیم پروتکل تمامی مایکروسرویس‌ها را از SOAP به REST تغییر دهیم ولی API Gateway ما همچنان با پروتکل قبلی با کاربر صحبت کند و بدین صورت تغییرات را از دید کاربر مخفی کنیم.
مزیت دیگر استفاده از API Gateway قابلیت Fault Tolerance است. اگر یکی از مایکروسرویس‌ها در دسترس نباشد، API Gateway می‌تواند پیام مناسبی را به کاربر نشان دهد یا آن بخش از درخواست که به آن مایکروسرویس مربوط است را با پیام مناسب پر کند ولی بقیه اطلاعات را به صورت کامل برگرداند. در این صورت کاربر دریک صفحه تمامی اطلاعاتی که در دسترس است را می‌تواند مشاهده کند و فقط قسمتی که در دسترس نیست از کار می‌افتد.
یکی دیگر از قابلیت‌های بسیار مهم API Gateway امکان Caching می‌باشد. با استفاده از این قابلیت می‌توانیم با توجه به قابلیت‌ها و بیزینس هر مایکروسرویس، درخواست‌های زده شده به یک یا چند مایکروسرویس را کش کرده و از این پس آن درخواست‌ها را به سرعت و بدون نیاز به برقراری ارتباط با مایکروسرویس مربوطه پاسخ دهیم. این قابلیت می‌تواند فشار را بر روی مایکروسرویس‌های مختلف کاهش داده و باعث افزایش سرعت شود.
همانند هر تکنیک دیگری استفاده از مایکروسرویس نیز می‌تواند مشکلات خاص خود را داشته باشد.
اولین مشکل به وجود امدن Single Point Of Failure است. کل کارکرد سیستم ما به بالا بودن و کارکرد صحیح API Gateway وابسته است و اگر این مولفه از دسترس خارج شود یا دچار باگی باشد کلیه‌ی کارکرد سیستم می‌تواند دچار خطا شود. برای همین نگهداری و High Availability این مولفه از اهمیت خاصی برخوردار است.
تمامی سیستم ما به این مولفه نیاز دارد. با هر تغییر در API یا کارکرد هر مایکروسرویس لازم است که تنظیمات API Gateway نیز عوض شده و این مولفه دوباره مستقر شود. به همین دلیل نرخ استقرار برای این مولفه زیاد خواهد بود.
همچنین این مولفه یک گره‌ی جدید در مسیر درخواست کاربر اضافه می‌کند و درخواست‌ها مستقیما به سرویس مربوطه نمی‌رسند. به همین دلیل ممکن است سربار این درخواست نیز قابل توجه باشد و درخواست‌های ساده را مقداری کند بکند. همچنین اگر load balance برای مولفه‌های API Gateway به خوبی انجام نشود این مولفه ممکن است به گلوگاه سرویس ما تبدیل شود.
این ابزار توسط تیم اسپرینگ ارائه شده است و با زبان جاوا و فریم‌ورک Spring WebFlux نوشته شده است. یکی از مزیت‌های این ابزار Reactive بودن و استفاده از Async API هاست. به همین دلیل سربار بسیار کمی دارد و درخواست‌های بسیار زیادی را می‌تواند پردازش کند. این ابزار تقریبا تمامی اطلاعات لازم را می‌تواند از طریق فایل کانفیگ دریافت کند و درخوست‌ها را براساس آن هدایت کند. به همین دلیل بسیار منعطف است و کارکرد ساده‌ایی دارد. علاوه بر همه‌ی این ها تیم Spring Cloud به خوبی این مولفه را پشتیبانی می‌کند.
این ابزار توسط بنیاد Apache ارائه شده است. این ابزار در اصل در یک شرکت چینی توسعه پیدا کرده است و سپس به بیاد Apache اهدا شده است. یکی از مزیت‌های این ابزار داشتن داشبورد بسیار قوی و خوب است. از مزیت‌های دیگر آن قابلیت اضافه کردن پلاگین‌های مختلف و اجرای آن‌ها بدون نیاز به استقرار مجدد می‌باشد.
در این مقاله به معرفی اجمالی معماری مایکروسرویس پرداختیم. همچنین توضیح دادیم چرا در این معماری استفاده از API Gateway لازم است. سپس به بررسی مزایا و معایب API Gateway پرداختم و هر مورد را شرح دادیم. در انتها به معرفی دو ابزار معروف در این حوزه پرداختیم و در نهایت شرکت‌های معروف این حوزه در ایران را معرفی کردیم.
این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.
https://whatis.techtarget.com/definition/API-gateway-application-programming-interface-gateway
