API Gateway

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

اگر قصد توسعه یک فروشگاه آنلاین باشد که شامل چند صفحه است. اگر صفحه جزئیات محصولات در نظر گرفته شود، هدف اصلی آن نمایش جزئیات هر محصول است. علاوه بر این شامل اطلاعاتی مانند فروشندگان، بخش نظردهی، بخش ثبت امتیاز، پرسش و پاسخ و پیشنهادات است. اگر از معماری میکروسرویس استفاده نشود و به کمک روش Monolith اپلیکیشن موبایل طراحی شود، به کمک یک درخواست ساده از api مربوطه اطلاعات گرفته می‌شود. اما در معماری میکروسرویس نیاز است تا اطلاعات هر بخش از سرویس مربوطه گرفته شود. برای مثال اطلاعات سرویس سبد خرید، سرویس پرسش و پاسخ، سرویس محصول پیشنهادی و سرویس محصولات از سرویس حاوی اطلاعات مورد نیاز درخواست می‌شود. می‌توان فرض کرد در صورت نیاز اطلاعات یک سرویس، مشتری به طور مستقیم با آن تعامل داشته باشد و درخواست دهد. اما برای یک صفحه ساده همانند صفحه مذکور برای نمایش جزئیات محصول، نیاز است تا به چندین مقصد متفاوت درخواست فرستاده شود و با بالارفتن تعداد درخواست‌ها،ساخت و مدیریت صفحه نیز به شدت سخت و پیچیده خواهد شد. همچنین هر سرویس برای تعامل api مربوطه پروتکل‌های متفاوت مانند Thrift و AMQP دارد که ممکن است برخی از پروتکل به راحتی با وب سازگار نباشند. دیگر چالش زمانی است که نیاز به تغییر میکروسرویس‌ها و یا ادغام یا ترکیب چند میکروسرویس باشد و به احتمال زیاد Refactoring با مشکل مواجه خواهد شد.

برای رفع این چالش‌ها، API Gateway مورد استفاده قرار می‌گیرد و روشی بهتر برای تعامل مشتری‌ها با هر سرویس است. در این روش برای ارتباط مشتری با هر یک از سرویس‌های سیستم، تنها از یک گذرگاه api مشترک استفاده می‌شود. به این صورت پیچیدگی‌های معماری داخلی از دید کاربر خارجی پنهان است و فقط با یک api تعامل و ارتباط دارد. Api gateway وظیفه ارتباط با سرویس‌های مختلف و دریافت نتیجه نهایی برای درخواست کاربر دارد. به این ترتیب ارتباط کاربر خارجی به سادگی صورت می‌گیرد. در شکل شمای کلی از این معماری قابل مشاهده است.

تمامی درخواست‌های کاربران به api gateway وارد می‌شود. با مسیریابی هر سرویس مربوطه و تعامل با پروتکل‌های تنظیم شده، اطلاعات مورد نیاز برای کاربر آماده می‌شود. در ادامه نکاتی راجع به طراحی ذکر می‌شود.

عملکرد و مقیاس پذیری

تنها تعداد محدودی از شرکت‌ها مانند نتفلیکس نیاز به پاسخگویی روزانه میلیاردها درخواست دارند. با این حال، در بیشتر برنامه‌ها عملکرد و مقیاس پذیری API Gateway بسیار مهم است و API Gateway باید بر پلتفرمی ساخته شود که از ورودی/خروجی آسنکرون و غیر مسدود کننده پشتیبانی کند. انواع مختلفی از این فناوری‌ها وجود دارد که می‌توان برای پیاده سازی یک API Gateway مقیاس پذیر استفاده کرد. برای مثال در JVM می‌توان از پلتفرم‌های مبتنی بر NIO مانند Netty، Vertx، Spring Reactor یا JBoss Undertow استفاده کرد. یکی از پلتفرم‌های محبوب دیگر Node.js است که بر روی موتور جاوا اسکریپت کروم ساخته شده است. گزینه دیگر استفاده از NGINX Plus است. NGINX Plus یک وب سرور مقیاس پذیر، با کارایی بالا است که پروکسی ارائه می دهد و به آسانی مستقر، پیکربندی و برنامه‌ریزی می‌شود. NGINX Plus می‌تواند احراز هویت، کنترل دسترسی، درخواست‌های تعادل بار، پاسخ‌های ذخیره‌سازی را مدیریت و نظارت کند.

