نگاه اولیه به NET Aspire.

چند هفته‌ی گذشته مشغول بررسی و امتحان NET Aspire. بودم و نتیجه رو اینجا با شما به اشتراک گذاشتم. اگر NET. کار می‌کنید حتماً با Aspire آشنا بشید.

تلاش کردم توضیحات رو همراه با مراحل راه‌اندازی بیان کنم تا در صورت نیاز از همین مقاله استفاده کنید. اگر توضیحات اولیه برای شما مهم نیست، مستقیم به بخش اجرا بروید.

نمای کلی

تعریفی که خود Microsoft ارائه کرده‌است:

.NET Aspire is an opinionated, cloud ready stack for building observable, production ready, distributed applications.

اما تعریف من، اگر Microsoft بودم:

دنبال ساخت پروژه‌های بزرگ، مبتنی بر معماری Microservice، روی بستر Cloud هستی؟ ما در حال ساختن یک ساختار برای تولید، توسعه، استقرار و رصد این پروژه‌ها هستیم. به شما کمک می‌کنه تا همه‌ی سرویس‌های یک پروژه رو یک‌جا مدیریت کنید.

توسعه این پروژه حتماً برای ترویج بیشتر استفاده از NET. و همچنین گسترش استفاده از Azure انجام شده. (که اگر شما هم مثل من توسعه دهنده‌ی NET. باشید از این موضوع خوشحال خواهید شد.)

این ساختار هنوز کامل نشده و در حال توسعه است. اما الان می‌تونید روی سیستم خودتون امتحانش کنید.

همه چیز باید Preview‌ باشد

نکته اول این که برای استفاده از Aspire باید Visual Studio Preview رو نصب کنید و امکان استفاده از Aspire روی نسخه‌های پایدار و به روز VS، هنوز ممکن نیست.

برای پیدا کردن و نصب بیشتر NuGetها هم باید گزینه‌ی Include prerelease رو تیک بزنید.

و همچنین توصیه می‌کنم NET 9.‌ رو هم نصب کنید. (امکان تست روی NET 8.‌ وجود دارد ولی بیشتر امکانات برای نسخه ۹ توسعه داده‌شده‌اند.)

شروع

حالا فقط کافی است که یک پروژه از نوع Aspire بسازید. (با NET Aspire Starter Application. شروع کنید.)

پروژه‌ی ساخته شده شامل چند سرویس ساده برای تست و همچنین ۲ پروژه با پسوند‌های AppHost‌ و ServiceDefaults است.

شما در زمان اجرا فقط پروژه‌ی AppHost‌ رو اجرا می‌کنید و این پروژه، همه‌ی پروژه‌های دیگر را اجرا می‌کند.
در پروژه‌ی AppHost‌ فقط فایل Program.cs قابل مشاهده است که پروژه‌های دیگر داخل این فایل معرفی شده‌اند. هر پروژه‌ی web جدیدی هم که به solution اضافه کنید به صورت خودکار به این بخش افزوده خواهدشد.

در نهایت redis هم در همین فایل Add شده است و به هر یک از پروژه‌ها که نیاز باشد ارجاع داده می‌شود:

پروژه‌ی ServiceDefaults هم شامل یک فایل با نام Extensions.cs است که تنظیمات کلی برای دیگر پروژه‌هاست. هر پروژه‌ی web‌ که به solution اضافه کنید، این پروژه به صورت خودکار به Dependencyهای پروژه‌ی جدید اضافه می‌شود.

پرانتزی در مورد Kubernetes و Docker

اینجا این سوال مطرح می‌شود که: حالا که Microsoft یک ساختار برای اجرا و مدیریت Microservice ساخته و از عبارت orchestration (این عبارت برای معرفی Kubernetes استفاده شده‌است.) هم در معرفی بارها استفاده کرده است. آیا ما از Kubernetes و Docker بی‌نیاز هستیم؟

