علی حنیفی
علی حنیفی
خواندن ۱۰ دقیقه·۳ سال پیش

معرفی ابزارهای درگاه API

از زمانیکه ساخت و توسعۀ نرم‌افزارها آغاز شده، سال‌های زیادی می‌گذرد و تیم‌های توسعه دهنده همواره در این حرفه پیشرفت نموده و بهتر شده‌اند. فناوری‌ها و الگوهای معماری زیادی در این سال‌ها ظهور نموده‌اند که هرکدام متناسب با انواع خاصی از کاربردها هستند. میکروسرویس، یکی از این الگوهای معماری است که از دنیای طراحی دامنه محور، تحویل مداوم، اتوماسیون پلتفرم و زیرساخت، سیستم‌های مقیاس‌پذیر و برنامه‌نویسی چند زبانه پدید آمده است.

آقای رابِرت سی. مارتین در کتاب توسعۀ نرم‌افزار چابک: اصول، الگوها و کاربرد، اصطلاح اصل مسئولیت واحد (Single-responsibility principle) را چنین مطرح می‌کند:

چیزهایی را که به دلایل یکسان تغییر می‌کنند را در یکجا جمع‌آوری کنید و چیزهایی را که به دلایل مختلف تغییر می‌کنند از هم جدا کنید.

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

اما استفاده از معماری میکروسرویس با مشکلات و چالش‌هایی همراه است که از جملۀ آن‌ها می‌توان به عدم هماهنگی سرویس‌ها با پروتکل‌های ارتباطی، نیاز به پیاده‌سازی عملیات درگاهی (مثل ورود، خروج و غیره) در هر سرویس، کاهش سرعت پاسخ و بالارفتن بار سرور اشاره نمود. برای حل این مشکلات، یک لایۀ اضافی بین مشتری و سرور قرار می‌گیرد و به‌عنوان یک پاسخگوی درخواست مسیریابی معکوس از مشتری به سرور عمل می‌کند که به آن درگاه API گفته می‌شود.

در این پست قصد داریم تا شما را با درگاه API آشنا کنیم و برخی ابزارهای متن‌باز مرتبط را آن را معرفی نماییم. همچنین برخی شرکت‌های ایرانی ارائه دهندۀ خدمات درگاه API نیز در انتها معرفی خواهند شد.



درگاه API چیست؟

درگاه API در واقع یک الگوی نرم‌افزاری است که در مقابل یک رابط برنامه‌نویسی نرم‌افزار (API) یا گروهی از زیرسرویس‌ها قرار می‌گیرد تا درخواست‌ها، تحویل دادنی‌ها و خدمات را تسهیل کند. نقش اصلی درگاه API این است که به‌عنوان یک نقطۀ ورودی واحد، تعاملات بین برنامه‌ها، داده‌ها و خدمات سازمان و مشتریان داخلی و خارجی را استانداردسازی نماید.

با توضیحاتی که داده شد، شاید کمی بحث پیچیده شده باشد. بگذارید با یک مثال ادامه بدهیم. فرض کنید که می‌خواهید یک نرم‌افزار فروشگاه آنلاین بسازید؛ برنامۀ شما باید ویژگی‌هایی مثل لیست کالاها، سفارش دادن، جزئیات کالاها و غیره داشته باشد. بنابراین چنین برنامه‌ای باید سرویس‌هایی نظیر سرویس کالا، سرویس سفارش، سرویس قیمت‌گذاری، سرویس کاربران و غیره را به همراه خود داشته باشد.

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

