معرفی NET Aspire.:ساده‌سازی توسعه اپلیکیشن‌های Cloud-Native با استفاده از NET 8.

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

 
 چندین نسخه است که روی یکی از اهداف بلندمدت خود در حال پیشرفت هستیم. تبدیل کردن .NET به یکی از پربازده‌ترین پلتفرم‌های دنیا برای ساختن اپلیکیشن‌های ابری (cloud-native). ما در کنار برخی از سخت‌گیرانه‌ترین سرویس‌های مایکروسافت با نیازهای مقیاس‌بندی که برای اکثر برنامه‌ها بی‌سابقه است، کار کرده‌ایم. سرویس‌هایی که از صدها میلیون کاربر فعال ماهانه پشتیبانی می‌کنند. همکاری با این سرویس‌ها برای اطمینان از برآورده شدن نیازهایشان، تضمین کرد که ما قابلیت‌های اساسی را برای پاسخگویی به تقاضاهای سرویس‌های ابری با مقیاس بالا داشته باشیم. ما روی فناوری‌ها و کتابخانه‌های مهمی مانند Health Checks، YARP، فکتوری ساخت کلاینت HTTP و gRPC سرمایه‌گذاری کرده‌ایم. با AOT محلی، ما در حال کار برای رسیدن به نقطه‌ی ایده‌آل عملکرد و اندازه هستیم و SDK Container Builds دریافت هر برنامه‌ی .NET در یک container و آماده‌سازی آن برای cloud مدرن را برای توسعه‌دهنده بسیار ساده می‌کند. اما چیزی که از توسعه‌دهندگان شنیدیم این بود که ما باید کارهای بیشتری انجام دهیم. ساخت برنامه برای cloud هنوز هم خیلی سخت است. توسعه‌دهندگان به طور فزاینده‌ای از منطق کسب و کار خود و آنچه که بیشترین اهمیت را دارد، دور شده و با پیچیدگی‌های cloud دست و پنجه نرم می‌کنند. برای کمک به شما در ساده‌سازی پیچیدگی برنامه‌های ابری، ما این محصول جدید را معرفی میکنیم

NET Aspire.  چیست؟

NET Aspire. مجموعه‌ای از ابزارها و کتابخانه‌ها است که به شما کمک می‌کند تا برنامه‌های ابری قدرتمند، قابل مشاهده و قابل تنظیم را با استفاده از .NET بسازید.

Aspire شامل مجموعه کاملی از کامپوننت‌ها است که برای برنامه‌های ابری بهینه‌سازی شده‌اند و به طور پیش فرض قابلیت‌های کشف سرویس، تله‌متری، انعطاف‌پذیری و بررسی سلامت را ارائه می‌دهند.

Aspire به همراه تجربه‌ای توسعه‌دهنده محلی پیشرفته و ساده، به شما کمک می‌کند تا وابستگی‌های ضروری برای برنامه‌های ابری را به راحتی کشف، دریافت و پیکربندی کنید، هم برای برنامه‌های جدید .NET که از .NET 8+ استفاده می‌کنند و هم برای برنامه‌های .NET موجود.

زمان‌بندی:

• اولین پیش‌نمایش .NET Aspire با .NET 8 ارائه می‌شود.
• نسخه نهایی (GA) به عنوان بخشی از .NET 8 در بهار سال آینده منتشر خواهد شد.
• Aspire بخشی از .NET 8 است و در آینده با .NET همگام خواهد شد.
•  مستندات، گیت هاب

گشتی در NET Aspire . 

 در این بخش، به گشتی در template جدید .NET Aspire Starter می‌پردازیم و قبل از اینکه در ادامه به جزئیات بیشتری بپردازیم، به طور خلاصه به تمام ویژگی‌های آن اشاره می‌کنیم. این بخش به صورت یک مرور کلی گفتگویي طراحی شده است که می‌توانید به همراه آن پیش بروید. برای انجام این کار به جدیدترین نسخه .NET 8 و Visual Studio 2022 Preview (17.9 Preview 1) نیاز دارید. اگر از سیستم‌عامل‌های لینوکس یا مک استفاده می‌کنید، همچنان می‌توانید در این مسیر همراه ما باشید، اما برخی از مثال‌های ابزار ارائه شده هنوز در دسترس نخواهند بود.

