Leverans och prestanda för program

Den här artikeln hjälper dig att välja rätt Azure belastningsutjämningstjänst för din arbetsbelastning. Den jämför Azure Load Balancer, Application Gateway och Azure Front Door för regional och global trafikdistribution. Det förklarar också när de ska kombineras. För en kortare, tjänst-för-tjänst-översikt, se Vad är lastbalansering och innehållsleverans?

Vad den här artikeln beskriver

Applikationsleverans inkluderar hur ditt nätverk fördelar trafiken över backend-resurser efter att den anlänt till nätverksperimetern. Den här artikeln beskriver lastbalansering i Lager 4 och Lager 7 och global trafikacceleration. Den omfattar även beslutskriterierna för att välja mellan de tre primära Azure belastningsutjämningstjänster.

Note

Den här artikeln kompletterar Internet-ingress: exponerar ditt program för Internet, som fokuserar på hur trafiken kommer till nätverket. Den här artikeln fokuserar på hur du balanserar och levererar den trafiken till programserverdelarna.

Vem behöver den här artikeln

Läs den här artikeln om du:

  • Var värd för webbapplikationer eller API:er som kräver hög tillgänglighet i flera serverdelsinstanser.
  • Behöver SSL/TLS-avlastning, URL-baserad routing eller Web Application Firewall (WAF)-skydd för HTTP/HTTPS-trafik.
  • Distribuera trafik mellan flera Azure-regioner för prestanda eller haveriåterställning.
  • Kör arbetsbelastningar som inte använder HTTP (TCP/UDP) och som kräver regional lastbalansering med hälsoavsökningar.
  • Vill du veta vilken lastbalanserare som passar din trafiktyp, geografiska omfång och säkerhetskrav.

Fokus på lift-and-shift: Många ommigrerade interna applikationer behöver bara en regional lastbalanserare. Lägg till internetuppkopplade leveranstjänster när du publicerar en app till kunder.

Modernisera fokus: Välj leverans efter apptyp: Azure Front Door för globala webbappar och Traffic Manager för icke-webbappar som frontar aktiva och aktiva regionala slutpunkter.

Fokus mellan moln: Mappa lastbalanserare från andra moln till Azure motsvarigheter (till exempel AWS ALB till Application Gateway, NLB till Azure Load Balancer) och leverera via ekern bakom hubbens brandvägg.

Azure tjänster och funktioner

I följande tabell sammanfattas de tre primära Azure belastningsutjämningstjänster.

Service Vad det ger När du ska använda detta Viktiga begränsningar
Azure Standard Load Balancer Lager 4 -belastningsutjämning (TCP/UDP) inom en region. Hälsoavsökningar, zonredundans, utgående SNAT-regler och HA-portar för virtuella nätverksinstallationer. Virtual Machine Scale Sets, AKS-intern trafik, regionala arbetsbelastningar som inte använder HTTP/HTTPS och NVA med hög tillgänglighet. Ingen SSL/TLS-avslutning; ingen WAF; ingen URL-baserad routning. endast regionalt omfång.
Azure Application Gateway Nivå 7 (HTTP/HTTPS) regional belastningsutjämning. SSL/TLS-avslutning, URL-sökvägsbaserad routning, värd för flera platser, cookiebaserad sessionstillhörighet och valfri WAF-integrering. Regionala webbprogram som behöver SSL-avlastning, URL-routning, WebSocket-stöd eller WAF-skydd. Endast regional; kräver ett dedikerat undernät. passar inte för globala routnings- eller CDN-scenarier.
Azure Front Door Global unicast-lastbalansering och CDN. TLS-avslutning vid edge-noden, integrerad WAF, hälsokontroller av ursprungsservern, trafikuppdelning och cachelagring i fler än 190 globala närvaropunkter (PoPs). Globala webbapplikationer, aktiva active-active-driftsättningar i flera regioner, CDN och cachelagring samt global tillämpning av WAF-regler. endast HTTP/HTTPS; origins måste vara offentligt tillgängliga eller nåliga via Private Link (Premium-nivå).

Zon-redundans

