Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Programscenarier som kräver hög skala kan överskrida den beräkningsresurskapacitet som är tillgänglig för en enskild distribution av en app. Röstningsprogram, sportevenemang och tv-sända underhållningsevenemang är exempel på scenarier som kräver hög skala. Du kan stödja höga skalningskrav genom att skala ut appar horisontellt. För att hantera extrema belastningskrav kan många appdistributioner göras inom en enda region och mellan regioner.
Den här artikeln innehåller en översikt över hur du skapar en distribuerad topologi med en exempelapp och flera App Service-miljöer. Den vågräta skalningen utförs med hjälp av Azure Traffic Manager.
Översikt över horisontell skalningsprocess
App Service-miljöer är en idealisk plattform för horisontell utskalning. När du har valt en App Service Environment-konfiguration som kan stödja en känd begärandefrekvens kan utvecklare distribuera fler App Service-miljöer på ett "cookie cutter"-sätt för att uppnå en önskad kapacitet för högsta belastning.
Anta att en app som körs i en App Service Environment-konfiguration testas för att hantera 20 K-begäranden per sekund (RPS). Om den önskade högsta belastningskapaciteten är 100 K RPS kan fem App Service-miljöer skapas och konfigureras för att säkerställa att programmet kan hantera den maximala planerade belastningen.
Eftersom kunder vanligtvis kommer åt appar med hjälp av en anpassad (eller fåfäng) domän behöver utvecklare ett sätt att distribuera appbegäranden över alla App Service Environment-instanser. Ett bra sätt att uppnå det här målet är att lösa den anpassade domänen med hjälp av en Traffic Manager-profil. Profilen kan konfigureras så att den pekar på alla enskilda App Service-miljöer. Traffic Manager hanterar automatiskt distributionen av kunder i alla App Service-miljöer, baserat på belastningsutjämningsinställningarna i profilen. Den här metoden fungerar oavsett om alla App Service-miljöer distribueras i en enda Azure-region eller distribueras över hela världen i flera Azure-regioner.
I det här scenariot får kunderna ofta åtkomst till appar via den fåfänga domänen. De känner inte till antalet App Service-miljöer som kör en app. Utvecklare kan snabbt och enkelt lägga till och ta bort App Service-miljöer baserat på observerad trafikbelastning.
Följande diagram visar en app vågrätt skalad över tre App Service-miljöer i en enda region:
Topologikrav
För att skapa den distribuerade appen behöver du följande information:
Anpassad domän för appen: Fastställa det anpassade eller fåfänga domännamn som kunder använder för att få åtkomst till din app. För exempelappen i den här artikeln är
www.asabuludemo.comdet anpassade domännamnet .Traffic Manager-domän: Välj ett domännamn när du skapar Traffic Manager-profilen. Namnet kombineras med suffixet
trafficmanager.net, vilket anger att Traffic Manager underhåller registrering och hantering för domänposten. För exempelappen ärscalable-ase-demodomännamnet . Det fullständiga domännamnet som hanteras av Traffic Manager ärscalable-ase-demo.trafficmanager.net.Strategi för skalning av appens fotavtryck: Avgör hur appen distribueras i flera App Service-miljöer: en enda region, flera regioner eller en kombination. Tänk på var kundtrafiken kommer ifrån och hur väl resten av en apps back-end-infrastruktur kan skalas.
Överväg ett 100% tillståndslöst program som kan skalas massivt. Du kan använda en kombination av många App Service-miljöer i varje Azure-region multiplicerat med App Service-miljöer som distribuerats i många Azure-regioner. Microsoft Azure är tillgängligt i en mängd olika globala regioner, som stöder en global förekomst av hyperskaliga appar. Exempelappen använder tre App Service-miljöer i en enda Azure-region (USA, södra centrala).
Namngivningskonvention för App Service-miljöer: Definiera konventionen för namngivning av apptjänstmiljöer. Varje App Service-miljö kräver ett unikt namn. Om du har fler än bara en eller två App Service-miljöer är det bra att ha en namngivningskonvention som kan identifiera varje App Service-miljö. Exempelappen implementerar en enkel namngivningskonvention. Namnen på de tre App Service-miljöerna är
fe1ase,fe2aseochfe3ase.Namngivningskonvention för apparna: Definiera konventionen för namngivning av dina appar. Eftersom flera instanser av appen distribueras behöver du ett namn för varje instans av den distribuerade appen. Med App Service-miljöer kan du använda samma appnamn i flera App Service-miljöer. Eftersom varje App Service-miljö har ett unikt domänsuffix kan utvecklare återanvända samma appnamn i varje miljö. Du kan till exempel ha flera appar med namnet
myapp.env1.p.azurewebsites.net,myapp.env2.p.azurewebsites.net,myapp.env3.p.azurewebsites.netoch så vidare. För exempelappen har varje appinstans ett unikt namn:webfrontend1,webfrontend2ochwebfrontend3.
Traffic Manager-profil
När du har distribuerat flera instanser av en app i flera App Service-miljöer kan du registrera appinstanserna med Traffic Manager. Exempelappen kräver en Traffic Manager-profil för scalable-ase-demo.trafficmanager.net adressen. När kunder kommer åt den här platsen dirigerar profilkonfigurationen dem till de distribuerade appinstanserna:
-
webfrontend1.fe1ase.p.azurewebsites.net: Exempelappinstans som distribuerats i den första App Service-miljön. -
webfrontend2.fe2ase.p.azurewebsites.net: Exempelappinstans distribuerad på den andra App Service-miljön. -
webfrontend3.fe3ase.p.azurewebsites.net: Exempelappinstans som distribueras i tredje App Service-miljön.
Skapa profilen
Det enklaste sättet att registrera flera App Service-slutpunkter som körs i samma Azure-region är att använda Azure PowerShell. Det första steget är att skapa Traffic Manager-profilen. Följande kod skapar en ny profil med namnet scalableasedemo för exempelappen.
$profile = New-AzTrafficManagerProfile –Name scalableasedemo -ResourceGroupName demo-resource-group -TrafficRoutingMethod Weighted -RelativeDnsName scalable-ase-demo -Ttl 30 -MonitorProtocol HTTP -MonitorPort 80 -MonitorPath "/"
Observera hur parametern är inställd på -RelativeDnsNamescalable-ase-demo. Kommandot använder den här parametern för att skapa domännamnet scalable-ase-demo.trafficmanager.net och associera det med en Traffic Manager-profil.
Parametern -TrafficRoutingMethod definierar den belastningsutjämningsprincip som Traffic Manager använder för att avgöra hur kundbelastningen ska fördelas mellan alla tillgängliga slutpunkter. Exempelappen använder metoden Viktad . Kundbegäranden distribueras över alla registrerade programslutpunkter baserat på de relativa vikter som är associerade med varje slutpunkt.
Lägga till appinstanser i profilen
Nästa steg är att lägga till varje appinstans i profilen som en intern Azure-slutpunkt. Följande kod hämtar en referens till varje klientwebbapp. Sedan läggs varje app till som en Traffic Manager-slutpunkt via parametern -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 Observera kommandot för varje enskild appinstans. Parametern -TargetResourceId i varje kommando refererar till en av de tre distribuerade appinstanserna. Traffic Manager-profilen distribuerar belastningen över alla tre slutpunkter som registrerats i profilen.
Alla tre slutpunkterna använder samma värde (10) för parametern -Weight . Traffic Manager distribuerar kundförfrågningarna mellan alla tre appinstanserna så jämnt som möjligt.
Mer information finns i Använda PowerShell för att hantera Traffic Manager.
Anpassad domänanslutning med Traffic Manager
När du har konfigurerat profilen och lagt till instanser kan du peka appens anpassade domän på Traffic Manager-domänen. Exempelappen riktar den www.asabuludemo.com anpassade domänen mot Traffic Manager-domänen, scalable-ase-demo.trafficmanager.net.
I konfigurationen slutför du den här uppgiften med domänregistratorn som hanterar din anpassade domän. Genom att använda registratorns verktyg för domänhantering skapar du en CNAME post som pekar den anpassade domänen till Traffic Manager-domänen.
Du kan visa dina DNS-zon-konfigurationer i Azure-portalen under DNS-zon>DNS-hantering>Poster. Följande bild visar ett exempel på konfigurationen CNAME :
Registrera alla appinstanser
När anslutningen har upprättats måste du registrera den anpassade domänen med varje enskild appinstans. Om en begäran når en appinstans och instansen inte har någon anpassad domänregistrering misslyckas begäran.
Anmärkning
Den här artikeln beskriver inte registreringsprocessen för appinstanser. Se till att slutföra processen för konfigurationen med domänregistratorn som hanterar din anpassade domän.
I exempelappscenariot är www.asabuludemo.comden anpassade domänen , och varje appinstans är associerad med den anpassade domänen. Följande bild visar den här konfigurationen:
Mer information finns i Konfigurera en befintlig anpassad domän i Azure App Service.
Topologi för trafikdistribution
När alla webbappsinstanser kan nå Traffic Manager-domänen www.asabuludemo.com flödar begäranden för webbplatsen genom följande sekvens. Sekvensen använder konfigurationsnamnen för resurser i exempelprogrammet.
En webbläsare eller enhet gör en DNS-sökning för webbplatsen,
www.asabuludemo.com.CNAME-posten hos domänregistratorn gör att DNS-sökningen omdirigeras till Traffic Manager.
En DNS-sökning görs för domänen
scalable-ase-demo.trafficmanager.netmot en av Traffic Manager DNS-servrarna.Baserat på den belastningsutjämningsprincip som anges i parametern
-TrafficRoutingMethodväljer Traffic Manager en av de konfigurerade slutpunkterna. Den returnerar sedan FQDN för slutpunkten till webbläsaren eller enheten.Eftersom FQDN för slutpunkten är URL:en för en appinstans som körs i en App Service-miljö, begär webbläsaren eller enheten en Azure DNS-server för att matcha FQDN till en IP-adress.
Webbläsaren eller enheten skickar HTTP/S-begäran till IP-adressen.
Begäran kommer till en av appinstanserna som körs i någon av App Service-miljöerna.
Följande bild visar en DNS-sökning efter exempelappens anpassade domän. Det fördelas framgångsrikt till en appinstans som körs på en av de tre exempelmiljöerna för App Service (i det här fallet den andra av de tre miljöerna för App Service, fe2ase).