適用於 .NET 的可靠 Web 應用程式模式

Azure App Service

Azure Front Door

Azure Cache for Redis

.NET

本文提供實作 Reliable Web 應用程式模式的指引。此模式描述如何修改（replatform） Web 應用程式以進行雲端移轉。它提供符合 Azure Well-Architected Framework 原則的規範架構、程式代碼和組態指引。

為什麼適用於 .NET 的 Reliable Web 應用程式模式？

Reliable Web App 模式是一組原則和實作技術，可定義當您將 Web 應用程式移轉至雲端時，應該如何重新建立 Web 應用程式。其著重於在雲端中成功所需的最少程式碼更新。下列指引會使用參考實作作為整個範例。本指南遵循虛構公司 Relecloud 的重新平臺旅程，為您的旅程提供商務內容。在實作 .NET 的 Reliable Web App 模式之前，Relecloud 具有使用 ASP.NET 架構的整合式內部部署票證 Web 應用程式。

提示

GitHub 標誌可靠的 Web 應用程式模式有 參考實 作（範例）。它代表名為 Relecloud 的虛構公司 Reliable Web App 實作的結束狀態。這是生產等級的 Web 應用程式，其中包含本文所討論的所有程式代碼、架構和組態更新。部署並使用參考實作來引導您實作 Reliable Web 應用程式模式。

如何實作 Reliable Web 應用程式模式

本文包含實作 Reliable Web 應用程式模式的架構、程式代碼和設定指引。使用下列連結來移至您需要的特定指引：

商務內容。 將此指引與您的商務內容一致，並瞭解如何定義可推動重新調整決策的立即和長期目標。
架構指引。 瞭解如何選取正確的雲端服務，並設計符合您業務需求的架構。
程式代碼指引。 實作三種設計模式，以改善雲端 Web 應用程式的可靠性與效能效率：重試、斷路器和 Cache-Aside 模式。
組態指引。 設定驗證和授權、受控識別、許可權化環境、基礎結構即程式代碼和監視。

商務內容

重新格式化 Web 應用程式的第一個步驟是定義您的商務目標。您應該設定立即目標，例如服務等級目標（SLO）和成本優化目標，以及 Web 應用程式的未來目標。這些目標會影響您在雲端中選擇的雲端服務和 Web 應用程式的架構。定義 Web 應用程式的目標 SLO，例如 99.9% 執行時間。計算影響 Web 應用程式可用性之所有服務的複合 SLA。

例如，Relecloud 有積極的銷售預測，並預期其票證 Web 應用程式的需求增加。為了符合此需求，他們定義了 Web 應用程式的目標：

套用低成本、高價值的程式代碼變更。
達到99.9%的 SLO。
採用DevOps做法。
建立成本優化的環境。
改善可靠性和安全性。

Relecloud 的內部部署基礎結構並不是達成這些目標的符合成本效益的解決方案。他們決定將 Web 應用程式移轉至 Azure 是達成其立即和未來目標最符合成本效益的方式。

架構指導

Reliable Web 應用程式模式有一些基本的架構元素。您需要 DNS 來管理端點解析、Web 應用程式防火牆來封鎖惡意 HTTP 流量，以及負載平衡器來路由及協助保護輸入使用者要求。應用程式平台會裝載您的 Web 應用程式程式碼，並透過虛擬網路中的私人端點呼叫所有後端服務。應用程式效能監視工具會擷取計量和記錄，以協助您瞭解 Web 應用程式。

圖 1. Reliable Web 應用程式模式的基本架構元素。

設計架構

設計基礎結構以支援復原計量，例如復原時間目標（RTO）和恢復點目標（RPO）。 RTO 會影響可用性，且必須支援您的 SLO。判斷 RPO 並設定資料備援以符合 RPO。

選擇基礎結構可靠性。 判斷您需要多少個可用性區域和區域，以符合您的可用性需求。新增可用性區域和區域，直到複合 SLA 符合您的 SLO 為止。 Reliable Web 應用程式模式支持主動-主動或主動-被動設定的多個區域。例如，參考實作會使用主動-被動設定來符合 99.9% 的 SLO。

針對多區域 Web 應用程式，根據您的業務需求，將您的負載平衡器設定為將流量路由傳送至第二個區域，以支持主動-主動或主動-被動設定。這兩個區域需要相同的服務，但其中一個區域有連接區域的中樞虛擬網路。採用中樞和輪輻網路拓撲來集中和共用資源，例如網路防火牆。如果您有虛擬機，請將防禦主機新增至中樞虛擬網路，以增強安全性來管理它們。（見圖2.）

