این نتایج بنچمارک دوره 20 ام وبسایت Techempower در تاریخ (2021-02-08) است.
شامل پرفورمنس تست فریم ورک ها، میکرو فریم ورک ها و کتابخانه های وب میشه.
نزدیک 440 وب فریمورک و نتایج شون برای عملیات های مختلف قابل مشاهده و مقایسه است. هر کدوم از بخش ها در این صفحه، عملکردشون در سناریو های متفاوت رو نشون میده. مثلا تصویر اولی که در بالا فرستادم، در بحث کار با دیتابیس شامل کوئری گرفتن و برگرداندن لیستی از داده ها در زمان اجرا، به کلاینت عملکرد 347 فریم ورک رو گزارش کرده.
در این گزارش، ستون ها به ترتیب نشان دهنده موارد زیر به ازای هر رکورد هستن:
نام framework، حداکثر میزان کارایی (بسته به نوع تست مثلا تعداد پاسخ در ثانیه، زمان سریالایز و deserialize کردن json و کوئری ها و ...)، نرخ پاسخ موفق (Success Rate) و ستون آخر شامل طبقه بندی (نوع فریم ورک مثلا micro/fullstack)، زبان برنامه نویسی مثلا Rust/Go، پلتفرم مثلا Net.، وب سرور مثلا Kestrel/Nginx، سیستم عامل (که معمولا Linux هست)، دیتابیس مثلا postgres/sql/mysql، سیستم عاملی که دیتابیس رو اجرا میکنه (معمولا Linux)، ORM و رویکرد پیاده سازی (Impl Approach).
هر گزارشی تقریبا به همین شکله با اندکی تغییر در جزئیات دیگر در ستون های ذکر شده. مثلا تست های JSON serialization، Plaintext، Single/Multiple Queries هر کدوم به شرح گزارش عملکرد این فریم ورک ها در این سناریو ها پرداختن.
در تصویر اول فوق که تست Fortune هست، aspcore-ado-pg رتبه 12 ام با 401 هزار پاسخ در ثانیه است. (asp.net core + ado.net + postgreSql Db)
(Furtune Test: This test exercises the ORM, database connectivity, dynamic-size collections, sorting, server-side templates, XSS countermeasures, and character encoding.)
در ردیف های اول فریم ورک و میکروفریم ورک هایی مثل dragon و actix به ترتیب با 666,660(تقریبا 670هزار) پاسخ در ثانیه قرار دارند. (این فریم ورک ها با زبان های c++ و rust کار میکنن که خیلی سریع تر و بهینه تر هستن، اما توسعه با اون ها کار به مراتب دشوار تری هست)
در نظر داشته باشین، بعضی از این web framework ها، خیلی کوچک و با یکسری کاربرد های محدود و مشخص هستند. در عین حال وب فریم ورک هایی مثل Asp.NetCore یا فریم ورک های بر پایه Java یا پایتون، امکانات و کاربردهای بیشتری برای نرم افزار های بزرگ و enterprise دارن. تا مدتی node js هم در ردیف های بالای گزارش ها بود، اما رفته رفته نزول پیدا کرد و کمتر توسعه داده شد، مخصوصا با قدرت گرفتن NetCore. و یا فریم ورک هایی که با زبان سریع rust طراحی میشدن. اما هنوز هم نسبت به php نتایج قابل قبول تری داره :))
در تصویر دوم، تست PlainText (که فقط یک برنامه HelloWorld ساده است با تعداد بسیار عظیمی درخواست که باید به همه اونها متن HelloWorld رو برگردونه) Asp.net Core در rank دوم با 7,016,966 (تقریبا 7 میلیون و 17 هزار) پاسخ در ثانیه و نرخ 99.9% قرار گرفته که به جرعت، شاهکاری در سال های اخیر برای Net. هست (چرا که از معایب اون ضعف در پردازش رشته ها و مشکلات GC برای اون بود که الان خیلی بهینه تر شده، خوبه که بدونید دات نت رشته های پراستفاده و تکراری رو نگه میداره و ازشون استفاده مجدد میکنه بنابراین حجمشون کمتر و سرعت بالاتر میره).
(PlainText Test: In this test, the framework responds with the simplest of responses: a "Hello, World" message rendered as plain text. The size of the response is kept small so that gigabit Ethernet is not the limiting factor for all implementations. HTTP pipelining is enabled and higher client-side concurrency levels are used for this test)
تست های متعدد دیگه ای هم هست که میتونین در سایت ببینید:
https://www.techempower.com/benchmarks
t.me/csharpfriends #Benchmark #Techempower #Performance

