توضیحی درباره فریم ورک Blazor و برنامه های وب اسمبلی blazor و blazor server side

فریم ورک blazor دات نت، دو مدل داره، مدل اول با asp.net core کار میکنه و مثل برنامه های Asp core همون قابلیت ها رو به شما میده، بجای mvc شما از razor پیج ها استفاده میکنین و میتونین سرور و کلاینت رو در یک پروژه پیاده سازی کنین. تو این حالت صفحات از سرور به کلاینت ارسال میشن و توسط وب سرور داخلی asp core یعنی kestrel هاست میشن. تو این مدل شما خروجی وب اسمبلی ندارین.
مدل دوم که خروجیش وب اسمبلی هست مستقل از فریم ورک دات نت، روی مرورگر کاربر دانلود و اجرا میشه. امکاناتش نسب به مدل blazor server کمتره و معمولا فقط کدهای سمت کاربر رو داره و از طریق http میتونه با api های شما ارتباط برقرار کنه. تو این مدل که بیشتر شبیه برنامه های PWA هست همه چیز در قالب وب اسمبلی در مرورگر کاربر دانلود و پردازش میشه. بر خلاف مدل server که نیازمند سروری برای اجرا و پردازش درخواست هاست.
برای همین فقط باید کدهای سمت فرانت و ارتباط با سرویس هاتون رو توش بنویسین و از نوشتن منطق و ارتباط با دیتابیس و چیزهای حساس باید خودداری بکنین. به این دلیل که روش کنترلی نخواهید داشت و توسط کلاینت قابل مشاهده و کشف هست.
همچنین خروجی های وب اسمبلی به دلیل مستقل بودن میتونن هر جایی اجرا بشن. به این صورت شما نیازی به host یا سرور مجازی برای پروژه کلاینت تون ندارین و میتونین اون رو مانند کتابخانه ها و فایل ها، در CDN ها، صفحه های Github یا هر مکان دیگه ای برای دانلودش قرار بدین. برخلاف مدل سرور که نیاز به وب سرور و .net host داره.
مفاهیم Blazor تقریبا همانند فریم ورک های دیگه SPA است، مانند آنگولار و React.js.
امکان ساختن Component ها، service ها، استفاده از پکیج ها مثل بوت استرپ، material و هر کتابخانه جاوا اسکریپتی و یا nugget پکیج های دات نت دیگه ای.
همچنین علاوه بر این که میتونین از قابلیت های زبان c# در طراحی صفحاتتون استفاده کنین، امکان استفاده از جاوا اسکریپت هم دارید و دستتون بازه.
وب اسمبلی استاندارد جدیدی در دنیای وب هست و رفته رفته برای زبان های مختلفی مثل سی شارپ، داره براش کامپایلر نوشته میشه. این کامپایلر وظیفه تبدیل کدهای زبان مبدا به استاندارد های وب اسمبلی رو داره که توسط اکثر مرورگر های نسل جدید قابل فهم و اجراست. به این ترتیب دگرگونی بزرگی در دنیای وب ایجاد میشه. چرا که با هر زبانی که براش کامپایلر وب اسمبلی نوشته شده باشه، میتونید رابط کاربری و برنامه های وب و موبایل خودتون رو با کمترین وابستگی به جاوا اسکریپت تولید کنید.
در ادامه یک پروژه نمونه توسط Blazor client(وب اسمبلی) نوشتم که در گیتهاب قرار دادم. در پست بعدی به توضیح این مثال میپردازم.
https://github.com/mrgrayhat/BlazorMicroBlog/blob/master/Documents/screenshot/Index_FullPageScreenshot.png?raw=true

Project Repository:
https://github.com/mrgrayhat/BlazorMicroBlog