اما این نوع معماری، دارای مشکلات متعددی است:

  • تجربۀ کاربری به دلیل درخواست‌های متعدد مشتریان، ضعیف خواهد بود: کاربر باید چندین درخواست برای بازیابی داده‌ها داشته باشد و باید این درخواست‌ها را به‌صورت متوالی اجرا کند. بنابراین کُد نوشته شده تقریبا پیچیده خواهد بود. همچنین برای باز کردن یک صفحۀ معمولی، ممکن است یک درخواست چندین مرتبه به سرور فرستاده شده و پاسخ آن برگشت داده شود. همچنین این قضیه زمانی بدتر می‌شود که سرعت شبکه پایین‌ باشد.
  • پروتکل‌های ارتباطی متنوع هستند: برخی از سرویس‌ها ممکن است از پروتکل پیام‌رسانی gRPC یا AMQP و غیره استفاده کنند. این پروتکل‌ها در خود سرویس به‌خوبی کار می‌کنند، اما ممکن است به‌راحتی توسط سایر سرویس‌ها قابل استفاده نباشند یا ممکن است سازوکار برخی از پروتکل‌ها در برخی از پلتفرم‌های کاربران سخت باشد.
  • نیاز به پیاده‌سازی عملیات‌های سادۀ درگاهی در هر سرویس: برخی عملیات‌های ساده که در همۀ درگاه‌ها استفاده می‌شوند (مثل ورود، خروج، احراز هویت و غیره) باید در هر میکروسرویس پیاده‌سازی شوند که هم باعث کاهش سرعت و هم ایجاد ناهماهنگی و هدر رفتن منابع می‌شود.
  • کپسوله‌سازی (حفاظت) از داده‌ها وجود ندارد: توسعه دهندۀ یک سرویس گاهی اوقات سرویس‌های جدیدی را به نرم‌افزار اضافه می‌کند و حتی ممکن است API را تغییر دهد. اما اگر دانش در مورد سرویس در سمت کاربر تشکیل شده باشد، تغییر API سرویس دشوار است. همچنین ایجاد تغییرات در میکروسرویس‌ها بدون ایجاد اختلال در اتصال کاربر ممکن نیست.

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

یک درگاه API، انعطاف‌پذیری را برای استفاده از پروتکل‌های کاملاً مستقل فراهم می‌کند و به میکروسرویس‌ها اجازه می‌دهد تا به‌راحتی با یکدیگر ارتباط برقرار کنند. درگاه‌های API به توسعه‌دهندگان اجازه می‌دهند تا به عملکردهای زیرمجموعه‌ای از معماری به روش‌های مختلف دسترسی داشته باشند، بدون اینکه نقاط پایانی را به‌طور عمومی در معرض دید عموم قرار دهند. درگاه‌های API مزایای متعددی دارند که می‌توان از جملۀ آن‌ها به موارد زیر اشاره کرد:

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

همچنین استفاده از درگاه API معایبی نیز به‌همراه دارد:

  • یادگیری آن دشوار است: هنگامی که صحبت از معماری نرم‌افزار با دسترسی بالا در مقیاس بزرگ به‌میان می‌آید، یک منحنی یادگیری وجود دارد، یعنی نیاز به تجربۀ بالا، لازم است. این منحنی به‌خصوص جایی که درگاه API تنها نقطه ورودی است، به‌عنوان یک نقطۀ شکست عمل می‌کند.
  • پیکربندی آن دشوار است: پیکربندی برنامه و API برای تعامل از طریق یک درگاه API به هماهنگی بیشتری نیاز دارد که به سطح دشواری برای توسعه‌دهندگان می‌افزاید.
  • همراه با اُفت عملکرد خواهد بود: کاهش عملکرد به دلیل سناریوهای متعددی که درگاه API انجام می‌دهد و می‌تواند بر سرعت و قابلیت اطمینان برنامه تأثیر بگذارد، یک نگرانی است.



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

در این قسمت به چهار ابزار متن‌باز برتر در زمینۀ درگاه API اشاره می‌شود.

ابزار Kong Gateway

ابزار Kong Gateway محبوب‌ترین درگاه API اَبری متن‌باز است که به زبان Lua نوشته شده و با کمک Nginx اجرا می‌شود. این ابزار در واقع قالبی است که به سرعت بخشیدن به زمان رویداد کمک نموده و تضمین می‌کند که عملکرد تأخیر و مقیاس‌پذیری بی‌نظیری را برای همۀ برنامه‌های میکروسرویس‌ها بدون توجه به مکان اجرا، ارائه دهد.

شرکت‌هایی مانند Nasdaq ،Honeywell ،Cisco ،FAB ،Expedia ،Samsung ،Siemens و Yahoo Japan به‌طور گسترده از درگاه API Kong استفاده می‌کنند. برخی از ویژگی‌های ارائه شده توسط Kong عبارتند از: احراز هویت، کنترل ترافیک، تجزیه و تحلیل، ورود به سیستم، قابلیت توسعه با استفاده از معماری پلاگین.