یک نکته درباره اجرای پروژه Blazor MicroBlog و عملکردش:

توجه داشتیه باشین که برای استفاده از قابلیت pwa پروژه Blazor MicroBlog و نصب اون مثل یک اپلیکیشن در دستگاهتون، باید خروجی publish از api بگیرید و روی https اجرا کنین (ترجیحا Edge/Chrome)
(همچنین برای تست میتونید نسخه v0.8-beta1 PreRelease رو از قسمت releases گیتهاب پروژه دانلود و اجرا کنید)
برنامه سرور Api، اپ کلاینت رو داخل Net. پراکسی و هاست میکنه. از مزایای این روش عدم نیاز به اجرای جداگانه پروژه ها، caching یکپارچه تر، تست و اجرای نسخه pwa برنامه است.
تنها عیب این حالت نیاز به net core. برای اجراست که در هر صورت برای اجرای پروژه سرور نیازه. بعد از اون رابط کاربری روی مرورگر کاربر ذخیره و از همونجا اجرا میشه. بنابراین سرور سبک تر خواهد بود و کلاینت هم میتونه از قابلیت offline استفاده بکنه. چرا که نیاز به گرفتن صفحات از سرور نداره و از وب اسمبلی استفاده میکنه.
اگر نمیخواین از مدل Net Hosted. استفاده کنین، باید سرویس های Blazor رو از فایل startup سرور حذف کنین. در اینصورت پروژه کلاینت blazor رو باید دستی هاست و اجرا کنین که یکم دردسر داره. و بعدا روشش رو میگم. (چون فقط static file دارید)

خوشحال میشم دوستانی که علاقه مند هستن، نسخه 0.8 بتا پروژه MicroBlog رو تست کنن و بازخورد بدن. میتونید مستقیما exe برنامه رو اجرا کنین، بدون دردسر و کامپایل. در release ها موجوده)

https://github.com/mrgrayhat/BlazorMicroBlog
t.me/csharpfriends
#Blazor #Net5 #WebAssembly #BlazorHosted

از سری مفاهیم معماری میکروسرویس ها، Api Gateway چیست و چه کاربردهایی دارد:

1. مدیریت متمرکز درخواست ها و خروجی ها، logging و trace
2. اعمال محدودیت و مکانیزم های مختلف به فرآیندها، مانند
QOS، Rate Limiting، Load Balancing, Service Discovery, Authorization
3. پنهان کردن پیچیدگی ها و ساختار سرویس های سمت سرور، ایزوله کردن میکروسرویس ها
4. سهولت کلاینت ها در ارتباط با برنامه شما به طور متمرکز (البته که نیاز به مستندات برای توسعه کلاینت های external هست، که در مطلبی جدا به آن خواهم پرداخت)
5. امکان Scale Gateway ها برای بهبود عملکرد در شرایط مختلف مانند مناطق جغرافیایی، شبکه های و ...