Zonredundans skyddar programleveransnivån från datacenterfel. Varje tjänst hanterar tillgänglighetszoner på olika sätt:

  • Standard Load Balancer (offentlig) är zonredundant som standard eftersom standard offentliga IP-adresser är standard för zonredundant konfiguration. Trafiken fortsätter att flöda även om en tillgänglighetszon misslyckas. Standard Load Balancer (intern) kräver explicit zonredundant klientdelskonfiguration: du måste välja flera zoner när du skapar klientdels-IP-adressen.
  • Application Gateway v2 stöder zonredundans när du distribuerar instanser över flera tillgänglighetszoner. Ange zoner vid driftsättning. En zonredundant Application Gateway sprider instanser över de zoner du väljer, vilket behåller tillgängligheten om en enskild zon går offline.
  • Azure Front Door är i grunden zonredundant som global unicast-tjänst. Dess mer än 190 edge PoP:ar är spridda över flera regioner världen över, så att fel i en enskild zon eller region inte påverkar den globala trafikdirigeringen.

Autoscaling

Varje tjänst hanterar skalning på olika sätt:

  • Application Gateway v2 (Standard_v2- och WAF_v2-nivåer) stöder automatisk skalning baserat på trafikbelastning. Du konfigurerar minsta och högsta antal instanser och gatewayen skalar inom dessa gränser. Prissättningen använder kapacitetsenheter: ett sammansatt mått på nya anslutningar per sekund, beständiga anslutningar och dataflöde. Sätt det minsta antalet instanser till minst två för produktionsarbetsbelastningar för att undvika latens vid kallstart under trafiktoppar.
  • Azure Front Door skalas automatiskt som en hanterad global tjänst. Du behöver inte kapacitetsplanering eller instansstorlek.
  • Standard Load Balancer skalar till miljontals TCP/UDP-flöden utan manuella åtgärder eller konfigurationsändringar. Det är en fullständigt hanterad plattformstjänst utan instanskoncept.

Hälsoundersökningar

Alla tre tjänsterna använder hälsokontroller för att identifiera icke-fungerande backends och slutar dirigera trafik till dem:

  • Standard Load Balancer stöder TCP-, HTTP- och HTTPS-hälsoavsökningar. Konfigurera avsökningsintervall och tröskelvärden som inte är felfria för att kontrollera redundanshastigheten. Kortare intervall identifierar fel snabbare men genererar mer avsökningstrafik.
  • Application Gateway använder HTTP/HTTPS-hälsoavsökningar med anpassningsbara sökvägar, värdnamn och svarsmatchning. Med anpassade avsökningar kan du verifiera programlogik (till exempel kontrollera en /health slutpunkt som verifierar databasanslutningen).
  • Front Door använder HTTP/HTTPS-hälsoavsökningar på ursprungsservrar. Den stöder konfigurerbara sökvägar, intervall och matchning av svarskod. Front Door avsöker ursprunget från flera IP-adresser, vilket ger distribuerad hälsoverifiering.

Så här väljer du

Följande flödesschema sammanfattar den primära beslutssökvägen för att välja en Azure belastningsutjämningstjänst.

Flödesschema där man väljer en Azure-lastbalanseringstjänst genom att grena på HTTP kontra icke-HTTP-trafik, sedan enkelregion vs. global omfattning.

Använd följande beslutstabeller för att välja rätt belastningsutjämningstjänst för ditt scenario.

Vilken lastbalanserare behöver jag?

Jag måste... Användning
Belastningsutjämning av TCP/UDP-trafik inom en enda region Azure Standard Load Balancer: Layer 4-distribution med hälsoavsökningar, zonredundans och HA-portar.
Avsluta SSL/TLS, dirigera efter URL-sökväg eller värdnamn och lägg till WAF för en regional webbapp Azure Application Gateway: Regional belastningsutjämning för Layer 7 med integrerad WAF (v2 SKU).
Dirigera HTTP/HTTPS-trafik globalt, minska latens med edge caching, eller failover över regioner Azure Front Door: Global unicast med CDN, WAF och multiregion-ursprungshälsoprober.

Jämförelse av viktiga begränsningar

Service Lager Scope Nyckelbegränsning
Standardlastbalanserare Lager 4 (TCP/UDP) Regionala Ingen programmedvetenhet: kan inte inspektera HTTP-huvuden, URL:er eller cookies.
Application Gateway Lager 7 (HTTP/HTTPS) Regionala Kräver ett dedikerat undernät (/24 rekommenderas); kan inte dirigera trafik globalt.
Front Door Lager 7 (HTTP/HTTPS) Global Origins måste vara offentliga eller nåliga via Private Link (endast Premium-nivå); inget TCP/UDP-stöd.

Kombinera tjänster

