Patroon Claimcontrole

Sla een grote nettolading van berichten op in een extern gegevensarchief en verzend alleen een verwijzing naar de opgeslagen nettolading via het berichtensysteem. Ontvangende toepassingen geven het referentietoken, een claim check genoemd, door om de grote payload op te halen wanneer ze die moeten verwerken. Met deze aanpak kunnen workloads grote hoeveelheden gegevens verplaatsen zonder deze op te slaan in het berichtensysteem.

Context en probleem

Traditionele berichtensystemen zijn geoptimaliseerd voor het beheren van een groot aantal kleine berichten en beperken vaak de berichtgrootte die ze kunnen verwerken. Grote berichten lopen niet alleen risico's die de groottelimieten overschrijden, maar kunnen ook de systeemprestaties verminderen wanneer het berichtensysteem ze opslaat.

De volgende beperkingen zorgen ervoor dat inline payload-verzending via het berichtensysteem onvoldoende is:

• Afwijzing van groottelimiet. Berichtensystemen weigeren berichten die een geconfigureerd maximum overschrijden.

• Druk van brokerresources. Het opslaan van grote nettoladingen in de broker verbruikt onevenredig geheugen en schijf in vergelijking met de metagegevens die de broker nodig heeft om het bericht te routeren en af te leveren. Dit verbruik concurreert met de benodigde resources voor andere berichten in het systeem.

• Doorvoerdegradatie. Grotere berichten vergroten de serialisatie, overdracht en deserialisatietijd per bewerking.

• Escalatie van kosten. Sommige berichtensystemen brengen kosten in rekening per berichtgrootte, laag of capaciteitseenheid. Door grote payloads inline te verzenden, kunnen workloads in duurdere prijslagen of capaciteitstoewijzingen terechtkomen.

Solution

Het Claim Check-patroon scheidt de payloadopslag van de berichtaflevering. Een verzendende toepassing schrijft de volledige nettolading naar een extern gegevensarchief en verzendt een verwijzing naar die nettolading via het berichtensysteem. Het berichtensysteem ziet of slaat de payload nooit op. Ontvangende toepassingen gebruiken de referentie om de payload rechtstreeks uit de dataopslag op te halen. De verwijzing is een id die de ontvangende toepassing moet oplossen.

Het patroon volgt deze reeks:

1. De verzendende toepassing genereert de nettolading.
2. De verzendtoepassing slaat de payload op in de externe gegevensopslag.
3. Nadat het opslaan is voltooid, genereert de verzendende toepassing een verwijzing naar de opgeslagen nettolading en publiceert deze als een claimcontrolebericht naar het berichtensysteem.
4. Een ontvangende toepassing haalt het bericht op en leest het claimcontroletoken.
5. De ontvangende toepassing gebruikt het token om de payload op te halen uit de gegevensopslag.
6. De ontvangende applicatie verwerkt de payload.

Het berichtensysteem verwerkt alleen het kleine claim-checkbericht, waardoor afwijzing wegens een te grote berichtomvang wordt voorkomen en er geen middelen nodig zijn om grote berichtpayloads over te dragen en op te slaan. De externe gegevensopslag past toegangscontroles en levenscyclusbeleid toe op de payload, los van het berichtensysteem.

Problemen en overwegingen

Houd rekening met de volgende punten bij het bepalen hoe u dit patroon implementeert:

• Eigenaarschap van de levenscyclus van de payload. Definieer welk onderdeel eigenaar is van het verwijderen van nettoladingen en hoe het onderdeel bepaalt dat de nettolading niet nodig is. Coördineer de verlooptijd van berichten en de nettolading, zodat een geldige claimcontrole niet verwijst naar verwijderde gegevens.

• Voorwaardelijke toepassing. Bepaal of alle berichten claimcontroles moeten worden uitgevoerd of dat de beslissing voor claimcontrole per bericht moet worden genomen. Als het conditioneel is, zorg er dan voor dat het schema definieert of de payload inline of extern is.

• Token- en opslagbeveiliging. Sluit geen beveiligingstokens in als onderdeel van de claimcontrole. Beschouw autorisatie als een onafhankelijke interactie tussen producer- of consumersystemen en de gegevensopslag. Als voor uw oplossing gebruikers expliciet tijdelijke toegang moeten worden verleend, gebruikt u in plaats daarvan het patroon ValetSleutel .