در اکثر معماری های مبتنی بر سرویس، ارتباطات میان سرویس ها به شکل غیرمتمرکز و Mesh میباشد. به این صورت که سرویس ها consumer یکدیگر اند و به یکدیگر ریکوئست میزنند و پاسخ دریافتی را پردازش یا به سمت کلاینت ارسال میکنند.
پروژه ای شامل چند سرویس(Bounded Context) از جمله Auth, Shopping, Storage و ... را تصور کنید. این پروژه توسط یک یا چند کلاینت وب و موبایل مورد استفاده قرار میگیرد.
کلاینت[ها] باید برای دریافت اطلاعات محصولات فروشگاه با سرویس Shopping در ارتباط باشد. همچنین باید تراکنشها و خرید کاربران را هم ثبت نماید. جهت امور احراز هویت با سرویس Auth تبادل انجام دهد (مثلا توکن هارا دریافت کند یا توکن اعتبار سنجی شود) و در آخر به منظور انجام فرآیند پرداخت با سرویس Payment ارتباط بگیرد.
همچنین ممکن هست سرویس ها نیازمند ارتباط با یکدیگر هم باشند (مثلا آپلود و دانلود فایل یا نیاز به دیتاهای سرویسهای دیگر).
در ظاهر، ماجرا ساده و کم اهمیت است زیرا تعداد سرویس های سرور کم و نهایتا کلاینت به یک وبسایت و اپلیکیشن ختم شده.
حال سرویس دیگری اضافه میشود یا سرویسی تغییرات زیادی میکند. علاوه بر این که سرویس های وابسته دیگر هم ممکن هست نیازمند بروزرسانی و تغییرات باشند، کلاینت ها هم ملزم به اعمال بروزرسانی ها هستند. (توابع، کدهای generate شده، cache و آدرس endpoint api ها و ...)
در اینجا اتصال سفت سرویس ها آنها را شدیدا به یکدیگر وابسته میکند.
نکته بعدی مانیتورینگ، رهگیری و خطایابی و دشوار شدن مباحثی چون
Load balancing, Distributing, QoS & Circuit breaking, Rate Limiting
و مدیریت آنهاست.
اگر بخواهید یک instance دیگر از سرویس x اجرا کنید تا فشار درخواست ها را توزیع کنید نیازمند تغییرات در کدها، راه حل های سخت و یا دستی هستید(هارد کد، کش و میان افزار)، زیرا انعطاف زیر ساخت مورد نیاز برای scale کردن را ندارید.

اگر بخواهید فرآیند درخواست یک کاربر را رصد و لاگ کنید نیاز به جمع آوری و بررسی لاگ همه سرویس هاست. (مخصوصا اگر یک درخواست کارهای زیادی با سرویس های دیگه پشت صحنه انجام بده).
مثلا کاربر saeed درخواست خرید یک محصول را ثبت کرده و به دلایلی با خطا و مشکل مواجه شده (در پروسه احراز هویت یا ثبت درخواست، تغییر موجودی و یا پرداخت.
توسط log tracing/tracking از شروع درخواست تا پایان‌ آن، همه لاگ های ثبت شده در این بین مشخص میشوند. فرضا از سرویس x به y و توابع api آن، لاگ ها دنباله دار حاوی یک شناسه برای track اند).
اگر سرویسی برای انجام درخواستش وابسته به نتیجه سرویس دیگری باشد که به خطا خورده و یا متحمل پردازش زیادی شده، کلاینت به کلیه سرویس های وابسته مادامی که خروجی نگیرد فشار میاورد (یا timeout و یا پاسخ واقعی نمیدهد). در چنین حالتی کنترل تک تک سرویس ها و اعلام خروجی مناسب به کلاینت ها [و سرویس ها] یا جلوگیری از crash کردن و حملات DDos کار سخت و طاقت فرساییه( ddos فقط مختص عوامل خارجی نیست هر چند یک عامل خارجی ناخواسته هم میتواند شروع کننده آن باشد در هر سطح امنیتی)
مفاهیم
Load Balancing, Qos (Quality Of Service) & Circuit Breaker
برای حل این مشکلات بسیار کمک کننده اند. اما لازمه آنها پیکربندی مناسب و معماری منعطف میباشد.

در ادامه به بیان چند تا از مهمترین و رایج ترین مشکلات، در پروژه های مبتنی بر سرویس، مقیاس متوسط و بزرگ و راه حل های مطرح آنها میپردازیم. در نظر داشته باشید که همیشه راه حل های متعددی برای رفع مشکلات وجود دارند. وظیفه معمار/توسعه دهنده خوب ارائه و پیاده سازی مناسبترین راه حل برای سولوشِن است.
اینکه به بهانه پرفورمنس بالا، وقت کم یا دانش کم، با تولید مجدد چرخ یا روش های پاسخ سریع، بخواهیم صورت مسئله را موقتا کم رنگ کنیم معضلاتی از جمله:
آسیب پذیری های امنیتی (علل خصوص zero day)، کاهش بهره وری و کیفیت خدمات و افزایش نارضایتی، افزایش پیچیدگی و حجم سنگین توسعه و نگهداری نرم افزارها و زیر ساخت ها، از جمله مشهود ترین عواقب چنین تصمیمات و پیاده سازی هایی خواهد بود.
Don't Repeat yourself.
Dry/Wet

