Claim-Check mintaClaim-Check Pattern

Nagy méretű üzenetet oszthat meg egy jogcím-ellenőrzési és egy hasznos adattartalommal.Split a large message into a claim check and a payload. Küldje el a jogcímet az üzenetkezelési platformra, és tárolja a hasznos adatokat egy külső szolgáltatásban.Send the claim check to the messaging platform and store the payload to an external service. Ez a minta lehetővé teszi a nagy méretű üzenetek feldolgozását, miközben az üzenetsor védelmét és az ügyfelet túlterheli vagy lelassítja.This pattern allows large messages to be processed, while protecting the message bus and the client from being overwhelmed or slowed down. Ez a minta a költségek csökkentését is lehetővé teszi, mivel a tárterület általában olcsóbb, mint az üzenetkezelő platform által használt erőforrás-egység.This pattern also helps to reduce costs, as storage is usually cheaper than resource units used by the messaging platform.

Ezt a mintát Reference-Based üzenetkezelésnek is nevezzük, és eredetileg a Book Vállalati integráció Patterns, a Gregor Hohpe és a Bobby Woolf alapján írták le .This pattern is also known as Reference-Based Messaging, and was originally described in the book Enterprise Integration Patterns, by Gregor Hohpe and Bobby Woolf.

Kontextus és problémaContext and problem

Egy adott ponton egy üzenetküldési architektúrának képesnek kell lennie nagy méretű üzenetek küldésére, fogadására és kezelésére.A messaging-based architecture at some point must be able to send, receive, and manipulate large messages. Az ilyen üzenetek tartalmazhatnak bármit, beleértve a képeket (például az MRI-vizsgálatokat), a hangfájlokat (például a Call-Center hívásokat), a szöveges dokumentumokat, vagy bármilyen tetszőleges méretű bináris adat.Such messages may contain anything, including images (for example, MRI scans), sound files (for example, call-center calls), text documents, or any kind of binary data of arbitrary size.

Az ilyen nagyméretű üzenetek közvetlen küldése az üzenetsor-buszra nem ajánlott, mert több erőforrást és sávszélességet igényelnek.Sending such large messages to the message bus directly is not recommended, because they require more resources and bandwidth to be consumed. A nagyméretű üzenetek a teljes megoldást is lelassítják, mivel az üzenetkezelési platformok általában nagy mennyiségű kis méretű üzenet kezelésére alkalmasak.Large messages can also slow down the entire solution, because messaging platforms are usually fine-tuned to handle huge quantities of small messages. Emellett a legtöbb üzenetkezelési platform korlátozza az üzenetek méretét, ezért előfordulhat, hogy a nagy méretű üzenetekre is szüksége lehet a korlátok megkerülésére.Also, most messaging platforms have limits on message size, so you may need to work around these limits for large messages.

MegoldásSolution

A teljes üzenet tartalmát egy külső szolgáltatásba (például egy adatbázisba) tárolja.Store the entire message payload into an external service, such as a database. Szerezze be a tárolt adattartalomra mutató hivatkozást, és küldje el az üzenet-buszra mutató hivatkozást.Get the reference to the stored payload, and send just that reference to the message bus. A hivatkozás úgy viselkedik, mint a csomagok lekérésére használt jogcím-ellenőrzési, ezért a minta neve.The reference acts like a claim check used to retrieve a piece of luggage, hence the name of the pattern. Azok az ügyfelek, akik az adott üzenet feldolgozását érdeklik, a kapott referenciával kérhetik le a hasznos adatokat, ha szükséges.Clients interested in processing that specific message can use the obtained reference to retrieve the payload, if needed.

A Claim-Check minta ábrája

Problémák és megfontolandó szempontokIssues and considerations

A minta megvalósítása során az alábbi pontokat vegye figyelembe:Consider the following points when deciding how to implement this pattern:

  • Ha nem kell archiválnia az üzeneteket, érdemes lehet törölni az üzenetek adatmennyiségét.Consider deleting the message data after consuming it, if you don't need to archive the messages. Bár a blob Storage viszonylag olcsó, hosszú távon pénzbe kerül, különösen, ha sok az adatmennyiség.Although blob storage is relatively cheap, it costs some money in the long run, especially if there is a lot of data. Az üzenet törlését az üzenetet fogadó és feldolgozó alkalmazás, illetve egy külön dedikált folyamat aszinkron módon végezheti el.Deleting the message can be done synchronously by the application that receives and processes the message, or asynchronously by a separate dedicated process. Az aszinkron megközelítés eltávolítja a régi adatmennyiséget, és nincs hatással a fogadó alkalmazás átviteli sebességére és az üzenet feldolgozási teljesítményére.The asynchronous approach removes old data with no impact on the throughput and message processing performance of the receiving application.

  • Az üzenet tárolása és lekérése némi további terhelést és késést okoz.Storing and retrieving the message causes some additional overhead and latency. Előfordulhat, hogy a küldési alkalmazás logikáját csak akkor szeretné használni, ha az üzenet mérete meghaladja az üzenet-busz adatkorlátját.You may want to implement logic in the sending application to use this pattern only when the message size exceeds the data limit of the message bus. A minta kimarad a kisebb üzenetek esetében.The pattern would be skipped for smaller messages. Ez a megközelítés feltételes jogcím-ellenőrzési mintát eredményezne.This approach would result in a conditional claim-check pattern.