圖 2. 具有第二個區域和中樞和輪輻拓撲的 Reliable Web 應用程式模式。
選擇網路拓撲。 為您的 Web 和網路需求選擇正確的網路拓撲。如果您打算使用多個虛擬網路，請使用中樞和輪輻網路拓撲。它提供內部部署和虛擬網路的成本、管理和安全性優點和安全性優點，以及混合式連線選項。

挑選正確的 Azure 服務

當您將 Web 應用程式移至雲端時，應該選擇符合商務需求的 Azure 服務，並符合內部部署 Web 應用程式的目前功能。這項對齊有助於將重新調整工作降至最低。例如，使用可讓您保留相同資料庫引擎並支援現有中間件和架構的服務。下列各節提供為 Web 應用程式選取正確 Azure 服務的指引。

例如，在移至雲端之前，Relecloud 的票證 Web 應用程式是內部部署整合型 ASP.NET 應用程式。它會在兩部虛擬機上執行，並使用 SQL Server 資料庫。 Web 應用程式發生延展性和功能部署的常見問題。這個起點，他們的業務目標，SLO 推動他們的服務選擇。

應用程式平臺：使用 Azure App 服務作為您的應用程式平臺。 Relecloud 選擇 App Service 作為應用程式平臺，原因如下：
- 高服務等級協定（SLA）。 它具有高 SLA，符合生產環境 SLO 99.9%。
- 降低管理額外負荷。 這是一個完全受控的解決方案，可處理調整、健康情況檢查和負載平衡。
- .NET 支援。 它支援應用程式寫入的 .NET 版本。
- 容器化功能。 Web 應用程式可以在雲端上交集而不進行容器化，但應用程式平臺也支援容器化，而不需要變更 Azure 服務。
- 自動調整。 Web 應用程式可以根據使用者流量和組態設定自動相應縮小和相應放大。平臺也支持相應增加或減少以配合不同的裝載需求。
身分識別管理： 使用 Microsoft Entra ID 作為您的身分識別和存取管理解決方案。 Relecloud 選擇Microsoft Entra 標識符，原因如下：
- 驗證和授權。 應用程式需要驗證和授權來電中心員工。
- 可伸縮。 Microsoft Entra ID 調整以支援較大的案例。
- 使用者身分識別控制件。 客服中心員工可以使用其現有的企業身分識別。
- 授權通訊協議支援。 Microsoft Entra ID 支援適用於受控識別的 OAuth 2.0。
資料庫： 使用可讓您保留相同資料庫引擎的服務。使用數據存放區判定樹來引導您的選取。 Relecloud 的 Web 應用程式使用內部部署 SQL Server。他們想要使用現有的資料庫架構、預存程式和函式。 Azure 上提供數個 SQL 產品，但 Relecloud 基於下列原因選擇 Azure SQL 資料庫：
- 可靠性。 一般用途層提供高 SLA 和多重區域備援。它可以支援高用戶負載。
- 降低管理額外負荷。 SQL Database 提供受控 SQL 資料庫實例。
- 移轉支援。 它支援從內部部署 SQL Server 進行資料庫移轉。
- 與內部部署設定的一致性。 它支援現有的預存程式、函式和檢視。
- 彈性。 它支援備份和時間點還原。
- 專業知識和最少的重新作業。 SQL Database 可讓 Relecloud 利用現有的專業知識，而且需要最少的工作才能採用。
應用程式效能監視： 使用 Application Insights 分析應用程式的遙測。 Relecloud 選擇使用 Application Insights 的原因如下：
- 與 Azure 監視器整合。 它提供與 Azure 監視器的最佳整合。
- 異常偵測。 它會自動偵測效能異常。
- 故障排除。 其可協助您診斷執行中應用程式的問題。
- 監測。 它會收集使用者如何使用應用程式的相關信息，並可讓您輕鬆地追蹤自定義事件。
- 可見度間距。 內部部署解決方案沒有應用程式效能監視解決方案。 Application Insights 可讓您輕鬆地與應用程式平台和程式代碼整合。
快取： 選擇是否要將快取新增至 Web 應用程式架構。 Azure Cache for Redis 是主要的 Azure 快取解決方案。這是以 Redis 軟體為基礎的受控記憶體內部數據存放區。 Relecloud 的 Web 應用程式負載嚴重偏向於觀看音樂會和場地詳細數據。基於下列原因，Relecloud 已新增 Azure Cache for Redis：
- 降低管理額外負荷。 這是完全受控的服務。
- 速度和音量。 它具有高數據輸送量和低延遲讀取，適用於經常存取、變更緩慢的數據。
- 各種支援性。 這是 Web 應用程式所有實例要使用的統一快取位置。
- 外部數據存放區。 內部部署應用程式伺服器執行 VM 本機快取。此設定不會卸除高度頻繁的數據，而且無法使數據失效。
- 非粘性會話。 外部化會話狀態支援非粘性會話。
負載平衡器： 使用 PaaS 解決方案的 Web 應用程式應該使用 Azure Front Door、Azure 應用程式閘道，或兩者，視 Web 應用程式架構和需求而定。使用負載平衡器判定樹來挑選正確的負載平衡器。 Relecloud 需要第 7 層負載平衡器，才能跨多個區域路由傳送流量。公司需要多區域 Web 應用程式，才能符合 SLO 的 99.9%。 Relecloud 選擇 Azure Front Door 的原因如下：
- 全域負載平衡。 這是第 7 層負載平衡器，可跨多個區域路由傳送流量。
- Web 應用程式防火牆。 它會以原生方式與 Azure Web 應用程式防火牆整合。
- 路由彈性。 它可讓應用程式小組設定輸入需求，以支援應用程式未來的變更。
- 流量加速。 它會使用 anycast 到達最接近的 Azure 存在點，並尋找通往 Web 應用程式的最快路由。
- 自訂網域。 它支援具有彈性網域驗證的自定義功能變數名稱。
- 健康情況探查。 應用程式需要智慧型手機健康情況探查監視。 Azure Front Door 會使用來自探查的回應來判斷路由用戶端要求的最佳來源。
- 監視支援。 它支援內建報表，其中包含 Azure Front Door 和安全性模式的全方位儀錶板。您可以設定與 Azure 監視器整合的警示。 Azure Front Door 可讓應用程式記錄每個要求和失敗的健康情況探查。
- DDoS 保護。 它具有內建第 3-4 層 DDoS 保護。
- 內容傳遞網路。 它會將 Relecloud 定位為使用內容傳遞網路。內容傳遞網路提供網站加速。
Web 應用程式防火牆：使用 Azure Web 應用程式防火牆提供集中式保護，防止常見的 Web 惡意探索和弱點。 Relecloud 會基於下列原因使用 Azure Web 應用程式防火牆：
- 全域保護。 它提供改良的全域 Web 應用程式保護，而不會犧牲效能。
- Botnet 保護。 小組可以監視和設定設定，以解決與歹屍網路相關的安全性考慮。
- 與內部部署的同位。 內部部署解決方案是在IT所管理的Web應用程式防火牆後方執行。
- 易於使用。 Web 應用程式防火牆與 Azure Front Door 整合。
設定記憶體： 選擇是否要將應用程式組態記憶體新增至 Web 應用程式。 Azure 應用程式組態是集中管理應用程式設定和功能旗標的服務。檢閱應用程式組態最佳做法，以判斷此服務是否適合您的應用程式。 Relecloud 想要將檔案型設定取代為與應用程式平臺和程式代碼整合的中央組態存放區。基於下列原因，他們已將應用程式組態新增至架構：
- 靈活性。 它支援功能旗標。功能旗標可讓使用者在生產環境中加入加入和退出早期預覽功能，而不需要重新部署應用程式。
- Git 管線支援。 組態數據的來源必須是 Git 存放庫。更新中央組態存放區中數據所需的管線。
- 受控識別支援。 它支援受控識別，以簡化並協助保護與組態存放區的連線。
秘密管理員：如果您有在 Azure 中管理秘密，請使用 Azure 金鑰保存庫。您可以使用 ConfigurationBuilder 物件，將金鑰保存庫併入 .NET 應用程式中。 Relecloud 的內部部署 Web 應用程式會將秘密儲存在程式代碼組態檔中，但更好的安全性做法是將秘密儲存在支援 RBAC 和稽核控件的位置。雖然受控識別是連線到 Azure 資源的慣用解決方案，但 Relecloud 具有管理所需的應用程式秘密。 Relecloud 已使用金鑰保存庫，原因如下：
- 加密。 它支援待用和傳輸中的加密。
- 受控識別支援。 應用程式服務可以使用受控識別來存取秘密存放區。
- 監視和記錄。 Key Vault 有助於稽核存取，並在儲存的秘密變更時產生警示。
- 集成。 Key Vault 提供與 Azure 組態存放區（應用程式組態）和 Web 主控平臺（App Service）的原生整合。
記憶體解決方案： 請參閱 Azure 記憶體選項，根據您的需求挑選正確的記憶體解決方案。 Relecloud 的內部部署 Web 應用程式已將磁碟記憶體掛接至每個 Web 伺服器，但小組想要使用外部資料儲存解決方案。 Relecloud 基於下列原因選擇 Azure Blob 儲存體：
- 增強式安全性存取。 Web 應用程式可以排除端點，以匿名存取公開至公用因特網的記憶體。
- 加密。 Blob 記憶體會加密待用和傳輸中的數據。
- 彈性。 Blob 記憶體支援區域備援記憶體（ZRS）。區域備援記憶體會將數據同步復寫到主要區域中的三個 Azure 可用性區域。每個可用性區域都位於具有獨立電源、冷卻和網路的個別實體位置。此設定應該讓票證映像在遺失時具有復原性。
端點安全性： 使用 Azure Private Link，透過虛擬網路中的私人端點存取平臺即服務（PaaS）解決方案。虛擬網路與服務之間的流量會跨越Microsoft骨幹網路。 Relecloud 選擇 Private Link 的原因如下：
- 增強式安全性通訊。 Private Link 可讓應用程式在 Azure 平臺上私下存取服務，並減少數據存放區的網路使用量，以協助防止數據外洩。
- 最少投入。 私人端點支援 Web 應用程式所使用的 Web 應用程式平臺和資料庫平臺。這兩個平臺都會鏡像現有的內部部署設定，因此需要最少的變更。
網路安全性。 使用 Azure 防火牆來控制網路層級的輸入和輸出流量。使用 Azure Bastion 連線到具有增強安全性的虛擬機，而不需要公開 RDP/SSH 埠。 Relecloud 採用中樞和輪輻網路拓撲，並想要將共用的網路安全性服務放在中樞。 Azure 防火牆藉由檢查輪輻的所有輸出流量來提高網路安全性，以改善安全性。 Relecloud 需要 Azure Bastion，才能從 DevOps 子網中的 Jump 主機進行增強式安全性部署。

