Gateway-aggregatiepatroon

Een gateway gebruiken om verschillende afzonderlijke aanvragen samen te voegen in één aanvraag. Dit patroon is handig wanneer een client meerdere aanroepen naar verschillende back-endsystemen moet uitvoeren om een bewerking uit te voeren.

Context en probleem

Als u één taak wilt uitvoeren, moet een client mogelijk meerdere aanroepen uitvoeren naar verschillende back-endservices. Een toepassing die van veel services afhankelijk is om een taak uit te voeren moet bij elke aanvraag resources verbruiken. Wanneer er nieuwe functies of services aan de toepassing worden toegevoegd, zijn er extra aanvragen nodig, waardoor de resourcevereisten en netwerkoproepen verder worden verhoogd. Deze veelvuldige communicatie tussen een client en een back-end kan de prestaties en schaalbaarheid van de toepassing nadelig beïnvloeden. Microservicesarchitecturen hebben dit probleem vaker veroorzaakt omdat toepassingen die zijn gebouwd rond veel kleinere services een hoger aantal aanroepen tussen services hebben.

In het volgende diagram verzendt de client aanvragen naar elke service (genummerd 1, 2 en 3). Elke service verwerkt de aanvraag en retourneert een reactie op de toepassing (genummerd 4, 5 en 6). Het verzenden van afzonderlijke aanvragen op deze manier via een mobiel netwerk met een hoge latentie is inefficiënt en kan leiden tot verlies van connectiviteit of onvolledige reacties. Elke aanvraag kan parallel worden uitgevoerd. De toepassing moet echter nog steeds gegevens verzenden, wachten en verwerken voor elke aanvraag op afzonderlijke verbindingen, waardoor de kans op fouten toeneemt.

Een probleemdiagram voor het gatewayaggregatiepatroon.

Solution

Gebruik een gateway om de hoeveelheid communicatie tussen de client en de services te verminderen. De gateway ontvangt clientaanvragen, verzendt aanvragen naar de verschillende back-endsystemen en voegt de resultaten samen voordat deze naar de client worden teruggestuurd.

Dit patroon kan het aantal aanvragen dat de toepassing doet naar back-endservices verminderen en de prestaties van toepassingen verbeteren via netwerken met hoge latentie.

In het volgende diagram verzendt de toepassing een aanvraag naar de gateway (1). De aanvraag bevat een pakket extra aanvragen. De gateway ontsplitst deze aanvragen en verwerkt elke aanvraag door deze naar de relevante service (2) te verzenden. Elke service retourneert een antwoord naar de gateway (3). De gateway combineert de antwoorden van elke service en stuurt het antwoord naar de toepassing (4). De toepassing maakt één enkele aanvraag en ontvangt slechts één antwoord van de gateway.

Een oplossingsdiagram voor het gatewayaggregatiepatroon.

Problemen en overwegingen

Houd rekening met de volgende punten wanneer u besluit hoe u dit patroon implementeert:

  • De gateway mag geen servicekoppeling introduceren voor de back-endservices.

  • De gateway moet zich in de buurt van de back-endservices bevinden om de latentie zoveel mogelijk te verminderen.

  • De gatewayservice kan een single point of failure (SPoF) introduceren. Zorg ervoor dat de gateway goed is ontworpen om te voldoen aan de beschikbaarheidsvereisten van uw toepassing.

  • De gateway kan een knelpunt veroorzaken. Zorg ervoor dat de gateway voldoende prestaties heeft om de huidige belasting te verwerken en kan worden geschaald om te voldoen aan uw verwachte groei.

  • Voer belastingstests uit op de gateway om ervoor te zorgen dat u geen trapsgewijze fouten voor services introduceert.

  • Implementeer een veerkrachtig ontwerp door gebruik te maken van technieken zoals bulkheads, circuit breaking, opnieuw proberen en time-outs.

  • Als een of meer serviceaanroepen te lang duren, kan het acceptabel zijn om een time-out uit te voeren en een gedeeltelijke set gegevens te retourneren. Bekijk hoe uw toepassing met dit scenario omgaat.

  • Gebruik asynchrone invoer en uitvoer (I/O) om ervoor te zorgen dat een vertraging aan de back-end geen prestatieproblemen in de toepassing veroorzaakt.

  • Implementeer gedistribueerde tracering met behulp van correlatie-id's om elke afzonderlijke aanroep bij te houden.

  • Controleer aanvraaggegevens en de grootte van reacties.

  • Overweeg het retourneren van gegevens in de cache als failoverstrategie voor het afhandelen van fouten.

  • In plaats van aggregatie in de gateway te bouwen, kunt u overwegen om een aggregatieservice achter de gateway te plaatsen. Aggregatie van aanvragen heeft waarschijnlijk andere resourcevereisten dan andere services in de gateway en kan van invloed zijn op de routerings- en offloadfunctionaliteit van de gateway.

