Mönster för anspråkskontroll

Lagra en stor meddelandenyttolast i ett externt datalager och skicka endast en referens till den lagrade nyttolasten via meddelandesystemet. Mottagande applikationer visar upp referenstoken, kallad en claim check, för att hämta den stora datanyttolasten när de behöver bearbeta den. Detta tillvägagångssätt gör det möjligt för arbetslaster att överföra stora datanyttolaster utan att lagra dem i meddelandesystemet.

Kontext och problem

Traditionella meddelandesystem är optimerade för att hantera en stor mängd små meddelanden och begränsar ofta den meddelandestorlek som de kan hantera. Stora meddelanden riskerar inte bara att överskrida storleksgränserna, utan kan också försämra systemets prestanda när meddelandesystemet lagrar dem.

Följande begränsningar gör intern nyttolastöverföring via meddelandesystemet otillräcklig:

• Avvisning på grund av storleksgräns. Meddelandesystem avvisar meddelanden som överskrider ett konfigurerat maximum.

• Mäklarens resursbelastning. Att lagra stora nyttolaster i meddelandeförmedlaren förbrukar oproportionerligt mycket minne och diskutrymme jämfört med den metadata som meddelandeförmedlaren behöver för att vidarebefordra och leverera meddelandet. Den här förbrukningen konkurrerar med nödvändiga resurser för andra meddelanden i systemet.

• Dataflödesförsämring. Större meddelanden ökar serialisering, överföring och deserialiseringstid per åtgärd.

• Kostnadseskalering. Vissa meddelandesystem debiteras efter meddelandestorlek, nivå eller kapacitetsenhet. Överföring av stora nyttolaster infogade kan skicka arbetsbelastningar till högre kostnadsnivåer eller kapacitetsallokeringar.

Lösning

Mönstret Claim Check separerar lagring av nyttolast från meddelandeleverans. Ett sändande program skriver den fullständiga nyttolasten till ett externt datalager och skickar en referens till nyttolasten via meddelandesystemet. Meddelandesystemet ser eller lagrar aldrig nyttolasten. Mottagande program använder referensen för att hämta nyttolasten direkt från datalagret. Referensen är en identifierare som det mottagande programmet måste matcha.

Mönstret följer den här sekvensen:

1. Det sändande programmet genererar nyttolasten.
2. Det sändande programmet sparar nyttolasten i det externa datalagret.
3. När sparande har slutförts genererar det sändande programmet en referens till den lagrade nyttolasten och publicerar den till meddelandesystemet som ett anspråkskontrollmeddelande.
4. En mottagande applikation hämtar meddelandet och läser anspråkskontrolltoken.
5. Det mottagande programmet använder token för att hämta nyttolasten från datalagret.
6. Det mottagande programmet bearbetar nyttolasten.

Meddelandesystemet hanterar endast det lilla claim check-meddelandet, vilket gör att meddelandet inte avvisas på grund av storleken och att man slipper använda resurser för att överföra och lagra stora meddelandenyttolaster. Det externa datalagret tillämpar åtkomstkontroller och livscykelprinciper på nyttolasten oberoende av meddelandesystemet.

Problem och överväganden

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

• Ägarskap för nyttolastens livscykel. Definiera vilken komponent som äger nyttolastborttagning och hur komponenten avgör att nyttolasten inte behövs. Samordna meddelandets utgångstid och lagringstiden för nyttolasten så att en giltig claim check inte pekar på raderade data.

• Villkorsstyrd app. Bestäm om du vill göra alla anspråkskontroller för meddelanden eller fatta beslut om anspråkskontroll per meddelande. Om det är villkorligt, säkerställ att schemat definierar om nyttolasten är inbäddad eller extern.

• Token- och butikssäkerhet. Bädda inte in säkerhetstoken som en del av anspråkskontrollen. Lämna auktorisering som en oberoende interaktion mellan producent- eller konsumentsystem och datalagret. Om din lösning kräver att konsumenter uttryckligen beviljas tillfällig åtkomst använder du mönstret Valet Key i stället.