گشتی در راه‌حل Visual Studio

برنامه Starter به گونه‌ای طراحی شده است که شما را با یک سولسوشن .NET Aspire کارآمد راه اندازی کند و به شما امکان می‌دهد آن را امتحان کنید. این برنامه از دو پروژه و یک حافظه کش Redis تشکیل شده است. پروژه front-end یک برنامه وب Blazor است که اطلاعات آب و هوا را از طریق یک API back-end دریافت می‌کند.

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

 دو پروژه جدید در .NET Aspire Starter Template

در این بخش دو پروژه جدید که قبلاً ندیده‌اید را معرفی می‌کنیم:

• <appname>.AppHost
• <appname>.ServiceDefaults

پروژه AppHost

پروژه AppHost هر گونه پروژه .NET، کانتینر یا فایل اجرایی را که برای اجرای برنامه توزیع‌شده شما لازم است، اجرا می‌کند. هنگام استفاده از Visual Studio، اشکال‌زدایی به تمام پروژه‌های در حال اجرا متصل می‌شود و به شما امکان می‌دهد در هر سرویس برنامه خود قدم بگذارید و بین آنها جابجا شوید. در ادامه این پست به طور مفصل‌تر به این پروژه و کد موجود در آن خواهیم پرداخت.

پروژه ServiceDefaults

پروژه ServiceDefaults شامل منطق رایج متمرکز بر سرویس است که برای هر یک از پروژه‌ها در برنامه اعمال می‌شود. این جایی است که دغدغه‌های مشترک مانند سرویس دیسکاوری، تله‌متری و نقاط پایانی بررسی سلامت پیکربندی می‌شوند. ما می‌خواستیم این موضوع در تمام پروژه‌ها ثابت باشد، اما همچنین می‌دانیم که تیم‌ها و سازمان‌ها احتمالاً می‌خواهند برخی از تنظیمات را تغییر دهند. کد اشتراکی در این پروژه قابل‌کشف‌ترین و توسعه‌دهنده‌پسندترین مکانیزمی بود که می‌توانستیم برای دستیابی به این اهداف پیدا کنیم.

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

با اجرای یک برنامه starter .NET Aspire با F5 در Visual Studio یا dotnet run از طریق خط فرمان، به داشبورد توسعه‌دهنده منتقل می‌شوید. این داشبورد به عنوان یک ابزار ضروری برای اشکال‌زدایی برنامه‌های توزیع‌شده عمل می‌کند و یک نمای واحد از خدمات شما به همراه گزارش‌ها، معیارها و ردیابی‌های آنها ارائه می‌دهد.

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

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

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

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

چند سال پیش روی آزمایشی به نام Project Tye کار می‌کردیم. بسیاری از آموخته‌های آن آزمایش اکنون در .NET Aspire در دسترس هستند، از جمله این داشبورد که برای اولین بار در آن آزمایش امتحان شد. اگر از Project Tye لذت بردید و می‌خواستید ادامه داشته باشد، فکر می‌کنیم عاشق .NET Aspire خواهید شد.

کامپوننت ها درNET Aspire .

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

 اگر در حال دنبال کردن مراحل هستید و این بسته را نمی‌بینید، احتمالاً هنگام ایجاد پروژه، کادر «use Redis caching» را علامت نزده‌اید.

این بسته NuGet چیزی است که ما به آن کامپوننت .NET Aspire می‌گوییم. کامپوننت‌ها کتابخانه‌های چسباننده‌ای هستند که یک SDK را برای کار در محیط ابری پیکربندی می‌کنند. هر کامپوننت باید:

• ارائه JSON Schema به config برای تکمیل خودکار دستورالعمل در appsettings.json.
• از الگوهای انعطاف‌پذیری قابل تنظیم مانند تلاش مجدد، زمان‌های انتظار و قطع‌کننده‌های مدار برای به حداکثر رساندن در دسترس بودن استفاده کنید.
• بررسی‌های سلامت را در معرض دید قرار می‌دهد تا برنامه‌ها بتوانند سلامت سرویس از راه دور را ردیابی و به آن پاسخ دهند.
• ثبت‌نام، معیارها و ردیابی را با استفاده از انتزاع‌های مدرن .NET (ILogger، Meter، Activity) ارائه می‌دهد.
• روش‌های الحاقی را ارائه می‌دهد که خدمات را از 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 پروژه استارت‌آپ شماست. این کد پروژه‌های شما، وابستگی‌های آن‌ها را اجرا می‌کند و به طور مناسب آن‌ها را پیکربندی می‌کند تا به آن‌ها امکان برقراری ارتباط دهد. یکی از اهداف ما این است که تا حد امکان پورت‌ها و رشته‌های اتصال را از جریان توسعه شما حذف کنیم. ما این کار را از طریق یک مکانیزم سرویس دیسکاوری انجام می‌دهیم که به توسعه‌دهندگان اجازه می‌دهد هنگام برقراری تماس‌های HTTP به جای آدرس‌های IP و پورت‌ها از نام‌های منطقی استفاده کنند. در اینجا می‌بینید که من API خود را با نام apiservice نامگذاری می‌کنم، سپس آن را به عنوان یک مرجع به front-end پاس می‌دهم و سپس می‌توانم هنگام برقراری تماس‌های HTTP از طریق IHttpClientFactory از apiservice به عنوان نام استفاده کنم. تماس‌های برقرار شده با استفاده از این روش همچنین به لطف ادغام با پروژه Polly به طور خودکار دوباره امتحان می‌شوند و با خرابی‌های موقت برخورد می‌کنند.

AppHost وابستگی‌ها و الزامات برنامه شما را راه‌اندازی می‌کند و ابزار .NET Aspire آن‌ها را در حلقه توسعه شما برآورده می‌کند.

بررسی عمیق‌تر: کامپوننت هادر NET Aspire.

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

• اضافه کردن بسته Redis با کتابخانه کلاینت Redis.
• کشف و اضافه کردن یک کتابخانه بررسی‌های سلامت به طوری که برنامه شما بتواند به عدم دسترسی به Redis پاسخ دهد. این مورد اغلب اوقات نادیده گرفته می‌شود اما در عمل مفید است.
• اضافه کردن Redis به DI و پیکربندی رشته‌های اتصال. این کار پیچیده است زیرا باید بدانید که طول عمر انواع کتابخانه کلاینت Redis چه باید باشد. که نیاز به تحقیق دارد.
• پیکربندی کتابخانه کلاینت Redis برای ارسال خروجی log به سیستم تله‌متری شما.
• لاگ‌ها و معیارها متفاوت هستند و به لوله کشی‌های متفاوتی نیاز دارند.
• تصمیم‌گیری در مورد اینکه چه خط‌مشی و منطق انعطاف‌پذیری مورد نیاز است و پیکربندی Redis یا کپسوله کردن تماس‌ها با کتابخانه‌ای مانند Polly که می‌تواند خط‌مشی‌های انعطاف‌پذیری را پیاده‌سازی کند. این کار نیز نیاز به تحقیق در مورد قابلیت‌های Redis و دانش در مورد اینکه چه خط‌مشی انعطاف‌پذیری باید داشته باشید، دارد. این چیزی است که اغلب اوقات در ابتدای کار نمی‌دانید و منجر به این می‌شود که افراد بدون آن کار خود را ارسال کنند تا اینکه مشکلی در محیط عملیاتی رخ دهد که می‌توانست با یک خط‌مشی تلاش مجدد با تأخیر تصاعدی اجتناب شود.

 در مقابل، اگر از .NET Aspire استفاده کنیم:

• بسته .NET Aspire Redis را اضافه کنید.
• AddRedis را روی builder صدا بزنید.
• (به‌طور اختیاری) پیکربندی پیش‌فرض را در appSettings.json نادیده بگیرید (که اکنون شماتیک شده است، بنابراین تکمیل خودکار برای کشف آنچه قابل تنظیم است را دارید).

کامپوننت‌های .NET Aspire برای ارائه یک پیکربندی ایده‌آل آماده برای تولید بدون پنهان کردن SDK زیربنایی ساخته شده‌اند. در هر دو مثال ذکر شده، کد شما برای استفاده از Redis به طور مداوم از همان کتابخانه و انواع کلاینت Redis استفاده خواهد کرد.

برای اینکه یک کامپوننت برای استفاده آماده در نظر گرفته شود، باید موارد زیر را انجام دهد:

• پیکربندی دقیق، شماتیک و جزئی ارائه دهد.
• بررسی‌های سلامت را برای ردیابی و پاسخ به سلامت سرویس‌های از راه دور راه‌اندازی کند.
• یک الگوی انعطاف‌پذیری پیش‌فرض و قابل تنظیم (تلاش مجدد، زمان‌های انتظار و غیره) برای به حداکثر رساندن در دسترس بودن ارائه دهد.
• قابلیت‌های ثبت لاگ، معیار و ردیابی یکپارچه را برای مشاهده‌پذیری کامپوننت ارائه دهد.

 لیست اولیه کامپوننت‌های ما در زیر آمده است و می‌توانید برای اطلاعات بیشتر به .NET Aspire components overview | Microsoft Learn مراجعه کنید.

کامپوننت‌های مستقل از Cloud

کامپوننت‌های خاص Azure

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

مدل برنامه (Application Model)

