Claim-Check patroon

Event Grid
Blob Storage

Splits een groot bericht in een claimcontrole en een nettolading. Verzend de claimcontrole naar het berichtenplatform en sla de nettolading op naar een externe service. Met dit patroon kunnen grote berichten worden verwerkt, terwijl de berichtenbus en de client niet worden overweldigd of vertraagd. Dit patroon helpt ook om de kosten te verlagen, omdat opslag meestal goedkoper is dan resource-eenheden die door het berichtenplatform worden gebruikt.

Dit patroon wordt ook wel Reference-Based Messaging genoemd en is oorspronkelijk beschreven in het boek Enterprise Integration Patterns, door Gregor Hohpe en Bobby Woolf.

Context en probleem

Een architectuur op basis van berichten moet op een bepaald moment grote berichten kunnen verzenden, ontvangen en bewerken. Dergelijke berichten kunnen alles bevatten, waaronder afbeeldingen (bijvoorbeeld MRI-scans), geluidsbestanden (bijvoorbeeld callcenter-oproepen), tekstdocumenten of willekeurige binaire gegevens.

Het rechtstreeks verzenden van dergelijke grote berichten naar de berichtenbus wordt niet aanbevolen, omdat er meer resources en bandbreedte nodig zijn om te worden verbruikt. Grote berichten kunnen ook de hele oplossing vertragen, omdat berichtenplatforms meestal zijn afgestemd op het verwerken van grote hoeveelheden kleine berichten. De meeste berichtenplatforms hebben ook limieten voor de berichtgrootte, dus mogelijk moet u deze limieten omzeilen voor grote berichten.

Oplossing

Sla de volledige nettolading van het bericht op in een externe service, zoals een database. Haal de verwijzing naar de opgeslagen nettolading op en verzend alleen die verwijzing naar de berichtenbus. De verwijzing fungeert als een claimcontrole die wordt gebruikt om een stuk bagage op te halen, vandaar de naam van het patroon. Klanten die geïnteresseerd zijn in het verwerken van dat specifieke bericht, kunnen de verkregen verwijzing gebruiken om de nettolading op te halen, indien nodig.

Diagram of the Claim-Check pattern

Problemen en overwegingen

Beschouw de volgende punten als u besluit hoe u dit patroon wilt implementeren:

  • Overweeg de berichtgegevens te verwijderen nadat u deze hebt gebruikt, als u de berichten niet hoeft te archiveren. Hoewel blobopslag relatief goedkoop is, kost het wat geld op de lange termijn, vooral als er veel gegevens zijn. Het verwijderen van het bericht kan synchroon worden uitgevoerd door de toepassing die het bericht ontvangt en verwerkt, of asynchroon door een afzonderlijk toegewezen proces. Met de asynchrone benadering worden oude gegevens verwijderd zonder dat dit van invloed is op de doorvoer- en berichtverwerkingsprestaties van de ontvangende toepassing.

  • Het opslaan en ophalen van het bericht veroorzaakt extra overhead en latentie. Mogelijk wilt u logica in de verzendende toepassing implementeren om dit patroon alleen te gebruiken wanneer de berichtgrootte de gegevenslimiet van de berichtenbus overschrijdt. Het patroon wordt overgeslagen voor kleinere berichten. Deze benadering zou resulteren in een patroon voor voorwaardelijke claimcontrole.

Wanneer dit patroon gebruiken

Dit patroon kan worden gebruikt wanneer een bericht niet past bij de ondersteunde berichtlimiet van de gekozen berichtbustechnologie. Service Bus momenteel bijvoorbeeld een limiet van 100 MB (Premium-laag) heeft, terwijl Event Grid maximaal 1 MB-berichten ondersteunt.

Het patroon kan ook worden gebruikt als de nettolading alleen moet worden geopend door services die zijn gemachtigd om deze te zien. Door de nettolading te offloaden naar een externe resource, kunnen strengere verificatie- en autorisatieregels worden geïmplementeerd om ervoor te zorgen dat beveiliging wordt afgedwongen wanneer gevoelige gegevens worden opgeslagen in de nettolading.

Voorbeelden

In Azure kan dit patroon op verschillende manieren en met verschillende technologieën worden geïmplementeerd, maar er zijn twee hoofdcategorieën. In beide gevallen heeft de ontvanger de verantwoordelijkheid om de claimcontrole te lezen en te gebruiken om de nettolading op te halen.

  • Automatische generatie claimcontrole. Deze methode maakt gebruik van Azure Event Grid om de claimcontrole automatisch te genereren en deze naar de berichtenbus te pushen.

  • Handmatige generatie claimcontrole. In deze benadering is de afzender verantwoordelijk voor het beheren van de nettolading. De afzender slaat de nettolading op met behulp van de juiste service, haalt of genereert de claimcontrole en verzendt de claimcontrole naar de berichtenbus.

