Claim-Check patroon

  • Artikel
  • 6 minuten om te lezen

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

Dit patroon staat ook wel bekend als Reference-Based Messaging en werd oorspronkelijk beschreven in het boek Bedrijfsintegratie Patterns, door Gregor Hohpe enSchrijftSchrevenf.

Context en probleem

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

Het rechtstreeks verzenden van dergelijke grote berichten naar de berichtenbus wordt niet aanbevolen, omdat er meer resources en bandbreedte moeten 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 voor grote berichten omdraaien.

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 die verwijzing naar de berichtenbus. De verwijzing fungeert als een claimcontrole die wordt gebruikt om een stuk te halen, vandaar de naam van het patroon. Clients die geïnteresseerd zijn in het verwerken van dat specifieke bericht, kunnen de verkregen referentie gebruiken om de nettolading op te halen, indien nodig.

Diagram van het Claim-Check patroon

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 verbruikt, als u de berichten niet hoeft te archiveren. Hoewel blob-opslag relatief goedkoop is, kost het op de lange termijn wel wat geld, 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 implementeren in de verzendende toepassing om dit patroon alleen te gebruiken wanneer de berichtgrootte de gegevenslimiet van de berichtenbus overschrijdt. Het patroon wordt overgeslagen voor kleinere berichten. Deze aanpak zou resulteren in een voorwaardelijk claimcontrolepatroon.

Wanneer dit patroon gebruiken

Dit patroon moet worden gebruikt wanneer een bericht niet aan de ondersteunde berichtlimiet van de gekozen berichtbustechnologie kan komen. Zo heeft Event Hubs momenteel een limiet van 256 kB (Basic-laag), terwijl Event Grid alleen berichten van 64 kB ondersteunt.

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

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 claimcontrolegeneratie. Bij deze benadering wordt Azure Event Grid claimcontrole automatisch te genereren en naar de berichtenbus te pushen.

  • Handmatige claimcontrole genereren. 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 de claimcontrole op of genereert deze en verzendt de claimcontrole naar de berichtenbus.

Event Grid is een service voor gebeurtenisroutering en probeert gebeurtenissen te leveren binnen een configureerbare hoeveelheid tijd tot 24 uur. Daarna worden gebeurtenissen verwijderd of in een impasse geraakt. 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 het archiveren van berichten wordt ondersteund. Zie Dead letter and retry policies(Beleid voor dead letter en beleid voor opnieuw proberen) voor meer informatie over het afstemmen van Event Grid en het opnieuw leveren en opnieuw proberen van berichten, en over het configureren van niet-bezorgde berichten.

Automatisch claimcontrole genereren met Blob Storage en Event Grid

Bij deze methode zet de afzender de nettolading van het bericht neer in een aangewezen Azure Blob Storage container. 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 ontvangen en vervolgens de opgeslagen referentiegegevens gebruiken om de nettolading rechtstreeks vanuit blob-Storage.

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

U vindt hier voorbeeldcode voor deze methode.

Event Grid met Event Hubs

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

U vindt hier voorbeeldcode voor deze methode.

Claimcontrole genereren met Service Bus

Deze oplossing maakt gebruik van een specifieke Service Bus-invoegprogramma, ServiceBus.AttachmentPlugin,waardoor de claimcontrolewerkstroom eenvoudig kan worden geïmplementeerd. De invoeg voor het omzetten van een bericht in 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 fungeert als een meldingswachtrij waarop een client zich kan abonneren. Wanneer de consument het bericht ontvangt, maakt de invoegapp het mogelijk om de berichtgegevens rechtstreeks te lezen uit blob-Storage. Vervolgens kunt u kiezen hoe u het bericht verder wilt verwerken. Een voordeel van deze benadering is dat de werkstroom voor claimcontrole wordt geabstraheerd van de afzender en ontvanger.

U vindt hier voorbeeldcode voor deze methode.

Handmatig claimcontrole genereren met Kafka

In dit voorbeeld schrijft een Kafka-client de nettolading naar Azure Blob Storage. Vervolgens wordt een meldingsbericht met kafka ingeschakeld Event Hubs. De consument ontvangt het bericht en heeft toegang tot de nettolading van Blob Storage. In dit voorbeeld ziet u hoe u een ander berichtenprotocol kunt gebruiken om het claimcontrolepatroon in Azure te implementeren. Mogelijk moet u bijvoorbeeld bestaande Kafka-clients ondersteunen.

U vindt hier voorbeeldcode voor deze methode.

Volgende stappen