Aspire 9.5入門 - 快速入手這一基本工具

開始和安裝 Aspire 9.5

Tim 首先解釋了 Aspire 的目的。每位構建 API 或 web 應用程式的 .NET 開發人員都應了解這個重要的 Microsoft 工具。 關於 Aspire 能做什麼一直存在分歧，Tim 決定從頭開始展示其目的、設置和使用方法。

他打開 Visual Studio 並使用 Aspire 起始應用範本開始了一個新專案。 如果您尚未安裝 Aspire，他指向 Microsoft 的網站以獲取 Aspire 的設置和工具，並註明可以通過 .NET CLI、Visual Studio 或 VS Code 來安裝。 為了簡化，Tim 建議使用 CLI 指令：

dotnet new install aspire.templates

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

Tim 選擇了 Aspire Demo App，選擇 .NET 9，啟用了 HTTPS，並使用 Redis 整合以進行快取。 這展示了一個現實場景，其中 Aspire 在本地管理整個應用程式。 他跳過單元測試並繼續創建解決方案檔案。

探索專案結構和應用模型

生成專案後，Tim 剖析了由 Aspire 的應用模型創建的專案檔案。 解決方案包含四個主要專案，既包含典型的 .NET 專案，也包含 Aspire 特殊專案：

1. Web 專案 – 基於 Blazor 的 web 應用程式。

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

3. AppHost – 單一檔案的 AppHost 來啟動整個應用程式。

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

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

Tim 強調這個新應用模型如何提供第一級的多專案協作支持，讓開發者可以用一條指令運行整個應用程式。 AppHost 控制啟動順序和依賴，而 ServiceDefaults 自動注入配置默認值、健康檢查和遙測整合。

為什麼 Aspire 簡化了本地開發

Tim 說明了在沒有 Aspire 的情況下本地管理分散式系統的痛點。傳統上，開發者必須手動配置容器運行時設置、端口轉發和連接字串。 每個開發者必須單獨復制環境變數、使用者秘密以及 redis 或 API 連接。

使用 Aspire，Aspire CLI 自動處理這些事項。 它透過開發容器或 Docker 實例啟動依賴，如 Redis 容器，管理端點發現，並使用服務發現提供服務間的私有訪問。

Aspire 使用反向代理和端點解析系統，因此 web 前端不需要知道硬編碼的端口號。 它只需命名 API（如 "apiservice"）—Aspire 就會解決其餘問題。

這顯著改善了開發者體驗，消除了繁瑣的設置步驟，讓開發者專注於代碼而非基礎設施。

在 AppHost 中定義服務和依賴項

Tim 展示了 Aspire 配置的核心：AppHost 的 Program.cs 檔案。使用 var builder 模式，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);

此語法定義每個資源，設置依賴順序，並創建一個清晰的資源生命週期。 Aspire 自動處理等待依賴，確保快取首先啟動，然後是 API，再然後是 web 前端。

這小段指導給開發者提供了對啟動行為的細粒度控制，反映了生產就緒的分散式應用程式的運行方式。

運行 Aspire 並了解儀表板

當 Tim 運行專案時，Aspire 啟動其自己的容器運行時並打開 Aspire 儀表板——一個監控所有內容的中心介面。 初始出現一個錯誤："Container runtime unhealthy"—Docker 沒有運行。 一旦 Docker 啟動，Aspire 自動初始化一個 Redis 可執行資源並將其連接到應用程式的其餘部分。

儀表板顯示顏色編碼的狀態圖示，指示每個資源的健康狀況。 當 Redis、API 和 web 前端都在運行時，儀表板變為綠色，表示整個應用程式是健康的。

此通知系統立即反映實時狀態，比標準控制台日誌提供更清晰的錯誤信息。 開發者可以從介面中可視化服務關係、監控指標，甚至直接訪問資源端點。

通過 Aspire 儀表板的視覺見解

儀表板中的圖形視圖可視化服務如何連接。 例如，web 前端連接到 Redis 和 API 服務，而 API 是獨立的。 這種追溯視圖有助於理解內部呼叫和依賴的流向。

Tim 強調儀表板包含的追溯細節改進，如顯示追溯篩選選項和時間分解。 開發者可以通過 Aspire 的追溯視圖追蹤服務間的 HTTP 請求並查看性能影響。

集中式日誌記錄和結構化日誌

Aspire 將來自所有專案檔案的控制台日誌統一到一個視圖中。 開發者無需掌握多個日誌視窗，可以使用儀表板查看所有服務的日誌—web 應用程式、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 在計數器頁面中加入了結構化日誌並故意在天氣頁面中引入 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 部署分散式系統，所需配置最少。

系統已支持自定義資源圖示、名稱屬性和 AI 服務的預覽支持，例如 OpenAI 端點或 Azure PostgreSQL 連接。

Aspire 的統一工具鏈還支持版本控制和安全升級，適用於大版本和小版本之間，幫助團隊自信地採用像 Aspire 9.5 的更新。

最終想法和未來展望

當 影片 結束時，Tim 將 Aspire 稱為"開發者的金礦"。儀表板將追蹤視圖、健康檢查、日誌和指標統合到一個面板中——這是此前本地開發中所缺少的東西。

對於 Tim 和他的團隊，每個新的 .NET Aspire 專案現在默認使用此系統。 它使客製化構建速度更快，改善開發者體驗，並確保生產就緒的分散式應用程式在不同機器間行為一致。

他指出，ASPire 的主要發行將繼續完善追蹤篩選、端點解析和 AI 整合，同時專注於安全升級和一般可用性。

Tim 鼓勵大家探索 Aspire 9.5，在他們的下一個 .NET 專案中使用，並利用其一條命令的簡易性來查看日誌、管理開發隧道，並信心十足地在本地測試整個應用程式。