یکی از معایب blazor web assembly در حال حاضر حجم خروجی برنامه است. به طوری که به نسبت رقباش مثل آنگولار و react.js، چند برابر حجمش بیشتره. این مسئله در load اولیه برنامه محسوسه. چون اسمبلی ها و فایل ها باید روی مرورگر کاربر دانلود بشه. از طرفی، اسمبلی ها باید به شکلی تفسیر بشن و این سرعت رو کاهش میده.
اما بعد از لود اولیه، فایل ها cache میشن و در عرض چند ثانیه صفحه load میشه. در جابجایی بین صفحات و تغییر محتوای صفحات عملکرد خوبه. منتها همون بحث بارگزاری اولیه برنامه و رفرش کردن صفحات هست که نمیشه گفت Blazor از بقیه سریعتر و بهینه تره. اما این نوید رو میشه داد که در نسخه Net6. ( که در ماه نوامبر ۲۰۲۱ November 2021) پرفورمنس به طور قابل ملاحضه ای افزایش پیدا میکنه. این افزایش پرفورمنس و بهینه سازی، فقط مختص blazor نیست. تمام فریم ورک های تحت دات نت 6 از جمله xamarin, asp, wpf, blazor هر کدوم به نحوی تحت تاثیر قرار میگیرن.
بحث AOT در نسخه فعلی blazor پشتیبانی نمیشه. به دلایل متعددی blazor همچنان در حال توسعه است و به خاطر ماهیت وب اسمبلی، در نسل بعدیش حتما به لحاظ بنچمارکی هم حرف برای گفتن زیاد خواهد داشت. یک برنامه وب اسمبلی، منطقا باید سریعتر از برنامه های غیر native و جاوا اسکریپتی باشه. به گفته تیم blazor مایکروسافت، نسل بعد سرعتی نزدیک به native خواهد داشت و این یعنی حداقل ۲۰ برابر سرعت فعلی.
اما این قضیه تا چه حد میتونه عملی بشه؟ اگر مطالب و صحبت هاشون رو دنبال کرده باشید، یکی از مشکلاتی که تیم blazor دارن، بحث استفاده از Mono هست که به این دلیل فعلا امکان افزودن aot در نسخه 5 نیست، چرا که باید بازنویسی هایی بخاطرش انجام بشه و تغییراتی مثل کامپایل بخش ها و اسمبلی هایی به native صورت بگیره تا نیاز به مفسر زبان میانی IL کمتر بشه. در اینصورت کدهای اصلی با پرفورمنس نزدیک به native اجرا میشن.
امکانات و برنامه های زیاد دیگه ای هم در نقشه راه یا همون Net6 Roadmap. وجود داره. نکته ای که حائز اهمیته اینه که دات نت چند قدم پر ریسک و مهم رو به جلو برده. همون طور که با اومدن NetCore.، دات نت فریمورک با دگرگونی بزرگی همراه شد، رفته رفته تکنولوژی ها بهتر و کاملتر میشن. این وسط همیشه یک عده هستن که ساز مخالف و منفی میزنن یا با مقایسه های اشتباه دنبال خوب و بد میگردن.

همونطور که ربط دادن و مقایسه مباحثی مثل معماری با دیزاین پترن، نادرسته و درک صحیح از مطالعه و تجربه میطلبه، مقایسه نادرست مباحثی مانند وب اسمبلی و blazor، با آنگولار و فلاتر هم بسی ناشیانه است.
اول باید ببینیم به درک درستی رسیدیم یا نه. الزاما ده ها سال کار کردن ما رو عالم و حرفه ای نمیکنه. همونطور که ده ها سال عبادت و درس خوندن به تنهایی، از کسی مومن و کاربلد و دانشمند نمیسازه. در هر حوزه ای که وارد میشیم، قبل از حرف زدن تحقیق کنیم. مقالات خارجی درست و حسابی، پروژه های متن باز و اجرا شده، افراد متخصص در اون حوزه. بعد از اون عمل کنیم. صرف دونستن تئوری کافی نیست.
وقتی به درک صحیحی از موضوع رسیدیم، اونوقت میتونیم مثلا معایب یک معماری یا مزایای فلان فریم ورک رو به چالش بکشیم. تفسیر خودتون از مسئله رو، جواب درست ندونین. ساده تر بگم، خودتون رو عقل کل فرض نکنین! خیلی از عقل کل ها یک روزی فهمیدن اشتباه میکردن و تصحیح کردن نمونه اش نظریات انیشتین، خیلی های دیگم تا اخر عمر در جهالتشون پافشاری میکردن.
اینجانب که ادعایی در دانش ندارم و همواره در پی بروز کردن، تجربه کردن و اشتراک گذاری اون هستم. در حد توانم به موضوعاتی که تسلط خوبی داشته باشم میپردازم و بقیه رو به آینده موکول میکنم. (مثلا اخیرا خواستم راجع به هوش مصنوعی و یادگیری ماشین بنویسم که منصرف شدم و تصمیم گرفتم هر زمان پی مطالعه و تجربه کردنش رفتم ازش بنویسم، یا در حوزه پیاده سازی میکروسرویس ها، تجربه و موضوعات مختلفم رو سر جمع میکنم و با مثال قرار خواهم داد. به همین دلیل فعلا pause اش کردم)
@csharpfriends
#SoftwareEngineering #SoftwareArchitecture

