الگوی دروازه API در مقابل ارتباط مستقیم مشتری به میکرو سرویس قسمت دوم

الگوی API Gateway چیست؟هنگامی که برنامه های بزرگ یا پیچیده مبتنی بر میکروسرویس را با چندین برنامه مشتری طراحی و می سازید، یک رویکرد خوب برای در نظر گرفتن می تواند یک API Gateway باشد. این الگو سرویسی است که برای گروه های خاصی از ریزسرویس ها یک نقطه ورود تکی فراهم می کند. این شبیه به الگوی نما از طراحی شی گرا است، اما در این مورد، بخشی از یک سیستم توزیع شده است. الگوی API Gateway گاهی اوقات به عنوان "backend for frontend" (BFF) نیز شناخته می شود، زیرا شما آن را در حالی که به نیازهای برنامه مشتری فکر می کنید، می سازید.بنابراین، دروازه API بین برنامه های مشتری و میکروسرویس ها قرار می گیرد. به عنوان یک پروکسی معکوس عمل می کند و درخواست ها را از مشتریان به خدمات هدایت می کند. همچنین می تواند ویژگی های متقاطع دیگری مانند احراز هویت، خاتمه SSL و حافظه پنهان را ارائه دهد.برنامه‌ها به یک نقطه پایانی متصل می‌شوند، API Gateway، که برای ارسال درخواست‌ها به میکروسرویس‌های جداگانه پیکربندی شده است. در این مثال، API Gateway به عنوان یک سرویس سفارشی ASP.NET Core WebHost اجرا می شود که به عنوان یک کانتینر اجرا می شود.مهم است که برجسته کنید که در آن نمودار، از یک سرویس API Gateway سفارشی استفاده می‌کنید که با برنامه‌های مشتری متعدد و متفاوت روبرو است. این واقعیت می تواند یک خطر مهم باشد زیرا سرویس API Gateway شما بر اساس نیازهای مختلف برنامه های مشتری در حال رشد و تکامل خواهد بود. در نهایت، به دلیل آن نیازهای مختلف، پف می‌کند و به طور موثر می‌تواند شبیه یک برنامه یکپارچه یا سرویس یکپارچه باشد. به همین دلیل است که بسیار توصیه می شود که دروازه API را به چندین سرویس یا چندین دروازه کوچکتر API تقسیم کنید، به عنوان مثال، یکی از انواع فرم فاکتور برنامه هر مشتری.هنگام اجرای الگوی API Gateway باید مراقب باشید. معمولاً داشتن یک API Gateway که همه میکروسرویس های داخلی برنامه شما را جمع آوری می کند، ایده خوبی نیست. اگر این کار را انجام دهد، به عنوان یک جمع کننده یا ارکستر کننده یکپارچه عمل می کند و با جفت کردن همه میکروسرویس ها، استقلال میکروسرویس را نقض می کند.بنابراین، دروازه‌های API باید بر اساس مرزهای تجاری و برنامه‌های سرویس گیرنده تفکیک شوند و به عنوان یک جمع‌کننده واحد برای همه میکروسرویس‌های داخلی عمل نکنند.هنگامی که لایه API Gateway را به چندین دروازه API تقسیم می‌کنید، اگر برنامه شما دارای چندین برنامه مشتری باشد، می‌تواند محور اصلی در شناسایی انواع دروازه‌های API متعدد باشد، به طوری که می‌توانید برای نیازهای هر برنامه مشتری نمای متفاوتی داشته باشید. این مورد الگویی به نام "Backend for Frontend" (BFF) است که در آن هر دروازه API می تواند یک API متفاوت متناسب با هر نوع برنامه مشتری ارائه دهد، احتمالاً حتی بر اساس فاکتور فرم مشتری با پیاده سازی کد آداپتور خاص که در زیر چندین میکروسرویس داخلی فراخوانی می کند. همانطور که در تصویر زیر نشان داده شده است:یک برنامه وب سنتی به یک میکروسرویس MVC متصل می شود که از دروازه API وب استفاده می کند. این مثال یک معماری ساده شده با چند دروازه API ریزدانه را نشان می دهد. در این مورد، مرزهای شناسایی شده برای هر مدرسه API صرفاً بر اساس الگوی "Backend for Frontend" (BFF) است، بنابراین فقط بر اساس API مورد نیاز برای هر برنامه مشتری است. اما در برنامه‌های بزرگ‌تر نیز باید جلوتر رفته و برنامه‌های API دیگری را بر اساس مرزهای تجاری به عنوان محور دوم طراحی ایجاد کنید.ویژگی های اصلی در الگوی دروازه APIیک API Gateway می تواند ویژگی هایی را ارائه دهد. بسته به محصول، ویژگی‌های غنی‌تر یا ساده‌تری ارائه می‌دهد، با این حال، مهم‌ترین و مهم‌ترین ویژگی‌های هر دروازه API الگوهای طراحی زیر است:معکوس مسیریابی پروکسی یا دروازه. API Gateway یک پروکسی معکوس برای تغییر مسیر یا مسیریابی درخواست‌ها (مسیریابی لایه ۷، معمولاً درخواست‌های HTTP) به نقاط انتهایی میکروسرویس‌های داخلی ارائه می‌دهند. این دروازه یک نقطه پایانی یا URL برای برنامه های ارائه دهنده می کند و سپس به درخواست های داخلی داخلی می دهد را به گروهی از ریزسرویس های داخلی نگاشت می کند. این ویژگی به جدا کردن برنامه‌های سرویس گیرنده از میکروسرویس‌ها کمک می‌کند، اما هنگام انجام یک API یکپارچه با دادن دروازه API بین API یکپارچه و برنامه‌های مشتری، راحت است، سپس می‌توانید APIهای جدید را به‌عنوان ریزسرویس‌های جدید اضافه کنید. از آن استفاده می کنید. API یکپارچه تا زمانی که در آینده به مقدار زیادی از ریزسرویس تقسیم می شود. به دلیل وجود دروازه API، برنامه‌های سرویس گیرنده متوجه نمی‌شوند، آیا APIهای مورد استفاده به‌عنوان ریزسرویس‌های داخلی یا یک API یکپارچه پیاده‌سازی می‌شوند و مهمتر از آن، هنگام شروع و تغییر API یکپارچه به میکروسرویس‌ها، به لطف مسیریابی API Gateway، برنامه‌های مشتریان. با هیچ تغییری URI تحت تأثیر قرار نخواهد گرفت.درخواست تجمیع به عنوان بخشی از الگوی دروازه، می‌توانید درخواست کنید (معمولاً درخواست‌های HTTP) را با هدف قرار دادن میکروسرویس‌های داخلی در یک درخواست درخواست پاسخ‌گویی کنید. این الگو مخصوصاً زمانی مناسب است که صفحه/صفحه مشتری به اطلاعاتی از میکروسرویس نیاز دارد. با این، برنامه مشتری یک درخواست را به دروازه API ارسال می کند که درخواست را به میکروسرویس های داخلی ارسال می کند و سپس نتایج را جمع آوری می کند و همه چیز را به برنامه مشتری ارسال می کند. مزیت و هدف اصلی این الگوی طراحی، کاهش چت بین برنامه های مشتری و API باطن است، که به ویژه برای برنامه هایی از دور خارج از مرکز داده می شود که در آن میکروسرویس ها زندگی می کنند، مانند برنامه های تلفن همراه یا درخواست هایی که از برنامه های SPA می آیند، مهم است. جاوا اسکریپت در مرورگرهای راه دور مشتری. برای برنامه های وب معمولی که درخواست ها را در محیط سرور می دهد (مانند برنامه وب ASP.NET Core MVC)، این الگو بسیار مهم نیست زیرا بسیار کمتر از برنامه های راهنمای راه دور است.بسته به محصول API Gateway که استفاده می‌کنید، ممکن است این تجمیع را انجام دهید. با این حال، در بسیاری از موارد، ایجاد ریزسرویس‌های تجمیع تحت محدوده API Gateway پذیرش‌تر است، بنابراین تجمیع را در کد (یعنی کد C#) تعریف می‌کنید:اطلاعات مقطعی یا مربی دروازه. بسته به ویژگی‌هایی که هر محصول API Gateway ارائه می‌کند، می‌تواند عملکردها را از میکروسرویس‌های خارج از دروازه منتقل کند، که اجرای هر میکروسرویس را با ادغام نگرانی‌های متقابل در یک لایه ساده می‌کند. این ویژگی ویژه برای ویژگی‌های تخصصی که می‌تواند در هر میکروسرویس داخلی پیچیده باشد، مانند عملکرد زیر، مناسب است:احراز هویت و مجوزادغام خدمات کشفذخیره شده پاسخسیاست ها، قطع کننده مدار و QoS را دوباره امتحان کنیدمحدود کردن نرخ و گازمقایسه بارثبت، ردیابی، همبستگیهدرها، رشته های پرس و جو و تبدیل ادعاهاIP مجاز فهرستاستفاده از محصولات با ویژگی های API Gatewayبسته به هر پیاده‌سازی، نگرانی‌های متقابل بسیاری توسط محصولات API Gateways ارائه می‌شود. در اینجا بررسی می کنیم:Azure API ManagementOcelotAzure API ManagementAzure API Management نه تنها نیازهای API Gateway شما را برطرف می کند، بلکه ویژگی هایی مانند جمع آوری بینش از API های شما را ارائه می دهد. اگر از یک راه حل مدیریت API استفاده می کنید، یک API Gateway تنها جزء آن راه حل کامل مدیریت API است.Azure API Management هم نیازهای Gateway API و هم نیازهای مدیریتی شما مانند ورود به سیستم، امنیت، اندازه‌گیری و غیره را برطرف می‌کند. در این مورد، هنگام استفاده از محصولی مانند Azure API Management، این واقعیت که شما ممکن است یک API Gateway داشته باشید چندان خطرناک نیست زیرا این نوع دروازه‌های API "نازک‌تر" هستند، به این معنی که شما کد C# سفارشی را که می‌تواند به سمت یک جزء یکپارچه تکامل یابد، پیاده‌سازی نمی‌کنید.محصولات API Gateway معمولاً مانند یک پروکسی معکوس برای ارتباطات ورودی عمل می‌کنند، جایی که می‌توانید APIها را از میکروسرویس‌های داخلی فیلتر کنید و مجوز را برای APIهای منتشر شده در این لایه اعمال کنید.بینش‌های موجود از یک سیستم مدیریت API به شما کمک می‌کند تا درک درستی از نحوه استفاده و عملکرد API‌های خود داشته باشید. آنها این فعالیت را با امکان مشاهده گزارش های تحلیلی در زمان واقعی و شناسایی روندهایی که ممکن است بر تجارت شما تأثیر بگذارند، انجام می دهند. به علاوه، می‌توانید گزارش‌هایی درباره فعالیت‌های درخواست و پاسخ برای تجزیه و تحلیل بیشتر آنلاین و آفلاین داشته باشید.با مدیریت Azure API، می توانید API های خود را با استفاده از کلید، رمز و فیلتر IP ایمن کنید. این ویژگی‌ها به شما امکان می‌دهند سهمیه‌ها و محدودیت‌های نرخ انعطاف‌پذیر و دقیق را اعمال کنید، شکل و رفتار API‌های خود را با استفاده از خط‌مشی‌ها تغییر دهید، و عملکرد را با ذخیره پاسخ بهبود بخشید.در این راهنما و نرم افزار نمونه مرجع (eShopOnContainers)، معماری به یک معماری کانتینری ساده تر و سفارشی محدود شده است تا بر روی کانتینرهای ساده بدون استفاده از محصولات PaaS مانند مدیریت Azure API تمرکز شود. اما برای برنامه‌های کاربردی مبتنی بر میکروسرویس بزرگ که در Microsoft Azure مستقر شده‌اند، ما شما را تشویق می‌کنیم مدیریت API Azure را به‌عنوان پایه‌ای برای دروازه‌های API خود در تولید ارزیابی کنید.OcelotOcelot یک دروازه API سبک وزن است که برای رویکردهای ساده تر توصیه می شود. Ocelot یک دروازه API مبتنی بر منبع باز دات نت است که به ویژه برای معماری های میکروسرویس هایی ساخته شده است که به نقاط ورود یکپارچه به سیستم خود نیاز دارند. این سبک، سریع و مقیاس پذیر است و مسیریابی و احراز هویت را در میان بسیاری از ویژگی های دیگر فراهم می کند.دلیل اصلی انتخاب Ocelot برای برنامه مرجع eShopOnContainers 2.0 این است که Ocelot یک دروازه API سبک وزن هسته دات نت است که می توانید آن را در همان محیط استقرار برنامه که در آن میکروسرویس ها/کانتینرهای خود را استقرار می دهید، مانند میزبان Docker، Kubernetes، مستقر کنید. و غیره. و از آنجایی که مبتنی بر NET Core است، کراس پلتفرم است که به شما امکان می دهد روی لینوکس یا ویندوز مستقر شوید.نمودارهای قبلی که دروازه‌های API سفارشی را در کانتینرها نشان می‌دهند، دقیقاً نحوه اجرای Ocelot را در یک کانتینر و برنامه مبتنی بر میکروسرویس نشان می‌دهند.علاوه بر این، بسیاری از محصولات دیگر در بازار وجود دارند که ویژگی‌های API Gateways را ارائه می‌کنند، مانند Apigee، Kong، MuleSoft، WSO2، و محصولات دیگری مانند Linkerd و Istio برای ویژگی‌های کنترل‌کننده ورودی مش خدمات.بعد از بخش‌های توضیح اولیه معماری و الگوها، بخش‌های بعدی نحوه پیاده‌سازی API Gateways با Ocelot را توضیح می‌دهند.معایب الگوی دروازه APIمهمترین اشکال این است که وقتی یک API Gateway را پیاده سازی می کنید، آن ردیف را با میکروسرویس های داخلی جفت می کنید. اتصال مانند این ممکن است مشکلات جدی برای برنامه شما ایجاد کند. کلمنس واستر، معمار تیم اتوبوس خدمات Azure، در جلسه «پیام‌رسانی و میکروسرویس‌ها» در GOTO 2016 از این مشکل بالقوه به عنوان «ESB جدید» یاد می‌کند.استفاده از یک میکروسرویس API Gateway یک نقطه احتمالی دیگر از شکست ایجاد می کند.یک API Gateway می تواند زمان پاسخگویی را به دلیل تماس شبکه اضافی افزایش دهد. با این حال، این تماس اضافی معمولاً تأثیر کمتری نسبت به داشتن یک رابط مشتری دارد که به طور مستقیم با میکروسرویس‌های داخلی تماس می‌گیرد.اگر به درستی مقیاس بندی نشود، API Gateway می تواند به یک گلوگاه تبدیل شود.یک دروازه API اگر شامل منطق سفارشی و تجمیع داده ها باشد، به هزینه توسعه اضافی و تعمیر و نگهداری آینده نیاز دارد. توسعه دهندگان باید API Gateway را به روز کنند تا نقاط پایانی هر میکروسرویس را در معرض دید قرار دهند. علاوه بر این، تغییرات پیاده‌سازی در میکروسرویس‌های داخلی ممکن است باعث تغییرات کد در سطح دروازه API شود. با این حال، اگر دروازه API فقط امنیت، ورود به سیستم و نسخه‌سازی را اعمال می‌کند (مانند زمانی که از مدیریت API Azure استفاده می‌کنید)، این هزینه توسعه اضافی ممکن است اعمال نشود.اگر API Gateway توسط یک تیم توسعه داده شود، ممکن است یک گلوگاه توسعه ایجاد شود. این جنبه دلیل دیگری است که چرا یک رویکرد بهتر، داشتن چندین دروازه API ریز دانه است که به نیازهای مختلف مشتری پاسخ می دهد. همچنین می‌توانید API Gateway را به صورت داخلی به چندین ناحیه یا لایه‌هایی که متعلق به تیم‌های مختلف کار بر روی میکروسرویس‌های داخلی هستند، تفکیک کنید.