با توجه به رشد سریع و افزایش نیاز روزافزون کاربران به پلتفرمها معماریهای کوچک دیگر جوابگو پروژههای بزرگ نیستند. در این مقاله به صورت ساده و کاربردی به پاسخ سوال API Gateway چیست؟میپردازیم و آن را در قالب یک مثال کاربردی پیادهسازی کنیم. با توجه به کارکرد DDD یا Domain Driven Design میتوان پروژه بزرگ را به بخشهای کوچکتری تقسیم کرد. این کار باعث آسانتر شدن مدیریت پروژه میشود. البته باید در نظر داشت که این بخشبندی مزایا و معایب خودش را دارد که ما در این مقاله به آن نمیپردازیم. قبل از شروع مبحث API Gateway و با توجه به مرتبط بودن مباحث به یکدیگر در ابتدا نگاهی کلی به معماری Monolithic و Microservices انداخته و مزایا و معایب هر کدام را به صورت خلاصه بیان خواهیم کرد.
API Gateway به تنهایی مفهوم کاملی نیست و کاربردی ندارد. برای مثال میتوان پدال دوچرخه را در نظر گرفت که به تنهایی کاربردی ندارد اما وقتی در درون یک مجموعه قرار میگیرد، هم خودش کاربردی میشود و هم کارکرد مجموعه را تکمیل میکند. API Gateway هم بخش کوچکی از یک مجموعه بزرگتر به نام Microservices Patterns است که با قرار گرفتن در آن مجموعه معنا پیدا میکند.
لزومی ندارد که در یک پروژه حتما از API Gateway استفاده کرد. بلکه با توجه نیازمندیهای پروژه میتوان از ابزارهای مختلفی استفاده کرد.
سناریو زیر را درنظر بگیرد:
فرض کنید شما برای اجرای یک پروژه فروشگاهی برنامهریزی کردهاید. اپلیکیشن شما باید به user interface های مختلفی مثل android ,IOS ,spa سرویسدهی کند. همچنین اپلیکیشن باید اطلاعات مربوط به محصولات را به صورت REST API برای ۳rd party applications فراهم کند. به طور مثال ممکن است برای یک سفارش یک محصول لازم باشد، اطلاعات زیر را از سرور بگیریم:
- Number of items in the shopping cart
- Order history
- Customer reviews
هنگامی که از معماریهای single application) Monolithic) استفاده میکنیم مشتری با یک درخواست کل اطلاعات را واکشی میکند به طور مثال با فراخوانی آدرس زیر دادهها در یک آبجکت نسبتا بزرگ برگشت داده خواهد شد.
GET api.company.com/productdetails/{productId}
وقتی این درخواست ارسال میشود، در اپلیکیشن سرویسهای مختلفی برای گرفتن داده اجرا میشوند. برای مثال سرویس مربوط به تاریخچه، تعداد فروش، نظرات کاربران و …
مزایای Monolithic
- برنامهنویسی به این سبک آسانتر است.
- به دلیل همگونی پروژه انتشار آن آسانتر است.
- نیاز به دانش بالایی ندارد.
معایب Monolithic
- هنگامی که پروژه بزرگ میشود، توسعه و نگهداری آن سختتر است.
- جوابگو تعداد درخواستهای زیاد نیست و سرور ممکن است Down شود.
- به دلیل همبستگی موجود در پروژه وقتی که یک قسمت از پروژه از کار بیفتد، کل سیستم مختل میشود.
برای پروژههای بزرگ با تعداد درخواستهای زیاد معماریهای Monolithic جوابگو نیستند. Microserver Patterns پروژه را به قسمتهای مختلف تقسیم میکند که در آن هر قسمت به صورت انحصاری وظیفه خود را انجام میدهد. این معماری هم مزایا و معایب خودش دارد:
مزایا:
- در این معماری میتوان در Subdomain های مختلف از تکنولوژیهای مختلفی استفاده کرد .
- به دلیل این که پروژه به قسمتهای کوچک شکسته شده است، مدیریت و توسعه آن در درازمدت آسانتر است .
- اگر قسمتی از پروژه از کار بیفتد در رویکرد کل پروژه اختلالی ایجاد نمیشود.
معایب:
- پیادهسازی Microserver Patterns پیچیدهتر است.
- اجرای آن نیاز به نیروهای کار متخصص دارد .
- مدیریت و انتشار Microserver Patterns نسبت به روش قبلی سختتر است .
در جدول زیر می توانید ویژگی های دو معماری Microservice و Monolith Architecture را به طور خلاصه ببینید.
Api Gateway چیست ؟
تا الان به صورت کلی و خلاصه دو معماری Microservices و Monolithic را توضیح دادیم و مقایسه کردیم. با توجه سناریو گفته شده پروژه را میتوان به subdomainها مختلف تقسیم کرد . subdomainها میتوانند بدون هیچ وابستگی بر روی هاستهای مختلف قرار بگیرند. در این صورت مشتریان برای fetch کردن داده باید یک تا چند درخواست را به سرورهای مختلف ارسال کنند. این کار باعث پیچیدگی زیادی در سطح کلاینت میشود. مثال بالا را در نظر بگیرید که در آن برای واکشی دادهها به این روش اقدام میکنیم:
- GET api.shoppingCart.com – Number of items in the shopping cart
- GET api.orderService.com – Order history
- GET api.catalogService.com – Basic product information, such as its name, image, and price
API Gateway مثل یک پل ارتباطی بین کلاینتها و subdomain های مختلف قرار میگیرد. در این صورت کلاینتها یک درخواست را برای API Gateway ارسال کرده و API Gateway طبق درخواست سرویسهای subdomainهای مختلف را فرا میخواند. اگر با الگو facade آشنایی داشته باشید. میدانید که در الگو facade مجموعهای از سرویسها را در یک سرویس مشخص مینویسیم و بجای فراخوانی سرویسهای متعدد یک سرویس مشخص را فراخوانی میکنیم .API Gateway به هم همین شکل عمل میکند. شما به جای فراخوانی Subdomainهای مختلف یک سرویس «API Gateway» را فراخوانی میکنید.
چرا باید از API Gateway استفاده کنیم؟
همان طور که گفته شد با استفاده نکردن از API Gateway کلاینتها باید برای گرفتن داده درخواستهای متعددی به سرورهای مختلف ارسال کنند. علاوه بر این نیازهای کلاینتهای مختلف با هم متفاوت است. یکی دیگر از مشکلاتی که ممکن پیش بیایید این است که هنگام آپدیت وب سرویسهای مختلف کل کلاینتها باید آپدیت شوند که کار سخت و زمانبری است و درصد خطای بالایی دارد. API Gateway مزایایی زیادی دارد اما پیادهسازی آن تقریبا سخت است و درصورت از کار افتادن لایه API Gateway کل درخواستهای کلاینت ها مختل میشود.
بیشتر بخوانید: پیادهسازی الگوی نرمافزاری دکوریتور
شروع به کد:
مواردی که تا کنون مطرح شد، توضیحاتی کلی درباره API Gateway بود. در ادامه این مقاله قصد داریم در یک یک مثال ساده API Gateway را در یک پروژه فرضی پیاده سازی کنیم. برای این کار از dotnet استفاده خواهیم کرد.
در این مثال قصد داریم سیستم مربوط به یک دانشگاه را به صورت نمونه پیادهسازی کنیم. پس در ابتدا باید نیازمندیهای سیستم را مشخص کنیم .
نیازمندیها:
- ثبتنام دانشجویان
- نمایش اطلاعات مربوط به دانشجویان
- نمایش درسها
- نمایش اطلاعات مربوط به هر درس
نیازهای یک پروژه با توجه به درخواستهایی واحد تجاری مشخص میشود. مرحله بعدی که شاید سختترین مرحله باشد، مشخص کردن subdomain ها است. این کار تجربی بوده و باید با توجه به درخواستهای بخش تجاری، قسمتهای مختلف پروژه باید به واحدهای کوچک و بدون وابستگی به هم تقسیم شوند.
هدف اصلی که سیستم برای آن رسیدن به آن ایجاد میشود Core Domain نامیده میشود.
در این مثال student و course را دو میکروسرویس جدا در نظر گرفته میشوند. با توجه به مواردی که گفته شد، دو میکروسرویس student و course خواهیم داشت همچنین یک API Gateway برای برقراری ارتباط بین کلاینت و میکروسرویسها ایجاد خواهیم کرد
یک solution برای سه پروژه به شکل زیر ایجاد کنید:
- Course.Microservice
- Student.Miroservice
- Gateway.WebApi
توجه کنید با توجه به مباحث مطرح شده هر microservice میتواند مستقل از microserviceهای دیگر دیتابیسهای متفاوتی داشته باشد. حتی شما میتوانید از زبانهای برنامهنویسی و معماریهای مختلفی در پیادهسازی استفاده کنید.
در این جا ما برای راحتی کار از دیتابیس in memory استفاده میکنیم.
پس مشخص شدن نیازمندیها و تشخیص ساختار پروژه سراغ کدنویسی میرویم. کدهای مربوط به هر sub domain را پیادهسازی کنید در این مثال ما سرویسهای CRUD را برای هر sub domain پیادهسازی میکنیم.
تا اینجا کار توانستیم نیازمندیهای را مشخص کنیم و مطابق با درخواست واحد تجاری پروژه را به دو subdomain مختلف تقسیم کنیم. سپس در هر subdomain سرویسهای CRUD را پیادهسازی کردیم.
برای اجرا پروژه بر روی solution راست کلیک و گزینه properties را انتخاب کنید و در حالت multiple startup projects دو پروژه Course.Microservice را Student.Microservice را به حالت start در آورید و پروژه را اجرا کنید.
برای راحتی کار بر روی هر پروژه swagger نصب شده است که به صورت پیشفرض هنگام شروع پروژه اجرا میشود.
پس از اجرا پروژه دو صفحه با پورت مختلف اجرا میشوند . شاید سختترین قسمت کار تا الان شناسایی subdomain ها بود. هر sub domain کدهایی شبیه معماری monolithic دارد البته با توجه به موارد گفته شده هر Microservice میتواند به هر روشی پیادهسازی شود.
در ادامه وارد پروژه gateway شوید. در این قسمت قصد داریم درخواستهای مربوط به هر کلاینت را مدیریت کنیم. برای ارتباط gateway با Microservice روشها و کتابخانههای زیادی وجود دارد. در این پروژه ما از Ocelot استفاده میکنیم.
Ocelot یک API Gateway متنباز برای .net است که توسط مایکروسافت توسعه داده شده است. با Ocelot کلاینتها دیگر نگران کار با Microservice های مختلف نیستند کاری که Ocelot انجام میدهد، گرفتن درخواست http مربوط به کلاینتها و فرستادن به Microservice مناسب است.
Ocelot برای نسخههای core وجود دارد و شما در .net استاندارد نمیتوانید از آن استفاده کنید.
دو مفهوم کلی API Gateway
در API Gateway دو مفهوم کلی وجود دارد :
Upstream:
درخواستی که از کلاینت به Api Gateway ارسال میشود.
Downstream:
درخواستی که از Api Gateway به Microservice ها ارسال میشود.
Ocelot چه قابلیتهایی دارد؟
- Routing the Incoming Request to the required Microservice
- Authentication
- Authorization
- Load Balance for Enterprise Applications
برای نصب Ocelot میتوانید از nuget استفاده کرده یا به روش زیر آن را نصب کنید:
Install-Package Ocelot
وارد پروژه Api Gateway شوید بعد از نصب Ocelot در دو کلاس Program.cs و Startup.cs تنظیمات مورد نیاز را انجام دهید .
اگه به Program.cs دقت کنید Ocelot با یک فایل جیسونی کانفیگ میشود. فایلی به نام ocelot.json در روت پروژه ایجاد کنید و به صورت زیر کانفیگ کنید:
"Routes": [
{
"DownstreamPathTemplate": "/api/student",
"DownstreamScheme": "https",
"DownstreamHostAndPorts": [
{
"Host": "localhost",
"Port": 44391
}
],
"UpstreamPathTemplate": "/gateway/student",
"UpstreamHttpMethod": [ "POST", "PUT", "GET" ]
}
]
}
در Ocelot.json یک آبجکت با یک سری property ساختیم که بیان کننده آدرس Microservice های مختلف است. در مثال بالا آدرس get میکروسرویس student را پیاده سازی کردیم. Property های هر قسمت واضح هستند و نیازی به توضیحات اضافه ندارند.
Postman را باز کنید و آدرس زیر را به صورت get فراخوانی کنید.
با فراخوانی آدرس بالا درخواست به صورت Upstream به Gateway ارسال شده و درون Gateway با کانفیگهای لحاظ شده به صورت Downstream به میکروسرویس مورد نظر ارسال میشود.
بقیه route ها هم مانند الگو بالا پیادهسازی کنید. برای تست بقیه سرویسها میتوانید فایل قرار داده شده در گیت هاب را درون postman باز کرده وسرویسها را فرخوانی و تست کنید.
جمعبندی
در این مقاله به صورت کلی و ساده درباره میکروسرویسها صحبت کردیم و مزایا و معایب آنها را بیان کردیم. در ادامه مقاله با جزئیات بیشتری به API Gateway پرداختیم و در قالب یک مثال ساده آن را پیاده سازی کردیم. هدف اصلی این مقاله آشنایی با مفهوم کلی API Gateway بود. در پروژههای مبتنی بر microserver patterns بخشهای زیادی را باید مطالعه کرد و نیاز به کسب دانش زیادی دارد. شما با مطالعه این مقاله قسمتی از معماری microserver را هم یاد گرفته و میتوانید در پروژههای کوچک آن را پیاده سازی کنید. سورس این پروژه را در ادرس گیتاب میتوانید clone کرده و کدهای نوشته شده را بررسی کنید.
دیدگاهتان را بنویسید