程序代碼指引

若要成功將 Web 應用程式移至雲端，您必須使用重試模式、斷路器模式和 Cache-Aside 模式來更新 Web 應用程式程式代碼。

圖 3. 設計模式的角色。

每個設計模式都提供與一或多個 Well-Architected 架構支柱一致的工作負載設計優點。以下是您應該實作的模式概觀：

重試模式。 重試模式會藉由重試間歇性失敗的作業來處理暫時性失敗。在所有對其他 Azure 服務的輸出呼叫上實作此模式。
斷路器模式。 斷路器模式可防止應用程式重試非暫時性的作業。在所有對其他 Azure 服務的輸出呼叫中實作此模式。
Cache-Aside 模式。 Cache-Aside 模式會視需要將數據載入資料存放區中的快取。在對資料庫的要求上實作此模式。

設計模式	可靠性（RE）	效能效率（PE）	支援 WAF 原則
重試模式	✔		RE：07
斷路器模式	✔	✔	RE：03 RE：07 PE：07 PE：11
Cache-Aside 模式	✔	✔	RE：05 PE：08 PE：12

實作重試模式

將重試模式新增至您的應用程式程式代碼，以解決暫時服務中斷的問題。這些中斷稱為暫時性錯誤。暫時性錯誤通常會在幾秒內自行解決。重試模式可讓您重新傳送失敗的要求。它也可讓您設定重試與失敗前嘗試次數之間的延遲。

