توجه: این مقاله نوشته شده توسط Glenn Condron در وبسایت devblogs.microsoft.com منتشر شده است و توسط تیم تحریریه باگتو با هدف ارائه اطلاعات به کاربران فارسی‌زبان باگتو به زبان فارسی ترجمه شده است.

در چندین نسخه اخیر، ما پیشرفت‌هایی را در یکی از اهداف بلندپروازانه‌مان به دست آورده‌ایم: تبدیل .NET به یکی از مؤثرترین پلتفرم‌ها در جهان برای ساخت اپلیکیشن‌های  Cloud-Native.
ما در کنار برخی از خدمات پرتقاضای مایکروسافت که نیازهایی فراتر از اکثر برنامه‌ها داشتند، کار کرده‌ایم؛ خدماتی که صدها میلیون کاربر فعال ماهانه را پشتیبانی می‌کنند. همکاری با این خدمات برای اطمینان از رضایت نیازهای آن‌ها، اطمینان می‌دهد که ما توانایی‌های اساسی لازم برای پاسخگویی به نیازهای خدمات ابری در مقیاس بالا را داریم.
ما در تکنولوژی‌ها و کتابخانه‌های مهمی مانند بررسی سلامت (Health Checks)، YARP، کارخانه مشتری HTTP و gRPC سرمایه‌گذاری کرده‌ایم. با Native AOT، ما در تلاشیم تا به نقطه ایده‌آل عملکرد و اندازه دست یابیم، و ساخت کانتینرهای SDK به راحتی هر اپلیکیشن .NET را درون یک کانتینر قرار داده و آماده برای ابر مدرن می‌کند بدون نیاز به فکر یا کار توسعه‌دهنده.
اما آنچه از توسعه‌دهندگان شنیدیم این بود که ما نیاز به انجام کارهای بیشتری داشتیم. ساخت اپلیکیشن‌ها برای ابر هنوز خیلی دشوار بود. توسعه‌دهندگان به طور فزاینده‌ای از منطق تجاری خود و موضوعات مهم دور می‌شدند تا با پیچیدگی‌های ابر مقابله کنند.
برای کمک به شما در ساده‌سازی پیچیدگی‌های اپلیکیشن‌های ابری، ما ارائه می‌کنیم...
 

NET Aspire . چیست؟

.NET Aspire یک مجموعه انتخابی برای ساخت اپلیکیشن‌های cloud-native مقاوم، قابل مشاهده و قابل پیکربندی با استفاده از .NET است. این مجموعه شامل یک دسته از اجزاء منتخب است که برای استفاده در محیط‌های cloud-native با قابلیت‌هایی مانند کشف سرویس، تلمتری، انعطاف‌پذیری و بررسی‌های سلامت به صورت پیش‌فرض تقویت شده‌اند. ترکیبی از تجربه توسعه‌دهنده محلی پیشرفته و در عین حال ساده، .NET Aspire توسعه و پیکربندی وابستگی‌های اساسی برای اپلیکیشن‌های cloud-native را از روز اول تا صدم، هم برای اپلیکیشن‌های جدید و هم برای اپلیکیشن‌های موجود که از .NET 8 یا بالاتر استفاده می‌کنند، آسان می‌کند.
ما اولین پیش‌نمایش .NET Aspire را همراه با .NET 8 ارائه می‌دهیم و انتظار می‌رود به عنوان بخشی از .NET 8 در بهار سال آینده به عنوان نسخه نهایی (GA) عرضه شود. این بخشی از .NET 8 است و همراه با .NET در آینده به‌روزرسانی خواهد شد. مستندات، گیت هاب

گشتی در NET Aspire .
 

برای شروع، بیایید نگاهی به قالب جدید NET Aspire Starter . بیندازیم و به تمامی ویژگی‌های آن نگاهی اجمالی داشته باشیم، قبل از اینکه بعداً در این پست عمیق‌تر شویم. این بخش به عنوان یک مرور گفتگومآبانه طراحی شده است که می‌توانید با آن همراه شوید. شما به آخرین نسخه .NET 8 و پیش‌نمایش Visual Studio 2022 (17.9 Preview 1) نیاز خواهید داشت. اگر از لینوکس یا مک استفاده می‌کنید، همچنان می‌توانید با همه چیز همراه شوید، اما برخی از نمونه‌های ابزارهای داده شده هنوز در دسترس نخواهند بود.
گشتی در راه‌حل Visual Studio
اپلیکیشن استارتر برای این طراحی شده است که شما را با یک راه‌حل کاربردی .NET Aspire آشنا کند که می‌توانید آن را امتحان کنید. این اپلیکیشن از دو پروژه و یک کش Redis تشکیل شده است. پروژه front-end یک اپلیکیشن وب Blazor است که یک API back-end را برای اطلاعات آب و هوا فرا می‌خواند.

بررسی پروژه‌های جدید در  NET Aspire .
 