• Consistentie tussen payload en token. Het schrijven van de payload en de publicatie van het token vinden plaats in afzonderlijke systemen en maken geen deel uit van dezelfde atomische transactie. Een fout na het schrijven van de payload, maar vóór de publicatie van de token, kan een payload als wees achterlaten. Een token dat is gepubliceerd voordat de nettolading kan worden opgehaald, kan betekenen dat consumenten verwijzingen ontvangen die ze niet kunnen oplossen. Publiceer de token pas nadat het schrijven van de payload is geslaagd. Omdat bij opnieuw proberen dezelfde claim check meer dan één keer kan worden geleverd, gebruikt u het Idempotent Consumer-pattern om duplicaten veilig te verwerken.

• Integriteit van nettolading. Wanneer afnemers de integriteit van de payload moeten verifiëren, neem dan een contenthash of digitale handtekening op in het bericht. Definieer een protocol voor afwijkingen, zoals het payload afwijzen, het ophalen opnieuw proberen of het bericht ter onderzoek doorsturen.

• Beschikbaarheid en duurzaamheid van payload. De externe dataopslag moet gedurende de volledige periode waarin ontvangende toepassingen een payload moeten ophalen, beschikbaar en persistent blijven. Als de opslag een storing of gegevensverlies ondervindt, kunnen consumenten met geldige tokens hun gegevens niet ophalen en valt hun berichtverwerking stil.

• Latentie van een ophaalhop. Het patroon voegt extra netwerkreizen toe in vergelijking met inline berichtbezorging. Ontvangende applicaties moeten de externe gegevensopslag aanroepen om de payload op te halen voordat de verwerking kan beginnen.

• Ondersteuning voor door framework geleverde claimcontrole. Gebruik de mogelijkheden die uw messagebus-SDK biedt. NServiceBus biedt bijvoorbeeld een DataBus-functie waarmee de opslag en het ophalen van payloads kunnen worden geautomatiseerd.

Wanneer gebruikt u dit patroon?

Gebruik dit patroon wanneer:

• Berichtpayloads overschrijden regelmatig de maximale berichtgrootte die door het berichtensysteem wordt ondersteund. Door de payload uit te plaatsen naar een externe dataopslag en alleen een lichtgewicht claim check-token te verzenden, voorkom je afwijzingen vanwege groottelimieten.

• Grote berichten verbruiken onevenredige broker-resources. Grote berichten zijn van invloed op de prestaties van het berichtensysteem door de serialisatie en overdrachtstijd te verhogen of door de doorvoer te verminderen voor alle producenten en consumenten die het berichtensysteem delen.

• Payloads bevatten gevoelige informatie die niet zichtbaar moet zijn voor het berichtensysteem of voor tussenliggende onderdelen, zoals hulpprogramma's voor wachtrijbewaking. Pas het patroon toe op de volledige nettolading of alleen op de gevoelige gedeelten. Sla de gevoelige inhoud op in een beveiligd gegevensarchief met toegewezen toegangsbeheer om deze buiten het berichtenpad te houden.

• Berichten hebben complexe routering met herhaalde serialisatie. Berichten doorlopen meerdere routeringsonderdelen die serialisatie, deserialisatie, versleuteling of ontsleuteling uitvoeren. Verzend slechts een klein token via tussenpersonen om herhaalde verwerking van de volledige nettolading bij elke hop te elimineren en cumulatieve latentie te verminderen.

Dit patroon is mogelijk niet geschikt wanneer:

• Gevoeligheid voor latentie weegt zwaarder dan zorgen over de payloadgrootte. Workloads waarvoor de laagst mogelijke end-to-end latentie tussen producent en consument is vereist, tolereren mogelijk niet de toegevoegde netwerkhops voor nettoladingopslag en -ophaalbewerking. Als berichten inline kunnen worden afgeleverd zonder de grootte of prestatielimieten te overschrijden, is directe levering eenvoudiger en sneller.

• U kunt een transport of niveau kiezen dat de payloadgrootte ondersteunt. Wanneer payloads binnen de door het transport ondersteunde limiet blijven en geen onaanvaardbare doorvoer of latentie veroorzaken, verstuurt u ze inline om afhankelijkheid van externe opslag te voorkomen. Azure Service Bus Premium-laag ondersteunt bijvoorbeeld AMQP-berichten (Advanced Message Queuing Protocol) tot 100 MB. Houd berichten zo klein mogelijk, omdat grote berichten de doorvoer verminderen en latentie verhogen.

