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

در معماری میکروسرویس، هر میکروسرویس مجموعه ای از (معمولا) نقاط پایانی ریز دانه را در معرض دید قرار می دهد. همانطور که در این بخش توضیح داده شد، این واقعیت می تواند بر ارتباط مشتری به میکروسرویس تأثیر بگذارد.ارتباط مستقیم مشتری به میکروسرویس یک رویکرد ممکن، استفاده از معماری ارتباط مستقیم مشتری به میکرو سرویس است. در این رویکرد، یک برنامه مشتری می‌تواند درخواست‌ها را مستقیماً به برخی از میکروسرویس‌ها، ارسال کند.در این رویکرد، هر میکروسرویس دارای یک نقطه پایانی عمومی است که گاهی اوقات برای هر میکروسرویس یک پورت TCP متفاوت دارد. نمونه ای از URL برای یک سرویس خاص می تواند URL زیر در Azure باشد:http://eshoponcontainers.westus.cloudapp.azure.com:88/در یک محیط تولید مبتنی بر یک خوشه، آن URL به بار متعادل کننده استفاده شده در خوشه نقشه می‌دهد، که به نوبه خود درخواست‌ها را در میان ریزسرویس‌ها توزیع می‌کند. در محیط های تولیدی، می توانید یک Application Delivery Controller (ADC) مانند Azure Application Gateway بین میکروسرویس های خود و اینترنت داشته باشید. این لایه به عنوان یک لایه شفاف عمل می کند که نه تنها تعادل بار را انجام می دهد، بلکه خدمات شما را با ارائه پایان SSL ایمن می کند. این رویکرد با بارگذاری خاتمه SSL فشرده CPU و سایر وظایف مسیریابی به Azure Application Gateway، بار میزبان شما را بهبود می بخشد. در هر صورت، متعادل کننده بار و ADC از نقطه نظر معماری کاربردی منطقی شفاف هستند.یک معماری ارتباط مستقیم مشتری به میکروسرویس می تواند برای یک برنامه کاربردی کوچک مبتنی بر میکروسرویس به اندازه کافی خوب باشد، به خصوص اگر برنامه مشتری یک برنامه وب سمت سرور مانند یک برنامه ASP.NET MVC باشد. با این حال، هنگامی که برنامه‌های کاربردی مبتنی بر میکروسرویس بزرگ و پیچیده می‌سازید (به عنوان مثال، هنگام مدیریت ده‌ها نوع میکروسرویس)، و به‌ویژه زمانی که برنامه‌های سرویس گیرنده، برنامه‌های تلفن همراه یا برنامه‌های وب SPA از راه دور هستند، این رویکرد با چند مشکل مواجه می‌شود.هنگام توسعه یک برنامه کاربردی بزرگ بر اساس میکروسرویس، سؤالات زیر را در نظر بگیرید:چگونه برنامه‌های سرویس گیرنده می‌توانند تعداد درخواست‌ها را به بک‌اند به حداقل برسانند و ارتباطات چت را به چندین میکروسرویس کاهش دهند؟تعامل با چندین میکروسرویس برای ایجاد یک صفحه رابط کاربری واحد، تعداد رفت و برگشت ها را در سراسر اینترنت افزایش می دهد. این رویکرد تاخیر و پیچیدگی را در سمت UI افزایش می دهد. در حالت ایده آل، پاسخ ها باید به طور موثر در سمت سرور جمع شوند. این رویکرد تأخیر را کاهش می دهد، زیرا چندین قطعه داده به صورت موازی برمی گردند و برخی از UI می توانند داده ها را به محض آماده شدن نشان دهند.چگونه می توانید نگرانی های مقطعی مانند مجوز، تبدیل داده ها، و ارسال پویا درخواست را مدیریت کنید؟پیاده سازی امنیت و نگرانی های بین بخشی مانند امنیت و مجوز در هر میکروسرویس می تواند به تلاش توسعه قابل توجهی نیاز داشته باشد. یک رویکرد ممکن این است که آن سرویس‌ها را در میزبان Docker یا خوشه داخلی برای محدود کردن دسترسی مستقیم به آنها از خارج، و پیاده‌سازی آن نگرانی‌های مقطعی در یک مکان متمرکز، مانند دروازه API، داشته باشیم.چگونه برنامه های سرویس گیرنده می توانند با سرویس هایی که از پروتکل های غیر اینترنتی استفاده می کنند ارتباط برقرار کنند؟پروتکل های مورد استفاده در سمت سرور (مانند AMQP یا پروتکل های باینری) در برنامه های مشتری پشتیبانی نمی شوند. بنابراین، درخواست ها باید از طریق پروتکل هایی مانند HTTP/HTTPS انجام شوند و پس از آن به پروتکل های دیگر ترجمه شوند. رویکرد مرد میانی می تواند در این شرایط کمک کند.چگونه می توانید یک نما که مخصوص برنامه های موبایل ساخته شده است را شکل دهید؟API چندین میکروسرویس ممکن است به خوبی برای نیازهای برنامه های کاربردی مشتری مختلف طراحی نشده باشد. به عنوان مثال، نیازهای یک برنامه تلفن همراه ممکن است با نیازهای یک برنامه وب متفاوت باشد. برای برنامه های تلفن همراه، ممکن است نیاز به بهینه سازی بیشتر داشته باشید تا پاسخ های داده کارآمدتر باشند. می‌توانید این عملکرد را با جمع‌آوری داده‌ها از چندین میکروسرویس و بازگرداندن یک مجموعه از داده‌ها، و گاهی اوقات حذف هر گونه داده در پاسخی که برای برنامه تلفن همراه مورد نیاز نیست، انجام دهید. و البته ممکن است این داده ها را فشرده کنید. باز هم، یک نما یا API بین اپلیکیشن موبایل و میکروسرویس ها می تواند برای این سناریو راحت باشد.چرا به جای ارتباط مستقیم مشتری به میکرو سرویس، دروازه های API را در نظر بگیریددر معماری میکروسرویس‌ها، برنامه‌های سرویس گیرنده معمولاً نیاز به استفاده از عملکرد بیش از یک میکروسرویس دارند. اگر این مصرف مستقیماً انجام شود، مشتری باید چندین تماس را با نقاط پایانی میکروسرویس انجام دهد. وقتی برنامه تکامل می یابد و میکروسرویس های جدید معرفی می شوند یا میکروسرویس های موجود به روز می شوند چه اتفاقی می افتد؟ اگر برنامه شما دارای ریزسرویس‌های زیادی است، رسیدگی به بسیاری از نقاط پایانی از برنامه‌های مشتری می‌تواند یک کابوس باشد. از آنجایی که برنامه مشتری با آن نقاط پایانی داخلی همراه می شود، توسعه میکروسرویس ها در آینده می تواند تأثیر زیادی برای برنامه های مشتری ایجاد کند.بنابراین، داشتن یک سطح متوسط یا ردیف غیرمستقیم (Gateway) می تواند برای برنامه های کاربردی مبتنی بر میکروسرویس مناسب باشد. اگر دروازه‌های API ندارید، برنامه‌های سرویس گیرنده باید درخواست‌ها را مستقیماً به میکروسرویس‌ها ارسال کنند و این مشکلاتی مانند مشکلات زیر را ایجاد می‌کند:اتصال: بدون الگوی API Gateway، برنامه های مشتری به میکروسرویس های داخلی کوپل می شوند. برنامه های سرویس گیرنده باید بدانند که چگونه مناطق مختلف برنامه در میکروسرویس ها تجزیه می شوند. هنگام تکامل و بازسازی ریزسرویس‌های داخلی، این اقدامات بر تعمیر و نگهداری تأثیر می‌گذارند، زیرا به دلیل ارجاع مستقیم به میکروسرویس‌های داخلی از برنامه‌های سرویس گیرنده، باعث ایجاد تغییرات در برنامه‌های مشتری می‌شوند. برنامه های سرویس گیرنده باید به طور مکرر به روز شوند و این راه حل را دشوارتر می کند.رفت و برگشت بیش از حد: یک صفحه/صفحه واحد در برنامه مشتری ممکن است به چندین تماس با چندین سرویس نیاز داشته باشد. این رویکرد می تواند منجر به چندین رفت و برگشت شبکه بین مشتری و سرور شود و تأخیر قابل توجهی را اضافه کند. تجمیع در سطح متوسط می تواند عملکرد و تجربه کاربر را برای برنامه مشتری بهبود بخشد.مسائل امنیتی: بدون دروازه، همه میکروسرویس‌ها باید در معرض «جهان خارجی» قرار گیرند و سطح حمله را بزرگ‌تر از مخفی کردن میکروسرویس‌های داخلی که مستقیماً توسط برنامه‌های مشتری استفاده نمی‌شوند، می‌کند. هرچه سطح حمله کوچکتر باشد، برنامه شما می تواند ایمن تر باشد.نگرانی های متقاطع: هر میکروسرویس که به صورت عمومی منتشر می شود باید به نگرانی هایی مانند مجوز و SSL رسیدگی کند. در بسیاری از موقعیت‌ها، این نگرانی‌ها می‌توانند در یک لایه مدیریت شوند، بنابراین میکروسرویس‌های داخلی ساده‌تر می‌شوند.