使用內建的重試機制。 使用大部分 Azure 服務所提供的內建重試機制來加速實作。例如，參考實作會使用 Entity Framework Core 中的聯機復原，將要求中的重試模式套用至 SQL Database：

services.AddDbContextPool<ConcertDataContext>(options => options.UseSqlServer(sqlDatabaseConnectionString,
    sqlServerOptionsAction: sqlOptions =>
    {
        sqlOptions.EnableRetryOnFailure(
        maxRetryCount: 5,
        maxRetryDelay: TimeSpan.FromSeconds(3),
        errorNumbersToAdd: null);
    }));

使用重試程式設計連結庫。 針對 HTTP 通訊，請整合標準復原連結庫，例如 Polly 或 Microsoft.Extensions.Http.Resilience。這些連結庫提供完整的重試機制，對於管理與外部 Web 服務的通訊至關重要。例如，參考實作會使用 Polly 在每次程式代碼建構呼叫 IConcertSearchService 對象的物件時，強制執行 Retry 模式：

private void AddConcertSearchService(IServiceCollection services)
{
    var baseUri = Configuration["App:RelecloudApi:BaseUri"];
    if (string.IsNullOrWhiteSpace(baseUri))
    {
        services.AddScoped<IConcertSearchService, MockConcertSearchService>();
    }
    else
    {
        services.AddHttpClient<IConcertSearchService, RelecloudApiConcertSearchService>(httpClient =>
        {
            httpClient.BaseAddress = new Uri(baseUri);
            httpClient.DefaultRequestHeaders.Add(HeaderNames.Accept, "application/json");
            httpClient.DefaultRequestHeaders.Add(HeaderNames.UserAgent, "Relecloud.Web");
        })
        .AddPolicyHandler(GetRetryPolicy())
        .AddPolicyHandler(GetCircuitBreakerPolicy());
    }
}