Circuit Breaker & QOS (Quality of service) مکانیزم

مفهوم QOS یا کیفیت خدمات، توانایی ارائه اولویت های مختلف برای برنامه های مختلف و یا تضمین سطوح معینی از عملکرد یک جریان داده را بیان میکند. از معروف ترین کتابخانه هایی که پیکربندی و استفاده از این مکانیزم را فراهم میکنند کتابخانه Polly است که معمولا در کنار کتابخانه Ocelot با Api Gateway استفاده میشوند.
در صورتی که فرآیندی دچار اختلال و خطا شود، همه کلاینت ها خطا دریافت میکنند.
به عنوان مثال واکشی داده از سرویس منجر به رخ دادن استثناء هایی میشود. کلاینت ها هر بار درخواست قبلی را تکرار میکنند تا بلکه جوابی دریافت کنند و هزینه این اختلال، فشار به سرویس ها و حجم زیادی از درخواست ها است که میتواند منجر به کاهش پرفورمنس و تولید انبوهی لاگ و خطا شود.

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

توسط این مکانیزم وقتی سرویس/برنامه ای به مشکل میخورد، دیگر درگیر درخواست ها و پردازش های تکراری نمیشود، تا زمانی که تیم فنی هشدار مربوطه را دریافت کرده و مشکل را رفع کنند و یا سرویس به حالت stable برسد.

برخی از مهمترین پارامترهای مکانیزم QOS:
- تعداد استثناء های مجاز قبل از قطع جریان یا ExceptionsAllowedBeforeBreaking بیان کننده تعداد خطاهایی است که اگر بیبشتر از آن خطا رخ دهد، جریان سرویس قطع میشود.
- مدت زمان قطع جریان یا DurationOfBreak تعیین کننده زمانی است که سرویس از دسترس خارج میشود و اصطلاحا جریان های داده آن (درخواست ها و پاسخ ها ...) قطع میشوند، و سپس مجددا آزاد میشود.
- مدت زمان پایان دادن درخواست یا TimeoutValue تعیین کننده زمانی است که باید پس از آن درخواست متوقف شود و time out برگرداند. مثلا اگر مقدار را روی 10000 بگذارید(10ثانیه)، درخواست هایی که بیشتر از 10 ثانیه طول بکشند بطور خودکار متوقف شده و به time out میخورند.

به این ترتیب میتوان کنترل و دسترسی پذیری بهتری را برای سرویس ها مهیا کرد تا در صورت بروز هر نوع اختلال حادی، بتوان از آن مطلع شد و در عین حال فشار و پردازش زیادی را از روی دوش سرور و کلاینت کاست. معمولا QOS را در API Gateway ها (به صورت Global یا برای هر سرویس) پیاده و کانفیگ میکنند. هر چند که میتوان در کدهای هر سرویس هم اینکار را کرد اما مقصود در اینجا یکبار انجام دادن آن (در gateway) و ایجاد انعطاف برای هر سرویسی است.

https://ocelot.readthedocs.io/en/latest/features/qualityofservice.html

@csharpfriends
#ApiGateway #MicroService #Gateway #QOS #SoftwareArchitecture

مثالی از مکانیزم QoS و Circuit Breaker در یک API، که به خوبی فرآیند قطع جریان پس از رخ دادن خطا و سپس ادامه کار پس از باازگشت به وضعیت stable را نشان میدهد.
#Polly #QOS #Microservice

مکانیزم محدود کننده نرخ (Rate Limiting)