Event Grid is een service voor gebeurtenisroutering en probeert gebeurtenissen binnen een configureerbare hoeveelheid tijd tot 24 uur te leveren. Daarna worden gebeurtenissen verwijderd of niet-geschreven. Als u de nettoladingen van gebeurtenissen wilt archiveren of de gebeurtenisstroom opnieuw wilt afspelen, kunt u een Event Grid-abonnement toevoegen aan Event Hubs of Queue Storage, waar berichten gedurende langere perioden kunnen worden bewaard en berichten kunnen worden gearchiveerd. Zie De beleidsregels Dead letter en retry(s) voor meer informatie over het afstemmen van de bezorging van Event Grid-berichten en het opnieuw proberen en het configureren van een dode letter.

Automatische generatie van claimcontrole met Blob-Storage en Event Grid

In deze benadering wordt de nettolading van het bericht door de afzender in een aangewezen Azure Blob Storage container verwijderd. Event Grid genereert automatisch een tag/verwijzing en verzendt deze naar een ondersteunde berichtenbus, zoals Azure Storage Wachtrijen. De ontvanger kan de wachtrij peilen, het bericht ophalen en vervolgens de opgeslagen referentiegegevens gebruiken om de nettolading rechtstreeks vanuit blob-Storage te downloaden.

Hetzelfde Event Grid-bericht kan rechtstreeks worden gebruikt door Azure Functions, zonder dat u een berichtenbus hoeft te doorlopen. Deze aanpak maakt optimaal gebruik van de serverloze aard van zowel Event Grid als Functions.

Hier vindt u voorbeeldcode voor deze benadering.

Event Grid met Event Hubs

Net als in het vorige voorbeeld genereert Event Grid automatisch een bericht wanneer een nettolading naar een Azure Blob-container wordt geschreven. In dit voorbeeld wordt de berichtenbus echter geïmplementeerd met behulp van Event Hubs. Een client kan zich registreren om de stroom berichten te ontvangen terwijl ze naar de Event Hub worden geschreven. De Event Hub kan ook worden geconfigureerd voor het archiveren van berichten, waardoor ze beschikbaar worden gesteld als een Avro-bestand dat kan worden opgevraagd met behulp van hulpprogramma's zoals Apache Spark, Apache Drill of een van de beschikbare Avro-bibliotheken.

Hier vindt u voorbeeldcode voor deze benadering.

Claimcontrole genereren met Service Bus

Deze oplossing maakt gebruik van een specifieke Service Bus-invoegtoepassing, ServiceBus.AttachmentPlugin, waardoor de claimcontrolewerkstroom eenvoudig te implementeren is. De invoegtoepassing converteert een berichttekst naar een bijlage die wordt opgeslagen in Azure Blob Storage wanneer het bericht wordt verzonden.

using ServiceBus.AttachmentPlugin;
...

// Getting connection information
var serviceBusConnectionString = Environment.GetEnvironmentVariable("SERVICE_BUS_CONNECTION_STRING");
var queueName = Environment.GetEnvironmentVariable("QUEUE_NAME");
var storageConnectionString = Environment.GetEnvironmentVariable("STORAGE_CONNECTION_STRING");

// Creating config for sending message
var config = new AzureStorageAttachmentConfiguration(storageConnectionString);

// Creating and registering the sender using Service Bus Connection String and Queue Name
var sender = new MessageSender(serviceBusConnectionString, queueName);
sender.RegisterAzureStorageAttachmentPlugin(config);

// Create payload
var payload = new { data = "random data string for testing" };
var serialized = JsonConvert.SerializeObject(payload);
var payloadAsBytes = Encoding.UTF8.GetBytes(serialized);
var message = new Message(payloadAsBytes);

// Send the message
await sender.SendAsync(message);

Het Service Bus bericht fungeert als een meldingswachtrij waarop een client zich kan abonneren. Wanneer de consument het bericht ontvangt, maakt de invoegtoepassing het mogelijk om de berichtgegevens van blob-Storage rechtstreeks te lezen. Vervolgens kunt u kiezen hoe u het bericht verder wilt verwerken. Een voordeel van deze benadering is dat de werkstroom claimcontrole wordt geabstraheerd van de afzender en ontvanger.

Hier vindt u voorbeeldcode voor deze benadering.

Handmatige generatie van claimcontrole met Kafka

In dit voorbeeld schrijft een Kafka-client de nettolading naar Azure Blob Storage. Vervolgens wordt een meldingsbericht verzonden met behulp van Event Hubs met Kafka-functionaliteit. De consument ontvangt het bericht en heeft toegang tot de nettolading van blob-Storage. In dit voorbeeld ziet u hoe een ander berichtenprotocol kan worden gebruikt om het claimcontrolepatroon in Azure te implementeren. U moet bijvoorbeeld bestaande Kafka-clients ondersteunen.

Hier vindt u voorbeeldcode voor deze benadering.

Volgende stappen

  • Een alternatief patroon voor het verwerken van grote berichten is Splitsen en Aggregeren.