• Coördinatie tussen twee systemen is niet mogelijk. Het patroon vereist coördinatie tussen twee onafhankelijke systemen. De waarde van de claimcontrole moet worden geschreven op een manier die het ontvangende systeem begrijpt en de indeling ervan moet mogelijk na verloop van tijd worden aangepast.

Alternatives

Houd rekening met deze benaderingen als alternatieven voor dit patroon:

• Verklein de grootte van de inline-payload. Compressie kan herhaalde tekst of binaire payloads verkleinen, en een compactere serialisator kan de berichtoverhead verminderen. Kies deze benadering wanneer de gereduceerde nettolading comfortabel binnen de transportlimiet past en elke producent en consument dezelfde compressie- en serialisatieindeling kan gebruiken.

• Splits en aggregeer de payload op natuurlijke wijze. Verdeel een grote nettolading in een reeks kleinere berichten wanneer gebruikers segmenten onafhankelijk kunnen verwerken of opnieuw kunnen samenvoegen na de bezorging. Deze benadering bewaart de gegevens in het berichtensysteem, maar voegt sequentiëren, correlatie, dubbele verwerking en opnieuw verzamelen van vereisten toe. Zie de Splitter - en Aggregator-patronen van Enterprise Integration Patterns voor meer informatie.

Ontwerp van werkbelasting

Beoordeel hoe u het Claim Check-patroon in het ontwerp van een workload kunt gebruiken om in te spelen op de doelstellingen en principes van de Azure Well-Architected Framework pillars. De volgende tabel bevat richtlijnen over hoe dit patroon de doelstellingen van de pijlers ondersteunt.

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

Voorbeelden

Deze sectie bevat koppelingen naar GitHub-voorbeelden van het Claim Check-cloudpatroon die laten zien hoe Azure-services het Claim Check-patroon implementeren. In elk voorbeeld wordt Azure Blob Storage gebruikt als het externe gegevensarchief en wordt deze gekoppeld aan een ander Azure berichtensysteem. Voorbeelden 1 tot en met 3 gebruiken de blob-URL in een Azure Event Grid melding als claimcontrole. Voorbeeld 4 maakt gebruik van een aangepaste claimcontrole die door de verzendende toepassing wordt gepubliceerd.

In voorbeelden 1 tot en met 3:

1. Een verzendende toepassing uploadt een grote nettolading naar Blob Storage.
2. Tijdens het uploaden wordt een Microsoft.Storage.BlobCreated gebeurtenis geactiveerd via een Event Grid-systeemonderwerp.
3. Event Grid stuurt de melding, die een directe blob-URL bevat die door de voorbeelden wordt gebruikt als claimcontrole, naar het geconfigureerde berichtensysteem.
4. Een ontvangende toepassing, geïmplementeerd als een Azure Functions functie-app of opdrachtregelclient, haalt de melding op, extraheert de blob-URL en downloadt de nettolading rechtstreeks vanuit Blob Storage voor verwerking.

In een productie-implementatie filtert u het gebeurtenisabonnement op bewerkingen die duiden op een volledig vastgelegde block blob, en ontwerpt u de ontvanger zodanig dat deze vertraagde, dubbele en niet in de juiste volgorde binnenkomende gebeurtenissen kan afhandelen.

Voorbeeld 4 maakt gebruik van een andere benadering. In plaats van een Blob Storage-melding via Event Grid te routeren, stelt de verzendende toepassing de claim check op nadat de payload naar Blob Storage is geüpload. De verzendende toepassing publiceert vervolgens de claimcontrole naar het Azure Event Hubs Kafka-eindpunt met behulp van het Apache Kafka-protocol. Deze aanpak is geschikt voor omgevingen die al Kafka-compatibele producers gebruiken of aangepaste tokenindelingen vereisen.

De volgende tabel bevat elk voorbeeld met het berichtensysteem, claimcontrole-uitgever, ontvangende toepassing en opslagafhankelijkheden. Selecteer elke koppeling om de voorbeeldcode op GitHub weer te geven.

Volgende stappen 

• Lees de canonieke beschrijving van Enterprise Integration Patterns van Claim Check.
• Bekijk een andere implementatie in Omgaan met grote Service Bus berichten met behulp van claimcontrolepatroon.
• Kies tussen Azure Event Grid, Event Hubs en Service Bus.

Gerelateerde bronnen

• Asynchrone Request-Reply-patroon
• Patroon van concurrerende consumenten
• Sequentieel konvooipatroon
• Valet Key patroon