Aspire 9.5介紹 - 快速入門這個必備工具

Tim Corey

43分49秒

每位使用網頁應用程式的現代.NET開發者都應該了解如何使用Aspire 9.5。在他的詳細影片"Aspire 9.5 簡介 – 快速上手這個重要工具"中，Tim Corey介紹了這個新的.NET Aspire系統，解釋了它是什麼、其價值所在，以及如何快速入門。

在整個影片中，Tim逐步建立了一個範例解決方案，使用Visual Studio和最新的專案範本。 這篇文章緊密跟隨他的演練，提供關於專案文件、設置過程和Aspire為生產就緒的分佈式應用程式構建帶來的開發者體驗的完整指南。

開始使用和安裝Aspire 9.5

Tim首先解釋了Aspire的目的。每位構建API或網頁應用程式的.NET開發者都應該了解這個重要的Microsoft工具。 對於Aspire能做什麼一直存在混淆，Tim開始從頭演示其用途、設置和使用。

他打開Visual Studio，開始使用Aspire入門應用程式範本建立一個新專案。 如果您還沒有安裝Aspire，他指出了Microsoft的網站，提供關於Aspire的設置和工具，並注意到您可以透過.NET CLI、Visual Studio或VS Code安裝Aspire。 為簡單起見，Tim建議使用CLI命令：

dotnet new install aspire.templates

dotnet new install aspire.templates

這會安裝最新的專案範本，包括Aspire 9.5。安裝後，Visual Studio可能需要重啟以顯示這些範本。

Tim選擇了Aspire示範應用程式，選用.NET 9，啟用HTTPS，並使用Redis整合來進行快取。 這展示了一個Aspire在本地管理整個應用程式的真實案例。 他跳過單元測試，繼續建立解決方案檔案。

探索專案結構和應用程式模型

一旦專案生成，Tim分解了Aspire應用程式模型建立的專案文件。 該解決方案包括四個主要專案，這些專案既反映典型的.NET專案，也反映Aspire特定專案：

1. 網路專案 – 一個基於Blazor的網頁應用程式。

2. API服務 – 一個用於資料或業務邏輯的後端服務。

3. AppHost – 啟動整個應用程式的單一文件AppHost。

4. ServiceDefaults – 包含健康檢查、服務發現和遙測設置的庫。

前兩者代表了正常的分佈式系統（前端和後端），而後兩者則代表Aspire管理環境變數、依賴性和資源生命週期事件API的統一工具鏈。

Tim突出了這種新的應用程式模型如何為多專案協同提供一級支持，使開發者可以用一個命令運行他們的整個應用程式。 AppHost控制啟動順序和依賴性，而ServiceDefaults則自動注入配置預設、健康檢查和遙測整合。

為何Aspire簡化了本地開發

Tim解釋了在沒有Aspire的情況下在本地管理分佈式系統的痛點。傳統上，開發者必須手動配置容器運行環境設置、端口轉發和每個服務的連接字串。 每個開發者必須個別複製環境變數、使用者秘密以及redis或API的連接。

使用Aspire，Aspire的CLI會自動處理這些。 它通過開發容器或Docker實例啟動Redis容器等依賴性，管理端點發現，並使用服務發現在服務間提供私有存取。

Aspire使用反向代理和端點解析系統，因此網頁前端不需要知道硬編碼的端口號。 它只需通過名稱引用API（如"apiservice"）—Aspire會處理其餘部分。

這大大改善了開發者體驗，通過去除壓縮的設置步驟，使開發者專注於程式碼而非基礎設施。

在AppHost中定義服務和依賴性

Tim展示了Aspire設置的核心：AppHost的Program.cs文件。使用var構建器模式，Aspire通過簡單的命令定義每個服務，例如：

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);

Dim cache = builder.AddRedis("cache")
Dim api = builder.AddProject(Of Projects.ApiService)("apiservice")
Dim web = builder.AddProject(Of Projects.Web)("webfrontend") _
    .WithReference(cache) _
    .WithReference(api)

Dim cache = builder.AddRedis("cache")
Dim api = builder.AddProject(Of Projects.ApiService)("apiservice")
Dim web = builder.AddProject(Of Projects.Web)("webfrontend") _
    .WithReference(cache) _
    .WithReference(api)

這種語法定義每個資源，設置依賴性順序，並建立清晰的資源生命週期。 Aspire自動處理等待依賴性，確保快取首先啟動，接著是API和網頁前端。

這小集合指令給開發者對啟動行為的精細控制，模擬生產就緒的分佈式應用程式的運行方式。

運行Aspire並了解儀表板

當Tim運行專案時，Aspire啟動其自己的容器運行環境並打開Aspire儀表板——一個監控一切的中心介面。 最初，出現了一個錯誤："容器運行環境不健康"—Docker未運行。 一旦Docker啟動，Aspire自動初始化一個Redis可執行資源並將其連接到應用程式的其他部分。

儀表板顯示了色碼狀態圖標，指示每個資源的健康狀況。 一旦Redis、API和網頁前端都運行起來，儀表板變成綠色，顯示整個應用程式健康。

此通知系統即時顯示實時狀態，提供更明確的錯誤消息比標準控制台日誌。 開發者可以在UI中直接可視化服務關係，監控指標，甚至存取資源端點。