فرض کنید سرویسی در ثانیه چند صد درخواست پشت سر هم و بسیار سریع از کلاینت دریافت کند.
فرضا درخواست یک واکشی داده سنگین، میبایست صدبار اجرا شود ( حتی اگر کش هم داشته باشید فقط مرحله واکشی رو رد کردید). بنابر دلایل متعددی مانند حمله DDos، ربات ها و یا ارسال خیلی سریع درخواست به سرویس ها، سرویس های شما بی دفاع و آسیب پذیر هستند. ( در یک اپلیکیشن که اخیرا مینوشتیم کاربر میتونست تند تند صفحه رو با pull کردن رفرش کنه و جدای از داشتن کش به هر حال سرورو با ریکوئست های زیاد درگیر میکرد، یا همیشه خدا ربات های خزنده خارجی به endpoint های مختلف حمله میکردن)
مکانیزم محدود کننده نرخ تبادل (rate limiting) تعیین میکند که هر کلاینت مجاز به ارسال چند درخواست در ثانیه/دقیقه/ساعت/... است.
مثلا سرویس Payment(پرداخت) را طوری تنظیم کردید که اجازه ارسال 1 درخواست در فاصله زمانی 1 ثانیه را میدهد. هر کلاینتی که در طول 1 ثانیه، بیش از 1 درخواست ارسال کند پیامی مبنی بر محدود شدن به مدت 10 ثانیه دریافت میکند و زین پس درخواست های وی تا 10 ثانیه آینده بدون رسیدن به سرویس رد میشوند(چه 1 ریکوئست و چه 1000).

مهمترین پارامتر های مورد استفاده در این مکانیزم به شرح زیر میبباشد:
- دوره زمانی یا Period مشخص کننده بازه زمانی مجاز میبباشد، مثلا 1s/5m/1h/1d (1ثانیه/5دقیقه/1ساعت/1روز)
- زمان انتظار دوره یا Period Timespan تعیین کننده مدت زمانی است که میتوان پس از آن مجددا درخواست ارسال کرد. اگر کلاینت محدود شود و مثلا period timespan روی 10 تنظیم شده باشد، پس از گذشت 10 ثانیه مجاز به ارسال درخواست واقعی میشود.
- میزان محدودیت یا Limit تعیین کننده تعداد درخواست مجاز در بازه زمانی تعریف شده در Period است. بیشتر از این مقدار منجر به فعال شدن Period Timespan و اعمال محدودیت میشود.
- پیام تکمیل سهمیه مجاز یا QuotaExceededMessage حامل پیامیست که هنگام محدود شدن کلاینت به وی ارسال میشود.
- لیست سفید کلاینتها یا ClientWhitelist میتواند در بردارنده کلاینت های به خصوصی باشد که مکانیزم RateLimiting روی آنها اعمال نمیشود (مثلا کلاینت هایی مثل پنل ادمین که بهشون اطمینان دارید)
- کد وضعیت یا HttpStatusCode تعیین کننده http code دلخواهیست که هنگام رخ دادن مکانیزم محدودیت به کلاینت ارسال میشود (استاندارد کد 409 نشان دهنده وضعیت Too Many Request است)

https://ocelot.readthedocs.io/en/latest/features/ratelimiting.html

نمونه ای از مکانیزم Rate Limiting
و رخ داد Quota Exceeded
کلاینت محدود شده و خطای 409 و پیام مناسب را دریافت کرده، همچنین مشخص شده که میتواند پس از 1 ثانیه مجددا سعی کند (Retry After : 1)
#Ocelot #ApiGateway #Microservice

مکانیزم توزیع کننده و متعادل کننده بار (Load Balancing & distribution )