Många produktionsarkitekturer kombinerar flera belastningsutjämningstjänster i en kedja. Varje tjänst hanterar det som är bäst:

  • Front Door + Application Gateway: Använd Front Door för global trafikdistribution och edge WAF och dirigera sedan till regionala Application Gateway-instanser för URL-sökvägsbaserad routning och hantering av serverdelspooler. Front Door Premium kan ansluta till Application Gateway via Private Link och hålla Application Gateway privat. Det här mönstret passar distributioner i flera regioner där varje region har komplexa KRAV för URL-routning.
  • Front Door + Load Balancer: Använd Front Door för global HTTP/HTTPS-distribution, med en intern Standard Load Balancer bakom för att distribuera trafik över Virtual Machine Scale Sets eller NVAs inom en region. Front Door hanterar global routning och cachelagring medan Load Balancer tillhandahåller Layer 4-distribution till beräkningsinstanser.
  • Application Gateway + Load Balancer: Använd Application Gateway för HTTP/HTTPS-trafikhantering på klientdelen och Load Balancer för icke-HTTP-serverdelsnivåer (databaser, meddelandeköer) i samma distribution. Detta mönster håller lager 7-intelligensen i utkanten med en lätt lager 4-distribution internt.

Routningsfunktioner

Genom att förstå routningsfunktioner kan du begränsa ditt val:

Capability Standardlastbalanserare Application Gateway Front Door
URL-sökvägsbaserad routning No Ja Ja
Routning för flera platser (värdhuvud) No Ja Ja
Cookiebaserad sessionsaffinitet No Ja Ja
Viktad trafikdelning No No Ja
Geografisk routning No No Ja
avlastning av SSL/TLS No Ja Ja
WebSocket-stöd Genomkoppling Ja Ja
HTTP/2-stöd No Ja Ja

Tip

Application Gateway v2 skalar automatiskt mellan ett minsta och ett högsta antal instanser, och du betalar för minst den lägsta kapaciteten även när det inte finns någon trafik. Ange det minsta antalet instanser till baslinjebelastningen, inte din topp, och låt automatisk skalning absorbera toppar. Att överdimensionera minimivärdet är en vanlig orsak till onödiga kostnader för Application Gateway.

Designöverväganden

Designfokus för lift-and-shift-applikationsleverans

  • Använd en intern Azure Load Balancer för öst-västlig trafik mellan nivåer i en värdbaserad app, som matchar den belastningsutjämning som appen redan förlitade sig på.
  • Lägg endast till publika leveranstjänster för appar som du gör tillgängliga via internet; många migrerade interna arbetsbelastningar behöver inga sådana.
  • Håll leveransdesignen enkel och begränsad till en region under den inledande omflyttningen.
  • Dirigera all inkommande Internettrafik via hubbens brandvägg innan den når arbetsbelastningen.

Modernisera designfokus för programleverans

  • Välj efter programtyp: Azure Front Door för globala webbappar (edge-avslutning, WAF) och Azure Traffic Manager för icke-webbappar som behöver DNS-baserad regional distribution.
  • Distribuera i aktiv-aktiv-läge mellan regioner och dirigera trafiken till varje regions publika slutpunkt bakom brandväggen i hubben, som utför SNAT och DNAT.
  • Använd Application Gateway för regional routning på lager 7 och TLS-terminering, bakom Front Door när du behöver global distribution.
  • Distribuera inte både Front Door och Traffic Manager för samma flöde. välj en baserat på om appen är webb eller inte.

Designfokus för applikationsleverans över flera moln

  • Mappa leveranstjänster från andra moln till Azure: AWS Application Load Balancer eller Google Cloud Application Load Balancing till Azure Application Gateway, och nätverkslastbalanserare till Azure Load Balancer.
  • Använd Layer 7-leverans (Application Gateway med WAF) i spoke-nätverket och undvik att tilldela offentliga IP-adresser direkt till virtuella datorer.
  • Dirigera publik inkommande trafik genom den skyddade hubbens brandvägg innan den når migrerade arbetsbelastningar.
  • Använd Front Door eller Traffic Manager för leverans i flera regioner när arbetsbelastningar körs i mer än en Azure region.

Förutsättningar

Innan du implementerar tjänster för programleverans:

  • Distribuerat virtuellt nätverk: Du behöver minst ett virtuellt nätverk med undernät. Mer information finns i Design för virtuellt nätverk och undernät för planering av undernät.
  • Typ av arbetsbelastningstrafik identifierad: Ta reda på om din arbetsbelastning använder HTTP/HTTPS (Layer 7) eller TCP/UDP (Layer 4). Denna trafiktyp avgör ditt primära val av lastbalanserare.
  • Geografiskt omfång definierat: Avgör om dina användare befinner sig i en enda region eller distribueras globalt. Globala användare drar nytta av Front Doors unicastaccelerering.
  • Undernätskapacitet för Application Gateway: Application Gateway kräver ett dedikerat undernät utan andra resurser. Ett /24-subnät stödjer upp till 125 instanser plus fem Azure-reserverade adresser.

