Gateway-avlastningsmönster

Avlasta delade eller specialiserade tjänstfunktioner till en gateway-proxy. Den här metoden förenklar programutvecklingen genom att centralisera övergripande problem, till exempel klientriktad TLS-certifikatavslut, i gatewayen i stället för att duplicera dem mellan tjänster.

När flera tjänster delar ansvarsområden, till exempel autentisering, övervakning eller protokollöversättning, minskar konsolideringen av dessa problem till en enda gateway kostnaderna för konfiguration per tjänst och distributionsrisken.

Kontext och problem

Vissa funktioner är vanliga för flera tjänster och de kräver konfigurering, hantering och underhåll. En delad eller specialiserad tjänst som du distribuerar med varje programdistribution lägger till administrativa kostnader och ökar sannolikheten för distributionsfel. Du måste distribuera uppdateringar till en delad funktion för alla tjänster som delar den funktionen.

Säkerhetsproblem som tokenverifiering, kryptering och TLS-certifikathantering kan kräva att teammedlemmar har mycket specialiserade kunskaper. Utan en gateway kan du till exempel behöva konfigurera och distribuera ett klientbaserat certifikat på varje programinstans. Du måste spåra dess förfallodatum och uppdatera, testa och verifiera det över dessa instanser.

Andra vanliga tjänster, till exempel autentisering, auktorisering, loggning, övervakning, eller bandbreddsbegränsning kan vara svåra att implementera och hantera över ett stort antal distributioner. Om du konsoliderar den här typen av funktioner minskar kostnaderna och risken för fel.

Lösning

Lägg viss funktionalitet i en gateway. Gatewayen hanterar sedan tvärgående aspekter som hantering av klientvända certifikat, autentisering, TLS-terminering, övervakning, protokollöversättning och belastningsbegränsning för serverdelstjänsternas räkning.

Följande diagram visar en gateway som avslutar inkommande TLS-anslutningar och tillämpar delade funktioner. Gatewayen validerar serverdelscertifikatet och krypterar om trafiken via en separat TLS-anslutning till serverdelstjänsten.

Några fördelar med det här mönstret är följande:

• Förenkla utvecklingen av tjänster genom att centralisera delad konfiguration, till exempel autentisering, begränsning och loggning av begäranden, i stället för att implementera den i varje serverdelstjänst. Centraliseringen förbättrar konsekvensen och gör tjänstuppgraderingar enklare.

• Tillåt att dedikerade grupper implementerar funktioner som kräver särskilda kunskaper, till exempel säkerhet. Kärnteamet kan sedan fokusera på programfunktioner och lämna dessa specialiserade men övergripande frågor till relevanta experter.

• Sörj för konsekvens vid loggning och övervakning av begäranden och svar. Även om en tjänst inte är korrekt instrumenterad kan gatewayen tillhandahålla en baslinjenivå för övervakning och loggning.

• Centralisera koldioxidmedveten trafikhantering. En gateway kan justera cachelagring, hastighetsbegränsning och loggningsbeteenden baserat på koldioxidintensitetssignaler i realtid. Azure API Management tillhandahåller dessa funktioner i begränsad förhandsversion, i utvalda regioner och klassiska nivåer (Developer, Basic, Standard och Premium). Information om tillgänglighet och konfiguration finns i Miljömässigt hållbara API:er i Azure API Management.

• Hantera statiska gamla till nya URL-mappningar. Gatewayen kan returnera en omdirigering utan att anropa en backend och hålla äldre URL-hantering borta från varje tjänsts pipeline för begäranden.

Problem och överväganden

Tänk på följande när du bestämmer dig för hur du implementerar det här mönstret:

• Hög tillgänglighet och motståndskraft. Se till att gatewayen är mycket tillgänglig och motståndskraftig mot fel. Undvik enskilda felpunkter genom att köra flera instanser av din gateway. Eftersom gatewayen avslutar klientanslutningar och kan buffra begärandetexter bör du överväga hur pågående begäranden hanteras vid instansfel. Använd mekanismer för anslutningsdränering eller graciös avstängning så att borttagning eller omstart av en gatewayinstans inte tar bort aktiva sessioner.

• Kapacitet och skalning. Se till att gatewayen är utformad för de kapacitets- och skalningskrav som programmet och slutpunkterna ställer. Kontrollera att gatewayen inte blir en flaskhals för programmet och att den är tillräckligt skalbar. Gatewayen måste etableras för att hantera trafiktoppar, inte bara genomsnittlig belastning. Underetablering av gatewayen för att minska kostnaderna försämrar direkt prestanda för varje tjänst bakom den.