اول این که Kubernetes و Aspire ساختارهای متفاوتی دارند ولی پاسخ اجمالی این که خیر، چرخ رو از اول اختراع نکرده‌اند.

شما باید برای اجرای پروژه حتماً Docker را نصب داشته باشید و Kubernetes هم جزو Packageهای از پیش نصب شده در پروژه‌ی AppHost است.

اجرا

بخش جالب ماجرا از این‌جا شروع می‌شود.

بعد از اجرای پروژه شما یک صفحه‌ی شگفت‌انگیز را مشاهده می‌کنید:

در ابتدا لیست و اطلاعات همه‌ی پروژه‌ها نمایش داده می‌شود. redis هم در سطر اول به عنوان یک Container مشخص شده است. امکان مشاهده‌ی Logها و Detailها را دارید و در نوار کناری بخش Monitoring‌ را هم مشاهده می‌کنید.

در این dashboard امکانات متنوعی برای رصد پروژه‌ها ایجاد شده است:

بررسی یک سناریو برای درک بهتر

من یک سناریو ساختم که با هم بررسی کنیم:

یک پروژه به عنوان web.bff ایجاد کردم تا همه‌ی درخواست‌ها را پاسخ بدهد و درواقع یک reverse proxy باشد و درخواست‌ها را به سرویس‌های متناظر ارجاع دهد.

در پروژه‌ی BFF یک middleware هم برای authentication تعریف کردم تا صحتِ APIKey درخواست‌ها را بررسی کند. به این صورت که به یک پروژه‌ی دیگر به نام infrastructure.core با gRPC‌ متصل شود و APIKey‌ را هم در redis‌ نگه دارد.

در مرحله‌ی بعد اگر همه چیز درست بود، درخواست را به API اصلی ارجاع دهد.

یک پروژه هم با نام playground ایجاد کردم که API تستی داخل آن باشد. اسم API هم WeatherForecast است.

نتیجه Monitoring‌ این درخواست به WeatherForecast را می‌توانید در تصاویر زیر مشاهده کنید.

در سطر دوم مشخص شده است که من در چه زمانی این درخواست را ارسال کرده‌ام و چه پروژه‌هایی درگیر این درخواست شده‌اند:

همانطور که مشاهده کردید مدت زمان پاسخ هم درج شده است.

شما می‌توانید برای هر درخواست جزئیات دقیق‌تری را هم مشاهده کنید:

اینجا ترتیب و مدت زمان دقیق درخواست‌ها (طبق سناریو بالا) کاملاً مشخص شده است و حتی جزئیات هر درخواست به تفکیک نیز قابل مشاهده است. (دیدن اینا من رو خیلی هیجان‌زده کرده بود.)

حالا در بخش Structured Logs هم می‌توانیم مشاهده کنیم که به طور مثال در زمان درخواست به playground تلاش کرده تا به https پروژه redirect‌ بدهد که پیدا نشده است و warning ثبت شده:

فوق‌العاده بووووووووووووووووود. :)

و مرحله‌ی آخر Deploy

در حال حاضر که من این مقاله را می‌نویسم، زمانی که برای publish پروژه‌ی AppHost‌ اقدام کنید، با صفحه‌ی زیر روبه‌رو می‌شوید و خبری از ساختار قبلی که امکان publish روی سیستم یا از طریق FTP داشتیم نیست:

شما برای publish حتماً به Azure نیاز دارید. قطعاً این خبر خوبی برای ما داخل ایران نیست. البته در حال حاضر به طور کلی publish برای Aspire یک فرآیند ناقص است. شما اول باید یک manifest بسازید و در نهایت هم بخشی از امکاناتی که به صورت local می‌دیدید، برای شما در دسترس نخواهد بود.

نظر شخصی

با یک زیرساخت خوب و کارآمد روبه‌رو هستیم که احتمالاً در نیمه‌ی دوم ۲۰۲۴ به بلوغ کافی برای استفاده در پروژه‌ها خواهد رسید.