نمونه پروژه آموزشی blazor web assembly
Blazor MicroBlog:
همونطور که در مطلب قبلی گفتم، فریم ورک Blazor دات نت به شما امکان طراحی رابط کاربری و وب اپلیکیشن ها رو با کمترین میزان نیاز به جاوا اسکریپت و پکیج های شخص ثالث میده.
تصمیم گرفتم یک اپ PWA بلاگ، با blazor و مدل web assembly بنویسم.
این پروژه به ۳ قسمت تقسیم شده:
1. پروژه سرور که یک سرویس rest api نوشته شده با Asp.net core هست و امکان انجام عملیات CRUD یک وبلاگ رو داره و از efcore و دیتابیس sqlite استفاده میکنه.
همچنین قادر به هاست پروژه کلاینت در خودش هست و فقط کافیه exe یا dll این api رو اجرا کنید. خودش اپ blazor wasm رو پراکسی و برای کلاینت ها ارسال میکنه. (Blazor Asp.net Core Hosted)
همچنین قابلیت برگردوندن خروجی های paged و پاسخ های یکدست به صورت json و پشتیبانی از swagger و documentation داره که کار تست و تولید کد کلاینت هارو ساده میکنه.
2. پروژه کلاینت که تحت Blazor web assembly هست و شامل رابط کاربری برای نمایش و مدیریت وبلاگه. تا حد امکان سعی شده بی نیاز به js باشه و از قابلیت های c# و Razor components بهره گرفته بشه. همچنین بخش های مختلف صفحه، در قالب کامپوننت های مجزا طراحی شده، مانند قابلیت صفحه بندی (Pagination)، Card های بوت استرپ برای پست ها و نمایش لیست پست ها، ارسال toast نوتیفیکیشن، تغییر Theme به دو حالت Dark&Light.
این اپ pwa هست و با اولین اجرا از طریق مرورگر، میتونین روی موبایل و سیستم install کنین.(edge|chrome)
بیشتر جنبه آموزشی و تست پرفورمنس مدنظر بوده که راضی بودم، همه امکانات کامل نیست و به مرور تکمیل خواهد شد.
توضیحات بیشتر در readme ریپازیتوری گیت هاب من موجود است.
اگر پسندیدید به ریپازیتوری star و نظر بدین.
برای کامپایل و اجرا به Net5 Sdk. نیازمندید.
مخزن پروژه:
https://github.com/mrgrayhat/BlazorMicroBlog
(Thanks for you'r opinions and stars, share what you think with me And participate).

*یک نکته درباره فریم ورک Blazor و مدل کلاینت یا همون WebAssembly

همینطور که در مطالب قبلی گفته شد، blazor دات نت، دو مدل ServerApp و WebAssembly داره.
نمونه پروژه ای که در مطلب پیشین معرفی کردم با مدل وب اسمبلی blazor نوشته شده. وقتی یک پروژه blazor میسازید، در حالت blazor web assembly دو option وجود داره:
1. گزینه اول Asp.Net Core Hosted، امکان میده برنامه blazor شما، تحت Net. هاست بشه. یعنی نیاز به net core. برای اجرا شدن روی سرور شما داره و به راحتی میتونین از طریق خروجی exe یا dll که میسازه، اون رو اجرا کنید. (با مدل blazor server اشتباه نگیرید، این گزینه فقط امکان اجرای برنامه روی وب سرور دات نت رو اضافه میکنه و خروجی همچنان یک وب اسمبلی هست)
اگر تیک این گزینه رو نزنید( یا در کنسول آرگومان hosted-- موقع new کردن ندین)، خروجی پابلیش برنامه مستقل از دات نت ساخته میشه و اصلاحا فایل های فشرده static میده مثل html, js که میتونین اون ها رو در CDN ها یا Github Pages آپلود و اجرا کنین. پابلیش کردن این مدل مقداری کانفیگ و مراحل داره برای اجرا.

2. گزینه دوم PWA، که امکانات لازم مانند service worker.js رو برای ساختن یک اپ PWA به پروژه اضافه میکنه. میتونید خروجی رو روی سیستم عامل یا موبایلتون بدون نیاز به مرورگر اجرا کنین و قابلیت offline browsing داشته باشین. درست مثل یک اپ دسکتاپ یا موبایل. در غیر اینصورت برنامه باید حتما روی مرورگر و آنلاین کار بکنه.
برای ساختن اپ blazor pwa در vscode در command line وارد کنید:

 dotnet new blazorwasm --hosted --pwa 

یا با VisualStudio مدل blazor web assembly رو انتخاب و تیک گزینه PWA و Hosted و همچنین Configure Https رو بزنین (امن بودن ارتباطات در این اپ ها الزامیه و نیاز به https هست و این قابلیت فقط در خروجی publish فعال میشه)

اکثر فریم ورک ها مانند Angular, React.js,Vue.js هم از ساختن برنامه های PWA پشتیبانی میکنن.
برنامه های PWA امکان میدن تا وب سایت خودتون رو به شکل یک اپ ریسپانسیو موبایلی یا دسکتاپ در بیارین و کاربر میتونه اون رو مستقل از مرورگر نصب و اجرا کنه. به اینصورت نیاز به ساخت اپ های native برای هر سیستم عاملی مثل android,ios,windows,... نیست.

برای ساخت و آشنایی بیشتر با اپ های PWA میتوانید مقاله های زیر را مطالعه کنید:
https://devblogs.microsoft.com/visualstudio/building-a-progressive-web-app-with-blazor/
https://www.dotnetcurry.com/aspnet-core/progressive-web-apps-blazor-vuejs-angular
مقاله فارسی:
https://roocket.ir/articles/progressive-web-apps-future-of-modern-web

t.me/csharpfriends
#Blazor #WebAssembly #PWA #Net5 #AspNetCore

یک ویدئو آموزشی بسیار خوب درباره Blazor و قابلیت هایی که داره:
https://www.youtube.com/watch?v=Oeh2IJw7Zig
ویلیام در این ویدئو توضیح میده که چرا با جاوا اسکریپت خداحافظی کرده و با blazor رِل زده :)
از صفر ایجاد یک پروژه و افزودن قابلیت های مختلف، استفاده از js و ... نشون میده:
t.me/csharpfriends #Blazor #Net5

