درگاه API، یک ابزار مدیریت API بین کلاینت ها و مجموعه ای از سرویس های بک اند است. API یا همان Application programming interface در سازمان ها عملا توسط درگاه های API پیاده سازی می شوند. معمولا هر درگاه کارهای خاصی را انجام می دهد، برای مثال احراز هویت از درگاه های خاصی انجام می شود. سازمان ها یک gateway در ورودی سازمان خود دارند؛ یعنی هر سرویسی که می خواهد وارد سازمان شود و ورود هر نوع داده یا اطلاعاتی در آن بررسی می شود اما موضوعی که در این پست به آن می پردازیم، بحث ارتباط بین میکروسرویس های داخلی یک سازمان است که مدیریت ارتباطات بین میکروسرویس های مختلف را بر عهده دارد.
اصولا API ها به این منظور طراحی شده اند که ریکوئستی را دریافت کرده و پاسخ آن را بدهند؛ اما در واقعیت بحث های بسیاری در این امر وجود دارد از جمله:
درگاه مدیریت API ، ریکوئست ها را دریافت می کند و بر طبق دسته بندی آن را به سمت یک سرویس خاص میفرستد. در سازمان هایی که بر پایه ی Deployment های سریع و مداوم کار می کنند، عموما معماری بر اساس میکرو سرویس است و اساسا یکی از مزایای استفاده از معماری میکروسرویس، قابلیت deploy سریع است. در معماری میکرو سرویس، راه ارتباطی میان میکروسرویس ها با کلاینت ها، API ها هستند. چون در معماری میکرو سرویس بر خلاف monolithic تنها یک Endpoint وجود ندارد و چند دریافت کننده وجود دارد.همچنین در معماری های در بستر cloud نیز،API ها از اهمیت بالایی برخوردار هستند.
چون در معماری میکروسرویس، هر بخش از برنامه می تواند روی یک سرویس بالا آمده باشد، ممکن است برای لود شدن یک صفحه به عنوان مثال در یک وب اپلیکیشن به صدا زدن چند سرویس نیاز باشد. درگاه API مثل الگوی طراحی facade است. یعنی پیچیدگی صدا زدن چندین API از دید کاربر پنهان می ماند و از دید کاربر تنها یک API صدا زده می شود.
زمانی که در یک سیستم مونولیت، کلاینت درخواستی را ارسال می کند، این درخواست صرفا یک REST CALL به سمت اپلیکیشن است. در ادامه ماژولی مثل load balancer این درخواست را به یکی از instanceهای برنامه هدایت می کند. این instance ها همگی مشابه هستند زیرا سیستم یکپارچه است. حالا از هر instance ی می تواند روی دیتابیس های مختلفی کوئری زده شود و نتیجه یکجا شده و به سمت کاربر ارسال شود.
اما زمانی که اپلیکیشن با سبک معماری میکروسرویس توسعه داده شده باشد، برای مثال در یک صفحه وب یک اپلیکیشن فروشگاه اینترنتی، اطلاعات از چندین میکروسرویس مجزا آمده است. در تئوری، شاید به نظر برسد هر کلاینت می تواند به هر کدام از این میکروسرویس ها در ارتباط باشد و با هر میکروسرویس مثل یک سیستم مونولیت برخورد شود که endpoint ی برای برقراری ارتباط با بیرون را دارد؛ اما در عمل اینگونه نیست. مثلا در همان مثال فروشگاه اینترنتی اگر فروشگاه آنلاین بزرگی مثل آمازون را در نظر بگیریم، در پشت هر صفحه ممکن است نیاز باشد صدها سرویس فراخوانی شوند و اگر همه این درخواست ها بخواهند جدا جدا از طریق شبکه به سرویس مقصد خود متصل شوند، هم مشکل پیچیدگی استفاده و مدیریت فراخوانی ها به وجود می آید و در سمت کلاینت باید کدهای زیادی دولوپ شود و هم شبکه بسیار اشغال می شود. همچنین در بحث توسعه میکروسرویس ها مبحثی به نام خودمختاری هر میکروسرویس وجود دارد. یعنی تکنولوژی مورد استفاده در یک میکروسرویس می تواند مستقل از سایر میکروسرویس ها و پلتفرم ها و صرفا بر اساس نیاز های آن میکروسرویس انتخاب شود. پس ممکن است بعضی میکروسرویس ها امکان داشتن endpointی برای اتصال در محیط وب را به عنوان مثال نداشته باشند و نیاز باشد از این میکروسرویس در وب اپلیکیشن استفاده شود. پس نتیجه می شود، نحوه برخورد و برقراری ارتباط با میکروسرویس ها کاملا متفاوت از سیستم های مونولیت است. این همان جایی است که اهمیت استفاه از API Gateway خود را نشان می دهد. این درگاه باعث می شود از دید کلاینت ها سیستم طوری به نظر برسد که فقط یک درگاه ورودی دارد و همچنین از دید میکروسرویس های داخل سیستم راه ارتباطی بین یکدیگر تنها واسطی به نام API Gateway است. سازو کار این درگاه به سنگینی ESB که در معماری سرویس گرا نیست، مثلا وظیفه orchestration، چیزی که در معماری سرویس گرا بسیار رایج بود را ندارد، اما واسطی سبک وزن برای مدیریت است.
مهم ترین مزیت استفاده ازAPI Gateway که تا به اینجا بیان شد، یکپارچه بودن محل اتصال به سیستمی است که با معماری میکروسرویس توسعه داده شده است. اما معایبی مانند اضافه شدن یک کامپوننت جدید به سیستم وجود دارد، به هر حال این کاموننت پیچیدگی هایی مختص به خود برای توسعه، استقرار و مدیریت دارد. همچنین این ریسک به وجود می آید که اگر رخنه امنیتی در این درگاه وجود داشته باشد، می تواند بین تمام میکروسرویس ها و به خارج از سیستم منتشر شود. پس توسعه دهندگان همواره باید ابزارهای استفاده شده در آن را آپدیت کنند و به نگهداری این کامپوننت بسیار اهمیت بدهند. استفاده از معماری میکروسرویس و کامپوننت های مورد استفاده اش در هر صورت یک trade off برای تصمیم گیرندگان آن پروژه است. چون در کنار مزایای بسیار زیاد، معایبی نیز با خود دارد.
ملاحظاتی که باید در طراحی API Gateway در نظر گرفته شود:
شاید همه اپلیکشن ها مثل آمازون یا نتفلیکس نیاز به مدیریت میلیون ها کاربر در ثانیه را نداشته باشند اما چیزی که مهم است در طراحی این گذرگاه باید این دید وجود داشته باشد که در ادامه ممکن است نیاز به افزایش مقیاس سیستم باشد و گذرگاه باید این قابلیت را داشته باشد و همچنان کارآیی خود را حفظ کند. پس این کامپوننت باید درگاه ورودی خروجی آسنکرون داشته باشد تا بتواند حجم زیاد درخواست ها را مدیریت کند. برای مثال اگر قرار باشد API Gateway با جاوا پیاده سازی شود، می توان در JVM از فریمورک های NON Blocking I/O مثل Netty , Vertx , Spring Reactor یا JBoss استفاده کرد. گزینه دیگر استفاده ازNGINX plus است که شامل سرور وب و پروکسی است که هم کارایی بالایی دارد و هم مقیاس پذیر است. همچنین امکانات دیگری مثل احراز هویت، کنترل سطح دسترسی،توزیع بار، کش کردن درخواست ها و مانیتور کردن وضعیت سیستم را نیز دارد.
کار API Gateway هم ارسال درخواست های بیرونی به سرویس مقصد و هم مدیریت ارتباطات بین سرویسی برای تجمیع پاسخ های آن ها در داخل سیستم است. برای اینکه این زمان نهایی دریافت پاسخ توسط کلاینت کاهش یابد، نیاز است که این ارتباطات درون سیتسمی به صورت همروند اجرا شوند؛ اما به هر حال زمان هایی وجود دارد که بین این درخواست های رد و بدل شده، وابستگی هایی وجود دارد. مثلا اول از همه همیشه نیاز است که سرویس اعتبارسنجی پاسخ خود را بدهد و اگر درخواست معتبر بود در ادامه سرویس های دیگر اجرا شوند. در اینجا صرفا مدیریت آسنکرون درخواست ها کمک کننده نخواهد بود. راه حل بهتر که از پیچیده شدن کد نیز جلوگیری می کند، استفاده از زبان های Declarative است مانند Scala. همچنین در جاوا اکستنشن هایی وجود دارد مثل Rxjava .این ابزارها برای ساده سازی کد این گذرگاه و کارا بودن آن بسیار مفید است.
سیستمی که معماری میکروسرویس دارد، عموما یک سیستم توزیع شده است و باید مکانیزم ارتباطی بین اجزای داخلی آن وجود داشته باشد. دو مدل ارتباطی وجود دارد: یکی استفاده از مکانیزمی های آسنکرون بر پایه ارسال پیام. برای این منظور بعضی از سیستم ها از message broker هایی مثل JMS یا AMPQ استفاده می کنند. نوع دیگر استفاده از مکانیزم های سنکرون مثل http یا thrift است. یک پیاده سازی از API Gateway لازم است که از چندین مکانیزم ارتباطی مثل سنکرون و آسنکرون پشتیبانی کند.
لازم است که API Gateway محل هر میکروسرویس را بدانند تا بتوانند به آن آدرس دهی کنند. اما در زیرساختی هایی که امروزه استفاده می شود مثل Cloud این موضوع خیلی بدیهی نیست. چرا که ممکن است نیاز باشد محل یک میکروسرویس در طول زمان تغییر کند. پس این درگاه نیاز دارد از مکانیزم هایی استفاده کند که به طور پویا از محل قرارگیری هر میکروسرویس اطلاع داشته باشد. Service Registry دیتابیسی است که محل قرار گیری هر میکروسرویس در آن ذخیره میشود.
اگر زمانی که سرویسی سرویس دیگری را فراخوانی می کند، سرویس مقصد به هر دلیلی در دسترس نباشد یا زمان ارسال پاسخ آن طول بکشد، باید مکانیزمی در API Gateway فراهم باشد تا این درخواست گم نشود. مثلا گذرگاه می تواند اطلاعات کش شده ای که در رابطه با این درخواست از قبل داشت، به عنوان پاسخ آن ارسال کند یا اطلاعات دیفالتی را به عنوان پاسخ بر گرداند که سیستم کرش نکند و همچنین کاربر تجربه کاربری بهتری داشته باشد.
https://www.softwaretestinghelp.com/api-management-tools/
https://nikamooz.com/api-gateway/
«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است»