سناریویی را فرض کنید که تعداد درخواست های زیاد و یا پردازش های سنگینی دارد، در این شرایط سرویس ها اصطلاحا زیر بار سنگینی میروند و به کندی پردازش میکنند و پاسخ میدهند. حتما تا به حال راجع به load test و stress test شنیده اید (اگر نه مطلبی در این باره به صورت جدا خواهم نوشت که دانستنش واجب است). در این تست ها سناریو های متعدد را میچینند و سرویس ها را در شرایط مختلف مانند ۱۰۰۰ یوزر در ثانیه، ۱۰۰ کوئری در ثانیه، نرخ بروز خطا، سرعت پردازش صفحات و ... آنها را تست میکنند.
یکی از نتایج، میزان باری است که سرویس در بهترین، میانگین و بدترین شرایط در این سناریو ها میتواند تحمل کند. به عنوان مثال وبلاگی را تصور کنید که در ثانیه ۱۰۰۰ درخواست را دریافت و پردازش میکند، بسته به پرفورمنس شما ممکن است هر پاسخ میانگین 100 الی 30000 میلی ثانیه طول بکشد. نتیجتا پیگیر پرفورمنس کدهای نوشته شده خواهید شد و یا به فکر کلاستر و یا توزیع این بار روی چند instance و سرور دیگر از سرویس خواهید افتاد یا مثل خیلی ها میرید سراغ آپگرید سخت افزار و صورت مسئله را نادیده میگیرید.
مقاله های متعددی به چگونگی انجام این کار پرداخته اند و بسته به تکنولوژی مورد استفاده شما، روش ها و ابزار های متفاوتی معرفی شده که یکی از معروفترین ها کانتینر های داکر و ابزارهای kubernetes و swarm هستند.
نرخ پاسخ دهی مناسب، مصرف بهینه تر منابع و امکان scale کردن سرویس ها و سرور ها از برجسته ترین مزایای این روش میباشد. در عین حال، افزایش میزان پیچیدگی پیاده سازی، تاخیر، دیباگ، کنترل و به روزرسانی آنها از مورد توجه ترین معایب هستند. (که در مفاهیم میکروسرویس این امر بدیهی و مشهود است)
به مثال قبل برمیگردیم، سرویس بلاگ که وظیفه واکشی و درج اطلاعات را دارد میتواند به دو instance افزایش پیدا کند که هر کدام روی پورت دیگری در سرور listen میشوند. حال وظیفه سرویس اصلی (Gateway, Hub) این است که درخواست ها را طوری هندل کند که فشار بر روی هر دو instance تقسیم شده و طبیعتا نرخ پاسخ دهی و عملکرد را افزایش دهد.
مکانیزم ها و الگوریتم های مختلفی در این باره هست که تعیین کننده مکانیزم تقسیم بار و بالانس میان سرویس هاست.
یکی از این الگوریتم ها Round Robin یا الگوریتم پردازش نوبتی است. در این مدل، درخواست ها به صورت نوبتی به instance های موجود سرویس ها ارجاع میشود. مثلا اول به سرویس blog1 و درخواست بعدی به blog2.
الگوریتم دیگر LeastConnection به این شکل عمل میکند که درخواست های جدید را به instance ای که کمترین درخواست را پیش از این داشته، ارجاع میدهد. بدینصورت رهگیری درخواست ها و توزیع آنها محاسبه شده و اگر سرویس blog1 رکوئست های زیادتری دریافت کرده، زین پس تا مقطعی درخواست ها به blog2 داده میشوند، این کار میتواند برای متعادل کردن بار درخواست ها به طور نسبتا مساوی تری نسبت به الگوریتم نوبتی (که هر کس نوبتش باشه باید بپذیره) عمل کند. (هر کس سرش خلوت تره میپذیره)
الگوریتم Cookie Sticky Sessions از یک کوکی برای کلاینت ها استفاده میکند و در کوکی درج میشود که درخواست ها به کدام سرور ارسال شود. ممکن است برای یک کلاینت سروری در آسیا عملکرد بهتری از سروری در اروپا بدهد، پس این کلاینت با همان آدرسی که در کوکی اش ذخیره شده ارتباط میگیرد.

در مطلبی دیگر درباره چگونگی پیاده سازی و استفاده از این مکانیزم ها به کمک کتابخانه مشهور Ocelot.net در API Gateway ها میپردازیم و میزان بار میان سرویس ها را تقسیم میکنیم. همچنین توضیحاتی درباره ocelot و قابلیت های دیگر آن به همراه کتابخانه های هم خانواده وی ارائه خواهم کرد.

https://ocelot.readthedocs.io/en/latest/features/loadbalancer.html

@csharpfriends
#Microservice #ocelot #ApiGateway #LoadBalancing

بررسی اجمالی پیکربندی API Gateway یا گلوگاه با کتابخانه Ocelot

