هنگامی که میکروسرویس‌های خود را توسعه می‌دهید یک مسئله مهم پیش روی شما قرار دارد. چگونه clientهای شما با میکروسرویس‌های شما تعامل خواهند کرد؟ هنگامی که از روش Monolithic برای توسعه نرم‌افزارهای خود استفاده می‌کنید نهایتا یک Endpoint خواهید داشت و در صورت نیاز همین یک Endpoint برای تقسیم بار روی چند سرور نصب می‌شود و به کمک یک Load balancer بار روی این سرورها توزیع می‌شود. اما زمانیکه میکروسرویس توسعه می‌دهید مجموعه‌ای از endpointها خواهید داشت که باید بتوانید با آنها تعامل کنید. در ادامه قصد داریم راجع به تاثیرات تعداد زیادی endpoint داشتن و نحوه حل کردن این مشکل به کمک مفهومی به نام API Gatewaye اشاره نماییم.
برای تعامل clientها با میکروسرویسها تنها نقطه ورود برنامه ما یک Gateway است و راه ارتباطی Clientها با microserviceها همین Gateway است. در صورتی که با الگوی facade آشنایی داشته باشید API Gateway عملکردی شبیه به این الگو دارد. در این الگو به جای اینکه برای انجام یک کار با چندین API مختلف تعامل کنیم به سادگی با یک API تعامل می‌کنیم و پیچیدگی‌ها و معماری داخلی ما از چشم استفاده کننده پنهان می‌ماند. صدا زدن چندین سرویس مختلف و ترکیب نتنیجه و بازگرداندن نتیجه نهایی مواردی است که باید داخل API Gateway ما کپسوله شود و استفاده کننده نهایی به سادگی و با صدا زدن یک API نتیجه دلخواه خود را دریافت کند.
تمامی درخواست‌های کاربران به API Gateway تحویل داده می شود و در API Gateway مسیریابی به هر سرویس، تعامل با پروتوکل‌های مختلف و ترکیب نتیجه به دست آمده از هر میکروسرویس انجام می‌شود.
یکی دیگر از کارهای خوبی که در این زمینه می‌توان انجام داد پیاده سازی Gatewayهای تخصصی برای هر Client است. مسلما تمام داده‌هایی که در صفحه مانیتور نمایش داده می‌شود مناسب نمایش در صفحه یک گوشی موبایل نیست. پس بهتر است به ازای هر Client یک Gatewayتخصصی داشته باشیم که صرفا داده‌های آن Client را فراهم کند.
ثل هر کار دیگری استفاده از API Gateway هم مزایا و معایب خاص خود را دارد که ابتدا به مزایای آن می‌پردازیم. بزرگترین مزیت آن از بین بردن معایب روش دسترسی مستقیم است. عدم وابستگی به معماری داخلی سیستم ما باعث می‌شود کار Refactoring ساده‌تر قابل اجرا باشد و دیگر برای ترکیب یا تجزیه سرویس‌های مختلف دغدغه‌های قبل را نداشته باشیم( پیدا کردن جایی تا زمانی که آب‌ها از آسیاب بیوفتد). ارائه API تخصصی برای هر Client باعث افزایش بهره‌وری و بهبود خروجی‌ها و در یک کلام UX بهتر می‌شود. کاهش تعداد درخواست‌های ارسالی از Client هم مورد بعدی است که بهره‌وری کار را بالاتر می‌برد.
در کنار این مزایا اما چند ایراد نیز می‌توان به استفاده از این روش گرفت. بزرگترین ایراد این روش اضافه شدن یک ماژول بزرگ به سیستم است که باید همیشه سرحال و آنلاین باشد و در صورتی که عملکرد درستی ارائه نکند کل سیستم با مشکل مواجه خواهد شد. با توجه به اینکه تعامل با هرکدام از میکروسرویسها باید در API Gateway پیاده سازی شود و به ازای هر Clientهم نیاز داریم که پیاده سازی اختصاصی داشته باشیم این احتمال وجود دارد که همین API Gateway به سدی برای تیم توسعه تبدیل شود. زمانی که یک سرویس به روز می‌شود clientها باید منتظر بمانند تا این به روزرسانی در Gateway ارائه شود. به همین دلیل باید توسعه API Gateway ما طوری باشد که به سادگی قابل تغییر و به روزرسانی باشد.
با وجود تمامی این مشکلات اما نکات مثبت استفاده از این الگو به قدری زیاد است که نمی‌توان به سادگی از این الگو چشم پوشی کرد.
حال که با مزایا و معایب API Gateway آشنا شدیم به بررسی چند نکته در رابطه با پیاده سازی آن خواهیم پرداخت.
1- مسئله بهره‌وری و مقیاس پذیری:
احتمالا تعداد انگشت‌شماری شرکت در دنیا مانند Netflix وجود دارند که نیاز دارند روزانه به میلیون‌ها و میلیارد‌ها درخواست پاسخ بدهند و از دسترس خارج شدن آنها حتی برای چند لحظه غیر قابل قبول باشد. با این حال با توجه به شرایطی که بررسی شد،بهره وری بالا و قابلیت مقیاس پذیری از نیازهای اولیه هر API Gateway است. ابزارها و زبان‌های مختلفی وجود دارد که می‌تواند این ویژگی‌ها را در اختیار شما قرار دهد که برای مثلا می‌توان به .net core و Node.js اشاره کرد.
2- استفاده از مدل برنامه نویسی Reactive:
در بعضی موارد می‌توان به سادگی درخواست‌های ورودی را به یک مسیر جدید ارسال کرد و نتیجه را دریافت کرد و به کاربر بازگرداند. در بعضی موارد هم ممکن است یک درخواست ورودی به چندین سرویس ارجاع داده شود و در نهایت نتیجه تمامی این درخواست‌ها با هم ترکیب شود و به کاربر بازگردانده شود. در بعضی موارد هم ممکن است یک درخواست نیاز باشد از چند سرویس استفاده کند اما ترتیب و توالی استفاده از این سرویس‌ها اهمیت داشته باشد. برای مثال زمانی که قرار است به کاربری کالا پیشنهاد داده شود ابتدا لازم است تنظیمات و علائق کاربر از سرویس کاربران دریافت شده و سپس با اطلاعات دریافتی کالاهای پیشنهادی پیدا شده و در اختیار کاربر قرار بگیرد.
با توجه به شرایط توضیح داده شده احتمالا استفاده از روش‌های معمول برنامه نویسی خیلی زود ما را وارد جهنمی از کد‌های پیچیده و غیرقابل خواندن و تغییر می‌کند. پس بهتر است به روشی توسعه خود را انجام دهیم که مناسب شرایط باشد. در این شرایط به نظر می‌رسد Reactive Programming راهکار بهینه‌تری نسبت به روش معمول برنامه نویسی باشد.
۳- راهکارهای تعامل:
در یک API Gateway نیاز است با سرویس‌های مختلف تعامل انجام شود و اصطلاحا Inter-Process Communication انجام شود. سرویس‌های مختلف ممکن است راهکارهای متفاوتی برای تعامل در اختیار ما قرار دهند. ممکن است از روش‌های Async مثل AMQP یا روش‌های sync مثل HTTP و Thrift استفاده شود. به هر حال بدون توجه به روش‌های تعامل API Gateway مورد نظر ما باید بتواند با تمامی این روش‌ها ارتباط برقرار کند.
4- یافتن آدرس سرویس‌ها:
وقتی Gateway را پیاده سازی می‌کنیم باید به این موضوع فکر کنیم که نیاز داریم آدرس سرویس های مختلف را پیدا کنیم. در روش‌های قدیمی احتمالا نرم افزارهای ما به راحتی روی یک سرور نصب می‌شوند و دانستن آدرس آنها کار سختی نخواهد بود. اما در روش‌های جدید و استفاده از سرویس‌های ابری آدرس دیگر به سادگی و ثابت به دست نمی‌‌آید پس باید قبل از هر مسئله‌ای به یافتن آدرس میکروسرویسها بیاندیشیم. در قسمت‌های بعد به طور مفصل راجع به این مشکل و راه حل آن صحبت خواهیم کرد.
5- مدیریت خطاها:
مشکل دیگری که هنگام توسعه یک API Gateway باید به آن بیاندیشیم partial failure است. یعنی زمانی که یک درخواست کلی می‌آید و بخشی از درخواست قابل پاسخ گویی نیست. مثلا در سیستم فروشگاه و صفحه جزئیات فروشگاه یکی از سرویس‌ها در دسترس نباشد. مثلا سرویس پیشنهاد کالا در دسترس نباشد. API Gateway باید این قابلیت را داشته باشد که در این شرایط به جای اینکه کل درخواست را لغو کند،داده‌های بخش‌های صحیح را به دست آورد و برای بخش‌های مشکل دار خطا را مدیریت کند. برای مثال داده‌های کش شده داشته باشد که در این شرایط جایگزین داده‌های آنلاین شود. یا مثلا در صورتی که سرویس پیشنهاد کالا قطع باشد 10 کالای پرفروش را بازگرداند.
الف) گزینه های اختصاصی برمبنای سرویس ابر
ارائه دهندگان ابر دروازه های API را ارائه می دهند که برای ادغام با خدمات خود طراحی شده اند. از جمله این گزینه ها عبارتند از:
1- درگاه API آمازون.(AWS)
بخشی از مجموعه ابزارهای پلتفرم ابری AWS، API Gateway یک سرویس کاملاً مدیریت شده است که برای ایجاد، استقرار، مدیریت، نظارت و ایمن APIها، از جمله آنهایی که در پروتکل های REST، HTTP و Web Socket هستند، استفاده می شود. همچنین بر ویژگی‌هایی متمرکز شده است که به سمت انعطاف‌پذیری و مدیریت چرخه عمر تنظیم شده‌اند. البته API Gateway به راحتی با سایر سرویس ها و ابزارهای AWS مانند Cloud Trail برای ورود به سیستم، مدیریت هویت و دسترسی (IAM) برای احراز هویت و Cloud Formation برای ایجاد API ادغام می شود. کاربران می توانند از طریق تعدادی از نقاط دسترسی AWS، مانند کنسول مدیریت، CLI یا SDK به دروازه API Amazon دسترسی داشته باشند.
2- درگاه Azure .
سرویس مدیریت Azure API مایکروسافت دارای یک درگاه API به عنوان یکی از سه مؤلفه اصلی آن، در کنار پورتال Azure (رابط اداری) و پورتال توسعه دهنده (رابط توسعه دهنده) است. دروازه Azure تماس‌های HTTP را می‌پذیرد و مسیریابی می‌کند، محدودیت‌های استفاده و نرخ را اعمال می‌کند، پاسخ‌های پشتیبان را ذخیره می‌کند، تماس‌ها را ثبت می‌کند و تأیید را مدیریت می‌کند. ابزار دروازه همچنین با سرویس های Azure مانند Monitor برای تشخیص و برنامه های منطقی برای گردش کار و هماهنگی یکپارچه می شود.
3- درگاه API اوراکل.
به عنوان بخشی از خدمات زیرساخت ابری Oracle، درگاه API کاملاً مدیریت شده Oracle، ارائه دهنده APIهای RESTful برای سرویس های پشتیبان که از برنامه های بومی ابری پشتیبانی می کنند، می‌باشد.
ب) گزینه های منبع باز شخص ثالث
چندین گزینه محبوب درگاه API منبع باز عملکرد و مقیاسی را ارائه می دهند که با نیازهای اکثر شرکت ها مطابقت دارد.که برخی از مهمترین آنان عبارتند از:
1- درگاه KONG:
ابزار Kong Gateway یک دروازه API متن باز و بسیار مقیاس پذیر است که برای میکروسرویس ها و معماری های توزیع شده بهینه شده است. درگاه کنگ را در بالای سرور وب NGINX ساخته و با استفاده از مجوز Apache 2.0 آن را اداره می کند.
2- درگاه Tyk .
درگاه Tyk یکی دیگر از گزینه های دروازه منبع باز است که از سه جزء مجزا تشکیل شده است: داشبورد که رابطی برای معیارها و سازماندهی API فراهم می کند. پمپ، که پایداری داده و اتصالات پایگاه داده را فراهم می کند. و Gateway، که پروکسی است که تمام ترافیک را مدیریت می کند. Tyk API Gateway برای اجرا فقط به یک پایگاه داده Redis نیاز دارد و ویژگی های مشابه Kong را ارائه می دهد، از جمله روش های پراکسی ترافیک، کنترل های دسترسی و قابلیت های گزارش.
1- ابر درسا در سال ۱۳۹۸ توسط تعدادی از صاحب نظران در حوزه رایانش ابری بنیانگذاری شده و در سال ۱۴۰۰ با نام سیستم خبره درسا در اداره کل ثبت شرکت ها و موسسات غیرتجاری ثبت و با نام تجاری ابر درسا شروع به فعالیت نموده است. ماموریت ابر درسا تبدیل شدن به پلت فرم اول رایانش ابری در منطقه خاورمیانه است. سرویس ApiGateway ابری یک سرویس میزبانی API است.
این مجموعه وسیعی از توابع مدیریت چرخه زندگی را برای کمک به ایجاد معماری سیستم API محور ارائه می دهد. توابع مدیریت چرخه زندگی شامل طراحی API، توسعه، آزمایش، انتشار، فروش، O&M و نظارت، کنترل امنیت و عدم انتشار است.
سرویس Api Gateway ابری با استفاده از قابلیت های سازگاری و یکپارچگی قدرتمند خود، API های سیستم های تجاری مختلف را مدیریت می کند و API ها را به صورت متمرکز فراخوانی می کند. و این شرکت یکی از خدماتی که ارائه می‌کند، همین سرویس ابری API Gatewaye می‌باشد.
2- شرکت وصل با ارائه دهنده خدمات متنوعی در ارتباط با نرم افزار است. یکی از پلتفرم‌هایی که در همین موضوع مورد بحث API ارائه است، با نام تجاری سورنا است.
پلتفرم مدیریت API سورنا توسعه‌دهندگان را قادر می‌سازد تا برنامه‌هایی مرتبط با سامانه‌های داخلی سازمان/سرویس‌دهنده طراحی و پیاده‌سازی نمایند. همچنین APIها در تکنولوژی‌های مختلف نظیر اینترنت اشیا، رایانش ابری و داده‌های حجیم نقشی کلیدی را ایفا می‌نماید. پلتفرم مدیریت API سورنا پایداری، امنیت و پشتیبانی ویژهای ارائه می‌کند تا شرکتهای طرف ثالث، همکاران، شرکا و حتی توسعه‌دهندگان آزاد بتوانند با آسودگی خیال و اطمینان از آنها استفاده نمایند.
جمع بندی:
در این مقاله با اشاره ای بر معماری میکروسرویس و سپس روش تعامل کلاینتها در میکروسرویس یعنی درگاه API پرداخته شد . سپس در نهایت به معرفی ابزارهای مهم و مطرح و شرکتهای ایرانی فعال در این حوزه معرفی شد.
این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.
منابع:
منابع:
https://searchapparchitecture.techtarget.com/feature/A-feature-rundown-of-6-popular-API-gateway-tools?amp=1