private static IAsyncPolicy<HttpResponseMessage> GetRetryPolicy()
{
    var delay = Backoff.DecorrelatedJitterBackoffV2(TimeSpan.FromMilliseconds(500), retryCount: 3);
    return HttpPolicyExtensions
      .HandleTransientHttpError()
      .OrResult(msg => msg.StatusCode == System.Net.HttpStatusCode.NotFound)
      .WaitAndRetryAsync(delay);
}

實作斷路器模式

使用斷路器模式來處理非暫時性錯誤的服務中斷。斷路器模式可防止應用程式持續嘗試存取非回應服務。它會釋放應用程式，並協助防止CPU迴圈浪費，讓應用程式保留其終端使用者的效能完整性。

例如，參考實作會將斷路器模式套用至API的所有要求。它會使用 HandleTransientHttpError 邏輯來偵測可以安全地重試的 HTTP 要求，但會限制在指定時段內匯總錯誤的數目：

private static IAsyncPolicy<HttpResponseMessage> GetCircuitBreakerPolicy()
{
    return HttpPolicyExtensions
        .HandleTransientHttpError()
        .OrResult(msg => msg.StatusCode == System.Net.HttpStatusCode.NotFound)
        .CircuitBreakerAsync(5, TimeSpan.FromSeconds(30));
}

實作 Cache-Aside 模式

將 Cache-Aside 模式新增至 Web 應用程式，以改善記憶體內部數據管理。此模式會指派應用程式處理數據要求的責任，並確保快取與永續性記憶體之間的一致性，例如資料庫。其可縮短響應時間、增強輸送量，並減少更多調整的需求。它也會減少主要數據存放區上的負載，進而改善可靠性和成本優化。若要實作 Cache-Aside 模式，請遵循下列建議：

將應用程式設定為使用快取。 生產應用程式應該使用分散式 Redis 快取。此快取可藉由減少資料庫查詢來改善效能。它也會啟用非粘性會話，讓負載平衡器可以平均分散流量。參考實作會使用分散式 Redis 快取。 AddAzureCacheForRedis 方法將應用程式設定為使用 Azure Cache for Redis：

private void AddAzureCacheForRedis(IServiceCollection services)
{
    if (!string.IsNullOrWhiteSpace(Configuration["App:RedisCache:ConnectionString"]))
    {
        services.AddStackExchangeRedisCache(options =>
        {
            options.Configuration = Configuration["App:RedisCache:ConnectionString"];
        });
    }
    else
    {
        services.AddDistributedMemoryCache();
    }
}

快取高需求數據。 將 Cache-Aside 模式套用至高需求數據，以提高其有效性。使用 Azure 監視器來追蹤資料庫的 CPU、記憶體和記憶體。這些計量可協助您判斷在套用 Cache-Aside 模式之後，是否可以使用較小的資料庫 SKU。例如，參考實作會快取支持即將推出的 Concerts 頁面的高需求數據。 GetUpcomingConcertsAsync 方法會將數據從 SQL Database 提取至 Redis 快取，並使用最新的音樂會數據填入快取：

