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

Azure App Service

Azure Front Door

Azure Cache for Redis

.NET

本文提供實作 Reliable Web 應用程式模式的指引。此模式概述如何修改（replatform） Web 應用程式以進行雲端移轉。它提供符合良好架構架構原則的規範架構、程式代碼和設定指引。

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

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

提示

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

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

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

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

商務內容

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

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

套用低成本、高價值的程式代碼變更
達到服務等級目標 99.9%
採用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 應用程式。它在兩部虛擬機上執行，並具有Microsoft SQL Server 資料庫。 Web 應用程式在延展性和功能部署方面面臨常見的挑戰。這個起點，他們的業務目標，SLO 推動他們的服務選擇。

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

程序代碼指引

若要成功將 Web 應用程式移至雲端，您必須使用重試模式、斷路器模式和快取保留設計模式來更新 Web 應用程式程式代碼。

圖 3. 設計模式的角色。

每個設計模式都提供工作負載設計優點，以配合建構良好架構架構的其中一個支柱。以下是您應該實作的模式概觀：

重試模式：重試模式會重試間歇性失敗的作業來處理暫時性失敗。在所有對其他 Azure 服務的輸出呼叫上實作此模式。
斷路器模式：斷路器模式可防止應用程式重試非暫時性的作業。在所有對其他 Azure 服務的輸出呼叫中實作此模式。
Cache-Aside 模式：Cache-Aside 模式會比數據存放區更頻繁地新增和擷取快取。在對資料庫的要求上實作此模式。

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

實作重試模式

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

使用內建重試機制 使用大部分 Azure 服務都必須加速實作的內建重試機制。例如，參考實作會使用 Entity Framework Core 中的連線復原，將要求中的重試模式套用至 Azure SQL 資料庫（請參閱下列程式代碼）。

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 對象的物件時，都會強制執行重試模式（請參閱下列程式代碼）。

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 資料庫提取至 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
正確大小環境			✔			CO：05 CO：06
實作自動調整	✔		✔		✔	RE：06 CO：12 PE：05
自動資源部署				✔		OE：05
實作監視			✔	✔	✔	OE：07 PE：04

設定使用者驗證和授權

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

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

偏好暫時存取記憶體。 使用暫時權限來防範未經授權的存取和缺口，例如共用存取簽章（SASs）。在授與暫時存取權時，使用使用者委派 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 應用程式組態中。

例如，參考實作會使用 Authentication SQL 資料庫中的自變數連接字串，讓 App Service 可以使用受控識別連接到 SQL 資料庫：Server=tcp:my-sql-server.database.windows.net,1433;Initial Catalog=my-sql-database;Authentication=Active Directory Default。它會使用 DefaultAzureCredential ，允許 Web API 使用受控識別連線到金鑰保存庫（請參閱下列程式代碼）。

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

正確大小環境

使用 Azure 服務的效能層級（SKU），以符合每個環境的需求，而不需要過多。若要適當調整您的環境大小，請遵循下列建議：

預估成本。 使用 Azure 定價計算機來估計每個環境的成本。
成本優化生產環境。 生產環境需要符合生產環境所需的服務等級協定（SLA）、功能和規模所需的 SKU。持續監視資源使用量，並調整 SKU 以符合實際效能需求。
成本優化生產前環境。生產前環境應該使用低成本的資源、停用不必要的服務，並套用折扣，例如 Azure 開發/測試定價。請確定生產前環境與生產環境完全類似，以避免引入風險。此平衡可確保測試保持有效，而不會產生不必要的成本。
使用基礎結構即程式代碼定義 SKU（IaC）。 實作 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 管線將程式代碼從原始檔控制部署到各種環境，例如測試、預備和生產環境。如果您使用適用於 GitHub 專案的 Azure DevOps 或 GitHub Actions，請使用 Azure Pipelines。
整合單元測試。 排定管線內所有單元測試的執行優先順序，並在任何部署至 App Services 之前通過。納入 SonarQube 之類的程式碼質量和涵蓋範圍工具，以達到完整的測試涵蓋範圍。
採用模擬架構。 若要測試涉及外部端點，請使用模擬架構。這些架構可讓您建立仿真的端點。它們不需要設定實際的外部端點，並確保跨環境都一致測試條件。
執行安全性掃描。 使用靜態應用程式安全性測試（SAST）來尋找原始程式碼中的安全性缺陷和編碼錯誤。此外，進行軟體組合分析（SCA），以檢查第三方連結庫和元件是否有安全性風險。這些分析的工具可以輕鬆地整合到 GitHub 和 Azure DevOps 中。

實作監視

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

收集應用程式遙測。 在 Azure 應用程式 Insights 中使用自動結構來收集應用程式遙測，例如要求輸送量、平均要求持續時間、錯誤和相依性監視，而不需要變更程式代碼。

參考實作會使用 AddApplicationInsightsTelemetry NuGet 套件 Microsoft.ApplicationInsights.AspNetCore 中的來啟用遙測收集（請參閱下列程式代碼）。
```
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%
採用DevOps做法
建立成本優化的環境
增強可靠性和安全性

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

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

參考實作

共用方式為