چند سالیه که NetCore. و AspCore خیلی سر و صدا کرده. از بدو انتشارش تا الان، مهمترین موضوعاتی که مورد توجه برنامه نویس ها و اهل فن بوده، پرفورمنس زیاد و چندسکویی بودن اونه. قبلا نرم افزار هایی که با c#.net نوشته میشدن مختص محیط ویندوز بودن. بعدها عده ای خوش ذوق Mono رو نوشتن که امکان کامپایل و اجرای برنامه های تحت .net رو برای لینوکس و مک میداد. این اتفاق پیش آمدی شد برای موتور بازی سازی Unity تا بتونین توسط c# و mono برای هر os ای بازی بنویسین.
فریم ورک های دیگه ای مثل Xamarin قوی تر شدن که امکان طراحی و برنامه نویسی اپلیکیشن های موبایل برای android/ios/windowsPhone با c# و xaml رو میده.
اما با ظهور NetCore. و اخیرا Net5. دیگه این محدودیت ها به چشم نمیان و شما میتونین برنامه های وب و حتی دسکتاپ تون رو برای سیستم عامل های دیگه هم کامپایل کنین. علاوه بر اینکه NetCore. پیشفرض خروجی portable میده و همه جا فقط با نصب NetRuntime. اجرا میشن ( که با نوعی کامپایل میشه نیاز به رانتایم رو هم حذف کرد عملا، فقط حجم خروجی یکم بیشتر میشه). موتور unity جدید هم از netstandard. پشتیبانی میکنه.