Wanneer gebruikt u dit patroon?

Gebruik dit patroon wanneer:

  • Een client moet communiceren met meerdere back-endservices om een bewerking uit te voeren.

  • De client kan netwerken met een aanzienlijke latentie gebruiken, zoals mobiele netwerken.

Dit patroon is mogelijk niet geschikt wanneer:

  • U wilt het aantal aanroepen tussen een client en één service over meerdere bewerkingen heen verminderen. In dat scenario is het toevoegen van een batchbewerking aan de service mogelijk geschikter.

  • De client of toepassing bevindt zich in de buurt van de back-endservices en latentie is geen belangrijke factor.

Ontwerp van werkbelasting

Evalueer hoe u het Gateway Aggregation-patroon kunt gebruiken bij het ontwerpen van een workload om tegemoet te komen aan de doelstellingen en principes die aan bod komen in de pijlers van het Azure Well-Architected Framework. De volgende tabel bevat richtlijnen over hoe dit patroon de doelstellingen van elke pijler ondersteunt.

Pijler Hoe dit patroon ondersteuning biedt voor pijlerdoelen
betrouwbaarheid ontwerpbeslissingen helpen uw workload tolerant te worden defect te raken en ervoor te zorgen dat deze herstelt naar een volledig functionerende status nadat er een storing is opgetreden. Met deze topologie kunt u tijdelijke foutafhandeling verschuiven van een gedistribueerde implementatie tussen clients naar een gecentraliseerde implementatie.

- Aanbevelingen voor het afhandelen van tijdelijke fouten
Beslissingen over beveiligingsontwerpen helpen de vertrouwelijkheid, integriteit en beschikbaarheid van de gegevens en systemen van uw workload te waarborgen. Deze topologie vermindert vaak het aantal aanraakpunten dat een client heeft met een systeem, wat het openbare oppervlak en de verificatiepunten vermindert. De geaggregeerde backends kunnen volledig netwerkgeïsoleerd blijven van clientsystemen.

- SE:04 Segmentatie
- SE:08 Harden resources
Operational Excellence helpt bij het leveren van workloadkwaliteit via gestandaardiseerde processen en teamcohesie. Met dit patroon kunnen back-endlogica onafhankelijk van clients worden ontwikkeld. Deze ontkoppeling biedt u de flexibiliteit om de gekoppelde service-implementaties of zelfs gegevensbronnen te wijzigen, zonder dat u client-touchpoints hoeft te wijzigen.

- OE:04 Tools en processen
Prestatie-efficiëntie helpt uw workload efficiënt te voldoen aan de vereisten door middel van optimalisaties in schalen, gegevens en code. Dit ontwerp kan minder latentie veroorzaken dan een ontwerp waarin de client meerdere verbindingen tot stand brengt. Cacheopslag in aggregatie-implementaties beperkt het aantal aanroepen naar back-endsystemen.

- PE:03 Services selecteren
- PE:08 Gegevensprestaties

Als dit patroon compromissen binnen een pijler introduceert, moet u deze tegen de doelstellingen van de andere pijlers overwegen.

Example

Overweeg een toepassing op basis van microservices die een overzichtservaring voor een klant biedt. Wanneer een gebruiker een orderpagina opent, moet de toepassing gegevens ophalen uit meerdere back-endservices, zoals een orderservice, een verzendingsservice en een klantenserviceservice.