برای دریافت اطلاعات بیشتر می‌توانید به قسمت مستندات یا آدرس وبسایت Kong Gateway مراجعه نمایید.


ابزار Apache APISIX

ابزار Apache APISIX ابتدا در شرکت ZhiLiu چین متولد شد و سپس وارد اَنکوباتور Apache شد و تبدیل به یک ابزار متن‌باز گردید. مینگ وِن که معاون این پروژه است، بیان می‌کند که APISIX چالش‌های مختلفی را که توسط سرویس‌های بومی و میکروسرویس اَبری ایجاد می‌شود، حل می‌کند. ابزار Apache APISIX توسط شرکت‌هایی مانند 360، HelloTalk ،NetEase ،TravelSky و بسیاری دیگر استفاده می‌شود.

ابزار Apache APISIX مبتنی بر Nginx و etcd و دارای مسیریابی پویا و بارگذاری داغ (Hot Loading) است که مخصوصاً برای مدیریت API تحت سیستم میکروسرویس مناسب است.

برای دریافت اطلاعات بیشتر می‌توانید به آدرس وبسایت Apache APISIX مراجعه نمایید.


ابزار Ocelot

ابزار Ocelot یک درگاه API مبتنی بر دات نِت است. هدف این پروژه استفاده از دات نِت و میکروسرویس‌های در حال اجرا یا معماری سرویس‌گرا است که نیاز به یک نقطۀ ورود واحد به سیستم خود دارد. با این حال، با سرویسی که از پروتکل HTTP استفاده نموده و روی هر پلتفرمی که ASP.NET Core پشتیبانی می‌کند، اجرا می‌شود. Ocelot ویژگی‌های استانداردی مانند مسیریابی، احراز هویت، محدود کردن نرخ، حافظۀ پنهان، تعادل بار و غیره را ارائه می‌دهد. همچنین این برنامه از رمزگذاری، ارسال هِدِر میزبان و Swagger پشتیبانی نمی‌کند.

برای دریافت اطلاعات بیشتر می‌توانید به دایرکتوری گیت‌هاب ابزار Ocelot مراجعه نمایید.


ابزار Goku

ابزار Goku در واقع یک زیرمجموعه از پروژۀ EOLINK Inc است. این ابزار یک درگاه میکروسرویس مبتنی بر Golang است که مسیریابی پویا با کارایی بالا، هماهنگی خدمات، کنترل دسترسی API و غیره را امکان پذیر می‌کند. ابزار Goku یک رابط گرافیکی و سیستم پلاگین برای آسان‌تر کردن پیکربندی و توسعۀ راحت‌تر را فراهم می‌کند. جدا از ویژگی‌های استاندارد، Goku ویژگی‌هایی مثل خوشه‌بندی، به‌روزرسانی‌، هشداردهی، گزارش‌گیری و غیره را ارائه می‌دهد.

برای دریافت اطلاعات بیشتر می‌توانید به دایرکتوری گیت‌هاب ابزار Goku مراجعه نمایید.




معرفی شرکت های ایرانی

در این قسمت دو شرکت ایرانی که خدمات درگاه API را ارائه می‌دهند، آورده شده‌اند.

شرکت سیستم خبره دُرسا

این شرکت کار خود را از سال 1398 توسط تعدادی از صاحبنظران در حوزۀ رایانش اَبری آغاز نمود و سپس در سال 1400 با نام سیستم خبره درسا به ثبت رسید که نام تجاری آن اَبر درسا است.این شرکت ماموریت خود را تبدیل شدن به پلتفرم اول رایانش ابری در منطقۀ خاورمیانه بیان نموده و سرویس‌های مختلفی از جمله مدیریت و درگاه API را به مشتریان خود ارائه می‌دهد.

برای کسب اطلاعات بیشتر راجع به سامانۀ درگاه ابری API و آشنایی بیشتر با شرکت سیستم خبره درسا، می‌توانید به آدرس وبسایت آن مراجعه کنید.


