Gateway-aggregeringsmönster

Använd en gateway för att slå samman flera enskilda förfrågningar till en enda begäran. Det här mönstret är användbart när en klient måste göra flera anrop till olika serverdelssystem för att utföra en åtgärd.

Kontext och problem

För att utföra en enda uppgift kan en klient behöva göra flera anrop till olika serverdelstjänster. Ett program som förlitar sig på många tjänster för att utföra en uppgift måste förbruka resurser på varje begäran. När nya funktioner eller tjänster läggs till i programmet behövs extra begäranden, vilket ytterligare ökar resurskraven och nätverksanropen. Den här chattigheten mellan en klient och en serverdel kan påverka programmets prestanda och skala negativt. Arkitekturer för mikrotjänster har gjort det här problemet vanligare eftersom program som bygger på många mindre tjänster har ett högre antal korstjänstanrop.

I följande diagram skickar klienten begäranden till varje tjänst (numrerade 1, 2 och 3). Varje tjänst bearbetar begäran och returnerar ett svar till programmet (numrerat 4, 5 och 6). Att skicka enskilda begäranden på det här sättet via ett mobilnät med hög svarstid är ineffektivt och kan orsaka anslutningsförlust eller ofullständiga svar. Varje begäran kan köras parallellt. Programmet måste dock fortfarande skicka, vänta på och bearbeta data för varje begäran om separata anslutningar, vilket ökar risken för fel.

Lösning

Använd en gateway för att minska antalet anrop mellan klienten och tjänsterna. Gatewayen tar emot klientbegäranden, skickar begäranden till de olika serverdelssystemen och aggregerar resultatet innan den skickar tillbaka dem till klienten.

Det här mönstret kan minska antalet begäranden som programmet gör till serverdelstjänster och förbättra programprestanda i nätverk med långa svarstider.

I följande diagram skickar programmet en begäran till gatewayen (1). Begäran innehåller ett paket med extra begäranden. Gatewayen delar upp dessa begäranden och bearbetar varje begäran genom att skicka den till den relevanta tjänsten (2). Varje tjänst returnerar ett svar till gatewayen (3). Gatewayen kombinerar svaren från varje tjänst och skickar svaret till programmet (4). Programmet gör en begäran och får bara ett enda svar från gatewayen.

Problem och överväganden

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

Gatewayen bör inte införa koppling mellan backendtjänsterna.
Gatewayen bör finnas nära serverdelstjänsterna för att minska svarstiden så mycket som möjligt.
Gateway-tjänsten kan innebära en enda felpunkt (SPoF). Se till att gatewayen är korrekt utformad för att uppfylla programmets tillgänglighetskrav.
Gatewayen kan medföra en flaskhals. Se till att gatewayen har tillräcklig prestanda för att hantera den aktuella belastningen och kan skalas för att uppfylla din förväntade tillväxt.
Utför belastningstestning mot gatewayen för att säkerställa att du inte introducerar sammanhängande fel för tjänster.
Implementera en feltolerant design med hjälp av tekniker som bulkheads, circuit breaker, återförsök och tidsgränser.
Om ett eller flera tjänstanrop tar för lång tid kan det vara acceptabelt att överskrida tidsgränsen och returnera en del av datamängden. Fundera över hur programmet hanterar det här scenariot.
Använd asynkrona indata och utdata (I/O) för att säkerställa att en fördröjning i serverdelen inte orsakar prestandaproblem i programmet.
Implementera distribuerad spårning med hjälp av korrelations-ID:er för att spåra varje enskilt anrop.
Övervaka begärandemått och svarsstorlekar.
Överväg att returnera cachelagrade data som en redundansstrategi för hantering av fel.
I stället för att skapa aggregering i gatewayen bör du överväga att placera en aggregeringstjänst bakom gatewayen. Aggregering av begäranden kommer sannolikt att ha andra resurskrav än andra tjänster i gatewayen och kan påverka gatewayens routnings- och avlastningsfunktioner.

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 klient måste kommunicera med flera serverdelstjänster för att utföra en åtgärd.
Klienten kan använda nätverk som har betydande svarstider, till exempel mobilnät.

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

Du vill minska antalet anrop mellan en klient och en enskild tjänst över flera operationer. I det scenariot kan det vara lämpligare att lägga till en batchåtgärd i tjänsten.
Klienten eller programmet finns nära serverdelstjänsterna och svarstiden är inte en betydande faktor.

Design av arbetsbelastning

Utvärdera hur Gateway Aggregation-mönstret kan användas i utformningen av en arbetsbelastning för att uppfylla de mål och principer som behandlas i pelarna i Azure Well-Architected Framework. Följande tabell innehåller vägledning om hur det här mönstret stöder målen för varje pelare.