Mikor érdemes ezt a mintát használni?When to use this pattern

Ezt a mintát akkor kell használni, amikor egy üzenet nem fér el a kiválasztott Message Bus-technológia támogatott üzenet-korlátozásával.This pattern should be used whenever a message cannot fit the supported message limit of the chosen message bus technology. Például Event Hubs jelenleg legfeljebb 256 KB (alapszintű csomag), míg a Event Grid csak 64 KB-os üzeneteket támogat.For example, Event Hubs currently has a limit of 256 KB (Basic Tier), while Event Grid supports only 64-KB messages.

A minta akkor is használható, ha a hasznos adatokat csak olyan szolgáltatások érhetik el, amelyek jogosultak a megtekintésre.The pattern can also be used if the payload should be accessed only by services that are authorized to see it. A hasznos adatok külső erőforrásba való kiszervezésével szigorúbb hitelesítési és engedélyezési szabályok állíthatók be, így biztosítható, hogy a biztonság kikényszeríthető legyen, ha bizalmas adatokat tárolnak a hasznos adattartalomban.By offloading the payload to an external resource, stricter authentication and authorization rules can be put in place, to ensure that security is enforced when sensitive data is stored in the payload.

PéldákExamples

Az Azure-ban ez a minta többféle módon és különböző technológiákkal is megvalósítható, de két fő kategória van.On Azure, this pattern can be implemented in several ways and with different technologies, but there are two main categories. Mindkét esetben a fogadó feladata, hogy beolvassa a jogcímek ellenőrzését, és használja azt a hasznos adatok beolvasásához.In both cases, the receiver has the responsibility to read the claim check and use it to retrieve the payload.

  • Automatikus jogcím – ellenőrzési generáció.Automatic claim-check generation. Ezzel a megközelítéssel a Azure Event Grid automatikusan létrehozza a jogcím-ellenőrzését, és leküldheti azt az üzenet-buszba.This approach uses Azure Event Grid to automatically generate the claim check and push it into the message bus.

  • Kézi jogcím – ellenőrzési generáció.Manual claim-check generation. Ebben a megközelítésben a küldő feladata a hasznos adatok kezelése.In this approach, the sender is responsible for managing the payload. A küldő a megfelelő szolgáltatás használatával tárolja a hasznos adatokat, lekérdezi vagy létrehozza a jogcím-ellenőrzési adatokat, és elküldi a jogcímet az üzenet buszának.The sender stores the payload using the appropriate service, gets or generates the claim check, and sends the claim check to the message bus.

Event Grid egy esemény-útválasztási szolgáltatás, és egy konfigurálható időtartamon belül kísérli meg az események továbbítását akár 24 óráig.Event Grid is an event routing service and tries to deliver events within a configurable amount of time up to 24 hours. Ezt követően a rendszer elveti vagy elvetette az eseményeket.After that, events are either discarded or dead lettered. Ha archiválni szeretné az eseményhez kapcsolódó hasznos adatokat, vagy újra kell játszania az esemény-adatfolyamot, hozzáadhat egy Event Grid-előfizetést Event Hubshoz vagy Queue Storagehoz, ahol az üzenetek hosszabb ideig is megtarthatók, és az archivált üzenetek is támogatottak.If you need to archive the event payloads or replay the event stream, you can add an Event Grid subscription to Event Hubs or Queue Storage, where messages can be retained for longer periods and archiving messages is supported. További információ a Event Grid üzenetek kézbesítésének finomhangolásáról és az újrapróbálkozásról, valamint a kézbesítetlen levelek konfigurálásáról: kézbesítetlen levelek és újrapróbálkozási szabályzatok.For information about fine tuning Event Grid message delivery and retry, and dead letter configuration, see Dead letter and retry policies.

Automatikus jogcím – a Blob Storage és Event GridAutomatic claim-check generation with Blob Storage and Event Grid