• Payload- och tokenkonsistens. Nyttolastskrivning och tokenpublicering sker i separata system och finns inte i en atomisk transaktion. Ett fel efter nyttolastskrivning men innan tokenpublicering kan lämna en överbliven nyttolast. En token som publicerats innan nyttolasten kan hämtas kan innebära att användarna får referenser som de inte kan matcha. Publicera token först när nyttolastskrivningen har slutförts. Eftersom återförsök kan leverera samma claim check mer än en gång bör du använda Idempotent Consumer-mönstret för att hantera dubbletter på ett säkert sätt.

• Nyttolastintegritet. När konsumenter måste verifiera nyttolastintegriteten ska du inkludera en innehållshash eller digital signatur i meddelandet. Definiera ett protokoll för avvikelser, till exempel att avvisa nyttolasten, göra ett nytt hämtningsförsök eller skicka meddelandet för utredning.

• Nyttolasttillgänglighet och hållbarhet. Det externa datalagret måste vara tillgängligt och beständigt under hela den tid som de mottagande programmen behöver för att hämta en nyttolast. Om lagringsplatsen drabbas av ett avbrott eller dataförlust kan konsumenter som har giltiga tokenar inte hämta sin nyttolast, och deras meddelandebearbetning stannar upp.

• Hämtningshoppslatens. Mönstret lägger till extra nätverksresor jämfört med intern meddelandeleverans. Mottagande program måste anropa det externa datalagret för att hämta nyttolasten innan bearbetningen kan börja.

• Stöd för ramverksbaserad anspråkskontroll. Använd de funktioner som meddelandebussens SDK erbjuder. NServiceBus har till exempel en DataBus-funktion som kan automatisera nyttolastlagring och hämtning.

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

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

• Meddelandenyttolaster överskrider regelbundet den maximala meddelandestorlek som meddelandesystemet stöder. Genom att lagra nyttolasten i ett externt datalager och endast skicka en lätt claim check-token undviker du avvisningar på grund av storleksgränser.

• Stora meddelanden förbrukar oproportionerligt mycket brokerresurser. Stora meddelanden påverkar meddelandesystemets prestanda genom att öka serialiseringen och överföringstiden eller genom att försämra dataflödet för alla producenter och konsumenter som delar meddelandesystemet.

• Nyttolaster innehåller känslig information som inte ska vara synlig för meddelandesystemet eller för mellanliggande komponenter, till exempel verktyg för köövervakning. Använd mönstret på hela nyttolasten eller bara på dess känsliga delar. Lagra känsligt innehåll i ett skyddat datalager med dedikerade åtkomstkontroller för att hålla det borta från meddelandesökvägen.

• Meddelanden har komplex routning med upprepad serialisering. Meddelanden passerar flera routningskomponenter som utför serialisering, deserialisering, kryptering eller dekryptering. Överför endast en liten token via mellanhänder för att eliminera upprepad bearbetning av den fullständiga nyttolasten vid varje hopp och minska den kumulativa svarstiden.

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

• Svarstidskänsligheten väger tyngre än problem med nyttolaststorlek. Arbetsbelastningar som kräver lägsta möjliga svarstid från slutpunkt till slutpunkt mellan producent och konsument kanske inte tolererar de tillagda nätverkshoppen för nyttolastlagring och hämtning. Om meddelanden kan levereras infogat utan att överskrida storleks- eller prestandagränserna är direktleverans enklare och snabbare.

• Du kan välja en transport eller nivå som stöder nyttolaststorleken. När nyttolaster håller sig inom den gräns som transporten stöder och inte orsakar oacceptabel genomströmning eller latens, skicka dem direkt i meddelandet för att undvika beroendet av extern lagring. Till exempel stöder Azure Service Bus Premium-nivån AMQP-meddelanden (Advanced Message Queuing Protocol) upp till 100 MB. Håll meddelanden så små som möjligt eftersom stora meddelanden minskar dataflödet och ökar svarstiden.

