需要非常高規模的應用程式案例可能會超過應用程式單一部署可用的計算資源容量。 投票應用程式、體育賽事和電視娛樂活動都是需要極高規模的場景範例。 通過水平擴展應用可以滿足高規模需求。 為了處理極端負載需求,可以在單一區域內和跨區域進行許多應用程式部署。
概觀
App Service 環境是水平相應放大的理想平臺。選取可支援已知要求速率的 App Service 環境設定之後,開發人員可以以「Cookie Cutter」方式部署其他 App Service 環境,以達到所需的尖峰負載容量。
備註
如果您想要在註冊 Azure 帳戶之前開始使用 Azure App Service,請移至 試用 App Service,您可以在其中立即在 App Service 中建立短期入門 Web 應用程式。 無需信用卡;沒有承諾。
例如,假設在 App Service 環境設定上執行的應用程式已經過測試,可處理每秒 20 K 個要求 (RPS)。 如果所需的尖峰負載容量為 100 K RPS,則可以建立和設定五 (5) 個 App Service 環境,以確保應用程式可以處理最大預計負載。
由於客戶通常會使用自訂 (或虛名) 網域來存取應用程式,因此開發人員需要一種方法,可在所有 App Service 環境實例之間散發應用程式要求。 達成此目標的絕佳方式是使用 Azure 流量管理員配置檔解析自訂網域。 流量管理員設定檔可設定為指向所有個別的 App Service 環境。 流量管理員將根據流量管理員設定檔中的負載平衡設定,自動負責在所有的 App Service 環境中進行客戶的分配。 無論所有 App Service 環境都是部署在單一 Azure 區域中,還是跨多個 Azure 區域在全球範圍內部署,此方法都適用。
此外,由於客戶透過虛名網域存取應用程式,因此客戶不知道執行應用程式的 App Service 環境數目。 因此,開發人員可以根據觀察到的流量負載,快速輕鬆地新增和移除 App Service 環境。
下列概念圖描述在單一區域內水平擴展至三個應用服務環境的應用程式。
本文的其餘部分會逐步解說使用多個 App Service 環境為範例應用程式設定分散式拓撲所涉及的步驟。
規劃拓撲
在建立分散式應用程式佔用空間之前,提前掌握一些資訊會有所幫助。
-
應用程式的自訂網域: 客戶將用來存取應用程式的自訂網域名稱是什麼? 對於範例應用程式,自訂網域名稱為
www.asabuludemo.com。 - 流量管理員網域: 建立 Azure 流量管理員設定檔時選擇網域名稱。 此名稱會與 trafficmanager.net 後綴結合,以註冊流量管理員所管理的網域項目。 對於範例應用程式,選擇的名稱是 scalable-ase-demo。 因此,流量管理員所管理的完整網域名稱為 scalable-ase-demo.trafficmanager.net。
- 擴展應用程式使用量的策略: 應用程式使用量是否會分散在單一區域中的多個 App Service 環境中? 多個地區? 兩種方法的混合搭配? 根據客戶流量來源的預期,以及應用程式支援後端基礎結構其餘部分的擴展程度來做出決策。 例如,使用 100% 無狀態應用程式時,可以透過結合每個 Azure 區域中多個應用程式服務環境進行大規模擴展,然後再乘以跨許多 Azure 區域部署的應用程式服務環境。 有 15+ 全球 Azure 區域可供選擇,客戶可以真正建立全球超大規模應用程式足跡。 針對本文所用的範例應用程式,已在單一 Azure 區域 (美國中南部) 中建立三個 App Service 環境。
- App Service 環境的命名慣例: 每個 App Service 環境都需要唯一的名稱。 除了一兩個 App Service 環境之外,擁有命名慣例來協助識別每個 App Service 環境會很有幫助。 針對範例應用程式,使用了簡單的命名慣例。 三個 App Service 環境的名稱是 fe1ase、 fe2ase 和 fe3ase。
- 應用程式的命名慣例: 由於將部署應用程式的多個執行個體,因此部署應用程式的每個執行個體都需要一個名稱。 App Service 環境的一項鮮為人知但方便的功能是,相同的應用程式名稱可以在多個 App Service 環境中使用。 由於每個 App Service 環境都有唯一的網域尾碼,因此開發人員可以選擇在每個環境中重複使用完全相同的應用程式名稱。 例如,開發人員可以將應用程式命名為: myapp.foo1.p.azurewebsites.net、 myapp.foo2.p.azurewebsites.net、 myapp.foo3.p.azurewebsites.net 等。不過,對於範例應用程式,每個應用程式執行個體也有唯一的名稱。 使用的應用程式執行個體名稱為 webfrontend1、 webfrontend2 和 webfrontend3。
設定流量管理員設定檔
在多個 App Service 環境中部署應用程式的多個執行個體之後,就可以向流量管理員註冊個別應用程式執行個體。 範例應用程式需要一個流量管理員設定檔,用於scalable-ase-demo.trafficmanager.net,以便將客戶路由到下列任何已部署的應用程式實例:
- webfrontend1.fe1ase.p.azurewebsites.net: 部署在第一個 App Service 環境中的範例應用程式執行個體。
- webfrontend2.fe2ase.p.azurewebsites.net: 部署在第二個 App Service 環境中的範例應用程式實例。
- webfrontend3.fe3ase.p.azurewebsites.net: 部署在第三個 App Service 環境中的範例應用程式實例。
註冊多個 Azure App Service 端點 (全部都在 相同的 Azure 區域中執行) 的最簡單方式是使用 PowerShell Azure Resource Manager 流量管理員支援。
第一個步驟是建立 Azure 流量管理員設定檔。 下列程式碼顯示如何為範例應用程式建立設定檔:
$profile = New-AzTrafficManagerProfile –Name scalableasedemo -ResourceGroupName yourRGNameHere -TrafficRoutingMethod Weighted -RelativeDnsName scalable-ase-demo -Ttl 30 -MonitorProtocol HTTP -MonitorPort 80 -MonitorPath "/"
請注意 RelativeDnsName 參數如何設定為 scalable-ase-demo。 此參數會導致建立網域名稱 scalable-ase-demo.trafficmanager.net 並與流量管理員設定檔相關聯。
TrafficRoutingMethod 參數會定義流量管理員將用來判斷如何在所有可用端點之間分散客戶負載的負載平衡原則。 在此範例中,選擇了 加權 方法。 由於此選擇,客戶請求將根據與每個端點相關聯的相對權重,分散到所有已註冊的應用程式端點。
建立設定檔後,每個應用程式執行個體都會新增至設定檔做為原生 Azure 端點。 下列程式碼會擷取各前端 Web 應用程式的參考。 然後,它會透過 TargetResourceId 參數將每個應用程式新增為流量管理員端點。
$webapp1 = Get-AzWebApp -Name webfrontend1
Add-AzTrafficManagerEndpointConfig –EndpointName webfrontend1 –TrafficManagerProfile $profile –Type AzureEndpoints -TargetResourceId $webapp1.Id –EndpointStatus Enabled –Weight 10
$webapp2 = Get-AzWebApp -Name webfrontend2
Add-AzTrafficManagerEndpointConfig –EndpointName webfrontend2 –TrafficManagerProfile $profile –Type AzureEndpoints -TargetResourceId $webapp2.Id –EndpointStatus Enabled –Weight 10
$webapp3 = Get-AzWebApp -Name webfrontend3
Add-AzTrafficManagerEndpointConfig –EndpointName webfrontend3 –TrafficManagerProfile $profile –Type AzureEndpoints -TargetResourceId $webapp3.Id –EndpointStatus Enabled –Weight 10
Set-AzTrafficManagerProfile –TrafficManagerProfile $profile
請留意,對於每個應用程式執行個體分別會有一個 Add-AzureTrafficManagerEndpointConfig 呼叫。 每個 PowerShell 命令中的 TargetResourceId 參數都會參考三個已部署的應用程式執行個體之一。 流量管理員配置檔會將負載分散到配置檔中註冊的所有三個端點。
所有三個端點都對 Weight 參數使用相同的值 (10)。 這種情況會導致流量管理員將客戶要求相對平均地分散到所有三個應用程式實例之間。
將應用程式的自訂網域指向流量管理員網域
必要的最後一個步驟是將應用程式的自訂網域指向流量管理員網域。 針對範例應用程式,將 www.asabuludemo.com 指向 scalable-ase-demo.trafficmanager.net。 請向管理自訂網域的網域註冊商完成此步驟。
使用註冊機構的網域管理工具,建立 CNAME 記錄,將自訂網域指向流量管理員網域。 下圖顯示了此CNAME配置的示例:
雖然本主題未涵蓋,但請記住,每個個別應用程式執行個體也必須向其註冊自訂網域。 否則,如果要求傳送至應用程式執行個體,且應用程式尚未向應用程式註冊自訂網域,則要求將會失敗。
在此範例中,自訂網域是 www.asabuludemo.com,且每一個應用程式執行個體都有與其相關聯的自訂網域。
如需向 Azure App Service 應用程式註冊自訂網域的回顧,請參閱 註冊自訂網域。
嘗試分散式拓蹼
流量管理員和 DNS 設定的最終結果是,要求 www.asabuludemo.com 將流經下列順序:
- 瀏覽器或裝置會進行 DNS 查詢以針對
www.asabuludemo.com - 網域註冊商的 CNAME 紀錄會導致 DNS 查詢重新導向至 Azure Traffic Manager。
- 對其中一個 Azure 流量管理員 DNS 伺服器執行 scalable-ase-demo.trafficmanager.net 的 DNS 查閱。
- 根據稍早在 TrafficRoutingMethod 參數中指定的負載平衡原則,流量管理員會選取其中一個已設定的端點。 然後,它會將該端點的 FQDN 傳回給瀏覽器或裝置。
- 由於端點的 FQDN 是在 App Service Environment 上執行之應用程式執行個體的 Url,因此瀏覽器或裝置會要求 Microsoft Azure DNS 伺服器將 FQDN 解析為 IP 位址。
- 瀏覽器或裝置會將 HTTP/S 請求傳送到 IP 位址。
- 要求會送達在其中一個 App Service 環境上執行的應用程式執行個體之一。
下面的主控台圖片顯示範例應用程式自訂網域的 DNS 查閱。 它會成功解析到一個應用程式執行個體,該執行個體運行於三個範例應用程式服務環境中的第二個環境上。
相關內容
- PowerShell Azure Resource Manager 流量管理員支援 (部分內容可能是機器或 AI 翻譯)