public async Task<ICollection<Concert>> GetUpcomingConcertsAsync(int count)
{
    IList<Concert>? concerts;
    var concertsJson = await this.cache.GetStringAsync(CacheKeys.UpcomingConcerts);
    if (concertsJson != null)
    {
        // There is cached data. Deserialize the JSON data.
        concerts = JsonSerializer.Deserialize<IList<Concert>>(concertsJson);
    }
    else
    {
        // There's nothing in the cache. Retrieve data 
        // from the repository and cache it for one hour.
        concerts = await this.database.Concerts.AsNoTracking()
            .Where(c => c.StartTime > DateTimeOffset.UtcNow && c.IsVisible)
            .OrderBy(c => c.StartTime)
            .Take(count)
            .ToListAsync();
        concertsJson = JsonSerializer.Serialize(concerts);
        var cacheOptions = new DistributedCacheEntryOptions {
            AbsoluteExpirationRelativeToNow = TimeSpan.FromHours(1)
        };
        await this.cache.SetStringAsync(CacheKeys.UpcomingConcerts, concertsJson, cacheOptions);
    }
    return concerts ?? new List<Concert>();
}

讓快取數據保持最新狀態。 排程定期快取更新，以與最新的資料庫變更同步。使用數據波動性和使用者需要判斷最佳重新整理速率。這種做法可確保應用程式使用 Cache-Aside 模式來提供快速存取和目前資訊。例如，參考實作只會快取一個小時的數據，並使用 CreateConcertAsync 方法來清除數據變更時的快取索引鍵：
```
public async Task<CreateResult> CreateConcertAsync(Concert newConcert)
{
    database.Add(newConcert);
    await this.database.SaveChangesAsync();
    this.cache.Remove(CacheKeys.UpcomingConcerts);
    return CreateResult.SuccessResult(newConcert.Id);
}
```
確保數據一致性。 實作機制，以在任何資料庫寫入作業之後立即更新快取。使用事件驅動更新或專用數據管理類別，以確保快取一致性。一致地同步處理快取與資料庫修改是 Cache-Aside 模式的核心。參考實作會使用 UpdateConcertAsync 方法來讓快取中的數據保持一致：
```
public async Task<UpdateResult> UpdateConcertAsync(Concert existingConcert), 
{
   database.Update(existingConcert);
   await database.SaveChangesAsync();
   this.cache.Remove(CacheKeys.UpcomingConcerts);
   return UpdateResult.SuccessResult();
}
```

設定指引

下列各節提供實作組態更新的指引。每個區段都與一或多個「架構良好架構」的支柱對齊。

組態	可靠性（RE）	安全性（SE）	成本優化（CO）	卓越營運（OE）	效能效率（PE）	支援 WAF 原則
設定使用者驗證和授權		✔		✔		SE：05 OE：10
實作受控識別		✔		✔		SE：05 OE：10
Rightsize 環境			✔			CO：05 CO：06
實作自動調整	✔		✔		✔	RE：06 CO：12 PE：05
自動資源部署				✔		OE：05
實作監視			✔	✔	✔	OE：07 PE：04

設定使用者驗證和授權

當您將 Web 應用程式移轉至 Azure 時，請設定使用者驗證和授權機制。依照下列建議進行：

使用身分識別平臺。 使用Microsoft身分識別平台來設定 Web 應用程式驗證。此平台支援使用單一Microsoft Entra 目錄、來自不同組織的多個Microsoft Entra 目錄，以及Microsoft身分識別或社交帳戶的應用程式。
建立應用程式註冊。 Microsoft Entra 識別碼需要在主要租用戶中註冊應用程式。應用程式註冊可協助確保可存取 Web 應用程式的使用者在主要租使用者中具有身分識別。
使用平臺功能。 使用平臺功能來驗證使用者及存取數據，將自定義驗證程式代碼的需求降到最低。例如，App Service 提供內建的驗證支援，因此您可以在 Web 應用程式中撰寫最少或沒有程式代碼時登入使用者及存取數據。
在應用程式中強制執行授權。 使用 RBAC 將最低許可權指派給應用程式角色。為不同的使用者動作定義特定角色，以避免重疊並確保清楚。將用戶對應至適當的角色，並確保他們只能存取必要的資源和動作。

偏好暫時存取記憶體。 使用暫時許可權來防範未經授權的存取和缺口。例如，您可以使用共用存取簽章（SAS）來限制一段時間的存取。當您授與暫時存取權時，使用使用者委派 SAS 將安全性最大化。這是唯一使用 Microsoft Entra ID 認證且不需要永久記憶體帳戶密鑰的 SAS。
在 Azure 中強制執行授權。 使用 Azure RBAC 將最低許可權指派給使用者身分識別。 Azure RBAC 會定義身分識別可以存取的 Azure 資源、這些資源可以執行哪些動作，以及他們可存取的區域。
避免永久提高的許可權。 使用 Microsoft Entra Privileged Identity Management 授與特殊許可權作業的 Just-In-Time 存取權。例如，開發人員通常需要系統管理員層級的存取權，才能建立/刪除資料庫、修改數據表架構，以及變更用戶權力。當您使用 Just-In-Time 存取時，使用者身分識別會收到執行特殊許可權工作的暫時許可權。

