مطالعه موردی یک صفحه پیچیده (مثلاً صفحه محصول) یک برنامه فروشگاه اینترنتی را در نظر بگیرید. اگر به صفحه زیر لیست محصولات آمازون نگاه کنیم، می توانیم اطلاعات زیادی را که برای ارائه توسط این صفحه خاص مورد نیاز است، ببینیم.
amazon case study
بیایید تمام میکروسرویس هایی را که ممکن است برای ارائه صفحه خاص بالا نیاز داشته باشیم فهرست کنیم.
- جستجوی محصول
- موجودی محصول
- ارسال محصول
- رتبه‌بندی و بررسی‌ها
- موتور سیستم توصیه گر(پیشنهاد دهنده محصول)
- امور مالی و بیمه را در نظر بگیرید
این شش سرویس می تواند میکرو سرویس هایی باشند که در صفحه بالا ارائه سرویس می دهند استفاده می‌شوند.
بیان مسئله
از آنجایی که اگر مشتری بخواهد به این خدمات دسترسی داشته باشد، این میکروسرویس ها به طور جداگانه در سرور دیگری مستقر شده اند، حداقل هفت (6) تماس باید برای یک صفحه درخواست شود.
Access To Microservices
اما آیا واقعا رویکرد خوبی است؟
فکر نمی‌کنم این یک رویکرد توصیه‌شده باشد، زیرا ما باید هفت ریکوئست مختلف داشته باشیم، که قطعاً بر عملکرد، مصرف منابع، زمان بارگذاری و غیره تأثیر می‌گذارد. اگر مجبور باشیم میکروسرویس های Reviews و Rating را در دو سرویس مختلف جدا کنید، باید کد مشتری را به روز کنیم. مشتری باید یک ریکوئستبرای دریافت نظرات و یک ریکوئست برای دریافت رتبه بندی داشته باشد که واقعاً بهترین راه برای مقابله با آن نیست.
راه حل
روش بهتری برای تعامل clientها با میکروسرویس‌ها وجود دارد که آن را با نام API Gateway می‌شناسیم. در این روش تنها نقطه ورود برنامه ما یک Gateway است و راه ارتباطی Clientها با microserviceها همین Gateway است. درصورتی‌که با الگوی facade آشنایی داشته باشید API Gateway عملکردی شبیه به این الگو دارد. در این الگو به‌جای اینکه برای انجام یک کار با چندین API مختلف تعامل کنیم به‌سادگی با یک API تعامل می‌کنیم و پیچیدگی‌ها و معماری داخلی ما از چشم استفاده‌کننده پنهان می‌ماند. صدازدن چندین سرویس مختلف و ترکیب نتیجه و بازگرداندن نتیجه نهایی مواردی است که باید داخل API Gateway ما کپسوله شود و استفاده‌کننده نهایی به‌سادگی و با صدازدن یک API نتیجه دلخواه خود را دریافت کند.تمامی درخواست‌های کاربران به API Gateway تحویل داده می‌شود و در API Gateway مسیریابی به هر سرویس، تعامل با پروتکل‌های مختلف و ترکیب نتیجه به‌دست‌آمده از هر میکروسرویس انجام می‌شود.
یکی دیگر از کارهای خوبی که در این زمینه می‌توان انجام داد پیاده‌سازی Gatewayهای تخصصی برای هر Client است. مسلماً تمام داده‌هایی که در صفحه مانیتور نمایش داده می‌شود مناسب نمایش در صفحه یک گوشی موبایل نیست. پس بهتر است به‌ازای هر Client یک Gateway تخصصی داشته باشیم که صرفاً داده‌های آن Client را فراهم کند.
مزایا و معایب استفاده از API Gateway
مثل هر کار دیگری استفاده از API Gateway هم مزایا و معایب خاص خود را دارد که ابتدا به مزایای آن می‌پردازیم. بزرگ‌ترین مزیت آن ازبین‌بردن معایب روش دسترسی مستقیم است. عدم وابستگی به معماری داخلی سیستم ما باعث می‌شود کار Refactoring ساده‌تر قابل‌اجرا باشد و دیگر برای ترکیب یا تجزیه سرویس‌های مختلف دغدغه‌های قبل را نداشته باشیم. ارائه API تخصصی برای هر Client باعث افزایش بهره‌وری و بهبود خروجی‌ها و در یک‌کلام UX بهتر می‌شود. کاهش تعداد درخواست‌های ارسالی از Client هم مورد بعدی است که بهره‌وری کار را بالاتر می‌برد.
در کنار این مزایا اما چند ایراد نیز می‌توان به استفاده از این روش گرفت. بزرگ‌ترین ایراد این روش اضافه‌شدن یک ماژول بزرگ به سیستم است که باید همیشه سرحال و آنلاین باشد و درصورتی‌که عملکرد درستی ارائه نکند کل سیستم با مشکل مواجه خواهد شد. باتوجه‌به اینکه تعامل با هرکدام از میکروسرویس‌ها باید در API Gateway پیاده‌سازی شود و به‌ازای هر Client هم نیاز داریم که پیاده‌سازی اختصاصی داشته باشیم این احتمال وجود دارد که همین API Gateway به سدی برای تیم توسعه تبدیل شود. زمانی که یک سرویس به‌روز می‌شود clientها باید منتظر بمانند تا این به‌روزرسانی در Gateway ارائه شود. به همین دلیل باید توسعه API Gateway ما طوری باشد که به‌سادگی قابل تغییر و به‌روزرسانی باشد.
با وجود تمامی این مشکلات اما نکات مثبت استفاده از این الگو به‌قدری زیاد است که نمی‌توان به‌سادگی از این الگو چشم‌پوشی کرد.
مسئله بهره‌وری و مقیاس‌پذیری
احتمالاً تعداد انگشت‌شماری شرکت در دنیا مانند Netflix وجود دارند که نیاز دارند روزانه به میلیون‌ها و میلیاردها درخواست پاسخ بدهند و از دسترس خارج‌شدن آن‌ها حتی برای چند لحظه غیرقابل‌قبول باشد. بااین‌حال باتوجه‌به شرایطی که بررسی شد، بهره‌وری بالا و قابلیت مقیاس‌پذیری از نیازهای اولیه هر API Gateway است. ابزارها و زبان‌های مختلفی وجود دارد که می‌تواند این ویژگی‌ها را در اختیار شما قرار دهد که برای مثلاً می‌توان به .net core و Node.js اشاره کرد.
راهکارهای تعامل
در یک API Gateway نیاز است با سرویس‌های مختلف تعامل انجام شود و اصطلاحاً Inter-Process Communication انجام شود. سرویس‌های مختلف ممکن است راهکارهای متفاوتی برای تعامل در اختیار ما قرار دهند. ممکن است از روش‌های Async مثل AMQP یا روش‌های sync مثل HTTP و Thrift استفاده شود. به‌هرحال بدون توجه به روش‌های تعامل API Gateway موردنظر ما باید بتواند با تمامی این روش‌ها ارتباط برقرار کند.
یافتن آدرس سرویس‌ها
وقتی Gateway را پیاده‌سازی می‌کنیم باید به این موضوع فکر کنیم که نیاز داریم آدرس سرویس‌های مختلف را پیدا کنیم. در روش‌های قدیمی احتمالاً نرم‌افزارهای ما به‌راحتی روی یک سرور نصب می‌شوند و دانستن آدرس آن‌ها کار سختی نخواهد بود. اما در روش‌های جدید و استفاده از سرویس‌های ابری آدرس دیگر به‌سادگی و ثابت به دست نمی‌آید پس باید قبل از هر مسئله‌ای به یافتن آدرس میکروسرویس‌ها بیندیشیم. در قسمت‌های بعد به طور مفصل راجع به این مشکل و راه‌حل آن صحبت خواهیم کرد.
مدیریت خطاها
مشکل دیگری که هنگام توسعه یک API Gateway باید به آن بیندیشیم partial failure است. یعنی زمانی که یک درخواست کلی می‌آید و بخشی از درخواست قابل پاسخ‌گویی نیست. مثلاً در سیستم فروشگاه و صفحه جزئیات فروشگاه یکی از سرویس‌ها در دسترس نباشد. مثلاً سرویس پیشنهاد کالا در دسترس نباشد. API Gateway باید این قابلیت را داشته باشد که در این شرایط به‌جای اینکه کل درخواست را لغو کند، داده‌های بخش‌های صحیح را به دست آورد و برای بخش‌های مشکل‌دار خطا را مدیریت کند. برای مثال داده‌های کش شده داشته باشد که در این شرایط جایگزین داده‌های آنلاین شود. یا مثلاً درصورتی‌که سرویس پیشنهاد کالا قطع باشد ۱۰ کالای پرفروش را بازگرداند.
معرفی API Gatewayها
- Kong Gateway (OSS)
- Ocelot
- Apache APISIX
- Tyk
- KrakenD
- Gravitee.io API Platform
- Gloo Edge
- Goku API Gateway
- WSO2 API Microgateway
- Fusio
- Apiman
- API Umbrella
جمع‌بندی
در این قسمت راجع به یکی از الگوهای پرکاربرد و شرایط و نیازمندی‌های توسعه آن صحبت کردیم. پیاده‌سازی یک API Gateway خالی‌ازلطف نیست و می‌تواند به درک بهتر چگونگی پیاده‌سازی این الگو کمک کند. بااین‌حال برای پروژه‌های عملیاتی باتوجه‌به شرایط و نیازهای پروژه استفاده از ابزارهای آماده برای این کار مانند Kong، aws api gateway یا Ocelot گزینه‌های بهتری است
