上的 ASP.NET Web Forms 應用程式 HA 和自動擴展 AWS

當您將舊版 ASP.NET Web Forms 應用程式遷移至 時 AWS，實現高可用性是重要的考量。您可以使用 Amazon EC2 Auto Scaling 群組和負載平衡器，將流量分散到多個 EC2 執行個體。不過，許多 ASP.NET Web Forms 應用程式非常依賴工作階段狀態，這使得它們本質上具有狀態。根據預設，伺服器會將產生的工作階段 IDs存放在記憶體中，並透過 Cookie 將 ID 傳回給用戶端。當您嘗試跨多個 EC2 執行個體執行相同的應用程式時，此方法會變得有問題，因為每個執行個體都會維持自己的工作階段狀態，導致不一致的使用者體驗和潛在的資料遺失。

為了解決這項挑戰，並確保遷移的 ASP.NET Web Forms 應用程式可以無縫擴展到多個執行個體，同時維持工作階段狀態，您有兩個主要選項：啟用黏性工作階段或使用共用備份儲存。

啟用 &ALB 的黏性工作階段

在 上 AWS，您可以設定 Application Load Balancer 使用黏性工作階段，也稱為工作階段親和性。當您啟用黏性工作階段時，Application Load Balancer 會將後續請求從相同的用戶端路由到相同的 EC2 執行個體。這可確保在使用者與應用程式互動期間保留使用者的工作階段狀態。

這種方法提供直接的解決方案，但在可擴展性和容錯能力方面具有限制。如果 EC2 執行個體失敗或無法使用，黏性工作階段會中斷，且使用者的工作階段狀態會遺失。此外，黏性工作階段可能會導致跨執行個體的負載分佈不均勻，並可能導致資源爭用或利用率不足，進而限制應用程式有效擴展的能力。基於這些原因，我們建議您改用共用備份存放區做為工作階段儲存。

使用工作階段儲存的共用備份存放區

將具狀態 ASP.NET Web Forms 應用程式遷移至 的建議方法是 AWS 使用工作階段儲存的共用備份存放區。應用程式可以在高度可用且可擴展的儲存解決方案中存放工作階段資料，例如 Amazon DynamoDB、適用於 SQL Server 的 Amazon Relational Database Service (Amazon RDS) 或 Amazon ElastiCache (Redis OSS)，而不是依賴個別 EC2 執行個體上的記憶體內工作階段狀態。

當您使用共用備份存放區時，您可以將工作階段狀態與個別 EC2 執行個體分離，讓應用程式可以順暢地跨多個執行個體擴展，而不會遺失工作階段資料。此方法也會改善容錯能力，因為工作階段資料會獨立於應用程式執行個體，以確保即使執行個體失敗或在擴展事件期間也不會遺失使用者工作階段。

若要將 ASP.NET Web Forms 應用程式設定為使用 Redis 做為工作階段儲存的共用備份存放區：

1. 為叢集建立新的安全群組。安全群組必須允許對 Redis 的傳入請求，其使用 TCP 連接埠 6379。

2. 啟動新的 Redis 叢集。請務必指定您在第一個步驟中建立的安全群組。

3. 取得您剛建立之執行個體的端點地址。您必須等待幾分鐘，叢集才會啟動，地址才會變成可用。

4. 修改 web.config 檔案並新增下列組態：

   <sessionState mode="Custom" customProvider="RedisStateStore">
     <providers>
       <add name="RedisStateStore" type="Microsoft.Web.Redis.RedisSessionStateProvider"
            host="[YourRedisClusterEndpoint]"
            accessKey=""
            ssl="true" />
     </providers>
   </sessionState>

   [YourRedisClusterEndpoint] 將 取代為 ElastiCache (Redis OSS) 叢集的適當值。

透過實作工作階段儲存的共用備份存放區，您可以在 上為遷移的 ASP.NET Web Forms 應用程式提供高可用性、可擴展性和容錯能力 AWS。此方法符合雲端原生最佳實務，並確保順暢的使用者體驗，即使您的應用程式跨多個 EC2 執行個體或可用區域擴展也一樣。此外，它提供比黏性工作階段更強大和可靠的解決方案，讓您的應用程式充分利用 AWS 基礎設施提供的可擴展性和彈性。