使用受控識別

針對支援受控識別的所有 Azure 服務，使用受控識別。受控識別可讓 Azure 資源（工作負載身分識別）向其他 Azure 服務進行驗證並與其互動，而不需要您管理認證。為了簡化移轉，您可以繼續使用混合式和舊版系統的內部部署驗證解決方案，但您應該儘快將其轉換為受控識別。若要實作受控識別，請遵循下列建議：

挑選正確的受控識別類型。當您有兩個或多個需要相同許可權集的 Azure 資源時，偏好使用使用者指派的受控識別。這種方法比為每個資源建立系統指派的受控識別更有效率，並將相同的許可權指派給所有資源。否則，請使用系統指派的受控識別。
設定最低許可權。 使用 Azure RBAC，只授與對作業至關重要的許可權，例如資料庫中的 CRUD 動作或存取秘密。工作負載身分識別許可權是持續性的，因此您無法提供工作負載身分識別的 Just-In-Time 或短期許可權。如果 Azure RBAC 未涵蓋特定案例，請使用 Azure 服務層級存取原則來補充 Azure RBAC。
為其餘秘密提供安全性。 將任何剩餘的秘密儲存在 Azure 金鑰保存庫。在應用程式啟動時從金鑰保存庫載入秘密，而不是在每個 HTTP 要求期間載入。 HTTP 要求內的高頻率存取可能會超過交易限制金鑰保存庫。將應用程式組態儲存在 Azure 應用程式組態中。

參考實作會使用 SQL 資料庫連接字串中的 Authentication 自變數，讓 App Service 可以使用受控識別來連線到 SQL 資料庫：Server=tcp:my-sql-server.database.windows.net,1433;Initial Catalog=my-sql-database;Authentication=Active Directory Default。它會使用 DefaultAzureCredential，允許 Web API 使用受控識別連線到 Key Vault：

    builder.Configuration.AddAzureAppConfiguration(options =>
    {
         options
            .Connect(new Uri(builder.Configuration["Api:AppConfig:Uri"]), new DefaultAzureCredential())
            .ConfigureKeyVault(kv =>
            {
                // Some of the values coming from App Configuration
                // are stored in Key Vault. Use the managed identity
                // of this host for the authentication.
                kv.SetCredential(new DefaultAzureCredential());
            });
    });

Rightsize 環境

使用符合每個環境需求的 Azure 服務效能層級（SKU），而不需要超過它們。若要將環境版權化，請遵循下列建議：

預估成本。 使用 Azure 定價計算機來估計每個環境的成本。
成本優化生產環境。 生產環境需要符合生產環境所需的服務等級協定（SLA）、功能和規模所需的 SKU。持續監視資源使用量，並調整 SKU 以符合實際效能需求。
成本優化生產前環境。生產前環境應該使用低成本的資源，並利用 azure 開發/測試定價等折扣。在這些環境中，您應該停用不需要的服務。同時，請確定生產前環境與生產環境相近，以避免產生風險。維持此平衡可確保測試保持有效，而不會產生不必要的成本。
使用基礎結構即程式代碼（IaC）來定義 SKU。 實作 IaC 以根據環境動態選取並部署正確的 SKU。此方法可增強一致性並簡化管理。

例如，參考實作會使用 Bicep 參數將更昂貴的層（SKU）部署到生產環境：

    var redisCacheSkuName = isProd ? 'Standard' : 'Basic'
    var redisCacheFamilyName = isProd ? 'C' : 'C'
    var redisCacheCapacity = isProd ? 1 : 0

實作自動調整

自動調整可協助確保 Web 應用程式保持復原性、回應性，且能夠有效率地處理動態工作負載。若要實作自動調整，請遵循下列建議：