شما دو پروژه جدیدی را خواهید دید که پیش از این ندیده‌اید: <appname>.AppHost و <appname>.ServiceDefaults.
پروژه AppHost: این پروژه تمام پروژه‌های .NET، کانتینرها، یا فایل‌های اجرایی مورد نیاز برای راه‌اندازی اپلیکیشن توزیع شده شما را اجرا می‌کند. هنگامی که در Visual Studio هستید، امکان دیباگ کردن به تمام پروژه‌های در حال اجرا وصل می‌شود که به شما اجازه می‌دهد وارد هر سرویس در اپلیکیشن خود شوید و در آن گام بردارید. ما بعداً در این پست به طور عمیق‌تری درباره این پروژه و کدهای درون آن صحبت خواهیم کرد.
پروژه ServiceDefaults: این پروژه منطق مشترک مرتبط با خدمات را که به تمام پروژه‌ها در اپلیکیشن اعمال می‌شود، در بر دارد. اینجا جایی است که موضوعات مشترک مانند کشف سرویس، تلمتری و نقاط پایانی بررسی سلامت پیکربندی می‌شوند. ما می‌خواستیم این موارد در تمام پروژه‌ها یکسان باشد، اما درک می‌کنیم که تیم‌ها و سازمان‌ها ممکن است بخواهند برخی تنظیمات را تغییر دهند. کد مشترک در پروژه، مکانیزم قابل کشف و دوستانه برای توسعه‌دهندگان بود که ما برای دستیابی به این اهداف یافتیم.

داشبورد - مرکزی برای نظارت و بررسی اپلیکیشن شما
 

با اجرای اپلیکیشن استارتر .NET Aspire با استفاده از کلید F5 در Visual Studio یا با دستور dotnet run از طریق خط فرمان، شما به داشبورد توسعه‌دهنده هدایت می‌شوید. این داشبورد به عنوان یک ابزار اساسی برای دیباگ کردن اپلیکیشن‌های توزیع شده عمل می‌کند و نمای یکپارچه‌ای از سرویس‌های شما در کنار لاگ‌ها، متریک‌ها و ردیابی‌هایشان ارائه می‌دهد.
این داشبورد تنها یک پنجره به اپلیکیشن cloud-native شما نیست؛ بلکه یک پلتفرم تعاملی است که بینش‌های ارزشمندی را در مورد پروژه‌های شما فراهم می‌کند و هرگونه خطا را برجسته می‌کند تا امکان تحقیق عمیق‌تر فراهم شود. در زیر تصویری از یک پروژه با خطای شناسایی شده وجود دارد که با یک نقطه قرمز نشان داده شده است:

نمایش لاگ‌ها و ردیابی‌ها در NET Aspire .
 

ما همچنین می‌توانیم لاگ‌ها را در سراسر تمام پروژه‌ها مشاهده کنیم، و حتی ردیابی توزیع شده‌ای که یک درخواست به صفحه آب و هوا را نشان می‌دهد. ردیابی‌ها ابزاری حیاتی در تشخیص مشکلات در سیستم‌های توزیع شده هستند. این ویژگی امکان مشاهده جریان یک درخواست و تعامل آن با سایر بخش‌های اپلیکیشن را فراهم می‌کند، که در شناسایی و حل مسائل مربوط به عملکرد و خطاهای مختلف بسیار مفید است.
 

داشبورد توسعه‌دهنده در NET Aspire . 
 

داشبورد توسعه‌دهنده مرکزی برای جمع‌آوری تمام داده‌های تشخیصی مربوط به زمان توسعه و عیب‌یابی کندی‌ها و باگ‌ها در ماشین توسعه شما است. این داشبورد از همان استانداردهای بازی استفاده می‌کند که شما در تولید هنگام پیکربندی سیستم‌های تلمتری خود مانند Grafana+Prometheus، Application Insights و غیره استفاده می‌کنید. ما بعداً در این پست به طور عمیق‌تری در مورد داشبورد صحبت خواهیم کرد.
چند سال پیش ما روی آزمایشی به نام Project Tye کار کردیم، بسیاری از یادگیری‌های حاصل از آن آزمایش اکنون در .NET Aspire، از جمله این داشبورد که اولین بار در آن آزمایش آزموده شد، در دسترس هستند. اگر از Project Tye لذت برده‌اید و می‌خواستید آن ادامه یابد، پس فکر می‌کنیم شما .NET Aspire را دوست خواهید داشت.

اجزاء درNET Aspire .
 

حالا بیایید نگاهی بیندازیم به چیزهایی که در پروژه‌ها متفاوت است. اولاً، پروژه وب دارای یک بسته NuGet با نام Aspire در نام آن، یعنی Aspire.StackExchange.Redis.OutputCaching، است.

اگر همراه هستید و این بسته را نمی‌بینید، احتمالاً هنگام ایجاد پروژه گزینه "استفاده از کش Redis" را علامت‌گذاری نکرده‌اید.
این بسته NuGet آنچه ما به عنوان یک جزء NET Aspire. نامیده‌ایم است. اجزاء، کتابخانه‌های چسبنده‌ای هستند که یک SDK را برای کار در محیط ابری پیکربندی می‌کنند. هر جزء باید:
1.    ارائه اسکیما JSON برای پیکربندی: برای تکمیل بیانیه در appsettings.json.
2.    استفاده از الگوهای انعطاف‌پذیری قابل پیکربندی: مانند تلاش‌های مجدد، زمان‌بندی‌ها و مدارشکن‌ها برای حداکثر کردن در دسترس بودن.
3.    فراهم کردن بررسی‌های سلامت: امکان ردیابی و پاسخ به سلامت سرویس‌های دوردست.
4.    ارائه لاگ‌گیری، متریک‌ها و ردیابی یکپارچه: با استفاده از انتزاعات مدرن .NET (ILogger, Meter, Activity).
5.    ارائه روش‌های توسعه‌ای: که سرویس‌های SDK را به کانتینر DI با طول عمر مناسب برای انواع ثبت شده متصل می‌کنند.