Ebben a megközelítésben a feladó elveszíti az üzenet tartalmát egy kijelölt Azure Blob Storage-tárolóba.In this approach, the sender drops the message payload into a designated Azure Blob Storage container. Event Grid automatikusan létrehoz egy címkét vagy hivatkozást, és elküldi azt egy támogatott üzenet-buszra, például az Azure Storage-várólistákba.Event Grid automatically generates a tag/reference and sends it to a supported message bus, such as Azure Storage Queues. A fogadó lekérdezheti a várólistát, lekérheti az üzenetet, majd a tárolt hivatkozási adatok használatával közvetlenül letöltheti a hasznos adatokat a Blob Storageról.The receiver can poll the queue, get the message, and then use the stored reference data to download the payload directly from Blob Storage.

Ugyanaz a Event Gridi üzenet közvetlenül is felhasználható Azure functionssegítségével anélkül, hogy az üzenet-buszon át kellene haladnia.The same Event Grid message can be directly consumed by Azure Functions, without needing to go through a message bus. Ez a megközelítés teljes mértékben kihasználja a Event Grid és a függvények kiszolgáló nélküli jellegét.This approach takes full advantage of the serverless nature of both Event Grid and Functions.

Ehhez a megközelítéshez itttalál példát.You can find example code for this approach here.

Event Grid a Event HubsEvent Grid with Event Hubs

Az előző példához hasonlóan a Event Grid automatikusan létrehoz egy üzenetet, amikor egy adattartalmat egy Azure Blob-tárolóba ír.Similar to the previous example, Event Grid automatically generates a message when a payload is written to an Azure Blob container. Ebben a példában azonban az üzenetsor Event Hubs használatával valósul meg.But in this example, the message bus is implemented using Event Hubs. Az ügyfelek regisztrálhatják magukat, hogy megkapják az üzenetek streamjét az Event hub-ba való írás során.A client can register itself to receive the stream of messages as they are written to the event hub. Az Event hub az üzenetek archiválására is konfigurálható, így elérhetővé teheti őket Avro-fájlként, például az Apache Spark, az Apache Drill vagy az elérhető Avro-kódtárak használatával.The event hub can also be configured to archive messages, making them available as an Avro file that can be queried using tools like Apache Spark, Apache Drill, or any of the available Avro libraries.

Ehhez a megközelítéshez itttalál példát.You can find example code for this approach here.

Jogcím-ellenőrzési generáció Service BusClaim check generation with Service Bus

Ez a megoldás kihasználja a ServiceBus. AttachmentPluginegy adott Service Bus beépülő moduljának előnyeit, amely megkönnyíti a jogcím-ellenőrzési munkafolyamat megvalósítását.This solution takes advantage of a specific Service Bus plugin, ServiceBus.AttachmentPlugin, which makes the claim-check workflow easy to implement. A beépülő modul az üzenet elküldésekor az Azure Blob Storageban tárolt mellékletbe alakítja az összes üzenettörzs tartalmát.The plugin converts any message body into an attachment that gets stored in Azure Blob Storage when the message is sent.

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);

Az Service Bus üzenet értesítési várólistaként működik, amelyet az ügyfél előfizethet a szolgáltatásra.The Service Bus message acts as a notification queue, which a client can subscribe to. Amikor a fogyasztó megkapja az üzenetet, a beépülő modul lehetővé teszi, hogy közvetlenül beolvassa az üzenet adatait Blob Storageról.When the consumer receives the message, the plugin makes it possible to directly read the message data from Blob Storage. Ezután megadhatja, hogyan dolgozza fel az üzenetet tovább.You can then choose how to process the message further. Ennek a megközelítésnek az az előnye, hogy elvonta a kérelem-ellenőrzési munkafolyamatot a feladótól és a fogadótól.An advantage of this approach is that it abstracts the claim-check workflow from the sender and receiver.

Ehhez a megközelítéshez itttalál példát.You can find example code for this approach here.

Kézi jogcím – a Kafka-vizsgálat létrehozásaManual claim-check generation with Kafka

Ebben a példában a Kafka-ügyfél a hasznos adatokat az Azure Blob Storageba írja.In this example, a Kafka client writes the payload to Azure Blob Storage. Ezt követően értesítési üzenetet küld a Kafka-kompatibilis Event Hubshasználatával.Then it sends a notification message using Kafka-enabled Event Hubs. A fogyasztó megkapja az üzenetet, és hozzáfér a hasznos adatokhoz Blob Storage.The consumer receives the message and can access the payload from Blob Storage. Ez a példa azt szemlélteti, hogyan használható egy másik üzenetküldési protokoll a jogcím-ellenőrzési minta megvalósítására az Azure-ban.This example shows how a different messaging protocol can be used to implement the claim-check pattern in Azure. Előfordulhat például, hogy támogatnia kell a meglévő Kafka-ügyfeleket.For example, you might need to support existing Kafka clients.

Ehhez a megközelítéshez itttalál példát.You can find example code for this approach here.