شرکت وصل

شرکت وصل در سال‌های گذشته تلاش نموده است تا با برنامه­‌ریزی­‌های استراتژیک، بلندمدت و تفکری متفاوت، خود را به‌عنوان یکی از فعالان حوزۀ فناوری اطلاعات کشور معرفی نماید. در این راستا پلتفرم معرفی شده توسط این شرکت، سورِنا نام دارد که خدمات متفاوتی مانند مدیریت چرخۀ APIها، انعطاف‌پذیری و امنیت را برای میکروسرویس‌ها ایجاد می‌نماید.

برای کسب اطلاعات بیشتر راجع به سامانۀ سورنا و آشنایی بیشتر با شرکت وصل، می‌توانید به آدرس وبسایت آن مراجعه کنید.



سخن پایانی

به‌طور خلاصه، درگاه API یک پروکسی معکوس است که میکروسرویس‌ها را به‌عنوان API ارائه می‌دهد. یک درگاه API همچنین به حداقل‌سازی خطرات احتمالیِ در معرض قرار دادن عمومی خدمات باطنی سرویس‌ها و منابع داده به‌طور مستقیم، کمک می کند. استفاده از درگاه API باعث می‌شود کُد نوشته شده تمیزتر و ساده‌تر باشد، تأخیر به حداقل برسد و احراز هویت و رمزگذاری ساده‌تر شود.

درصورتیکه نیاز به اطلاعات بیشتری در این سبک از معماری دارید، می‌توانید کتاب کریس ریچاردسون به نام الگوی میکروسرویس‌ها را مطالعه کنید. همچنین مستندات سرویس‌های اَبری Azure شرکت مایکروسافت نیز حاوی اطلاعات جالب و آموزنده‌ای هستند که پیشنهاد می‌شود آن‌ها را مطالعه نمایید.

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



مراجع

[1] Ali, A. (2021, January 18). 14 Open Source and Managed API Gateway for Modern Applications. Geekflare.

[2] H. (2018, June 22). The What, Why, and How of a Microservices Architecture. Medium.

https://medium.com/hashmapinc/the-what-why-and-how-of-a-microservices-architecture-4179579423a9

[3] Martin, R. C., Rabaey, J. M., Chandrakasan, A. P., Nikolić, B., Newkirk, J. W., & Koss, R. S. (2003). Agile Software Development. Pearson Education.

[4] Montgomery, J. (2021, March 30). API gateway. WhatIs.Com.

https://whatis.techtarget.com/definition/API-gateway-application-programming-interface-gateway

[5] Nadaduru, L. N. (2021, October 25). What is an API Gateway - FAUN Publication. Medium.

https://faun.pub/api-gateway-analysis-74b304f2e145

[6] Schiesser, M. (2019, January 10). What is an API Gateway? - Glasnostic Blog.

https://glasnostic.com/blog/what-is-an-api-gateway-aws-express-kong

[7] Shah, B. (2021, October 14). Microservices Design - API Gateway Pattern - Dev Genius. Medium.

https://blog.devgenius.io/microservices-design-api-gateway-pattern-980e8d02bdd5

[8] Siahaan, J. N. (2019a, September 8). API Gateway Part 1 - Easyread. Medium.

https://medium.com/easyread/api-gateway-part-1-7901ba703f9

[9] Siahaan, J. N. (2019b, September 8). API Gateway Part 2 - Easyread. Medium.

https://medium.com/easyread/api-gateway-part-2-7264ee5be187

[10] Why Use API Gateway? Pros & Cons | Knowledge Base. (2021, January 13). Dashbird.

https://dashbird.io/knowledge-base/api-gateway/pros-and-cons-of-using-an-api-gateway/

[11] ابر درسا. (2021, December 2). سرویس Api Gateway ابری.

https://dorsacloud.com/service-post/api-gateway-service/

[12] سورنا (API Management) | شرکت وصل. (2021). شرکت وصل.

http://vasl.ir/platform/api-management/



معماری نرم افزارمعماری نرم افزار بهشتیمعماری_نرم_افزار_بهشتیapi gatewayapi
شاید از این پست‌ها خوشتان بیاید