Wprowadzenie do Aspire 9.5 - Szybki start z tym niezbędnym narzędziem

Pierwsze kroki i instalacja Aspire 9.5

Tim zaczyna od wyjaśnienia przeznaczenia Aspire. Każdy programista .NET, który tworzy interfejsy API lub aplikacje internetowe, powinien zrozumieć to niezbędne narzędzie firmy Microsoft. Pojawiły się pewne niejasności co do możliwości Aspire, więc Tim postanawia od podstaw zademonstrować jego przeznaczenie, konfigurację i sposób użycia.

Otwiera Visual Studio i rozpoczyna nowy projekt, korzystając z szablonu aplikacji startowej Aspire. Jeśli nie masz zainstalowanego programu Aspire, autor odsyła do strony internetowej Microsoftu, gdzie znajdziesz instrukcje dotyczące konfiguracji i narzędzi dla programu Aspire, zaznaczając, że można go zainstalować za pomocą .NET CLI, Visual Studio lub VS Code. Dla uproszczenia Tim zaleca użycie polecenia CLI:

dotnet new install aspire.templates

Spowoduje to zainstalowanie najnowszych szablonów projektów, w tym Aspire 9.5. Po instalacji może być konieczne ponowne uruchomienie programu Visual Studio, aby szablony stały się widoczne.

Tim wybiera aplikację demonstracyjną Aspire, wybiera .NET 9, włącza HTTPS i korzysta z integracji z Redis do buforowania. To pokazuje rzeczywisty scenariusz, w którym Aspire zarządza całą aplikacją lokalnie. Pomija testy jednostkowe i przechodzi do tworzenia plików rozwiązania.

Zapoznanie się ze strukturą projektu i modelem aplikacji

Po wygenerowaniu projektu Tim analizuje pliki projektu utworzone przez model aplikacji Aspire. Rozwiązanie obejmuje cztery główne projekty, które odzwierciedlają zarówno typowe projekty .NET, jak i te specyficzne dla Aspire:

1. Projekt internetowy – aplikacja internetowa oparta na Blazorze.

2. Usługa API – usługa backendowa do obsługi danych lub logiki biznesowej.

3. AppHost – pojedynczy plik AppHost, który uruchamia całą aplikację.

4. ServiceDefaults – biblioteka zawierająca funkcje sprawdzania stanu, wykrywania usług i konfiguracji telemetrii.

Pierwsze dwa reprezentują typowy system rozproszony (frontend i backend), podczas gdy pozostałe dwa reprezentują ujednolicony zestaw narzędzi Aspire do zarządzania zmiennymi środowiskowymi, zależnościami oraz interfejsami API zdarzeń cyklu życia zasobów.

Tim podkreśla, że ten nowy model aplikacji zapewnia doskonałe wsparcie dla koordynacji wielu projektów, umożliwiając programistom uruchamianie całej aplikacji za pomocą jednego polecenia. AppHost kontroluje kolejność uruchamiania i zależności, podczas gdy ServiceDefaults automatycznie wstrzykuje domyślne ustawienia konfiguracyjne, kontrole stanu i integrację telemetrii.

Dłączego Aspire upraszcza lokalny rozwój

Tim wyjaśnia trudności związane z lokalnym zarządzaniem systemem rozproszonym bez Aspire. Tradycyjnie programiści muszą ręcznie konfigurować ustawienia środowiska uruchomieniowego kontenerów, przekierowanie portów i ciągi połączeń dla każdej usługi. Każdy programista musi indywidualnie odtworzyć zmienne środowiskowe, sekrety użytkownika oraz połączenia z Redis lub API.

W przypadku Aspire, Aspire CLI zajmuje się tym automatycznie. Uruchamia zależności, takie jak kontenery Redis, za pośrednictwem kontenera deweloperskiego lub instancji Docker, zarządza wykrywaniem punktów końcowych oraz zapewnia prywatny dostęp między usługami przy użyciu wykrywania usług.

Aspire wykorzystuje odwrotny serwer proxy i system rozpoznawania punktów końcowych, dzięki czemu interfejs użytkownika nie musi znać stałych numerów portów. Wystarczy po prostu podać nazwę API (np. "apiservice") — Aspire zajmie się resztą.

Znacznie poprawia to komfort pracy programistów, eliminując żmudne etapy konfiguracji i pozwalając im skupić się na kodzie, a nie na infrastrukturze.

Definiowanie usług i zależności w AppHost

Tim pokazuje serce konfiguracji Aspire: plik Program.cs w AppHost. Wykorzystując wzorzec Builder, Aspire definiuje każdą usługę za pomocą prostych poleceń, takich jak:

var cache = builder.AddRedis("cache");
var api = builder.AddProject<Projects.ApiService>("apiservice");
var web = builder.AddProject<Projects.Web>("webfrontend")
    .WithReference(cache)
    .WithReference(api);