ما بعداً در این پست به جزئیات بیشتری در مورد اجزاء می‌پردازیم. نکته کلیدی این است که اجزاء NET Aspire. وابستگی‌ها را برای احترام به مجموعه‌ای از نیازمندی‌ها پیکربندی می‌کنند که ما معتقدیم مصرف‌کنندگان را برای موفقیت در ابر آماده می‌کند. آن‌ها SDK/کتابخانه واقعی را پوشش یا پنهان نمی‌کنند، بلکه به عنوان چسب عمل می‌کنند تا اطمینان حاصل شود که کتابخانه با یک مجموعه خوب از پیش‌فرض‌ها پیکربندی شده و به درستی با DI ثبت می‌شود. این وظیفه‌ای است که معمولاً امروزه به توسعه‌دهنده واگذار می‌شود.

کدنویسی در NET Aspire.
 

حالا بیایید نگاهی به کد در اپلیکیشن Blazor بیندازیم که API آب و هوا را فرا می‌خواند، و سپس به برخی از کدها در پروژه AppHost که قبلاً در مورد آن صحبت کردیم. ابتدا، در فایل Program.cs پروژه وب ما می‌توانید کدی شبیه به این ببینید:

builder.Services.AddHttpClient<WeatherApiClient>(
   client => client.BaseAddress = new("http://apiservice"));

این کد برای پیکربندی front-end وب ما جهت فراخوانی API آب و هوا است. اما چند چیز غیرمعمول در اینجا وجود دارد، از جمله اینکه نام apiservice از کجا می‌آید؟ برای پاسخ به این سؤال، برای اولین بار به پروژه AppHost خود نگاه می‌کنیم، اینجا فایل Program.cs از آن پروژه است:

var builder = DistributedApplication.CreateBuilder(args);
var cache = builder.AddRedisContainer("cache");
var apiservice = builder.AddProject<Projects.AspireApp_ApiService>("apiservice");
builder.AddProject<Projects.AspireApp_Web>("webfrontend")
   .WithReference(cache)
   .WithReference(apiservice);
builder.Build().Run();

این کد اجرا می‌شود زیرا AppHost پروژه استارتاپ شما است. این کد پروژه‌های شما، وابستگی‌های آن‌ها را اجرا کرده و به صورت مناسبی پیکربندی می‌کند تا بتوانند با یکدیگر ارتباط برقرار کنند. یکی از اهداف ما حذف پورت‌ها و رشته‌های اتصال از جریان توسعه شما به اندازه ممکن است. ما این کار را از طریق مکانیزم کشف سرویس انجام می‌دهیم که به توسعه‌دهندگان اجازه می‌دهد از نام‌های منطقی به جای آدرس‌های IP و پورت‌ها هنگام انجام تماس‌های HTTP استفاده کنند. شما می‌توانید ببینید که من API خود را apiservice نامگذاری کرده‌ام، سپس آن را به عنوان یک مرجع به front-end ارجاع داده‌ام و می‌توانم از apiservice به عنوان نامی هنگام انجام تماس‌های HTTP از طریق IHttpClientFactory استفاده کنم. تماس‌های انجام شده با این روش نیز به صورت خودکار تلاش مجدد خواهند کرد و خطاهای گذرا را مدیریت می‌کنند، به لطف ادغام با پروژه Polly.
AppHost وابستگی‌ها و نیازمندی‌های اپلیکیشن شما را تنظیم می‌کند، و ابزارهای .NET Aspire آن‌ها را در حلقه توسعه شما برآورده می‌کند.

بررسی عمیق‌تر: اجزاء در NET Aspire.
 

ما شروع به بررسی عمیق‌تر اجزاء درNET Aspire . می‌کنیم. اجزاء NET Aspire. برای حل مشکلاتی طراحی شده‌اند که ما از مشتریان خود در مورد شروع توسعه اپلیکیشن‌های cloud-native شنیده‌ایم، مانند اینکه تکنیک‌ها و پیکربندی‌های بسیاری وجود دارد که باید به درستی انجام شوند و مسیر شروع واضح نیست. ما به این مشکل کمک می‌کنیم با ارائه نظرات مشخص در مورد آنچه که یک جزء باید فراهم کند، و اینکه همه اجزاء حداقل باید پیش‌فرض‌های انعطاف‌پذیری، بررسی‌های سلامت، پیکربندی تلمتری و ادغام با DI را فراهم کنند. برای نمایش این موضوع، بیایید نگاهی بیندازیم به اینکه چگونه یک اپلیکیشن آماده برای تولید ممکن است Redis را در اپ خود پیکربندی کند:

1.    بسته Redis را همراه با کتابخانه کلاینت Redis اضافه کنید.
2.    کشف و اضافه کردن کتابخانه بررسی‌های سلامت تا اپلیکیشن شما بتواند به عدم دسترسی Redis واکنش نشان دهد. این مورد اغلب نادیده گرفته می‌شود اما در عمل مفید است.
3.    Redis را به DI اضافه کرده و رشته‌های اتصال را پیکربندی کنید. این کار پیچیده است زیرا باید بدانید چه طول عمری برای انواع کتابخانه کلاینت Redis باید در نظر گرفته شود که نیازمند تحقیق است.
4.    کتابخانه کلاینت Redis را برای ارسال خروجی لاگ به سیستم تلمتری خود پیکربندی کنید.
5.    لاگ‌ها و متریک‌ها متفاوت هستند و نیازمند پیکربندی متفاوتی دارند.
6.    تصمیم‌گیری در مورد سیاست و منطق انعطاف‌پذیری مورد نیاز و پیکربندی Redis یا پوشش تماس‌ها با کتابخانه‌ای مانند Polly که می‌تواند سیاست‌های انعطاف‌پذیری را پیاده‌سازی کند. این باز هم نیازمند تحقیق در مورد قابلیت‌های Redis و دانش در مورد سیاست انعطاف‌پذیری مورد نیاز شما است، که اغلب چیزی نیست که شما از ابتدا بدانید و باعث می‌شود افراد بدون آن به تولید بروند تا زمانی که چیزی در تولید خراب شود که می‌توانست با یک سیاست تلاش مجدد با فاصله زمانی افزایشی اجتناب شود.

اگر این روند را با استفاده از NET Aspire.مقایسه کنیم:
1.    بسته Redis .NET Aspire را اضافه کنید.
2.    روی سازنده، AddRedis را فراخوانی کنید.
3.    به صورت اختیاری، پیکربندی پیش‌فرض در appSettings.json را بازنویسی کنید (که اکنون ساختاربندی شده است تا شما تکمیل را برای کشف آنچه قابل تنظیم است داشته باشید).
اجزاء NET Aspire.رای ارائه یک پیکربندی بهینه و آماده برای تولید طراحی شده‌اند بدون اینکه SDK زیربنایی را مخفی کنند. در هر دو مثال ذکر شده، کد شما برای استفاده از Redis به طور مداوم از همان کتابخانه و انواع مشتری Redis استفاده خواهد کرد.

یک جزء برای اینکه آماده استفاده باشد باید موارد زیر را فراهم کند:
1.    ارائه پیکربندی دقیق و ساختاربندی شده.
2.    راه‌اندازی بررسی‌های سلامت برای ردیابی و پاسخ به سلامت سرویس‌های دوردست.
3.    ارائه الگوی انعطاف‌پذیری پیش‌فرض و قابل پیکربندی (تلاش‌های مجدد، زمان‌بندی‌ها و غیره) برای حداکثر کردن در دسترس بودن.
4.    ارائه لاگ‌گیری، متریک‌ها و ردیابی یکپارچه برای قابل مشاهده کردن جزء.
مجموعه اولیه اجزاء ما در زیر فهرست شده‌اند، و اطلاعات بیشتر می‌توانید در بخش معرفی اجزاء .NET Aspire در Microsoft Learn پیدا کنید.

Cloud-agnostic components

1.    PostgreSQL Entity Framework Core: ارائه کتابخانه کلاینت برای دسترسی به پایگاه داده‌های PostgreSQL با استفاده از Entity Framework Core.
2.    PostgreSQL: ارائه کتابخانه کلاینت برای دسترسی به پایگاه داده‌های PostgreSQL.
3.    RabbitMQ: ارائه کتابخانه کلاینت برای دسترسی به RabbitMQ.
4.    Redis Distributed Caching: ارائه کتابخانه کلاینت برای دسترسی به کش‌های Redis برای کشینگ توزیع شده.
5.    Redis Output Caching: ارائه کتابخانه کلاینت برای دسترسی به کش‌های Redis برای کشینگ خروجی.
6.    Redis: ارائه کتابخانه کلاینت برای دسترسی به کش‌های Redis.
7.    SQL Server Entity Framework Core: ارائه کتابخانه کلاینت برای دسترسی به پایگاه داده‌های SQL Server با استفاده از Entity Framework Core.
8.    SQL Server: ارائه کتابخانه کلاینت برای دسترسی به پایگاه داده‌های SQL Server.

Azure specific components

1.    Azure Blob Storage: ارائه کتابخانه کلاینت برای دسترسی به Azure Blob Storage.
2.    Azure Cosmos DB Entity Framework Core: ارائه کتابخانه کلاینت برای دسترسی به پایگاه داده‌های Azure Cosmos DB با استفاده از Entity Framework Core.
3.    Azure Cosmos DB: ارائه کتابخانه کلاینت برای دسترسی به پایگاه داده‌های Azure Cosmos DB.
4.    Azure Key Vault: ارائه کتابخانه کلاینت برای دسترسی به Azure Key Vault.
5.    Azure Service Bus: ارائه کتابخانه کلاینت برای دسترسی به Azure Service Bus.
6.    Azure Storage Queues: ارائه کتابخانه کلاینت برای دسترسی به صف‌های ذخیره‌سازی Azure.

