C# Friends
از سری مطالب معماری و مهندسی نرم افزار #2 مفاهیمی در معماری نرم افزار خیلی وقت ها کج فهمیده میشه و در این مطلب سعی میکنم این موضوع رو کمی تشریح کنم. 1. معماری نرم افزار (Software Architecture): معماری نرم افزار به موضوع شناخت و ترسیم کلیت نرم افزار و شکستن…
از سری مطالب معماری نرم افزار #4
1.2 معماری سرویس گرا (SOA)
به طور معمول با استفاده از معماری سرویس گرا و یا SOA، یک سیستم نرم افزاری به عنوان ترکیبی از سرویسهای مختلف، طراحی و ایجاد می شود. مثلا سرویس های پرداخت، محصولات فروشگاه، گزارشگیری،احراز هویت. (نرم افزار به عنوان سرویس)
مشابه معماری یکپارچه، این سرویس ها که همگی جهت پاسخ به نیازها و معمولا در قالب یک نرم افزار طراحی شده اند، به صورت وب سرویس های جداگانه ارائه میشوند. اما از نظر ساختاری همچنان شباهت زیادی به معماری یکپارچه دارند. از اهداف اصلی SOA استفاده مجدد از عملکردهای سیستم و اشتراک گذاری اجزای آن است (برخلاف میکروسرویس ها که مستقل اند و اشتراک گذاری رو به حداقل میرسونن و بیشتر مفهوم bounded-context رو ارائه میدن).
پروتکل اصلی ارتباطی اینگونه نرم افزار ها Soap است. حتما با وب سرویس های قدیمی مثل asmx و wcf ها در دات نت سر و کار داشتید.
محاسبات سرویس گرا (SOC) ، نمونه ای از محاسبات است که در آن طراحی و توسعه سیستم های کاربردی بر پايه سرویس به عنوان عنصر اساسی ، انجام می گیرد. سرویس ها عناصری هستند که مستقل از پلتفرم بوده و در ساخت سیستمهای توزیع شده سریع و ارزان قیمت کمک می نمایند. همچنین سازمانها را قادر می- سازند تا توابع خود را از طریق زبانها و پروتکلهای بر پایه XML پیاده سازی و بر روی اینترنت یا اینترانت ارائه نمایند.
پروتکل های انتقال پیام متعددی میان سرویس ها استفاده میشود( در مطلب دیگری پروتکل ها رو توضیح میدم) که هر کدام شیوه پیاده سازی متفاوتی ارائه میکنند، برخلاف میکروسرویس ها که معمولا بر بستر استاندارد http rest ارتباط دارند و هرگونه کلاینت ای میتواند با آنها بدون وابستگی ارتباط برقرار کند.
در این معماری عملکرد و سرویس ها به 4 دسته تقسیم میشن:
* سرویس های تجاری: شامل سرویس های اصلی که توسط XML نمایش داده میشن.
* سرویس های سازمانی: برای برآورده کردن و پیاده سازی عملکردهایی که در لایه تجاری مورد نیاز هست، به عنوان واسط سرویس های زیر بنایی و برنامه عمل میکنن.
* سرویس های برنامه کاربردی: لایه ای که هر کدام از برنامه های کاربردی (سرویس ها) در آن توسعه داده میشود و توسط رابط کاربری و UI از اونها استفاده میشه.
* سرویس های زیربنایی: عملکرد های عمومی مشترک برنامه که میتونن از طریق بقیه برنامه ها و سرویس ها هم فراخوانی بشن؛ مانند مدیریت و احراز هویت کاربران.
+ مزایا:
* قابلیت تغییر و تحویل سریعتر، به شما اجازه میدهد عملکرد سرویس ها را تغییر داده و سریعتر آنها را به مصرف کننده برسانید.
* افزایش تعامل و امکان استفاده مجدد بیشتر، در سطوح مختلف مانند سرویس ها و داده ها
* تکامل و توسعه تدریجی، امکان افزودن قابلیت ها و بخش های مختلف را در قالب سرویس های جدید آسان تر میکند. بدین صورت دیگر مجبور به طراحی و استقرار کل نرم افزار بصورت یکجا و کلی نیستید.
* انعطاف پذیری بیشتر نسبت به معماری یکپارچه، امری است که باعث میشود سرویس ها چه داخل سازمان ها و چه خارج از آنها، منعطف تر و تغییر پذیر تر باشند.
- معایب:
* مشابه معماری یکپارچه، معمولا اکثر قابلیت ها و سرویس های نرم افزار در یک پروژه و تحت یک نرم افزار واحد به صورت وب سرویس نوشته میشوند که وب سرویس ها و لایه های کاربردی و عملیاتی آنها مشابه Monolithic است.
* زبان ارتباطی xml
* ارتباطات مستقیم وب سرویس ها و پروتکل ارتباطی میان آنها
* پرفورمنس کمتر بدلیل مشکلات مربوط به تاخیر و اختلال در ارتباطات بین سرویس ها، به دلیل ماهیت شبکه و بسترهای ارتباطی که در معماری های مبتنی بر سرویس رایج هستند
البته که این معماری در زمان خود مزایای بیشماری از آنچه ذکر شد داشته و همچنین معایب و نواقصی که به مرور و طی سیر تکاملی چندین ساله جای خود را به معماری هایی چون میکروسرویس ها و سیستم های ابری داد. آنچه که پیداست همانند طبیعت، تکامل یک امر انکار ناپذیر و تغییر جزئی از این چرخه است، پیشرفت های سریع در علوم گوناگون و شیوه های جدید تر و بهینه تر مانند ماشین های سبز الکترومکانیکی و راکت های قابل استفاده مجدد، همه نشان از لزوم به روز بودن اند، اهمیتی نمیدهند که من و شما در چه بازه تاریخی گیر کرده باشیم. هستی محکوم به تغییر و سازگاری است.
در ادامه به معماری میکروسرویس و پیدایش مفاهیم آن خواهم پرداخت.
@csharpfriends
#SoftwareEngineering #SoftwareArchitecture #SOA
1.2 معماری سرویس گرا (SOA)
به طور معمول با استفاده از معماری سرویس گرا و یا SOA، یک سیستم نرم افزاری به عنوان ترکیبی از سرویسهای مختلف، طراحی و ایجاد می شود. مثلا سرویس های پرداخت، محصولات فروشگاه، گزارشگیری،احراز هویت. (نرم افزار به عنوان سرویس)
مشابه معماری یکپارچه، این سرویس ها که همگی جهت پاسخ به نیازها و معمولا در قالب یک نرم افزار طراحی شده اند، به صورت وب سرویس های جداگانه ارائه میشوند. اما از نظر ساختاری همچنان شباهت زیادی به معماری یکپارچه دارند. از اهداف اصلی SOA استفاده مجدد از عملکردهای سیستم و اشتراک گذاری اجزای آن است (برخلاف میکروسرویس ها که مستقل اند و اشتراک گذاری رو به حداقل میرسونن و بیشتر مفهوم bounded-context رو ارائه میدن).
پروتکل اصلی ارتباطی اینگونه نرم افزار ها Soap است. حتما با وب سرویس های قدیمی مثل asmx و wcf ها در دات نت سر و کار داشتید.
محاسبات سرویس گرا (SOC) ، نمونه ای از محاسبات است که در آن طراحی و توسعه سیستم های کاربردی بر پايه سرویس به عنوان عنصر اساسی ، انجام می گیرد. سرویس ها عناصری هستند که مستقل از پلتفرم بوده و در ساخت سیستمهای توزیع شده سریع و ارزان قیمت کمک می نمایند. همچنین سازمانها را قادر می- سازند تا توابع خود را از طریق زبانها و پروتکلهای بر پایه XML پیاده سازی و بر روی اینترنت یا اینترانت ارائه نمایند.
پروتکل های انتقال پیام متعددی میان سرویس ها استفاده میشود( در مطلب دیگری پروتکل ها رو توضیح میدم) که هر کدام شیوه پیاده سازی متفاوتی ارائه میکنند، برخلاف میکروسرویس ها که معمولا بر بستر استاندارد http rest ارتباط دارند و هرگونه کلاینت ای میتواند با آنها بدون وابستگی ارتباط برقرار کند.
در این معماری عملکرد و سرویس ها به 4 دسته تقسیم میشن:
* سرویس های تجاری: شامل سرویس های اصلی که توسط XML نمایش داده میشن.
* سرویس های سازمانی: برای برآورده کردن و پیاده سازی عملکردهایی که در لایه تجاری مورد نیاز هست، به عنوان واسط سرویس های زیر بنایی و برنامه عمل میکنن.
* سرویس های برنامه کاربردی: لایه ای که هر کدام از برنامه های کاربردی (سرویس ها) در آن توسعه داده میشود و توسط رابط کاربری و UI از اونها استفاده میشه.
* سرویس های زیربنایی: عملکرد های عمومی مشترک برنامه که میتونن از طریق بقیه برنامه ها و سرویس ها هم فراخوانی بشن؛ مانند مدیریت و احراز هویت کاربران.
+ مزایا:
* قابلیت تغییر و تحویل سریعتر، به شما اجازه میدهد عملکرد سرویس ها را تغییر داده و سریعتر آنها را به مصرف کننده برسانید.
* افزایش تعامل و امکان استفاده مجدد بیشتر، در سطوح مختلف مانند سرویس ها و داده ها
* تکامل و توسعه تدریجی، امکان افزودن قابلیت ها و بخش های مختلف را در قالب سرویس های جدید آسان تر میکند. بدین صورت دیگر مجبور به طراحی و استقرار کل نرم افزار بصورت یکجا و کلی نیستید.
* انعطاف پذیری بیشتر نسبت به معماری یکپارچه، امری است که باعث میشود سرویس ها چه داخل سازمان ها و چه خارج از آنها، منعطف تر و تغییر پذیر تر باشند.
- معایب:
* مشابه معماری یکپارچه، معمولا اکثر قابلیت ها و سرویس های نرم افزار در یک پروژه و تحت یک نرم افزار واحد به صورت وب سرویس نوشته میشوند که وب سرویس ها و لایه های کاربردی و عملیاتی آنها مشابه Monolithic است.
* زبان ارتباطی xml
* ارتباطات مستقیم وب سرویس ها و پروتکل ارتباطی میان آنها
* پرفورمنس کمتر بدلیل مشکلات مربوط به تاخیر و اختلال در ارتباطات بین سرویس ها، به دلیل ماهیت شبکه و بسترهای ارتباطی که در معماری های مبتنی بر سرویس رایج هستند
البته که این معماری در زمان خود مزایای بیشماری از آنچه ذکر شد داشته و همچنین معایب و نواقصی که به مرور و طی سیر تکاملی چندین ساله جای خود را به معماری هایی چون میکروسرویس ها و سیستم های ابری داد. آنچه که پیداست همانند طبیعت، تکامل یک امر انکار ناپذیر و تغییر جزئی از این چرخه است، پیشرفت های سریع در علوم گوناگون و شیوه های جدید تر و بهینه تر مانند ماشین های سبز الکترومکانیکی و راکت های قابل استفاده مجدد، همه نشان از لزوم به روز بودن اند، اهمیتی نمیدهند که من و شما در چه بازه تاریخی گیر کرده باشیم. هستی محکوم به تغییر و سازگاری است.
در ادامه به معماری میکروسرویس و پیدایش مفاهیم آن خواهم پرداخت.
@csharpfriends
#SoftwareEngineering #SoftwareArchitecture #SOA
C# Friends
از سری مطالب معماری و مهندسی نرم افزار #2 مفاهیمی در معماری نرم افزار خیلی وقت ها کج فهمیده میشه و در این مطلب سعی میکنم این موضوع رو کمی تشریح کنم. 1. معماری نرم افزار (Software Architecture): معماری نرم افزار به موضوع شناخت و ترسیم کلیت نرم افزار و شکستن…
از سری مطالب معماری نرم افزار #5
1.3 مقدمه ای بر معماری میکروسرویس (Microservice)
رشد و تکامل در هر چیزی قابل مشاهده و اندازه گیری هست؛ تکامل گونه های جانوران، طبیعت، نسل های مختلف، علم و خیلی چیزهای دیگه پروسه های طولانی و زیادی رو طی کردن تا به شکل امروزی در اومدن و همچنان تا وقتی دنیا دنیاست، هر چیزی یا محکوم به فناست یا تکامل. فلسفیش نمیکنم، مقصودم بیان چرخه تغییر و ایجاد چیزهای مختلف در طول زمانه.
روزگاری در دنیای برنامه نویسی و نرم افزار، معماری های مختلفی معرفی و ابداع میشدن. یک روز معماری P2P، روز دیگری Master Slave، کلاینت-سرور، Mainframe و الی ماشالله، که در دهه های 1960-1970 و تا مدت ها بعد رشد و استفاده زیادی داشتند. نیازمندی ها روز به روز بیشتر و پیچیده تر میشن، برنامه ها بزرگ تر و توسعه و نگهداریشون هم به مراتب سخت تر و هزینه برتر.
حتی تا دهه اخیر، معماری سرویس گرا (SOA) با کلی ویژگی و برتری جزو پرکاربرد ترین معماری در طراحی نرم افزار ها و سامانه ها بود. با توجه به حجم بسیار زیادی از چیزهایی که دهه های پیشین در موردش گفته میشد و یک جورایی سوپرمنی آمده بود تا بسیاری از نیازمندی های سازمان ها و نرم افزار های Enterprise رو حل کنه. انصافا هم در دوره خودش بسیاری کاربرد ها داشت و داره.
امکان ایجاد ارتباط های مستقیم میان نرم افزار ها و اجزای مختلف سازمان و اشتراک گذاری داده میان آنها، از برجسته ترین نقطه قوت SOA هست. اکثر سامانه های دولتی و تجاری عمومی و خصوصی سازمان ها به شیوه سرویس گرا طراحی شدند. سامانه های وزارت دارائی، صنعت و معدن، استانداری ها و تعداد کثیری سرویس که من دیدم و در توسعه برخی از اونها نقش داشتم، هنوز هم بر پایه معماری SOA هستند.
با تکنولوژی وب سرویس های asmx و wcf دات نت و بعد ها web api و REST
فرآیندی که شما درخواست میکنید از طریق وب سرویس های مختلف پردازش و منتقل میشن. از سامانه ای به سامانه دیگر، از وزارت بهداشت به ثبت احوال و به دارائی و ورزش؛ نه فقط در کشور ایران، در بسیاری از کشور های جهان امثال بانک ها هم به همین صورت اند. خیلی هاشون انقدر در هم تنیده و بزرگ شدن که روزانه اخبار هک شدن و درز اطلاعات یا از کار افتادنشون رو میشنویم (در کشور عزیز ما البته همه دیتاهامون کف اینترنت ریخته، به لطف دوستان و اربابان)
در ادامه به شرح علل به وجود اومدن میکروسرویس ها و دلایل استفاده از اونها میپردازم
@csharpfriends
#SoftwareEngineering #SoftwareArchitecture #Microservice
1.3 مقدمه ای بر معماری میکروسرویس (Microservice)
رشد و تکامل در هر چیزی قابل مشاهده و اندازه گیری هست؛ تکامل گونه های جانوران، طبیعت، نسل های مختلف، علم و خیلی چیزهای دیگه پروسه های طولانی و زیادی رو طی کردن تا به شکل امروزی در اومدن و همچنان تا وقتی دنیا دنیاست، هر چیزی یا محکوم به فناست یا تکامل. فلسفیش نمیکنم، مقصودم بیان چرخه تغییر و ایجاد چیزهای مختلف در طول زمانه.
روزگاری در دنیای برنامه نویسی و نرم افزار، معماری های مختلفی معرفی و ابداع میشدن. یک روز معماری P2P، روز دیگری Master Slave، کلاینت-سرور، Mainframe و الی ماشالله، که در دهه های 1960-1970 و تا مدت ها بعد رشد و استفاده زیادی داشتند. نیازمندی ها روز به روز بیشتر و پیچیده تر میشن، برنامه ها بزرگ تر و توسعه و نگهداریشون هم به مراتب سخت تر و هزینه برتر.
حتی تا دهه اخیر، معماری سرویس گرا (SOA) با کلی ویژگی و برتری جزو پرکاربرد ترین معماری در طراحی نرم افزار ها و سامانه ها بود. با توجه به حجم بسیار زیادی از چیزهایی که دهه های پیشین در موردش گفته میشد و یک جورایی سوپرمنی آمده بود تا بسیاری از نیازمندی های سازمان ها و نرم افزار های Enterprise رو حل کنه. انصافا هم در دوره خودش بسیاری کاربرد ها داشت و داره.
امکان ایجاد ارتباط های مستقیم میان نرم افزار ها و اجزای مختلف سازمان و اشتراک گذاری داده میان آنها، از برجسته ترین نقطه قوت SOA هست. اکثر سامانه های دولتی و تجاری عمومی و خصوصی سازمان ها به شیوه سرویس گرا طراحی شدند. سامانه های وزارت دارائی، صنعت و معدن، استانداری ها و تعداد کثیری سرویس که من دیدم و در توسعه برخی از اونها نقش داشتم، هنوز هم بر پایه معماری SOA هستند.
با تکنولوژی وب سرویس های asmx و wcf دات نت و بعد ها web api و REST
فرآیندی که شما درخواست میکنید از طریق وب سرویس های مختلف پردازش و منتقل میشن. از سامانه ای به سامانه دیگر، از وزارت بهداشت به ثبت احوال و به دارائی و ورزش؛ نه فقط در کشور ایران، در بسیاری از کشور های جهان امثال بانک ها هم به همین صورت اند. خیلی هاشون انقدر در هم تنیده و بزرگ شدن که روزانه اخبار هک شدن و درز اطلاعات یا از کار افتادنشون رو میشنویم (در کشور عزیز ما البته همه دیتاهامون کف اینترنت ریخته، به لطف دوستان و اربابان)
در ادامه به شرح علل به وجود اومدن میکروسرویس ها و دلایل استفاده از اونها میپردازم
@csharpfriends
#SoftwareEngineering #SoftwareArchitecture #Microservice
Mr.Grayhat [Saeed.R]
What is Blazor and what is Razor Components? - Scott Hanselman https://www.hanselman.com/blog/WhatIsBlazorAndWhatIsRazorComponents.aspx
چگونه تصمیم گرفتم از Blazor استفاده کنم:
مدتی هست که در حال نوشتن یک سیستم مدیریت محتوا و وبلاگ بر پایه معماری میکروسرویس هستم که دربارش توضیح مفصلی در مطلب دیگه ای خواهم داد.
رابط کاربری و سمت فرانت اند رو اول با Angular شروع کردم به پیاده سازی. متای سرویس ها و مدل های سمت سرور به صورت خودکار توسط nswag تولید میشه برای کلاینت آنگولار. nswag کتابخانه ای برای تولید کدهای سمت سرور شما برای کلاینت ها با زبان های مختلفی مثل typenoscript, c#, js و ... استفاده میشه.
فقط نیاز هست تا ماژول ها، کامپوننت های مورد نظر و فراخوانی سرویس ها نوشته بشه که در کلاینت generate شده. برای من بخش سخت و طاقت فرسای کار طراحی رابط کاربری و سر و کله زدن با پکیج های node بود. علاوه بر اون syntax تایپ اسکریپت (که باز نسبت به js خیلی بهتره) یه سری قواعد متفاوتی داره. در عین حال فریم ورک خوبیه هم از لحاظ سرعت و هم ابزارها و امکانات زیادی که براش تولید شده. امکان PWA کردن اپ هم به راحتی هست.
اما همونطور که گفتم چند چیز اذیتم میکرد، اول پکیج های بسیار زیاد npm و مدیریت ورژن ها و آپدیت هاشون که کلی side effect و باگ ممکنه ایجاد بکنن در برنامه. دوم با syntax اش خیلی راحت نبودم و کلی باید میگشتم تا مثلا بفهمم داده های دریافتی رو چطوری Map میکنن و کلی تابع و چیز مختلف که داره.
این مشکلات برای امثال من بیشتر پر رنگ هست که فرانت کار حرفه ای نیستن یا با این فریم ورک ها زیاد کار نکردن. برای کسی که کلی وقت گذاشته و پروژه زده مسلما راحت تره کما اینکه میشنوم خیلیاشون به مشکلات آنگولار واقف ان.
در درجه بعد نمیخواستم mvc بزنم فرانت رو چون SPA میخواستم.
تا چند وقت پیش که با یکی از دوستان بحث Blazor و وب اسمبلی شد. از نحوه کارکردش تا مقایسه اش با مابقی فریم ورک ها. مهمتر از همه بحث وب اسمبلی.
بعد از اون مشتاق شدم درباره Blazor در دات نت 5، یه تحقیق مجدد بکنم. دیدم نسبت به ۲ سال پیش خیلی بهتر شده هر چند هنوز جای کار داره اما سریع باهاش ارتباط گرفتم. وب اسمبلی و در کنارش طراحی رابط کاربری با سی شارپ و قابلیت هاش برام جذاب بود. کما اینکه افرادی مثل من که به سی شارپ و net core تسلط بیشتری دارن تا جاوا اسکریپت و تایپ اسکریپت، به راحتی میتونن باهاش فرانت اند رو هم پیاده بکنن و چندین ماه درگیر یادگیری فریم ورک های دیگه و سر و کله زدن باهاشون نشن.
به خصوص که من نیاز دارم تا برای پروژم فرانت هم طبق نیازهای خودم پیاده سازی کنم.
در ادامه درمورد وب اسمبلی و فریم ورک Blazor.net یه توضیحی میدم و نمونه پروژه ای که باهاش پیاده کردم رو در گیتهاب قرار میدم تا بقیه علاقه مندان هم بتونن باهاش آشنا بشن.
@csharpfriends #Blazor #WebAssembly #FrontEnd
مدتی هست که در حال نوشتن یک سیستم مدیریت محتوا و وبلاگ بر پایه معماری میکروسرویس هستم که دربارش توضیح مفصلی در مطلب دیگه ای خواهم داد.
رابط کاربری و سمت فرانت اند رو اول با Angular شروع کردم به پیاده سازی. متای سرویس ها و مدل های سمت سرور به صورت خودکار توسط nswag تولید میشه برای کلاینت آنگولار. nswag کتابخانه ای برای تولید کدهای سمت سرور شما برای کلاینت ها با زبان های مختلفی مثل typenoscript, c#, js و ... استفاده میشه.
فقط نیاز هست تا ماژول ها، کامپوننت های مورد نظر و فراخوانی سرویس ها نوشته بشه که در کلاینت generate شده. برای من بخش سخت و طاقت فرسای کار طراحی رابط کاربری و سر و کله زدن با پکیج های node بود. علاوه بر اون syntax تایپ اسکریپت (که باز نسبت به js خیلی بهتره) یه سری قواعد متفاوتی داره. در عین حال فریم ورک خوبیه هم از لحاظ سرعت و هم ابزارها و امکانات زیادی که براش تولید شده. امکان PWA کردن اپ هم به راحتی هست.
اما همونطور که گفتم چند چیز اذیتم میکرد، اول پکیج های بسیار زیاد npm و مدیریت ورژن ها و آپدیت هاشون که کلی side effect و باگ ممکنه ایجاد بکنن در برنامه. دوم با syntax اش خیلی راحت نبودم و کلی باید میگشتم تا مثلا بفهمم داده های دریافتی رو چطوری Map میکنن و کلی تابع و چیز مختلف که داره.
این مشکلات برای امثال من بیشتر پر رنگ هست که فرانت کار حرفه ای نیستن یا با این فریم ورک ها زیاد کار نکردن. برای کسی که کلی وقت گذاشته و پروژه زده مسلما راحت تره کما اینکه میشنوم خیلیاشون به مشکلات آنگولار واقف ان.
در درجه بعد نمیخواستم mvc بزنم فرانت رو چون SPA میخواستم.
تا چند وقت پیش که با یکی از دوستان بحث Blazor و وب اسمبلی شد. از نحوه کارکردش تا مقایسه اش با مابقی فریم ورک ها. مهمتر از همه بحث وب اسمبلی.
بعد از اون مشتاق شدم درباره Blazor در دات نت 5، یه تحقیق مجدد بکنم. دیدم نسبت به ۲ سال پیش خیلی بهتر شده هر چند هنوز جای کار داره اما سریع باهاش ارتباط گرفتم. وب اسمبلی و در کنارش طراحی رابط کاربری با سی شارپ و قابلیت هاش برام جذاب بود. کما اینکه افرادی مثل من که به سی شارپ و net core تسلط بیشتری دارن تا جاوا اسکریپت و تایپ اسکریپت، به راحتی میتونن باهاش فرانت اند رو هم پیاده بکنن و چندین ماه درگیر یادگیری فریم ورک های دیگه و سر و کله زدن باهاشون نشن.
به خصوص که من نیاز دارم تا برای پروژم فرانت هم طبق نیازهای خودم پیاده سازی کنم.
در ادامه درمورد وب اسمبلی و فریم ورک Blazor.net یه توضیحی میدم و نمونه پروژه ای که باهاش پیاده کردم رو در گیتهاب قرار میدم تا بقیه علاقه مندان هم بتونن باهاش آشنا بشن.
@csharpfriends #Blazor #WebAssembly #FrontEnd
GitHub
GitHub - mrgrayhat/CleanMicroserviceArchitecture: Clean Microservice Architecture system use api gateway and angular ui
Clean Microservice Architecture system use api gateway and angular ui - GitHub - mrgrayhat/CleanMicroserviceArchitecture: Clean Microservice Architecture system use api gateway and angular ui
اگر اهل موسیقی مخصوصا موزیکای خاص موقع کار کردن هستین میتونین اینجا دانلود کنین و یا با بقیه به اشتراک بزارین.
📣 channel : @PG_sound
group:
https://news.1rj.ru/str/ProgrammingSound
📣 channel : @PG_sound
group:
https://news.1rj.ru/str/ProgrammingSound
Telegram
Programming Sound
👤 Admin : @seyed_dev
توضیحی درباره فریم ورک 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 دات نت، دو مدل داره، مدل اول با 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
C# Friends
توضیحی درباره فریم ورک Blazor و برنامه های وب اسمبلی blazor و blazor server side فریم ورک blazor دات نت، دو مدل داره، مدل اول با asp.net core کار میکنه و مثل برنامه های Asp core همون قابلیت ها رو به شما میده، بجای mvc شما از razor پیج ها استفاده میکنین و…
نمونه پروژه آموزشی 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 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).
GitHub
GitHub - mrgrayhat/BlazorMicroBlog: Microblog is a small blog system written by blazor web assembly framework and asp.net core.…
Microblog is a small blog system written by blazor web assembly framework and asp.net core. The goal is to demonstrate blazor capabilities for user interface design and implementation of pwa applic...
*یک نکته درباره فریم ورک Blazor و مدل کلاینت یا همون WebAssembly
همینطور که در مطالب قبلی گفته شد، blazor دات نت، دو مدل ServerApp و WebAssembly داره.
نمونه پروژه ای که در مطلب پیشین معرفی کردم با مدل وب اسمبلی blazor نوشته شده. وقتی یک پروژه blazor میسازید، در حالت blazor web assembly دو option وجود داره:
1. گزینه اول Asp.Net Core Hosted، امکان میده برنامه blazor شما، تحت Net. هاست بشه. یعنی نیاز به net core. برای اجرا شدن روی سرور شما داره و به راحتی میتونین از طریق خروجی exe یا dll که میسازه، اون رو اجرا کنید. (با مدل blazor server اشتباه نگیرید، این گزینه فقط امکان اجرای برنامه روی وب سرور دات نت رو اضافه میکنه و خروجی همچنان یک وب اسمبلی هست)
اگر تیک این گزینه رو نزنید( یا در کنسول آرگومان
2. گزینه دوم PWA، که امکانات لازم مانند service worker.js رو برای ساختن یک اپ PWA به پروژه اضافه میکنه. میتونید خروجی رو روی سیستم عامل یا موبایلتون بدون نیاز به مرورگر اجرا کنین و قابلیت offline browsing داشته باشین. درست مثل یک اپ دسکتاپ یا موبایل. در غیر اینصورت برنامه باید حتما روی مرورگر و آنلاین کار بکنه.
برای ساختن اپ blazor pwa در vscode در command line وارد کنید:
اکثر فریم ورک ها مانند 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 دات نت، دو مدل 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
Microsoft News
Building a Progressive Web App with Blazor
A Progressive Web Application (PWA) is a Single Page Application (SPA) that uses modern browser APIs and capabilities to behave like a desktop app. Blazor WebAssembly (now in preview) includes support for Progressive Web Applications. This blog post walks…
یک ویدئو آموزشی بسیار خوب درباره Blazor و قابلیت هایی که داره:
https://www.youtube.com/watch?v=Oeh2IJw7Zig
ویلیام در این ویدئو توضیح میده که چرا با جاوا اسکریپت خداحافظی کرده و با blazor رِل زده :)
از صفر ایجاد یک پروژه و افزودن قابلیت های مختلف، استفاده از js و ... نشون میده:
t.me/csharpfriends #Blazor #Net5
https://www.youtube.com/watch?v=Oeh2IJw7Zig
ویلیام در این ویدئو توضیح میده که چرا با جاوا اسکریپت خداحافظی کرده و با blazor رِل زده :)
از صفر ایجاد یک پروژه و افزودن قابلیت های مختلف، استفاده از js و ... نشون میده:
t.me/csharpfriends #Blazor #Net5
YouTube
Blazor Web Apps - Goodbye JavaScript! I'm in love with C#
By this time next year most of us will be hooked on Blazor WebAssembly. Now we can run C# code directly in our browsers and get the added bonus of having a full .NET stack for building enterprise web applications.
00:00:00 - Introduction
00:00:21 - Pain…
00:00:00 - Introduction
00:00:21 - Pain…
چند سالیه که 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 ها و اونایی که مصرف حافظه رو خودشون مدیریت میکنن منطقا سریعترند.
فریم ورک های دیگه ای مثل 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 ها و اونایی که مصرف حافظه رو خودشون مدیریت میکنن منطقا سریعترند.
www.techempower.com
TechEmpower Framework Benchmarks
Performance comparison of web application frameworks using community-contributed test implementations.
بنچمارک اخیر سایت Techempower برای فریم ورک ها/میکروفریم های وب
تصویر اول گزارش تست Fortune
تصویر دوم گزارش تست plaintext
تصویر اول گزارش تست Fortune
تصویر دوم گزارش تست plaintext
C# Friends
Photo
این نتایج بنچمارک دوره 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
شامل پرفورمنس تست فریم ورک ها، میکرو فریم ورک ها و کتابخانه های وب میشه.
نزدیک 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
www.techempower.com
TechEmpower Framework Benchmarks
Performance comparison of web application frameworks using community-contributed test implementations.
C# Friends
نمونه پروژه آموزشی blazor web assembly Blazor MicroBlog: همونطور که در مطلب قبلی گفتم، فریم ورک Blazor دات نت به شما امکان طراحی رابط کاربری و وب اپلیکیشن ها رو با کمترین میزان نیاز به جاوا اسکریپت و پکیج های شخص ثالث میده. تصمیم گرفتم یک اپ PWA بلاگ، با…
یک نکته درباره اجرای پروژه 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
توجه داشتیه باشین که برای استفاده از قابلیت 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
C# Friends pinned «یک نکته درباره اجرای پروژه Blazor MicroBlog و عملکردش: توجه داشتیه باشین که برای استفاده از قابلیت pwa پروژه Blazor MicroBlog و نصب اون مثل یک اپلیکیشن در دستگاهتون، باید خروجی publish از api بگیرید و روی https اجرا کنین (ترجیحا Edge/Chrome) (همچنین برای…»
C# Friends
از سری مطالب معماری نرم افزار #5 1.3 مقدمه ای بر معماری میکروسرویس (Microservice) رشد و تکامل در هر چیزی قابل مشاهده و اندازه گیری هست؛ تکامل گونه های جانوران، طبیعت، نسل های مختلف، علم و خیلی چیزهای دیگه پروسه های طولانی و زیادی رو طی کردن تا به شکل امروزی…
از سری مفاهیم معماری میکروسرویس ها، 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
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
C# Friends
*یک نکته درباره فریم ورک Blazor و مدل کلاینت یا همون WebAssembly همینطور که در مطالب قبلی گفته شد، blazor دات نت، دو مدل ServerApp و WebAssembly داره. نمونه پروژه ای که در مطلب پیشین معرفی کردم با مدل وب اسمبلی blazor نوشته شده. وقتی یک پروژه blazor میسازید،…
یکی از معایب 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.، دات نت فریمورک با دگرگونی بزرگی همراه شد، رفته رفته تکنولوژی ها بهتر و کاملتر میشن. این وسط همیشه یک عده هستن که ساز مخالف و منفی میزنن یا با مقایسه های اشتباه دنبال خوب و بد میگردن.
اما بعد از لود اولیه، فایل ها 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.، دات نت فریمورک با دگرگونی بزرگی همراه شد، رفته رفته تکنولوژی ها بهتر و کاملتر میشن. این وسط همیشه یک عده هستن که ساز مخالف و منفی میزنن یا با مقایسه های اشتباه دنبال خوب و بد میگردن.
C# Friends
یکی از معایب blazor web assembly در حال حاضر حجم خروجی برنامه است. به طوری که به نسبت رقباش مثل آنگولار و react.js، چند برابر حجمش بیشتره. این مسئله در load اولیه برنامه محسوسه. چون اسمبلی ها و فایل ها باید روی مرورگر کاربر دانلود بشه. از طرفی، اسمبلی ها باید…
همونطور که ربط دادن و مقایسه مباحثی مثل معماری با دیزاین پترن، نادرسته و درک صحیح از مطالعه و تجربه میطلبه، مقایسه نادرست مباحثی مانند وب اسمبلی و blazor، با آنگولار و فلاتر هم بسی ناشیانه است.
اول باید ببینیم به درک درستی رسیدیم یا نه. الزاما ده ها سال کار کردن ما رو عالم و حرفه ای نمیکنه. همونطور که ده ها سال عبادت و درس خوندن به تنهایی، از کسی مومن و کاربلد و دانشمند نمیسازه. در هر حوزه ای که وارد میشیم، قبل از حرف زدن تحقیق کنیم. مقالات خارجی درست و حسابی، پروژه های متن باز و اجرا شده، افراد متخصص در اون حوزه. بعد از اون عمل کنیم. صرف دونستن تئوری کافی نیست.
وقتی به درک صحیحی از موضوع رسیدیم، اونوقت میتونیم مثلا معایب یک معماری یا مزایای فلان فریم ورک رو به چالش بکشیم. تفسیر خودتون از مسئله رو، جواب درست ندونین. ساده تر بگم، خودتون رو عقل کل فرض نکنین! خیلی از عقل کل ها یک روزی فهمیدن اشتباه میکردن و تصحیح کردن نمونه اش نظریات انیشتین، خیلی های دیگم تا اخر عمر در جهالتشون پافشاری میکردن.
اینجانب که ادعایی در دانش ندارم و همواره در پی بروز کردن، تجربه کردن و اشتراک گذاری اون هستم. در حد توانم به موضوعاتی که تسلط خوبی داشته باشم میپردازم و بقیه رو به آینده موکول میکنم. (مثلا اخیرا خواستم راجع به هوش مصنوعی و یادگیری ماشین بنویسم که منصرف شدم و تصمیم گرفتم هر زمان پی مطالعه و تجربه کردنش رفتم ازش بنویسم، یا در حوزه پیاده سازی میکروسرویس ها، تجربه و موضوعات مختلفم رو سر جمع میکنم و با مثال قرار خواهم داد. به همین دلیل فعلا pause اش کردم)
@csharpfriends
#SoftwareEngineering #SoftwareArchitecture
اول باید ببینیم به درک درستی رسیدیم یا نه. الزاما ده ها سال کار کردن ما رو عالم و حرفه ای نمیکنه. همونطور که ده ها سال عبادت و درس خوندن به تنهایی، از کسی مومن و کاربلد و دانشمند نمیسازه. در هر حوزه ای که وارد میشیم، قبل از حرف زدن تحقیق کنیم. مقالات خارجی درست و حسابی، پروژه های متن باز و اجرا شده، افراد متخصص در اون حوزه. بعد از اون عمل کنیم. صرف دونستن تئوری کافی نیست.
وقتی به درک صحیحی از موضوع رسیدیم، اونوقت میتونیم مثلا معایب یک معماری یا مزایای فلان فریم ورک رو به چالش بکشیم. تفسیر خودتون از مسئله رو، جواب درست ندونین. ساده تر بگم، خودتون رو عقل کل فرض نکنین! خیلی از عقل کل ها یک روزی فهمیدن اشتباه میکردن و تصحیح کردن نمونه اش نظریات انیشتین، خیلی های دیگم تا اخر عمر در جهالتشون پافشاری میکردن.
اینجانب که ادعایی در دانش ندارم و همواره در پی بروز کردن، تجربه کردن و اشتراک گذاری اون هستم. در حد توانم به موضوعاتی که تسلط خوبی داشته باشم میپردازم و بقیه رو به آینده موکول میکنم. (مثلا اخیرا خواستم راجع به هوش مصنوعی و یادگیری ماشین بنویسم که منصرف شدم و تصمیم گرفتم هر زمان پی مطالعه و تجربه کردنش رفتم ازش بنویسم، یا در حوزه پیاده سازی میکروسرویس ها، تجربه و موضوعات مختلفم رو سر جمع میکنم و با مثال قرار خواهم داد. به همین دلیل فعلا pause اش کردم)
@csharpfriends
#SoftwareEngineering #SoftwareArchitecture
Telegram
C# Friends
C#, Asp.Net Core, Blazor & Architecture
Guids, Experiences, Tutorials, News and Codes.
Github: saeedrezayi/mrgrayhat
Contact me: @mrgrayhat
Guids, Experiences, Tutorials, News and Codes.
Github: saeedrezayi/mrgrayhat
Contact me: @mrgrayhat