الگوی: API Gateway / Backends for Frontends

تصور می کنیم شما در حال ساخت یک فروشگاه آنلاین هستید که از الگوی معماری میکروسرویس استفاده می کند و صفحه جزئیات محصول را اجرا می کنید. شما باید چندین نسخه از جزئیات محصول رابط کاربری ایجاد کنید:

• HTML5/UI مبتنی بر JavaScript برای مرورگرهای دسک تاپ و موبایل-HTML توسط یک برنامه وب سمت سرور ایجاد می شود
• مشتریان بومی اندروید و آیفون - این مشتریان از طریق API های REST با سرور تعامل دارند

علاوه بر این ، فروشگاه آنلاین باید جزئیات محصول را از طریق API REST برای استفاده توسط برنامه های شخص ثالث در معرض دید قرار دهد.

جزئیات محصول UI می تواند اطلاعات زیادی را در مورد یک محصول به نمایش بگذارد. به عنوان مثال ، صفحه جزئیات Amazon.com برای POJOS در نمایش های اکشن:

• اطلاعات اساسی در مورد کتاب مانند عنوان ، نویسنده ، قیمت و غیره
• سابقه خرید شما برای کتاب
• دسترسی
• گزینه های خرید
• موارد دیگری که اغلب با این کتاب خریداری می شوند
• سایر موارد خریداری شده توسط مشتریانی که این کتاب را خریداری کرده اند
• بررسی مشتری
• رتبه بندی فروشندگان
• …

از آنجا که فروشگاه آنلاین از الگوی معماری MicroService استفاده می کند ، داده های جزئیات محصول در چندین سرویس پخش می شود. مثلا،

• خدمات اطلاعات محصول - اطلاعات اساسی در مورد محصول مانند عنوان ، نویسنده
• خدمات قیمت گذاری - قیمت محصول
• سرویس سفارش - تاریخ خرید برای محصول
• خدمات موجودی - در دسترس بودن محصول
• خدمات مرور - بررسی مشتری…

در نتیجه ، کدی که جزئیات محصول را نشان می دهد ، باید اطلاعات را از همه این خدمات دریافت کند.

مسئله

چگونه مشتریان یک برنامه مبتنی بر میکروسرویس به خدمات فردی دسترسی پیدا می کنند؟

نیروها

دانه بندی API های ارائه شده توسط میکروسرویس اغلب با آنچه مشتری نیاز دارد متفاوت است. میکروسرویس ها به طور معمول API های ریز دانه را ارائه می دهند ، به این معنی که مشتریان باید با چندین سرویس تعامل داشته باشند. به عنوان مثال ، همانطور که در بالا توضیح داده شد ، مشتری نیاز به جزئیات مربوط به یک محصول دارد تا داده ها را از خدمات متعدد دریافت کند.

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

عملکرد شبکه برای انواع مختلف مشتری متفاوت است. به عنوان مثال ، یک شبکه موبایل به طور معمول بسیار کندتر است و از تأخیر بسیار بالاتری نسبت به یک شبکه غیر موبایل برخوردار است. و البته ، هر WAN بسیار کندتر از یک LAN است. این بدان معنی است که یک مشتری موبایل بومی از شبکه ای استفاده می کند که ویژگی های عملکرد بسیار متفاوتی نسبت به LAN دارد که توسط یک برنامه وب سمت سرور استفاده می شود. برنامه وب سمت سرور می تواند چندین درخواست برای خدمات پس زمینه ایجاد کند بدون اینکه بر تجربه کاربر تأثیر بگذارد ، جایی که به عنوان یک مشتری تلفن همراه فقط می تواند چند مورد را ایجاد کند.

تعداد نمونه های خدمات و مکان های آنها (میزبان+درگاه) به صورت پویا تغییر می کند

تقسیم به خدمات می تواند با گذشت زمان تغییر کند و باید از مشتری پنهان شود

خدمات ممکن است از مجموعه متنوعی از پروتکل ها استفاده کنند که برخی از آنها ممکن است دوستانه وب نباشند

راه حل

یک دروازه API را اجرا کنید که نقطه ورود به سیستم برای همه مشتری ها باشد. API Gateway از یکی از دو روش درخواست ها را انجام می دهد. برخی از درخواست ها به سادگی مجاورت/مسیریابی به خدمات مناسب می شوند. این درخواست های دیگر را با استفاده از چندین سرویس انجام می دهد.

دروازه API به جای ارائه یک API با اندازه یک اندازه ، می تواند API متفاوت را برای هر مشتری در معرض دید خود قرار دهد. به عنوان مثال ، Netflix API Gateway کد آداپتور خاص مشتری را اجرا می کند که به هر مشتری API را در اختیار شما قرار می دهد که متناسب با نیازهای آن باشد.

دروازه API همچنین ممکن است امنیت را اجرا کند ، به عنوان مثالتأیید کنید که مشتری مجاز به انجام درخواست است

تنوع: بالها برای جبهه ها

تنوع این الگوی ، پشتوانه های الگوی Frontends است. این یک دروازه API جداگانه برای هر نوع مشتری تعریف می کند.

در این مثال ، سه نوع مشتری وجود دارد: برنامه وب ، برنامه تلفن همراه و برنامه شخص ثالث خارجی. سه دروازه مختلف API وجود دارد. هرکدام یک API برای مشتری خود فراهم می کند.

مثال ها

زمینه

استفاده از یک دروازه API مزایای زیر را دارد:

• مشتری ها را از نحوه تقسیم برنامه در میکروسرویس ها عایق بندی می کند
• مشتری ها را از مشکل تعیین مکان های خدمات خدمات عایق بندی می کند
• API بهینه را برای هر مشتری فراهم می کند
• تعداد درخواست ها/دورگرد را کاهش می دهد. به عنوان مثال ، API Gateway به مشتریان این امکان را می دهد تا داده ها را از چندین سرویس با یک سفر یک دور بازیابی کنند. درخواست های کمتری نیز به معنای سربار کمتری است و تجربه کاربر را بهبود می بخشد. یک دروازه API برای برنامه های تلفن همراه ضروری است.
• مشتری را با حرکت منطق برای تماس با چندین سرویس از مشتری به API Gateway ساده می کند
• ترجمه از یک پروتکل API سازگار با وب عمومی "استاندارد" به هر پروتکل در داخل

الگوی API Gateway اشکالاتی دارد:

• افزایش پیچیدگی - دروازه API بخش دیگری است که باید توسعه یابد ، مستقر شود و مدیریت شود
• افزایش زمان پاسخ به دلیل هاپ شبکه اضافی از طریق دروازه API - با این حال ، برای بیشتر برنامه ها هزینه یک میزگرد اضافی ناچیز است.

• چگونه دروازه API را پیاده سازی کنید؟یک رویکرد رویداد محور/واکنشی بهتر است اگر باید مقیاس را برای رسیدگی به بارهای زیاد مقیاس کند. در JVM ، کتابخانه های مبتنی بر NIO مانند Netty ، Renactor Spring و غیره معنی دارند. Nodejs گزینه دیگری است.

الگوهای مرتبط

• الگوی معماری میکروسرویس نیاز به این الگوی را ایجاد می کند.
• API Gateway باید از الگوی کشف سمت مشتری یا الگوی کشف سمت سرور استفاده کند تا درخواست ها را به نمونه های خدمات موجود منتقل کند.
• دروازه API ممکن است کاربر را تأیید کرده و یک نشانه دسترسی حاوی اطلاعات مربوط به کاربر را به سرویس ها منتقل کند
• یک دروازه API برای فراخوانی سرویس ها از یک قطع کننده مدار استفاده می کند
• یک دروازه API اغلب الگوی ترکیب API را پیاده سازی می کند

استفاده های شناخته شده

برنامه مثال

به Gateway API که بخشی از برنامه مثال الگوی MicroService من است مراجعه کنید. با استفاده از بهار Cloud Gateway اجرا شده است.

درباره microservice.io

Microservice.io توسط کریس ریچاردسون برای شما آورده شده است. معمار نرم افزار با تجربه ، نویسنده Pojos in Action ، خالق اصلی CloudFoundry.com و نویسنده الگوهای MicroService.

کریس به مشتریان در سراسر جهان کمک می کند تا معماری میکروسرویس را از طریق مشارکت مشاوره و کلاسهای آموزشی و کارگاه های آموزشی اتخاذ کنند.

بیاموزید که چگونه یک الگوی سرویس و شاسی میکروسرویس ایجاد کنید

به Maing LiveProject من نگاهی بیندازید که به شما می آموزد که چگونه یک الگوی خدمات و شاسی های میکروسرویس را توسعه دهید.

Bootcamp مجازی جدید: الگوهای داده توزیع شده در یک معماری میکروسرویس

Bootcamp مجازی من ، الگوهای داده توزیع شده در یک معماری میکروسرویس ، اکنون برای ثبت نام باز است!

این الگوهای مدیریت داده توزیع شده از جمله SAGA ، ترکیب API و CQR را پوشش می دهد.

این برنامه شامل سخنرانی های ویدیویی ، آزمایشگاه های کد و یک کنفرانس ویدیویی هفتگی است که در منطقه های مختلف تکرار می شود.

قیمت معمولی 395 دلار در هر شخص است اما از کوپن WSSEULWL برای ثبت نام با قیمت 190 دلار استفاده می کنید (تا 30 نوامبر 2022 معتبر است). تخفیف های عمیق تری برای خرید چندین صندلی وجود دارد.

در مورد میکروسرویس ها بیاموزید

کریس منابع بی شماری را برای یادگیری معماری میکروسرویس ارائه می دهد.

کلاسهای آموزشی

کریس کارگاه های جامع ، کلاس های آموزشی و بوت کامپ ها را برای مدیران ، معماران و توسعه دهندگان آموزش می دهد تا به سازمان شما کمک کند تا از میکروسرویس ها به طور مؤثر استفاده کند.

از مشکلات مربوط به اتخاذ میکروسرویس ها و یادگیری مباحث اساسی مانند تجزیه و طراحی خدمات و نحوه بازپرداخت یکپارچه سازی یکپارچه به میکروسرویس خودداری کنید.

به صورت حضوری و از راه دور تحویل داده شد.

کتاب را دریافت کنید: الگوهای میکروسرویس

کتاب کریس ریچاردسون را بخوانید:

به عنوان مثال برنامه های میکروسرویس

آیا می خواهید مثالی ببینید؟برنامه های مثال کریس ریچاردسون را بررسی کنید. کد را مشاهده کنید

خدمات میکروسرویس را بسازید

خدمات مشاوره

کریس را برای ایجاد نقشه راه تصویب میکروسرویس درگیر کنید و به شما در تعریف معماری میکروسرویس کمک کند ،

پلت فرم رویداد

برای مقابله با چالش های مدیریت داده های توزیع شده در معماری MicroService خود از پلت فرم Eventuate.io استفاده کنید.

Eventuate آخرین راه اندازی کریس است. استفاده از الگوی SAGA برای مدیریت معاملات و الگوی CQRS برای اجرای نمایش داده ها آسان است.