امروزه، این مجموعه از اجزاء توسط مایکروسافت در دسترس و عرضه شده است. هدف ما این است که فرآیند تبدیل شدن به یک جزء Aspire و نیازمندی‌ها/بهترین شیوه‌های مربوط به آن‌ها بیشتر توسط جامعه رانده شود، همزمان با تغییرات در ابر و تمایل بیشتر کتابخانه‌ها به داشتن اجزاء.

مدل برنامه در  NET Aspire.
 

پروژه AppHost در یک اپلیکیشن  NET Aspire. به شما امکان می‌دهد نیازهای اپلیکیشن خود را با زبانNET Aspire .مورد علاقه‌تان (ابتدا پشتیبانی از #C) بیان کنید. این پروژه مسئول هماهنگی اجرای اپلیکیشن شما روی ماشین توسعه‌دهنده است.
هماهنگ‌سازی یک توانایی اصلی در .NET Aspire است که برای ساده‌سازی اتصالات و پیکربندی‌ها بین بخش‌های مختلف اپلیکیشن cloud-native طراحی شده است. .NET Aspire انتزاعات مفیدی را ارائه می‌دهد که به شما امکان می‌دهد دغدغه‌هایی مانند کشف سرویس، متغیرهای محیطی و پیکربندی‌های کانتینر را بدون نیاز به مدیریت جزئیات پیاده‌سازی سطح پایین، هماهنگ کنید. این انتزاعات همچنین الگوهای راه‌اندازی یکسانی را در سراسر اپلیکیشن‌ها با بسیاری از اجزاء و سرویس‌ها فراهم می‌کنند.
هماهنگ‌سازی .NET Aspire در موارد زیر کمک می‌کند:
•    ترکیب برنامه: تعریف منابعی که اپلیکیشن را تشکیل می‌دهند، از جمله پروژه‌های .NET، کانتینرها، فایل‌های اجرایی یا منابع ابری.
•    کشف سرویس: تعیین نحوه ارتباط منابع مختلف با یکدیگر.
برای مثال، با استفاده از NET Aspire. ، کد زیر یک منبع کانتینر Redis محلی، یک منبع پروژه برای یک API ایجاد می‌کند و رشته اتصال و URL مناسب را در پروژه "webfrontend" پیکربندی می‌کند.

var builder = DistributedApplication.CreateBuilder(args);
var cache = builder.AddRedisContainer("cache");
var apiservice = builder.AddProject<Projects.AspireApp_ApiService>("apiservice");
builder.AddProject<Projects.AspireApp_Web>("webfrontend")
   .WithReference(cache)
   .WithReference(apiservice);
builder.Build().Run();

پروژه "webfrontend" حالا می‌تواند درخواست‌های HTTP را به http://apiservice ارسال کند بدون اینکه نگران مپینگ پورت باشد. رشته اتصال Redis حتی شفاف‌تر است زیرا جزء .NET Aspire کتابخانه کلاینت Redis را برای استفاده از رشته اتصال فراهم شده به صورت خودکار پیکربندی می‌کند. این امر منبع بزرگی از تنظیمات مستعد به خطا در جریان توسعه شما را حذف می‌کند و هم شروع کار و هم پیوستن به تیم را ساده‌تر می‌کند. اگر شما از کشف سرویس در تولید استفاده می‌کنید، حتی اگر فقط ویژگی‌های پیش‌فرض Kubernetes باشد، این نیز تولید را نسبت به پیکربندی دستی بهتر منعکس می‌کند.
مجموعه اولیه منابع ما به شرح زیر است: منابع داخلی
•    پروژه: یک پروژه .NET، به عنوان مثال اپلیکیشن‌های وب ASP.NET Core.
•    کانتینر: یک تصویر کانتینر، مانند یک تصویر Docker.
•    اجرایی: یک فایل اجرایی.

افزونه‌های Cloud-Agnostic در NET Aspire.
 

هر یک از این منابع زمانی در دسترس قرار می‌گیرند که بسته NuGet (جزء) مربوط به منبع متناظر را اضافه کنید. برای هر یک از این‌ها، می‌توانید در طول توسعه .NET Aspire را برای راه‌اندازی یک کانتینر تنظیم کنید یا از طریق رشته‌های اتصال به منبع موجود/خارجی متصل شوید.
•    Postgress
•    RabbitMQ
•    Redis
•    SQL Server
 

افزونه‌های مخصوص Azure
 

هر یک از این روش‌ها زمانی در دسترس قرار می‌گیرند که بسته NuGet (جزء) مربوط به منبع متناظر را اضافه کنید. Azure Storage در حال حاضر تنها منبعی است که از اجرای یک کانتینر محلی پشتیبانی می‌کند، بقیه نیازمند اطلاعات اتصال برای منابع واقعی Azure هستند.
•    Azure Storage (بلاب‌ها، جداول، صف‌ها)
•    Azure Cosmos DB
•    Azure KeyVault
•    Azure Redis Cache
•    Azure Service Bus
شما می‌توانید اطلاعات بیشتری در مورد نحوه کار هماهنگ‌سازی در مستندات .NET Aspire بیابید: معرفی هماهنگ‌سازی .NET Aspire | Microsoft Learn

داشبورد توسعه‌دهنده در NET Aspire.
 

داشبورد NET Aspire. تنها زمانی قابل مشاهده است که AppHost در حال اجرا باشد و به صورت خودکار زمانی که پروژه را شروع می‌کنید، اجرا می‌شود. ناوبری سمت چپ لینک‌هایی را به بخش‌های مختلف داشبورد که در اینجا توصیف خواهیم کرد، فراهم می‌کند. علاوه بر این، آیکون چرخ‌دنده در بالا و سمت راست داشبورد به صفحه تنظیمات دسترسی دارد که به شما اجازه می‌دهد تجربه داشبورد خود را پیکربندی کنید.
 

1.    پروژه‌ها: صفحه پروژه‌ها صفحه اصلی داشبورد است و تمام منابع پروژه در اپلیکیشن شما را فهرست می‌کند. وظیفه اصلی آن نمایش وضعیت هر پروژه و ارائه URL‌هایی به بخش‌های مختلف اپ است. همچنین زمانی که خطایی برای یک پروژه ثبت شده باشد، یک نشان را نمایش می‌دهد که به شما اجازه می‌دهد به راحتی مشکلات را شناسایی کنید.
2.    کانتینرها: این صفحه مشابه صفحه پروژه‌ها است، اما برای منابع کانتینر اپلیکیشن شما. در گشتی که بالاتر داشتیم، کانتینر کش Redis در اینجا نمایش داده می‌شود.
3.    اجرایی‌ها: این صفحه مشابه صفحه پروژه‌ها است، اما برای منابع اجرایی اپلیکیشن شما.
4.    لاگ‌ها: بخش لاگ‌های داشبورد به لاگ‌های تمام بخش‌های اپلیکیشن شما در یک مکان مرکزی دسترسی فراهم می‌کند.

1.    لاگ‌های پروژه: خروجی از ارائه‌دهنده لاگ در پروژه‌های .NET شما در اینجا قابل مشاهده است. شما می‌توانید بین هر پروژه تعویض کنید و هر سطح شدت لاگ با رنگ متفاوتی نمایش داده می‌شود.
2.    لاگ‌های کانتینر: این صفحه مشابه لاگ‌های پروژه است، اما برای کانتینرها.
3.    لاگ‌های اجرایی: این صفحه مشابه لاگ‌های پروژه است، اما برای فایل‌های اجرایی.
4.    لاگ‌های ساختاربندی شده: صفحه لاگ‌های ساختاربندی شده نمای فیلترپذیری از تمام لاگ‌های شما را ارائه می‌دهد. لاگ‌های ساختاربندی شده ویژگی‌های پیام‌های لاگ شما را حفظ می‌کنند تا بتوانند به صورت جداگانه فیلتر یا جستجو شوند، در حالی که در صفحات دیگر لاگ‌ها تمام ویژگی‌ها به یک پیام لاگ رشته‌ای ترکیب شده‌اند.
5.    ردیابی‌ها: صفحه ردیابی‌ها مسیر یک عملکرد را از طریق تمام بخش‌های اپلیکیشن شما، یک ردیابی توزیع شده، نشان می‌دهد. این نمایش می‌تواند در یافتن گلوگاه‌ها، کندی‌ها، و تشخیص سایر رفتارها که فقط زمانی ظاهر می‌شوند که کل سیستم استفاده می‌شود و نه به صورت مجزا، بسیار ارزشمند باشد. ما یک اسکرین‌شات از نمای ردیابی‌ها را در بخش گشت بالا نشان دادیم، که نشان می‌دهد چگونه می‌توانید یک عملکرد را با استفاده از کش Redis، API و فرانت‌اند در یک نمایش مشاهده کنید.
6.    متریک‌ها: صفحه متریک‌ها تمام متریک‌های اپلیکیشن شما را نشان می‌دهد.

قابلیت مشاهده در NET Aspire.
 

اپلیکیشن‌های NET Aspire. به طور پیش‌فرض قابل مشاهده هستند. قابلیت مشاهده عالی به این معناست که شما می‌توانید تعیین کنید که در راه‌حل خود چه اتفاقی در حال رخ دادن است، به ویژه در زمان قطعی، از تمام داده‌هایی که از اپلیکیشن در حال اجرا جمع‌آوری می‌شوند. به طور خاص از لاگ‌ها، متریک‌ها، و ردیابی‌ها. فقط داشتن لاگ‌ها و متریک‌ها باعث نمی‌شود که کل سیستم شما قابل مشاهده باشد اگر نتوانید تعیین کنید که چه اتفاقی در حال رخ دادن است؛ شما به داده‌های درست در نمای درست در زمان درست نیاز دارید.
این بدان معناست که برای قابل مشاهده بودن یک اپلیکیشن:
1.    تمام بخش‌های اپلیکیشن توزیع شده باید داده‌ها را به گونه‌ای فراهم کنند که شما بتوانید آن‌ها را مصرف کنید، از جمله خود .NET، کتابخانه‌هایی که استفاده می‌کنید، و کد اپلیکیشن خودتان.
2.    این داده‌ها باید به جایی فرستاده شوند که شما بتوانید به آن‌ها دسترسی داشته باشید.
3.    ابزارهایی برای مشاهده/پرس‌وجو/درک کردن داده‌ها باید وجود داشته باشند.
در NET Aspire.ما به طور فزاینده‌ای در Open Telemetry سرمایه‌گذاری کرده‌ایم، هم به عنوان فرمت داده‌ها، هم پذیرش نام‌گذاری و ساختار Open Telemetry برای داده‌ها، و همچنین پروتکل Open Telemetry (OLTP) برای خارج کردن داده‌ها از اپلیکیشن شما و وارد کردن آن‌ها به یک اکوسیستم از ابزارها.

در .NET Aspire، ما کد لازم برای اتصال Open Telemetry را به صورت پیش‌فرض در پروژه ServiceDefaults فراهم می‌کنیم. ما از کد مشترک استفاده کردیم زیرا کنوانسیون‌هایی مانند نام نقاط پایانی سلامت وجود دارد که انتظار می‌رود برخی افراد بخواهند آن‌ها را برای پروژه یا شرکت خود سفارشی کنند. هنگام آزمایش، ما متوجه شدیم که استفاده از کد مشترک تجربه بهتری برای تعریف این نوع پیش‌فرض‌هایی که افراد می‌توانند تنظیم کنند فراهم می‌کند، تا اینکه آن‌ها را در یک کتابخانه با تنظیمات پیکربندی قرار دهیم.
.NET Aspire همچنین داشبورد توسعه‌دهنده‌ای را که بالاتر ذکر شد فراهم می‌کند که تمام لاگ‌ها، متریک‌ها و ردیابی‌ها از اپلیکیشن شما را در اختیار شما قرار می‌دهد. یکی از ویژگی‌های برجسته داشبورد نمای ردیابی‌ها است که یک ردیابی توزیع شده از درخواست‌هایی که از طریق اپلیکیشن شما رفته‌اند را فراهم می‌کند. در مثال زیر، ما یک درخواست به صفحه آب و هوای الگوی Aspire Starter App ارسال کردیم. شما می‌توانید ببینید که چگونه درخواست از فرانت‌اند به کش Redis می‌رود تا ببیند آیا داده‌ها در کش هستند (خط DATA redis GET)، سپس چون هیچ داده‌ای در کش وجود ندارد، یک تماس با API بک‌اند انجام می‌دهد و در نهایت آن داده‌ها را کش می‌کند.
 

این نوع نمایش کمک می‌کند تا مواردی مانند اقدامات کاربرانی که باعث مسیرهای ناکارآمد در سیستم می‌شوند، به راحتی یافت شوند. شما به سرعت مواردی مانند تماس‌های متعدد با پایگاه داده یا سرویس‌های فردی که سایر بخش‌های سیستم را کند می‌کنند را مشاهده خواهید کرد. کشف این نوع مشکلات بدون این نوع داده‌ها و نمایش داده‌ها می‌تواند دشوار باشد.

Service Discovery
 

یکی از اجزای کلیدی در ساخت هر اپلیکیشن توزیع شده، توانایی فراخوانی سرویس‌های دوردست است. به عنوان بخشی از .NET Aspire، ما کتابخانه جدیدی برای کشف سرویس به نام Microsoft.Extensions.ServiceDiscovery ساخته‌ایم. این کتابخانه انتزاع اصلی و پیاده‌سازی‌های مختلفی از کشف سرویس سمت کلاینت و تعادل بار را فراهم می‌کند که ادغام بی‌درزی را با HttpClientFactory، YARP و همچنین در محیط‌های مستقر مانند Kubernetes و Azure Container Apps امکان‌پذیر می‌سازد.
 

استقرار یک اپلیکیشن NET Aspire.
 

محصولات نهایی یک اپلیکیشن NET Aspire. شامل اپ‌های  NET .و پیکربندی هستند که می‌توانند در محیط‌های ابری شما مستقر شوند. با تفکر قوی مبتنی بر کانتینر در .NET Aspire، ساخت کانتینرهای بومی SDK .NET به عنوان ابزاری ارزشمند برای انتشار این اپ‌ها در کانتینرها با سهولت عمل می‌کند.
در حالی که NET Aspire. خود به صورت بومی مکانیسم مستقیمی برای استقرار اپلیکیشن‌ها در مقصدهای نهایی‌شان ارائه نمی‌دهد، مدل برنامه‌ای که بالاتر توضیح داده شد، همه چیز در مورد اپلیکیشن، وابستگی‌ها، پیکربندی‌ها، و اتصالات به هر یک از سرویس‌ها را می‌داند. مدل برنامه می‌تواند یک تعریف منیفست تولید کند که تمام این روابط و وابستگی‌ها را توصیف می‌کند که ابزارها می‌توانند آن را مصرف، افزایش، و برای استقرار روی آن بنا کنند.
با این منیفست، ما امکان استقرار اپلیکیشن .NET Aspire شما در Azure با استفاده از Azure Container Apps را به ساده‌ترین و سریع‌ترین شکل ممکن فراهم کرده‌ایم. با کار کردن با قابلیت‌های جدید در Azure Developer CLI و NET Aspire.، این تجربیات ترکیبی به شما امکان می‌دهند به سرعت یک محیط NET Aspire. را تشخیص دهید، اپلیکیشن را درک کنید، و فوراً منابع Azure را در یک مرحله تهیه و استقرار دهید.

(توجه: بخش‌هایی از این ویدیو با سرعت بالاتری پخش می شود. اپ aspire-starter به طور معمول حدود ۵ دقیقه برای تهیه و استقرار زمان می‌برد.)

همانطور که در ویدیو بالا می‌بینید، این یکی از سریع‌ترین روش‌ها برای رفتن از کد به ابر با استفاده از NET Aspire. است. ما به تکامل این قابلیت استقرار اپ‌های NET Aspire. ادامه خواهیم داد، سهولت استقرار را از ابزارهایی مانند مکانیسم انتشار Visual Studio گسترش می‌دهیم، از همان منیفست زیربنایی و ادغام با Azure Developer CLI، مستقیماً از IDE مورد علاقه شما استفاده می‌کنیم!
Azure Developer CLI همچنین می‌تواند از منیفست، bicep ایجاد کند تا به توسعه‌دهندگان و مهندسان پلتفرم اجازه دهد فرآیندهای استقرار را بررسی یا افزایش دهند.
ما انتظار داریم این یک جزء کلیدی باشد که بسیاری از سیستم‌های IaC با آن ادغام می‌شوند.

اپلیکیشن‌های موجود
 

تاکنون در این پست وبلاگ، ما بسیاری از اپلیکیشن‌های جدید را نشان داده‌ایم، اما .NET Aspire همچنین می‌تواند با اپلیکیشن‌های موجود استفاده شود، زیرا امکان پذیرش تدریجی بخش‌های مختلف این استک وجود دارد.
ابتدا، .NET Aspire بخشی از .NET 8 است. بنابراین، شما قبل از تلاش برای استفاده از هر بخشی از این استک، نیاز به به‌روزرسانی دارید. ما ابزارها و راهنمایی‌هایی را برای کمک به شما در این زمینه داریم که می‌توانید اینجا پیدا کنید:  Upgrade Assistant | .NET (microsoft.com) . همچنین شما به آخرین نسخه پیش‌نمایش Visual Studio نیاز خواهید داشت، اگر بخواهید از ابزارهای Visual Studio استفاده کنید، 17.9 در زمان نوشتن این متن.
پس از آن، شما می‌توانید روی یک پروژه در Visual Studio راست‌کلیک کرده و Add -> Aspire Orchestrator Support را انتخاب کنید.
 

سپس با پیامی روبرو خواهید شد که از شما می‌خواهد تا پروژه و اقدام انجام شده را تایید کنید.
 

این اقدام دو پروژه AppHost و ServiceDefaults ایجاد می‌کند، پروژه‌ای که شما انتخاب کرده‌اید از قبل به AppHost اضافه شده است. حالا می‌توانید پروژه AppHost را اجرا کنید و داشبورد توسعه‌دهنده را مشاهده کنید. از اینجا می‌توانید به پروژه ServiceDefaults ارجاع دهید و متد AddServiceDefaults() را روی سازنده اپلیکیشن خود فراخوانی کنید. این کار Open Telemetry، نقاط پایانی بررسی سلامت، کشف سرویس و الگوهای پیش‌فرض انعطاف‌پذیری برای این پروژه را راه‌اندازی می‌کند.
هنگامی که از Visual Studio استفاده نمی‌کنید، همچنان می‌توانید پروژه‌های AppHost و ServiceDefaults را به یک راه‌حل موجود با استفاده از dotnet new اضافه کنید، اما آن‌ها از قبل به یک پروژه موجود مانند مثال بالا ارجاع داده نمی‌شوند.
حالا می‌توانید به اجزاء .NET Aspire تغییر کنید اگر از هر یک از سرویس‌هایی که اجزاء دارند استفاده می‌کنید. این ممکن است به معنای حذف برخی پیکربندی‌های صریح باشد اگر قبلاً خودتان آنچه که جزء انجام می‌دهد را تنظیم کرده‌اید. شما همچنین می‌توانید آزادانه از اجزاء در هر اپ .NET 8 بدون هماهنگ‌سازی استفاده کنید. این کار باعث می‌شود که انعطاف‌پذیری و سایر پیکربندی‌ها به جزء اعمال شوند، اما شما بقیه موارد .NET Aspire مانند داشبورد، کشف سرویس، و پورت‌ها، URL‌ها یا رشته‌های اتصال خودکار را دریافت نخواهید کرد.

نتیجه‌گیری
 

ما واقعاً هیجان‌زده هستیم که امروز اولین پیش‌نمایش .NET Aspire را به شما ارائه دهیم. با ساختن بر پایه‌های محکم اصول و یک رابط برنامه‌نویسی بسیار کارآمد در .NET 8، ما اطمینان داریم که شما از کارآمدی در ساخت اپلیکیشن‌های cloud native خود با استفاده از .NET Aspire لذت خواهید برد.
امروز با این منابع شروع کنید:
•    نصب بار کاری Aspire با استفاده از نصب‌کننده Visual Studio.
•    ساخت اولین راه‌حل .NET Aspire خود.
مهم‌تر از همه، ما می‌خواهیم بدانیم که چه چیزی برای شما کار می‌کند و چه چیزی را می‌توانیم بهبود ببخشیم. .NET Aspire بخشی از پلتفرم و بنیاد .NET است و یک پروژه منبع باز در کنار پلتفرم است. با ما در https://github.com/dotnet/aspire در تعامل باشید.