استفاده از مدل برنامه نویسی واکنشی

این تکنیک برخی از درخواست‌ها را به سادگی با مسیریابی به سرویس مربوطه پاسخ‌ میدهد. باقی درخواست‌ها با فراخوانی چندین سرویس پشتیبان و جمع‌آوری نتایج، صورت می‌گیرد. برخی از درخواست‌ها، مانند درخواست جزئیات محصول، درخواست‌های مربوط به خدمات پشتیبان مستقل از یکدیگر هستند. به منظور کمینه سازی زمان پاسخ، API Gateway باید درخواست های مستقل را همزمان انجام دهد. در رویکرد مناسب، کد API Gateway با استفاده از رویکرد واکنشی به سبک اعلانی نوشته می‌شود. به عنوان مثال، Future در Scala، CompletableFutureدر جاوا 8 و Promise در جاوا اسکریپت را می‌توان نام برد. استفاده از یک رویکرد واکنشی این امکان را فراهم می‌کند تا کد API Gateway ساده و در عین حال کارآمد نوشته شود.

فراخوان خدمات

یک برنامه کاربردی مبتنی بر میکروسرویس یک سیستم توزیع شده است و باید از مکانیزم ارتباط بین فرآیندی استفاده کند. یکی از سبک‌های ارتباطی، استفاده از مکانیزم ناهمزمان و مبتنی بر پیام است. برخی از پیاده سازی‌ها از یک واسط پیام مانند JMS یا AMQP استفاده می‌کنند و یا مانند Zeromq، بدون واسط هستند و به طور مستقیم ارتباط برقرار می‌کنند. سبک دیگر ارتباط بین فرآیندی یک مکانیسم همزمان مانند HTTP یا Thrift است. یک سیستم ممکن است از هر دو سبک ناهمزمان و همزمان استفاده کند. API Gateway باید از مکانیسم‌های ارتباطی مختلفی پشتیبانی کند.

کشف خدمات

در این تکنیک API Gateway باید آدرس IP و پورت هر میکروسرویسی که با آن در ارتباط است را بداند. در یک برنامه میکروسرویس مبتنی بر ابر، سرویس‌های زیرساخت، مانند کارگزار پیام، معمولاً دارای آدرس استاتیک هستند و می‌توان از طریق متغیرهای محیط سیستم عامل مشخص شوند. با این حال، تعیین مکان یک سرویس برنامه چندان آسان نیست. سرویس‌های برنامه دارای مکان‌هایی به صورت پویا هستند. Api gateway، مانند هر سرویس گیرنده دیگری در سیستم، باید از مکانیسم کشف سرویس سیستم (کشف سمت سرور یا کشف سمت مشتری) استفاده کند.

رسیدگی به خرابی‌های جزئی

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

برای نمونه Netflix Hystrix یک کتابخانه فوق العاده مفید برای نوشتن کدی است که خدمات از راه دور را فراخوانی می کند. Hystrix تماس هایی را که از آستانه تعیین شده فراتر می روند، بررسی می‌کند و مشتری را از انتظار بیهوده برای سرویس بی پاسخ باز می‌دارد.

نمونه‌هایی از ابزارهایی متن باز برای api gateway شامل موارد زیر است:

• Kong Gateway

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

• Apache APISIX

این ابزار بتدا در فناوری ZhiLiu چین متولد شد. آقای مینگ ون، معاون پروژه، بیان می‌کند که این ابزار چالش‌های مختلفی را در سرویس‌های بومی ابری و میکروسرویس‌ها حل می‌کند. APISIX توسط شرکت‌هایی مانند 360، HelloTalk، NetEase، TravelSky و بسیاری دیگر استفاده می‌شود. Apache APISIX مبتنی بر Nginx و etcd است و دارای مسیریابی پویا و بارگذاری پلاگین است و برای مدیریت API تحت سیستم میکروسرویس مناسب است. نمایی از این ابزار در شکل آورده شده است.

• Tyk