In een microservicesarchitectuur worden deze services onafhankelijk geïmplementeerd en uitgerold. Zonder aggregatie moet de client elke service rechtstreeks aanroepen, wat de latentie en complexiteit verhoogt.

Om dit probleem op te lossen, gebruikt de toepassing Azure API Management als de aggregatielaag van de gateway. De client verzendt één aanvraag naar een API Management-bewerking die fungeert als collector voor ordergegevens. API Management roept vervolgens de ondersteunende back-end-API's aan en retourneert een geïntegreerd antwoord op de client.

U kunt deze lichtgewicht samenstelling implementeren met behulp van het beleid voor verzendaanvragen van API Management om gegevens op te halen uit meerdere services en een gecombineerde reactie te maken. In dit voorbeeld worden de back-endservices uitgevoerd in een Azure Container Apps-omgeving en implementeert u elke back-endservice als een container-app die verborgen blijft voor directe clienttoegang.

Diagram met een clientaanvraag die via API Management stroomt naar de services voor order-, verzendings- en klantprofielen in een app-omgeving.

Een Visio-bestand van deze architectuur downloaden.

De aanvraagstroom volgt deze stappen:

  1. De client verzendt een aanvraag naar een eindpunt voor een orderoverzicht dat beschikbaar wordt gemaakt via API Management.

  2. API Management past een beleid toe waarmee de order-, verzendings- en klantprofielgegevens van de back-endservices worden verzameld.

  3. API Management voegt de antwoorden van de back-end samen tot één payload met een samenvatting van de bestelling.

  4. API Management retourneert het geaggregeerde antwoord op de client.

Door deze aggregatielaag te introduceren, vermindert de oplossing retouren van client-naar-service en vereenvoudigt de interactie tussen clients. Deze laag wordt daarmee verantwoordelijk voor het op een robuuste manier afhandelen van niet-reagerende back-endservices en het voorkomen dat storingen zich verspreiden door het geaggregeerde antwoord. Behard uw API Management-beleid met behulp van time-outs per aanvraag, voorwaardelijke foutafhandeling en circuitonderbrekers.

Als een van de back-endaanroepen een time-out krijgt of een fout retourneert, kan API Management het gedrag toepassen dat het best bij de bewerking past. Het kan bijvoorbeeld een gedeeltelijk antwoord retourneren wanneer ontbrekende gegevens acceptabel zijn, of het kan mislukken van de hele aanvraag wanneer volledige en consistente ordergegevens vereist zijn. Maak deze beslissing expliciet in het beleidsontwerp, zodat clients voorspelbaar gedrag ervaren.

Deze benadering werkt goed wanneer de gateway eenvoudige compositie, gegevensvorming en antwoordsamenstelling uitvoert. Als voor de aggregatie aangepaste domeinlogica, complexe transformaties of langer lopende indeling is vereist, plaatst u die functionaliteit in een toegewezen aangepaste service achter de gateway.

Verzamel voor bewaking telemetrie over het volledige aanvraagpad, zodat u het gedrag van API Management kunt correleren met back-endlatentie. Deze zichtbaarheid is belangrijk in een gatewayaggregatiepatroon, omdat één clientbewerking afhankelijk is van meerdere back-endaanroepen en fouten of trage reacties in elke afhankelijkheid van invloed kunnen zijn op het uiteindelijke geaggregeerde resultaat. Gebruik Azure Monitor als centraal waarneembaarheidsplatform. Verzamel API Management-logboeken en metrische gegevens voor het gateway- en beleidsuitvoeringspad en schakel bewaking voor Container Apps in om toepassingslogboeken en metrische gegevens van de back-endcontainer-apps vast te leggen. Routeer API Management en back-endtelemetrie naar een Log Analytics werkruimte voor geïntegreerde query's, waarschuwingen en probleemoplossing. Met deze telemetrie kunt u time-outpatronen detecteren, bepalen welke back-endafhankelijkheid een gedeeltelijk of mislukt antwoord heeft veroorzaakt en waarschuwingen maken voor verhoogde latentie of foutpercentages.

Volgende stappen 

  • Last updated on