• Samordning mellan två system är inte möjlig. Mönstret kräver samordning mellan två oberoende system. Anspråkskontrollvärdet måste skrivas på ett sätt som det mottagande systemet kan förstå, och dess format kan behöva justeras över tid.

Alternatives

Tänk på dessa metoder som alternativ till det här mönstret:

• Minska inline-nyttolaststorleken. Komprimering kan minska repetitiv text eller binära nyttolaster, och en mer kompakt serialiserare kan minska meddelandekostnaderna. Välj den här metoden när den minskade nyttolasten passar bekvämt inom transportgränsen och varje producent och konsument kan använda samma komprimerings- och serialiseringsformat.

• Dela upp och sammanfoga nyttolasten på ett naturligt sätt. Dela upp en stor nyttolast i en sekvens med mindre meddelanden när konsumenter kan bearbeta segment oberoende av varandra eller sätta ihop dem igen efter leveransen. Den här metoden behåller data i meddelandesystemet, men lägger till krav på sekvensering, korrelation, duplicerad hantering och ommontering. Mer information finns i Splitter- och Aggregator-mönstren från Enterprise Integration Patterns.

Design av arbetsbelastning

Utvärdera hur Claim Check-mönstret används i utformningen av en arbetsbelastning för att uppfylla de mål och principer som tas upp 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 pelarna.

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

Examples

Det här avsnittet länkar till GitHub exempel på anspråkskontroll i molnet som visar hur Azure tjänster implementerar mönstret För anspråkskontroll. Varje exempel använder Azure Blob Storage som externt datalager och parkopplar det med ett annat Azure meddelandesystem. Exempel 1 till och med 3 använder blob-URL:en i ett Azure Event Grid-meddelande som anspråkskontroll. Exempel 4 använder en anpassad anspråkskontroll som det sändande programmet publicerar.

I exempel 1 till 3:

1. Ett sändande program laddar upp en stor nyttolast till Blob Storage.
2. Uppladdningen utlöser en Microsoft.Storage.BlobCreated händelse via ett Event Grid-systemämne.
3. Event Grid dirigerar meddelandet, som innehåller en direkt blob-URL som exemplen använder som anspråkskontroll, till det konfigurerade meddelandesystemet.
4. Ett mottagande program, implementerat som en Azure Functions funktionsapp eller kommandoradsklient, hämtar meddelandet, extraherar blob-URL:en och laddar ned nyttolasten direkt från Blob Storage för bearbetning.

I en produktionsimplementering filtrerar du händelseprenumerationen efter åtgärder som anger en fullständigt bekräftad blockblob och utformar mottagaren för att hantera fördröjda, duplicerade och out-of-order-händelser.

Exempel 4 använder en annan metod. I stället för att dirigera ett Blob Storage meddelande via Event Grid skapar det sändande programmet anspråkskontrollen efter att nyttolasten har laddats upp till Blob Storage. Det sändande programmet publicerar sedan anspråkskontrollen till Azure Event Hubs Kafka-slutpunkten med hjälp av Apache Kafka-protokollet. Den här metoden passar miljöer som redan använder Kafka-kompatibla producenter eller kräver anpassade tokenformat.

I följande tabell visas varje exempel med dess meddelandesystem, anspråkskontrollutgivare, mottagande program och lagringsberoenden. Välj varje länk för att visa exempelkoden på GitHub.

Nästa steg

• Läs beskrivningen av kanoniska företagsintegreringsmönster för anspråkskontroll.
• Granska en annan implementering i Hantera stora Service Bus-meddelanden med claim check-mönstret.
• Välj mellan Azure Event Grid, Event Hubs och Service Bus.

Relaterade resurser

• Asynkront Request-Reply mönster
• Mönster för konkurrerande konsumenter
• Sekventiell konvojmönster
• Valet-nyckelmönster