Grundpelare	Så här stöder det här mönstret pelarmål
Tillförlitlighets designbeslut hjälper din arbetsbelastning att bli motståndskraftig mot funktionsfel och säkerställer att den återställer sig till ett fullständigt fungerande tillstånd när ett fel uppstår.	Med den här topologin kan du flytta övergående felhantering från en distribuerad implementering mellan klienter till en centraliserad implementering. - Rekommendationer för hantering av tillfälliga fel
Beslut om säkerhetsdesign bidrar till att säkerställa konfidentialitet, integritet och tillgänglighet för arbetsbelastningens data och system.	Den här topologin minskar ofta antalet beröringspunkter som en klient har med ett system, vilket minskar den offentliga ytan och autentiseringspunkterna. De aggregerade backend-systemen kan förbli helt nätverksisolerade från klienterna. - SE:04 Segmentering - SE:08 Härda resurser
Operational Excellence hjälper till att leverera arbetsbelastningskvalitet genom standardiserade processer och teamsammanhållning.	Det här mönstret gör att serverdelslogik kan utvecklas oberoende av klienter. Den här avkopplingen ger dig flexibiliteten att ändra de länkade tjänstimplementeringarna, eller till och med datakällor, utan att behöva ändra klientpekpunkter. - OE:04 Verktyg och processer
Prestandaeffektivitet hjälper din arbetsbelastning effektivt uppfylla kraven genom optimering av skalning, data och kod.	Den här designen kan medföra mindre svarstid än en design där klienten upprättar flera anslutningar. Cachelagring i aggregeringsimplementeringar minimerar anrop till serverdelssystem. - PE:03 Välj tjänster - PE:08 Dataprestanda

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

Överväg ett mikrotjänstbaserat program som ger en ordersammanfattningsupplevelse för en kund. När en användare öppnar en ordersida måste programmet hämta data från flera serverdelstjänster, till exempel en ordertjänst, en leveranstjänst och en kundprofiltjänst.

I en arkitektur för mikrotjänster implementeras och distribueras dessa tjänster oberoende av varandra. Utan aggregering måste klienten anropa varje tjänst direkt, vilket ökar svarstiden och komplexiteten.

För att lösa det här problemet använder programmet Azure API Management som gateway-sammansättningslagret. Klienten skickar en enda begäran till en API Management-åtgärd som fungerar som insamlare för orderinformation. API Management anropar sedan de stödjande serverdels-API:erna och returnerar ett enhetligt svar till klienten.

Du kan implementera den här enkla kompositionen med hjälp av API Management-principen för sändningsbegäran för att hämta data från flera tjänster och konstruera ett kombinerat svar. I det här exemplet körs serverdelstjänsterna i en Azure Container Apps miljö och du distribuerar varje serverdelstjänst som en containerapp som förblir dold från direkt klientåtkomst.

Ladda ned en Visio-fil av den här arkitekturen.

Begärandeflödet följer dessa steg:

Klienten skickar en begäran till en ordersammanfattningsslutpunkt som exponeras via API Management.
API Management tillämpar en princip som samlar in order-, leverans- och kundprofildata från serverdelstjänsterna.
API Management sammanställer serverdelens svar till en enda nyttolast för ordersammanfattningen.
API Management returnerar det aggregerade svaret till klienten.

Genom att introducera det här aggregeringslagret minskar lösningen tur och retur från klient till tjänst och förenklar klientinteraktioner. Det här lagret ansvarar för att på ett robust sätt hantera backendtjänster som inte svarar och förhindra att fel sprider sig genom det aggregerade svaret. Härda dina API Management-principer med hjälp av tidsgränser per begäran, hantering av villkorsfel och kretsbrytare.

Om ett av serverdelsanropen överskrider tidsgränsen eller returnerar ett fel kan API Management tillämpa det beteende som passar bäst för åtgärden. Det kan till exempel returnera ett partiellt svar när data som saknas är godtagbara, eller så kan hela begäran misslyckas när fullständiga och konsekventa orderdata krävs. Gör det här beslutet explicit i principdesignen så att klienter upplever förutsägbart beteende.

Den här metoden fungerar bra när gatewayen utför enkel sammansättning, anpassning och sammanställning av svar. Om aggregeringen kräver anpassad domänlogik, komplexa transformeringar eller orkestrering som körs längre, placerar du den funktionen i en dedikerad anpassad tjänst bakom gatewayen.

För övervakning samlar du in telemetri över den fullständiga begärandesökvägen så att du kan korrelera API Management-beteendet med svarstid för serverdelen. Den här synligheten är viktig i ett gateway-aggregeringsmönster eftersom en enskild klientåtgärd är beroende av flera backend-anrop, och fel eller långsamma svar i ett beroende kan påverka det slutliga aggregerade resultatet. Använd Azure Monitor som den centrala observerbarhetsplattformen. Samla in API Management-loggar och måttvärden för gatewayen och principkörningssökvägen, och aktivera övervakning för Container Apps för att samla in programloggar och måttvärden från backend-containerapparna. Dirigera API Management och backend-telemetri till en Log Analytics-arbetsyta för enhetliga frågor, aviseringar och felsökning. Med den här telemetrin kan du identifiera tidsgränsmönster, identifiera vilket serverdelsberoende som orsakade ett partiellt eller misslyckat svar och skapa aviseringar för förhöjd svarstid eller felfrekvens.

Nästa steg

Feedback

Var den här sidan till hjälp?

Last updated on 2026-06-03