نکته مهم بعدی اینه که تقریبا تمام بنچ مارک ها ، تست های پرفورمنسی و عملیاتی ای که در وب سایت های معروفی مثل techempower منتشر میشه و میبینید؛ بر بستر لینوکس هستند. طبق گفته مایکروسافت، Asp.Net Core در حالتی که توسط وب سرور داخلی خودش یعنی Kestrel اجرا بشه چندین برابر سریعتر از حالتیه که در IIS ویندوز اجرا بشه. به دلیل اینکه واسط های اضافی ارتباطی کمتر میشن و از قابلیت های بازنویسی شده خود net core که بهینه ترن استفاده میشه.
علاوه بر این قضیه، اشاره شده که سرعت اجرا و عملکرد برنامه های netcore. در محیط های لینوکسی (بهتره بگم unix base) بیشتر از ویندوز هست. این مهم چندین دلیل داره که برخی از اون هارو که میدونم و تست کردم میگم:
1. محیط ترمینال برنامه، در ویندوز cmd یک ترمینال وابسته است که به صورت sync کار میکنه. همچنین encoding و فرآیند درج و چاپ متن در اون تک رشته ایه و با block شدن thread برنامه همراهه، ازین رو با محیط های unix ای متفاوته.
پروسه درج و چاپ متن در ترمینال های لینوکس async هست، سریعتره و حافظه و پردازش کمتری مصرف میکنه. برای تست این موضوع میتونین تعداد زیادی Log در برنامه تون ایجاد کنین که در کنسول نمایش داده بشه. این خروجی رو در ویندوز و لینوکس مقایسه بکنین مثلا response time درخواست ها یا سرعت خاتمه کار اون task پس از چاپ تعداد زیادی متن در console.
(میتونین با یک کتابخانه logging مثل serilog لاگینگ برنامه تون رو کامل تر و بیشتر بکنین و request/response ها و توابع تون رو لاگ کنین و سطح لاگینگ رو بزارین روی Debug، این قضیه بیشتر هنگام زیر بار بودن سرور مشهوده)
2. پلتفرم اجرای برنامه، در هر دو سیستم عامل ویندوز و لینوکس api های متفاوتی برای ارتباط در سطوح پایین تر و سیستم عامل وجود داره. به شکل چشم گیری توابع و کتابخانه های لینوکسی بهینه تر و سریعتر عمل میکنن (حالا چه به خاطر زبان c و کتابخانه های پورت شده زبان ماشین و چه کرنِل)، به همین دلیل مایکروسافت چندین بار کتابخانه های netcore. رو تعویض و بازنویسی کرده.
3. مصرف منابع یکی دیگه از معضلات ویندوز، به دلایل متعددی ویندوزها resource بیشتری در اختیار میگیرین و خودشون اون رو به برنامه های ثالث دیگه تخصیص میدن و مدیریت میکنن. مصرف حافظه و سربار پردازشی در این قضیه مشهوده و از کسی پوشیده نیست. ساده ترین کار مقایسه یک سیستم عامل لینوکسی با یک ویندوزی هست.
یا مثلا اخیرا سرور مجازی ای گرفته بودم که 2 هسته cpu و 2g رم داشت. پروژه رو روی یک ubuntu اجرا کردم و نهایت مصرف سرور من 1 هسته cpu و 512mb الی 1g رم بود. در حالی که در نسخه ویندوزی این مشخصات حتی قادر به اجرای خود اون ویندوز هم نبودن(حتی در نسخه بدون رابط کاربری ویندوز مثل nano/core)، و حداقل 4 هسته و 4 گیگ رم دیگه باید بهش افزوده میشد. همین الان هم میتونین خودتون بدون نیاز به این کارها. کارای روزمره تون رو با این 2 سیستم عامل انجام بدین و خودتون مقایسه کنین.

مسئله دیگه ای که در benchmark های aspcore/netcore مشاهده میشه. دیتابیس هست. معمولا بنچمارک هایی که در اون ها از دیتابیس هایی مثل PostgreSQL و elastic استفاده شده، یا orm اونها ado.net بوده پرفورمنس و نتایج بهتری نسبت به sql server و mysql با efcore داشتن.
مراحل و stage هاشونم مشخصه. یکسری تست پردازش text ان، یکسری پردازش آبجکت های بزرگ مثل لیست ها و آرایه ها، یکسری کوئری ها و درج و خوندن و الی یادگیری ماشین و پردازش تصویر، انصافا عملکرد خوبی رو به نمایش گزاشته. اینم اضافه کنم که native ها از managed ها و اونایی که مصرف حافظه رو خودشون مدیریت میکنن منطقا سریعترند.

این نتایج بنچمارک دوره 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