یک ابزار api gateway متن باز سازمانی است. از ویژگی‌های آن می‌توان به احراز هویت، محدود کردن نرخ، مدیریت نسخه، اطلاعیه‌ها و رویدادها، نظارت و تجزیه و تحلیل دقیق اشاره کرد.

• Ocelot

هدف این پروژه استفاده از دات نت، میکروسرویس های در حال اجرا یا معماری سرویس گرا است که نیاز به یک نقطه ورود واحد به سیستم خود دارد. روی هر پلتفرمی که ASP.NET Core پشتیبانی می کند اجرا می‌شود.

این ابزار به عنوان یک میان افزار به ترتیب عمل می‌کند. HttpRequest در وضعیت پیکربندی نگهداری می‌شود تا زمانی که به میان افزار سازنده درخواست برسد. یک شی HttpRequestMessage ایجاد می‌شود و برای درخواست یک سرویس پایین دست استفاده می‌شود. میان افزاری که درخواست را می‌سازد آخرین قسمت در فرآیند Ocelot است. سپس HttpResponseMessage بر شی HttpResponse نگاشت می‌شود و به کاربر بازگردانده می‌شود.

این ابزار ویژگی‌های استانداردی مانند مسیریابی، احراز هویت، محدود کردن نرخ، حافظه پنهان و تعادل بار را ارائه می‌دهد. این برنامه از رمزگذاری خرد، ارسال header میزبان و Swagger پشتیبانی نمی‌کند.

• Goku

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

• Express Gateway

این ابزار بر روی Express.jsساخته شده است. Express Gateway مجموعه‌ای از مؤلفه‌ها است که به‌طور اعلانی پیرامون Expressساخته می‌شوند تا نیازمندی‌هایAPI Gateway را برآورده کنند. قدرت Express Gateway از اکوسیستم غنی پیرامون میان‌افزار Expressاستفاده می‌کند.

شرکت هایی از جمله Joyent، The Linux Foundation، VIRICITI، Switch Media، Coozy و Musement به طور گسترده از Express Gateway استفاده می‌کنند.

این ابزار ساده و سریع است و تمام ویژگی های اصلی را داراست.

• Gloo

یک API Gatewy و کنترل کننده ورودی ویژه برای محیط‎های ابری است. این برنامه بر روی Envoy Proxyساخته شده است تا ترافیک را در سراسر سرویس‌های برنامه متصل، ایمن و کنترل کند.

از ویژگی‌های این ابزار می‌توان به پورتال توسعه دهندگان، WAF، پیشگیری از دست دادن داده، احراز هویت، محدود کردن نرخ پیشرفته و مدیریت چند خوشه ای اشاره کرد.

• KrakenD

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

• Fusio
• WSO2

یک راه حل مدیریت API در چرخه حیات کامل است که می‌تواند در هر مکانی اجرا شود. می‌توان آن را در حالت اولیه، ابری یا به صورت ترکیبی مستقر کرد و اجزای آن در چندین زیرساخت ابری و اولیه توزیع و مستقر شود.

• Apigee
• Cloud Endpoints
• Amazon API Gateway
• Azure

هنگامی که API نوشته و آماده شد، نظارت و ایمن کردن آن نباید فراموش شود. برای افراد در حال توسعه برنامه نرم افزاری جهت تسریع در آزمایش و توسعه API، این ابزارهای متن باز می‌توانند مفید باشند.

خلاصه و نتیجه‌ گیری

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

شرکت سورنا از نمونه شرکت‌هایی در ایران است که در این زمینه خدمات ارائه می‌دهد. همان طور که در این گزارش اهمیت معماری میکروسرویس مرور شد این معماری امروزه در بسیاری از سامانه مورد استفاده قرار میگیرد. api gateway یک تکنیک مهم در این نوع معماری است. از جمله شرکت‌هایی که می‌توانند از این تکنولوژی بهره ببرند سامانه‌های فروشگاهی و خدمت رسان با درخواست های بالا و پیچیده هستند. برای نمونه این خدمات می‌تواند برای شرکت‌هایی همانند دیجیکالا و ترب قابل استفاده باشد و عملکرد سیستم را بهبود بخشیده و از پیچیدگی آن کاسته شود.

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