حال نگاهی به کتابخانه بسیار کاربردی ocelot می‌اندازیم. ocelot یک کتابخانه برای ساخت api gateway ها یا همان گلوگاه های برنامه است که به شما امکان پیکربندی آدرس ها و سرویس های مورد نظر و تعداد زیادی امکانات دیگر را میدهد.
در کانفیگ زیر، درخواستی که به مسیر blog/ در gateway میرسد با نام Upstream Path مشخص شده که ورودی ما هست(درخواست کلاینت یا سرویس دیگری)، بسته به کانفیگ به Downstream تعیین شده ارجاع داده میشود. (path ها همراه پارامترها و متد ها به همدیگر map میشوند، مانند routing mvc، عملا درخواست ها فقط ارجاع میشن و پاسخ دریافتی از سرویس ها از طریق gateway به کلاینت برمیگردد)
در این کانفیگ، دو instance از سرویس Blog اجرا شده و یکی از دو Down stream توسط مکانیزم load balancing انتخاب میشود.
پارامتر Downstream Path آدرس مسیریابی میکروسرویس ها را مشخص کرده و Downstream Scheme و HostAndPort به ترتیب پروتکل آنها و url و پورتی که هاست شده اند.
[Client] Request to gateway -> localhost:9000/blog/1
=> send [Get] /blog/1 to localhost:9001/api/blog/1
=> api gateway will receive blog service response -> send result to client
تنظیم Load Balancer هم روی الگوریتم نوبتی یا همان Round Robin است که بین localhost:9001 و localhost:9002 به ترتیب بار را تقسیم میکند.
به این صورت اتصال سفت میان سرویس ها کاهش یافته و کنترل و scalability پروژه افزایش چشمگیری میابد.
{
"DownstreamPathTemplate": "/api/blog/{id}",
"DownstreamScheme": "http",
"DownstreamHostAndPorts": [
{ "Host": "localhost", "Port": 9001 }, // blog instance #1
{ "Host": "localhost", "Port": 9002 } // blog clone #2
],
"UpstreamPathTemplate": "/blog/{id}",
"LoadBalancer": "RoundRobin", //OR LeastConnection OR Cookie sticky
"UpstreamHttpMethod": [ "Get" ]
}

Ocelot official Docs:
https://ocelot.readthedocs.io/en/latest/introduction/bigpicture.html

@csharpfriends
#Microservice #ocelot #ApiGateway #LoadBalancing

همینطور که در تصویر مشاهده میکنید، مفهوم گذرگاه و Api gateway به شکل ساده ای ترسیم شده.
رابط کاربری یا همان کلاینت، با Gateway در ارتباط خواهد بود و gateway وظیفه کنترل محدودیت ها، ثبت رخداد ها و مسیریابی به میکروسرویس ها را انجام میدهد.
گذرگاه مانند یک میان افزار، بسته به Config انجام شده برای آن (مانند mvc endpoint routing) وظیفه مسیریابی درخواست ها و مَپ کردن آنها به مسیرهای دو سرویس در پشت این گذرگاه را دارد. سپس خروجی آنها را برمیگرداند.
* یک درخواست میتواند نیازمند اجرای دو action مختلف باشد، مثلا کلاینت درخواست گزارش وضعیت هواشناسی را ارسال میکند، گذرگاه پس از گرفتن اطلاعات از سرویس آب و هوا (1) و سپس ارسال آن به سرویس دیگری برای پردازش (2) و نهایتا بازگشت نتیجه نهایی به کلاینت. این کار در Gateway ها امکان پذیر و قابل پیکربندی میباشد.
@csharpfriends #ApiGateway #MicroService #CleanArchitecture

از سری مطالب معماری مبتنی بر سرویس و میکروسرویس ها که در چند بخش توضیح داده شده / خواهد شد:
۱. انواع پیاده سازی میکروسرویس
۲. میکروسرویس ها و Api Gateway ها
- ارتباطات سرویس ها و کلاینت ها
- محدودیت نرخ درخواست ها و تبادل
- کیفیت خدمات و کنترل جریان QoS
- مقیاس پذیری، توزیع و تقسیم بار
- نگهداری و توسعه
- ابزار ها و کتابخانه های کاربردی، ocelot.net
۳. میکروسرویس ها، Message Broker و Event Bus ها
۴. داکر، container ها و kubernetes
۵. پلتفرم های ابری و ☁️ Cloud
۵.۱ سرویس های Azure