var cache = builder.AddRedis("cache");
var api = builder.AddProject<Projects.ApiService>("apiservice");
var web = builder.AddProject<Projects.Web>("webfrontend")
    .WithReference(cache)
    .WithReference(api);

Ta składnia definiuje każdy zasób, ustala kolejność zależności i tworzy przejrzysty cykl życia zasobów. Aspire automatycznie obsługuje oczekiwanie na zależności, zapewniając, że najpierw uruchamia się pamięć podręczna, następnie API, a na końcu interfejs internetowy.

Ten niewielki zestaw instrukcji zapewnia programistom szczegółową kontrolę nad zachowaniem podczas uruchamiania, odzwierciedlając sposób działania w gotowych do produkcji aplikacjach rozproszonych.

Uruchamianie Aspire i zrozumieniuiuiuiuie pulpitu nawigacyjnego

Kiedy Tim uruchamia projekt, Aspire uruchamia własne środowisko kontenerowe i otwiera Aspire Dashboard — centralny interfejs do monitorowania wszystkich procesów. Początkowo pojawia się błąd: "Container runtime unhealthy" — Docker nie działał. Po uruchomieniu Docker, Aspire automatycznie inicjuje zasób wykonywalny Redis i łączy go z resztą aplikacji.

Pulpit nawigacyjny wyświetla ikony statusu oznaczone kolorami, wskazujące stan każdego zasobu. Gdy Redis, API i interfejs użytkownika działają, pulpit nawigacyjny zmienia kolor na zielony, wskazując, że cała aplikacja działa prawidłowo.

Ten system powiadomień natychmiast odzwierciedla stan w czasie rzeczywistym, zapewniając bardziej przejrzyste komunikaty o błędach niż standardowe logi konsoli. Programiści mogą wizualizować relacje między usługami, monitorować wskaźniki, a nawet uzyskiwać dostęp do punktów końcowych zasobów bezpośrednio z interfejsu użytkownika.

Wizualne spostrzeżenia dzięki panelowi Aspire

Widok graficzny na pulpicie nawigacyjnym wizualizuje sposób połączeń między usługami. Na przykład interfejs użytkownika łączy się zarówno z Redis, jak i usługą API, podczas gdy API jest niezależne. Ten widok śladu pomaga zrozumieć wewnętrzny przepływ wywołań i zależności.

Tim podkreśla, że pulpit nawigacyjny zawiera ulepszenia dotyczące szczegółów śledzenia, takie jak wyświetlanie opcji filtrowania śledzeń i podziału czasowego. Programiści mogą śledzić żądania HTTP w różnych usługach i obserwować wpływ na wydajność, korzystając z widoku śladów w Aspire.

Scentralizowane logowanie i ustrukturyzowane logi

Aspire łączy logi konsoli ze wszystkich plików projektu w jednym widoku. Zamiast żonglować wieloma oknami logów, programiści mogą korzystać z pulpitu nawigacyjnego, aby przeglądać logi ze wszystkich usług — aplikacji internetowej, API i integracji Redis — na jednej osi czasu.

Tim pokazuje, że Aspire wykorzystuje logowanie strukturalne, umożliwiające tworzenie wpisów bogatych w kontekst, takich jak identyfikatory, parametry i tagi. Programiści mogą filtrować logi według poziomu (Info, Warning, Error) lub wartości właściwości.

Na przykład programista może wyświetlić tylko te wpisy, w których "evenOddResult" == "odd". To zaawansowane filtrowanie logów w połączeniu z prefiksami oznaczonymi kolorami w Aspire sprawia, że debugowanie jest intuicyjne i wizualne.

Praca z śladami i telemetrią

W zakładce Traces Tim pokazuje, w jaki sposób Aspire śledzi żądania w ramach usług aplikacji. Każdy ślad zawiera informacje o czasie, statusie i zakresach, pokazujące, która usługa przetworzyła dane.

Na przykład żądanie "GetWeather" pokazuje, kiedy nastąpiło trafienie lub brak trafienia w pamięci podręcznej, kiedy nastąpiło wywołanie API oraz ile czasu zajęła każda akcja. To filtrowanie śladów pozwala na precyzyjną identyfikację wąskich gardeł i zależności.

Aspire obsługuje również OpenTelemetry do eksportowania danych śledzenia do innych narzędzi lub systemów, zapewniając programistom pełną obserwowalność w ramach usług rozproszonych.

Wskaźniki w czasie rzeczywistym i monitorowanie wydajności

Tim analizuje wskaźniki, takie jak czas trwania żądań, aktywne połączenia SignalR oraz liczbę aktywnych żądań. Wskaźniki te wizualizują aktualny stan aplikacji i umożliwiają wczesne wykrywanie problemów z połączeniem lub opóźnieniami.

Dane metryczne w Aspire 9.5 również zyskują dzięki ulepszeniom szczegółów śledzenia i lepszemu filtrowaniu śladów, co pozwala programistom wskazać w czasie rzeczywistym miejsca, w których występują spadki wydajności.

Aspire służy do lokalnego programowania, a nie do produkcji