Säkerhetsfrågor

Belastningsutjämningstjänster är en del av din säkerhetsperimeter. De är de första komponenterna som bearbetar inkommande trafik, vilket gör deras säkerhetskonfiguration kritisk. Följ dessa rutiner för att skydda applikationsleveransskiktet.

Brandvägg för webbaserade program (WAF)

Aktivera WAF i förebyggande läge på Application Gateway eller Front Door för alla produktionswebbarbetsbelastningar. Identifieringsläget loggar endast hot utan att blockera dem. Använd den under den inledande finjusteringen för att identifiera falska positiva resultat och växla sedan till Förhindringsläge innan produktionstrafik börjar flöda.

WAF skyddar mot vanliga webbexploateringar, inklusive:

  • SQL-injektion och cross-site scripting (XSS)
  • Protokollavvikelser och begärandesmuggling
  • Robotar och crawlare (med botskyddsregler)
  • OWASP Topp 10 sårbarheter via hanterade regeluppsättningar

Både Application Gateway WAF och Front Door WAF använder samma regelmotor men skiljer sig åt i omfånget. Application Gateway WAF skyddar en regional distribution, medan Front Door WAF tillämpar principer på den globala gränsen innan trafiken når något ursprung. Detaljerad waf-justering och regeluppsättningskonfiguration finns i Web Application Firewall.

DDoS protection

Aktivera Azure DDoS Protection på alla publika IP-adresser kopplade till dina lastbalanseringstjänster. Standard Load Balancer offentliga klientdels-IP-adresser och offentliga IP-adresser för Application Gateway är primära mål för volymriska attacker. Dessa IP-adresser representerar programmets startpunkter.

Azure DDoS Protection tillhandahåller:

  • Ständigt aktiv trafikövervakning med adaptiv justering.
  • Automatisk attackreducering när trafiken överskrider ett tröskelvärde.
  • Attackera telemetri och aviseringar via Azure Monitor.
  • Kostnadsskydd (servicekredit) för resursskalning som DDoS-attacker utlöser.

Information om planering och konfiguration av DDoS-skydd finns i DDoS-skydd.

Azure Front Door Premium har stöd för Private Link-anslutning till ursprung. Den här funktionen eliminerar behovet av offentligt tillgängliga backendservrar. Front Door ansluter till ditt ursprung via Azure stamnätverk i stället för det offentliga Internet. Använd Private Link ursprung när:

  • Dina backend-tjänster är interna tjänster som inte bör ha offentliga IP-adresser.
  • Du behöver endast låsa ursprungsåtkomsten till Front Door-trafik.
  • Efterlevnadskrav förbjuder offentliga slutpunkter på programservrar.
  • Du vill ta bort attackytan för det publikt exponerade ursprunget.

Private Link ursprung som stöds är App Service, Azure Storage, Application Gateway, interna Standard Load Balancer och anpassade ursprung med Private Link-tjänsten.

För Private Link arkitekturmönster, se Privat åtkomst till Azure PaaS-tjänster.

Important

Front Door Standard-nivån stöder inte Private Link till ursprung. Endast Front Door Premium erbjuder den här funktionen.

Ömsesidig TLS (mTLS)

Application Gateway v2 stöder ömsesidig TLS för serverdelsautentisering. Använd mTLS när dina backendservrar kräver certifikatbaserad klientautentisering från gatewayen. Den här autentiseringen lägger till ett lager av förtroendeverifiering. Backend kan bekräfta att trafiken kommer från den legitima Application Gateway-instansen, inte från en illasinnad aktör som kringgått gatewayen.

Learn more

Nästa steg

Tip

Utforska på egen hand? Gå tillbaka till översiktsnavigatorn för att hitta nästa artikel efter funktion.

Nästa steg i din lift-and-shift-resa:

Kontrollera utgående Internettrafik: Centralisera utgående åtkomst via hubbens brandvägg och inaktivera standardutgående trafik.

Nästa steg i moderniseringsresan:

Konfigurera privat anslutning till PaaS-tjänster: Skapa undernät för Private Link i varje spoke-VNet för dina AKS-, ASE- och arbetsbelastningar för hanterade databaser.

Nästa steg i din molnöverskridande resa:

Skydda din transitväg mellan moln: Distribuera Azure Firewall i din säkra virtuella hubb för att inspektera all trafik mellan moln och internet.