自動化向外延展。 使用 Azure 自動調整來自動化生產環境中的水平調整。設定自動調整規則，以根據關鍵效能計量相應放大，讓您的應用程式可以處理不同的負載。
精簡調整觸發程式。 如果您不熟悉應用程式的調整需求，請使用 CPU 使用率作為初始調整觸發程式。精簡調整觸發程式，以包含其他計量，例如 RAM、網路輸送量和磁碟 I/O。目標是要符合 Web 應用程式的行為，以提升效能。
提供向外延展緩衝區。 將調整閾值設定為在達到容量上限之前觸發。例如，將調整設定為以 85% 的 CPU 使用率發生，而不是等到達到 100%。這種主動式方法有助於維護效能，並避免潛在的瓶頸。

自動資源部署

使用自動化在所有環境中部署和更新 Azure 資源和程序代碼。依照下列建議進行：

使用基礎結構即程序代碼。 使用持續整合和持續傳遞（CI/CD）管線，將基礎結構部署為程式代碼。 Azure 會針對每個 Azure 資源提供預先建置 Bicep、ARM （JSON）和 Terraform 範本。
使用持續整合/持續部署（CI/CD）管線。 使用 CI/CD 管線將程式代碼從原始檔控制部署到各種環境，例如測試、預備和生產環境。如果您正在使用 Azure DevOps，請使用 Azure Pipelines。針對 GitHub 專案使用 GitHub Actions。
整合單元測試。 排定管線內所有單元測試的執行優先順序，並在任何部署至 App Services 之前通過。納入 SonarQube 之類的程式碼質量和涵蓋範圍工具，以達到完整的測試涵蓋範圍。
採用模擬架構。 若要測試涉及外部端點，請使用模擬架構。這些架構可讓您建立模擬端點。它們不需要設定實際的外部端點，並確保跨環境都一致測試條件。
執行安全性掃描。 使用靜態應用程式安全性測試（SAST）來尋找原始程式碼中的安全性缺陷和編碼錯誤。此外，進行軟體組合分析（SCA），以檢查第三方連結庫和元件是否有安全性風險。這些分析的工具很容易整合到 GitHub 和 Azure DevOps 中。

實作監視

實作應用程式和平台監視，以提升 Web 應用程式的卓越營運和效能效率。若要實作監視，請遵循下列建議：

收集應用程式遙測。 使用 Azure Application Insights 中的自動結構來收集應用程式遙測，例如要求輸送量、平均要求持續時間、錯誤和相依性監視。您不需要進行任何程式代碼變更，即可使用此遙測。

參考實作會使用 NuGet 套件 Microsoft.ApplicationInsights.AspNetCoreAddApplicationInsightsTelemetry 來啟用遙測收集：
```
public void ConfigureServices(IServiceCollection services)
{
   ...
   services.AddApplicationInsightsTelemetry(Configuration["App:Api:ApplicationInsights:ConnectionString"]);
   ...
}
```
建立自定義應用程式計量。 針對自定義應用程式遙測使用程式代碼型檢測。將 Application Insights SDK 新增至您的程式代碼，並使用 Application Insights API。

參考實作會收集與購物車活動相關的事件遙測。 this.telemetryClient.TrackEvent 計算新增至購物車的票證。它會提供事件名稱（AddToCart），並指定具有 concertId 和 count的字典：
```
this.telemetryClient.TrackEvent("AddToCart", new Dictionary<string, string> {
    { "ConcertId", concertId.ToString() },
    { "Count", count.ToString() }
});
```
監視平臺。 為所有支援的服務啟用診斷。將診斷傳送至與應用程式記錄相同的目的地，以便相互關聯。 Azure 服務會自動建立平台記錄，但只會在您啟用診斷時加以儲存。針對支援診斷的每個服務啟用診斷設定。

部署參考實作

參考實作會引導開發人員完成從內部部署 ASP.NET 應用程式到 Azure 的模擬移轉，並醒目提示初始採用階段所需的變更。此範例使用虛構公司 Relecloud 的音樂會票證應用程式，其會透過其內部部署 Web 應用程式銷售票證。 Relecloud 為其 Web 應用程式設定下列目標：

實作低成本、高價值的程式代碼變更。
達到99.9%的 SLO。
採用DevOps做法。
建立成本優化的環境。
增強可靠性和安全性。

Relecloud 判斷其內部部署基礎結構不是符合這些目標的符合成本效益的解決方案。他們決定將 Web 應用程式移轉至 Azure 是達成其立即和未來目標最符合成本效益的方式。下列架構代表 Relecloud 可靠 Web 應用程式模式實作的結束狀態。

圖 4。參考實作的架構。下載此架構的 Visio 檔案。

參考實作

共用方式為