Tim wyraźnie zaznacza, że pulpit nawigacyjny Aspire nie jest przeznaczony do wdrażania na serwerach produkcyjnych. Wdrożenie tego mogłoby ujawnić szczegóły wewnętrznego systemu i zmienne środowiskowe, co może być ryzykowne.

Jednakże, deweloperzy mogą nadal używać polecenia aspire deploy Aspire, aby publikować usługi w Azure Container Apps, Azure Container App Jobs lub innych integracjach Aspire. Te opcje wdrożenia rosną, ale pozostają oddzielone od pulpitu nawigacyjnego.

Celem Aspire jest odzwierciedlenie środowiska zbliżonego do produkcyjnego lokalnie z bezpiecznymi aktualizacjami i wsparciem podglądu, a nie zastępowanie systemów monitorowania produkcji.

Eksperymentowanie z rejestrowaniem i obsługą wyjątków

Tim dodaje strukturalne logowanie na stronie Licznika i celowo wprowadza NotImplementedException na stronie Pogoda. Podczas ponownego uruchamiania, pulpit nawigacyjny natychmiast przechwytuje zarówno strukturalne logi, jak i nieobsłużone wyjątki.

Pokazuje, jak logi Aspire wyświetlają pełne szczegóły, w tym nazwę parametru, wartości i stos wywołań. Integracja z GitHub Models i Copilot AI umożliwia automatyczne wyjaśnienia wyjątków i sugestie kodu do poprawek—przykład wczesnych usług AI oraz integracji kreatora wizualizacji AI w doświadczeniu deweloperów.

Analiza błędów przy użyciu filtrowania śladów

W zakładce Ślady, Tim demonstruje, jak nieudane wywołania API pojawiają się z czerwonym wykrzyknikiem. Kliknięcie jednej ujawnia wszystkie powiązane logi, filtrowane według identyfikatora zakresu, łącząc każde żądanie w wielu projektach .NET.

Ten zintegrowany widok—logi, ślady i kontrole zdrowia połączone—dostarcza interaktywne podpowiedzi do debugowania i budowania systemów obserwowalnych bez zewnętrznej konfiguracji.

Integracja Aspire z istniejącymi projektami .NET

Tim następnie wyjaśnia, jak zintegrować Aspire z istniejącą aplikacją. Deweloperzy muszą tylko dodać dwie rzeczy:

• Projekt AppHost, który kontroluje, jakie usługi się uruchamiają i ich zależności.

• Projekt ServiceDefaults, który zapewnia flagi funkcji, kontrole zdrowia, telemetrię i odkrywanie usług.

Odwołując się do ServiceDefaults w każdym pliku projektu, deweloperzy automatycznie otrzymują domyślne zmienne środowiskowe, konfigurację logowania i telemetrię. System rozwiązywania punktów końcowych Aspire usuwa potrzebę ręcznego przekierowywania portów lub zarządzania łańcuchami połączeń.

Rozszerzanie zasięgu Aspire poza lokalne użycie

Tim odnosi się do tego, jak możliwości Aspire się rozwijają poza użycie lokalne. Dzięki integracjom z Azure Container Apps i Azure AI Foundry, deweloperzy mogą używać Aspire CLI do wdrażania rozproszonych systemów z minimalną konfiguracją.

System już obsługuje niestandardowe ikony zasobów, właściwości nazw i wsparcie podglądu dla usług AI, takich jak punkty końcowe OpenAI lub połączenia Azure PostgreSQL.

Zintegrowany zestaw narzędzi Aspire wspiera również kontrolę wersji i bezpieczne aktualizacje między głównymi i mniejszymi wersjami, pomagając zespołom w pewnym przyjęciu aktualizacji, takich jak Aspire 9.5.

Ostatnie uwagi i przyszłe perspektywy

Gdy wideo dobiega końca, Tim określa Aspire jako "kopalnię złota dla deweloperów." Pulpit nawigacyjny jednoczy widok śladów, kontrole zdrowia, logi i metryki w jednym zintegrowanym panelu—coś, co wcześniej było niedostępne w lokalnym rozwoju.

Dla Tima i jego zespołu, każdy nowy projekt .NET Aspire teraz domyślnie używa tego systemu. Skraca to czas budowy niestandardowych aplikacji, poprawia doświadczenia deweloperów i zapewnia, że aplikacje rozproszone gotowe do produkcji zachowują się spójnie na różnych maszynach.

Zauważa, że główne wydania Aspire będą nadal doskonalić filtrowanie śladów, rozwiązywanie punktów końcowych i integracje AI, jednocześnie utrzymując fokus na bezpiecznych aktualizacjach i ogólnej dostępności.

Tim zachęca wszystkich do eksploracji Aspire 9.5, używania go w kolejnych projektach .NET i wykorzystania jego prostoty "jedno polecenie" do przeglądania logów, zarządzania tunelami deweloperskimi i testowania całej aplikacji lokalnie z pewnością.