• Avlastningens omfattning. Avlastningsfunktioner som delas av flera tjänster eller vägar när de centraliseras minskar duplicerad implementering och hantering.

• Matchning av omdirigeringar. Match endast de avsedda äldre URL:erna och bevara normal routning för omatchade begäranden. Behåll omdirigeringar som är beroende av affärstillstånd eller programspecifik auktorisering i programmet. Relaterad vägledning finns i Bevara länkar när innehållet flyttas.

• Affärslogikavgränsning. Avlasta aldrig affärslogik till gatewayen.

• Transaktionsspårning. Överväg att generera korrelations-ID:n för loggning om du behöver spåra transaktioner.

• Omkostnader för svarstid. Gatewayen lägger till ett nätverkshopp till varje begäran. Varje avlastad funktion som gatewayen utför, till exempel TLS-avslutning, autentisering eller inspektion av begäran, lägger till bearbetningstid för begärandesökvägen. Gatewayanslutningspooler och keep-alive-anslutningar till serverdelstjänster kan delvis kompensera för svarstiden genom att återanvända anslutningar i stället för att upprätta nya för varje begäran. Utvärdera om den kombinerade svarstiden för gatewayhoppet och de avlastade funktionerna är acceptabel för arbetsbelastningens prestandamål.

• Driftkomplexitet. En centraliserad gateway konsoliderar hanteringen men koncentrerar även driftansvaret. Du måste hantera gatewaykonfigurationen, certifikatets livscykel, principuppdateringar och versionsuppgraderingar som ett gemensamt problem. Se till att det team som ansvarar för gatewayen har kapacitet och verktyg för att hantera den i skalan för alla tjänster som är beroende av den.

• Säkerhetskonsekvenser. Gatewayen är ett högt värdemål eftersom den centraliserar övergripande säkerhetsfunktioner som autentisering, TLS-avslutning och inspektion av begäranden. Om gatewayen komprometteras kan alla bakomliggande tjänster exponeras. Härda gatewayen, begränsa dess hanteringsyta och övervaka den för avvikande beteende oberoende av de serverdelstjänster som den skyddar.

• Skydd mot kringgående av gateway Konfigurera backendtjänster så att de endast accepterar begäranden via den avsedda gateway-sökvägen. Annars kan klienter ansluta direkt till en backend och kringgå autentisering, hastighetsbegränsning, begärandeinspektion och loggning i gatewayen.

• Identitetsspridning. Definiera om varje serverdel auktoriserar den ursprungliga anroparen, gatewayens arbetsbelastningsidentitet eller båda. Bevara anropartoken eller betrodda anspråk endast när serverdelen kräver delegerad användarkontext. Autentisera alltid gatewayen till serverdelen separat. Behandla inte obekräftade vidarebefordrade headerfält som bevis på identitet.

• TLS-underhåll. Om gatewayen avslutar TLS återupprättar du TLS till serverdelen. Vidarebefordra inte trafik via okrypterad HTTP. Behandla alla nätverk som ej betrodda. Den här topologin kräver fortfarande en process för att utfärda, rotera och återkalla serverdelscertifikat.

• Vidarebefordrade sidhuvuden och klientkontext. När gatewayen avslutar klientanslutningar och upprättar nya anslutningar till serverdelstjänster går information som klientens IP-adress, ursprungliga protokoll och värdnamn förlorad om inte gatewayen uttryckligen vidarebefordrar den. För strategier för att minimera riskerna, se Bevara det ursprungliga HTTP-värdnamnet mellan en omvänd proxy och dess bakändswebbapp.

När du ska använda det här mönstret

Använd det här mönstret i sådana här scenarier:

• En programdistribution har ett gemensamt problem, till exempel TLS-certifikat eller kryptering.
• En funktion som är gemensam för programdistributioner kan ha olika resurskrav, till exempel minnesresurser, lagringskapacitet eller nätverksanslutningar.
• Du vill flytta ansvaret för problem som nätverkssäkerhet, begränsning eller andra problem med nätverksgränser till ett mer specialiserat team.

Det här mönstret kanske inte är lämpligt när:

• Gatewayen måste innehålla tjänstspecifik logik eller routningsregler som nära kopplar ihop ändringar av serverdelstjänsten i gatewaykonfigurationsändringar. Att koppla gatewaynivån till interna tjänster innebär att serverdelsuppdateringar kan tvinga fram omdistribution av gatewayer, vilket minskar distributionens oberoende.
• Den avlastade uppgiften är resurslätt och arbetslasten är latenskänslig. Det ytterligare nätverkshoppet via gatewayen kanske inte motiveras när omkostnaderna överväger fördelarna med centralisering.
• Att centralisera problem till en delad gateway skapar en flaskhals för ändringshantering. Om gateway-teamets versionscykel är långsammare än serviceteamens, kan avlastning fördröja uppdateringar av certifikat, autentiseringsprinciper eller nätverksregler.

Design av arbetsbelastning

En arkitekt bör utvärdera hur Gateway Offloading-mönstret kan användas i utformningen av deras arbetsbelastning för att uppfylla de mål och principer som beskrivs i grundpelarna i Azure Well-Architected Framework. Ett exempel:

Om detta mönster inför kompromisser inom en pelare bör du överväga dem mot målen för de andra pelarna.

Example

Azure Application Gateway WAF_v2 kan implementera det här mönstret för ett regionalt webbprogram. Gatewayen avslutar klientens TLS-anslutningar, tillämpar WAF- och routningsprinciper och upprättar nya TLS-anslutningar till serverdelstjänsterna. Den här designen håller problem med delad begärandebearbetning borta från programkoden för serverdelen.

Application Gateway med TLS-avlastning

Följande diagram visar hur Application Gateway avslutar inkommande TLS-anslutningar, inspekterar och filtrerar trafiken och krypterar den igen innan den vidarebefordras till en serverdelspool via TLS.

Den här arkitekturen använder följande Application Gateway-komponenter för att avlasta delade funktioner och omkryptera serverdelstrafik:

• HTTPS-lyssnare. En HTTPS-lyssnare på port 443 accepterar inkommande TLS-anslutningar från klienter.
• TLS-certifikat. Ett PFX-certifikat, som kommer från Azure Key Vault, är kopplat till HTTPS-lyssnaren. Application Gateway avkrypterar inkommande trafik för att inspektera och dirigera den vidare och krypterar sedan om den innan den skickas vidare till backend-poolen. Serverdelsservrar behöver fortfarande certifikat för omkrypterade anslutningar, men i många fall kan plattformshanterade certifikat användas.
• Serverdelspool. En serverdelspool definierar uppsättningen HTTPS-servrar som tar emot den omkrypterade trafiken. Serverdelsmål kan vara virtuella datorer, Azure Virtual Machine Scale Sets, IP-adresser eller Azure App Service instanser. Begränsa serverdelsåtkomsten så att klienter inte kan kringgå Application Gateway och dess WAF-princip genom att ansluta direkt.
• HTTP-inställningar för serverdelen. Ange serverdelsprotokollet till HTTPS och porten till serverdelens TLS-port, till exempel 443. Konfigurera certifikatförtroende och ett värdnamn som matchar serverdelscertifikatet. Konfigurera det betrodda rotcertifikatet för en privat certifikatutfärdare. Mer information finns i TLS från slutpunkt till slutpunkt med V2 SKU.
• Routningsregel. En regel för begärandedirigering associerar lyssnaren med serverdelspoolen och HTTP-inställningarna för serverdelen. Sökvägsbaserade regler kan dirigera om olika URL-sökvägar till olika serverdelsgrupper.
• WAF-princip. Policyn definierar de hanterade och anpassade regler som används för att inspektera förfrågningar, inklusive eventuella Geomatch-regler.

Eftersom Application Gateway dekrypterar trafiken kan den granska begärandeinnehåll för intelligent routning, skriva om HTTP-huvuden och URL:er och tillämpa WAF-regler. Sedan krypteras trafiken igen innan begäranden vidarebefordras till serverdelen.

Konfigurationsvägledning finns i TLS-kryptering från slutpunkt till slutpunkt med Application Gateway.

Stödjande teknologier

Följande Azure tjänster kan hjälpa dig att implementera det här mönstret:

• Använd Application Gateway för regional webbtrafik.

• Använd Azure Application Gateway for Containers för Kubernetes-nativ ingress till AKS-arbetsbelastningar.

• Använd Azure Front Door för global webbtrafik eller webbtrafik i flera regioner.

• Använd Azure API Management för API-specifika problem som autentisering, begränsning, transformering och övervakning.

Nästa steg

• Alternativ för belastningsutjämning
• Använda API-gatewayer i mikrotjänster

Relaterade resurser

• Backends for Frontends-mönster
• Gateway-aggregationsmönster
• Gateway-routningmönstret
• Strypningsmönster
• Skydda API:er med hjälp av Application Gateway och API Management