پروژه AppHost در یک برنامه .NET Aspire به شما امکان می‌دهد نیازهای برنامه خود را با زبان .NET مورد علاقه‌تان (در ابتدا پشتیبانی از C#) بیان کنید. این پروژه مسئول هماهنگ کردن اجرای برنامه شما روی ماشین توسعه‌تان است.

هماهنگ‌سازی (Orchestration) قابلیت اصلی .NET Aspire است که برای ساده‌سازی اتصالات و پیکربندی‌ها بین بخش‌های مختلف برنامه ابری شما طراحی شده است. .NET Aspire انتزاع‌های مفیدی را ارائه می‌دهد که به شما امکان می‌دهد دغدغه‌هایی مانند کشف سرویس، متغیرهای محیطی و پیکربندی‌های کانتینر را بدون نیاز به مدیریت جزئیات پیاده‌سازی سطح پایین، هماهنگ کنید. این انتزاع‌ها همچنین الگوهای راه‌اندازی سازگاری را در سراسر برنامه‌های کاربردی با بسیاری از کامپوننت‌ها و سرویس‌ها ارائه می‌دهند.

هماهنگ‌سازی .NET Aspire به موارد زیر کمک می‌کند:

• ترکیب برنامه (App composition): منابعی را که برنامه را تشکیل می‌دهند، از جمله پروژه‌های .NET، کانتینرها، فایل‌های اجرایی یا منابع ابری تعریف کنید.
• کشف سرویس (Service discovery): تعیین اینکه چگونه منابع مختلف با یکدیگر ارتباط برقرار می‌کنند.

به عنوان مثال، با استفاده از .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 را برای استفاده از رشته اتصال ارائه شده به طور خودکار پیکربندی می‌کند. این کار باعث حذف منبع بزرگی از راه‌اندازی‌های مستعد خطا در جریان توسعه شما می‌شود و راه‌اندازی و سوار شدن (اشاره به اضافه شدن افراد جدید به تیم) را ساده می‌کند. اگر از Service Discovery در محیط عملیاتی استفاده می‌کنید، حتی اگر فقط از ویژگی‌های پیش‌فرض Kubernetes استفاده کنید، این مورد نسبت به پیکربندی دستی، تولید را به طور دقیق‌تری بازتاب می‌دهد.

مجموعه اولیه منابع ما در زیر آمده است:

منابع داخلی

• پروژه: یک پروژه .NET، به عنوان مثال برنامه‌های وب ASP.NET Core
• کانتینر: یک تصویر کانتینر، مانند یک تصویر Docker
• فایل اجرایی: یک فایل اجرایی

افزونه های مستقل از Cloud

هر کدام از این موارد زمانی در دسترس قرار می‌گیرند که بسته 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.

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

پروژه‌ها (Projects): صفحه پروژه‌ها صفحه اصلی داشبورد است، این صفحه لیستی از تمام منابع پروژه در برنامه شما را نشان می‌دهد. عملکرد اصلی آن نشان دادن وضعیت هر پروژه و دادن URLها به بخش‌های مختلف برنامه به شماست. همچنین زمانی که خطایی برای یک پروژه ثبت شده باشد، نشانگر (badge) نمایش می‌دهد تا به راحتی بتوانید مشکلات را پیدا کنید.

کانتینرها (Containers): این صفحه مشابه صفحه پروژه‌ها است، اما برای منابع کانتینر برنامه شما. در مثال بالا، کانتینر کش Redis در اینجا نمایش داده می‌شود.

فایل‌های اجرایی (Executables): این صفحه مشابه صفحه پروژه‌ها است، اما برای منابع فایل‌های اجرایی برنامه شما.

لاگ‌ها (Logs): بخش لاگ‌های داشبورد دسترسی به لاگ‌های تمام قسمت‌های برنامه شما را در یک مکان مرکزی فراهم می‌کند.

• لاگ‌های پروژه (Project Logs): خروجی از ارائه‌دهنده لاگ‌گیری در پروژه‌های .NET شما را می‌توان در اینجا مشاهده کرد، می‌توانید بین هر پروژه جابجا شوید و هر سطح شدت لاگ با رنگ متفاوتی نمایش داده می‌شود.
• لاگ‌های کانتینر (Container Logs): این صفحه مشابه لاگ‌های پروژه است، اما برای کانتینرها.
• لاگ‌های فایل‌های اجرایی (Executable Logs): این صفحه مشابه لاگ‌های پروژه است، اما برای فایل‌های اجرایی.

لاگ‌های ساختاریافته (Structured Logs): صفحه لاگ‌های ساختاریافته نمای قابل فیلتر از تمام لاگ‌های شما را ارائه می‌دهد. لاگ‌های ساختاریافته، ویژگی‌های پیام‌های لاگ شما را حفظ می‌کنند تا بتوان آن‌ها را به صورت جداگانه فیلتر/جستجو کرد، در حالی که سایر صفحات لاگ‌ها همه ویژگی‌ها را در یک پیام لاگ رشته‌ای واحد ادغام می‌کنند.

ردیابی‌ها (Traces): صفحه ردیابی‌ها مسیر یک اکشن واحد را در تمام قسمت‌های برنامه شما نشان می‌دهد، یک ردیابی توزیع‌شده. این نمای کلی می‌تواند در یافتن گلوگاه‌ها، کندی‌ها و تشخیص سایر رفتارهایی که فقط هنگام استفاده از کل سیستم و نه به صورت جداگانه ظاهر می‌شوند، بسیار ارزشمند باشد. ما در بخش تور بالا اسکرین‌شاتی از نمای ردیابی‌ها نشان دادیم و برجسته کردیم که چگونه می‌توانید یک اکشن واحد را با استفاده از کش Redis، API و فرونت‌اند، همه در یک نما مشاهده کنید.

معیارها (Metrics): صفحه معیارها، تمام معیارهای برنامه شما را نشان می‌دهد.

برای اطلاعات بیشتر در مورد داشبورد به اینجا مراجعه کنید: .NET Aspire dashboard | Microsoft Learn

قابلیت مشاهده (Observability)

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

این به این معنی است که برای اینکه یک برنامه قابل مشاهده باشد:

• تمام اجزای برنامه توزیع شده باید به روشی که شما می‌توانید مصرف کنید، داده ارائه دهند، از جمله خود .NET، کتابخانه‌هایی که استفاده می‌کنید و کد برنامه خودتان.
• این داده‌ها باید به جایی ارسال شوند که بتوانید به آن دسترسی داشته باشید.
• ابزارهایی برای مشاهده/پرس و جو/درک داده‌ها باید وجود داشته باشد.

در .NET ما بیشتر و بیشتر روی Open Telemetry سرمایه‌گذاری کرده‌ایم، هم به عنوان فرمت داده، با پذیرش نام‌گذاری و ساختار Open Telemetry برای داده‌ها، و هم پروتکل Open Telemetry (OTLP) برای خارج کردن داده از برنامه شما و وارد کردن آن به اکوسیستم ابزارها.

در .NET Aspire ما به طور پیش فرض کد را برای راه‌اندازی Open Telemetry در پروژه ServiceDefaults ارائه می‌دهیم. ما از کد مشترک استفاده کردیم زیرا کنوانسیون‌هایی مانند نام نقاط پایانی سلامت شما وجود دارد که ما انتظار داریم برخی از افراد بخواهند آن‌ها را برای پروژه یا شرکت خود سفارشی کنند. هنگام آزمایش، متوجه شدیم که کد مشترک تجربه بهتری را برای تعریف این نوع مقادیر پیش‌فرض که افراد می‌توانستند آن‌ها را تنظیم کنند، به جای قرار دادن آن‌ها در یک کتابخانه با تنظیمات پیکربندی، ارائه می‌دهد.

.NET Aspire همچنین داشبورد توسعه‌دهنده‌ای را که در بالا به آن اشاره کردیم ارائه می‌دهد که تمام لاگ‌ها، معیارها و ردیابی‌ها را از برنامه شما به شما می‌دهد. یکی از ویژگی‌های برجسته داشبورد، نمای Traces است که یک ردیابی توزیع شده از درخواست‌هایی را ارائه می‌دهد که از برنامه شما عبور کرده‌اند. در مثال زیر، درخواستی به صفحه آب و هوا از الگوی برنامه 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، ساخت‌های کانتینر بومی .NET SDK به عنوان ابزاری ارزشمند برای انتشار آسان این برنامه‌ها به کانتینرها عمل می‌کنند.

در حالی که خود .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 نیاز دارید که در زمان نگارش ۱۷.۹ است.

پس از داشتن آن، می‌توانید روی یک پروژه در 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 را به شما ارائه دهیم. با تکیه بر پایه محکم اصول اولیه و یک سطح API باورنکردنی در .NET 8، ما مطمئن هستیم که با استفاده از .NET Aspire برای ساخت برنامه‌های ابری Native خود، عاشق بهره‌وری خواهید شد.

امروز با این منابع شروع کنید:

• با استفاده از Visual Studio Installer، پکیج Aspire را دانلود کنید.
• اولین راه‌حل .NET Aspire خود را بسازید.

همچنین ما چند نمونه داریم که چند مورد از چیزهای جالب را به نمایش می‌گذارند:

• فرانت‌اند Node با بک‌اند .NET: https://github.com/dotnet/aspire-samples
• یکپارچه‌سازی DAPR: https://github.com/dotnet/aspire-samples
• تمامی نمونه برنامه کاربردی eShop با Aspire اجرا می‌شوند: https://github.com/dotnet/eShop

مهمتر از همه، می‌خواهیم بشنویم چه چیزی برای شما کار می‌کند و چه چیزی را می‌توانیم بهبود بخشیم. .NET Aspire بخشی از پلتفرم و فونداسیون .NET است و یک پروژه متن باز در کنار پلتفرم است. در اینجا با ما درگیر شوید:https://github.com/dotnet/aspire