通過Aspire儀表板的視覺化洞察

儀表板中的圖形視圖視覺化了服務如何連接。 例如，網頁前端連接到Redis和API服務，而API是獨立的。 這種跟踪視圖幫助理解內部的調用流和依賴性。

Tim強調儀表板包括跟踪細節改進，例如顯示跟踪篩選選項和時間分解。 開發者可以在跨服務的HTTP請求中追踪，並使用Aspire的跟踪視圖查看性能影響。

集中記錄和結構化日誌

Aspire將所有專案文件的控制台日誌統一在一個視圖中。 開發者不需要處理多個日誌窗口，而可以使用儀表板查看來自所有服務的日誌——網頁應用、API和Redis整合在一條時間線上。

Tim展示了Aspire使用結構化日誌，允許如ID、參數和標籤之類的內容豐富的記錄條目。 開發者可以按等級（資訊、警告、錯誤）或屬性值篩選日誌。

例如，開發者可以只查看"evenOddResult" == "odd"的條目。 這種先進的日誌篩選結合了Aspire的色碼前綴，使得除錯更加直觀和可視化。

在跟踪和遙測中工作

在跟踪選項卡中，Tim演示了Aspire如何跟踪應用程式中服務之間的請求。 每個跟踪包含時序、狀態和分段顯示了哪個服務處理了什麼。

例如，一個"GetWeather"請求顯示快取是否命中或錯過，API呼叫何時發生，以及每個動作花了多長時間。 這種跟踪篩選允許精確識別瓶頸和依賴性。

Aspire還支持OpenTelemetry，用於將跟蹤資料導出到其他工具或系統，提供全面的觀察能力。

實時指標和性能監控

Tim探索了如請求持續時間、SignalR已啟動的連接和已啟動請求數之類的指標。 這些指標視覺化了程式的即時狀態，提供早期檢測連接或延遲問題。

Aspire 9.5中的指標資料也受益於跟踪細節的改進和更好的跟踪篩選，使開發者能實時找出性能下降的原因。

Aspire適用於本地開發，而非生產環境

Tim明確指出，Aspire的儀表板並不適合部署到生產伺服器。 部署它可能會暴露內部的系統細節和環境變數，這可能存在風險。

然而，開發者可以仍然利用Aspire的aspire deploy命令來將服務發布到Azure Container Apps、Azure Container App Jobs或其他Aspire整合。 這些部署選項正在增長，但仍然與儀表板獨立。

Aspire的目的在於本地模擬類似生產環境，提供安全升級和預覽支持，而不是替代生產監控系統。

實驗日誌和例外處理

Tim在Counter頁面中新增了結構化日誌，並在Weather頁面引入了NotImplementedException。 重新運行時，儀表板立即捕獲了結構化日誌和未處理的例外。

他展示了Aspire的日誌顯示詳細資訊，包括參數名稱、值和調用堆棧。 與GitHub Models和Copilot AI的整合允許對例外進行自動解釋，並提供程式碼建議作為修復方案——這就是早期AI服務和生成式AI可視化器整合到開發者體驗的例子。

使用跟踪篩選分析錯誤

在跟踪選項卡中，Tim展示了失敗的API呼叫如何顯示帶有紅色驚嘆號圖標。 點擊一個會顯示所有相關日誌，根據跨度ID篩選，將每個請求連結到多個.NET專案。

這一統一的視圖——結合日誌、跟踪和健康檢查——提供了交互式提示，用於除錯和建立可觀察系統，而無需額外配置。

將Aspire整合到現有.NET專案中

接著Tim解釋了如何將Aspire整合到現有應用中。開發者只需新增兩項：

• AppHost專案，控制啟動哪些服務及其依賴性。

• ServiceDefaults專案，提供功能旗標、健康檢查、遙測和服務發現。

通過在每個專案文件中引用ServiceDefaults，開發者自動獲得預設環境變數、日誌設置和遙測。 Aspire的端點解析系統消除了手動端口轉發或連接字串管理的需要。

將Aspire擴展至本地用途之外

Tim談論到Aspire的能力正在超越本地用途的擴展。 透過Azure Container Apps和Azure AI Foundry整合，開發者可以使用Aspire CLI以最小配置部署分佈式系統。

系統已支援自定義資源圖標、名稱屬性、並對如OpenAI端點或Azure PostgreSQL連接的AI服務提供預覽支持。

Aspire的統一工具鏈亦支援版本控制，並在主版本和次版本之間提供安全升級，有助於團隊自信地採用像Aspire 9.5這樣的更新。

最後的想法和未來展望

當影片結束時，Tim稱Aspire對開發者而言是"金礦"。儀表板結合了跟踪視圖、健康檢查、日誌和指標到一個統一面板——這是在本地開發中之前不存在的。

對於Tim和他的團隊來說，所有新的.NET Aspire專案現在都預設使用此系統。 它加速了自定義構建，改善了開發者體驗，並確保生產就緒的分佈式應用程式在不同機器上表現一致。

他指出，Aspire的大版本將繼續改進跟踪篩選、端點解析和AI整合，同時保持對安全升級和通用可用性的關注。

Tim鼓勵大家探索Aspire 9.5，將其應用到下一個.NET專案中，並利用其簡單的一條命令查看日誌、管理開發隧道，並自信地在本地測試整個應用程式。