Jogcím-ellenőrzési minta

Azure Event Grid
Azure Blob Storage

Nagyméretű üzenet felosztása jogcím-ellenőrzésre és hasznos adatokra. Küldje el a jogcím-ellenőrzést az üzenetkezelési platformnak, és tárolja a hasznos adatokat egy külső szolgáltatásban. Ez a minta lehetővé teszi a nagyméretű üzenetek feldolgozását, miközben védi az üzenetbuszt és az ügyfelet a túlterheltségtől vagy a lelassulástól. Ez a minta a költségek csökkentésében is segít, mivel a tárolás általában olcsóbb, mint az üzenetkezelési platform által használt erőforrásegységek.

Ezt a mintát referenciaalapú üzenetkezelésnek is nevezik, és eredetileg Gregor Hohpe és Bobby Woolf írta le az Enterprise Integration Patterns című könyvben.

Kontextus és probléma

Egy üzenetkezelési alapú architektúrának képesnek kell lennie nagy méretű üzenetek küldésére, fogadására és kezelésére. Az ilyen üzenetek tartalmazhatnak bármit, beleértve a képeket (például MRI-vizsgálatokat), hangfájlokat (például call-center-hívásokat), szöveges dokumentumokat vagy tetszőleges méretű bináris adatokat.

Ilyen nagy üzenetek közvetlen küldése az üzenetbuszra nem ajánlott, mert több erőforrást és sávszélességet igényelnek. A nagyméretű üzenetek a teljes megoldást is lelassíthatják, mivel az üzenetkezelési platformok általában finomhangolva vannak, hogy nagy mennyiségű kis üzenetet kezeljenek. Emellett a legtöbb üzenetkezelési platformon korlátozva van az üzenetek mérete, ezért előfordulhat, hogy a nagyméretű üzenetekre vonatkozó korlátokat kell megkerülnie.

Megoldás

Tárolja a teljes üzenet hasznos adatait egy külső szolgáltatásban, például egy adatbázisban. Kérje le a tárolt hasznos adatokra mutató hivatkozást, és küldje el ezt a hivatkozást az üzenetbuszra. A referencia olyan, mint egy poggyász lekérésére használt jogcím-ellenőrzés, így a minta neve. Az adott üzenet feldolgozásában érdekelt ügyfelek szükség esetén a kapott hivatkozással lekérhetik a hasznos adatokat.

Diagram of the Claim-Check pattern.

  1. Üzenet küldése
  2. Üzenet tárolása az adattárban
  3. Az üzenet hivatkozásának leküldése
  4. Az üzenet hivatkozásának elolvasása
  5. Az üzenet lekérése
  6. Az üzenet feldolgozása

Problémák és megfontolandó szempontok

A minta megvalósítása során az alábbi pontokat vegye figyelembe:

  • Fontolja meg az üzenetadatok törlését a felhasználás után, ha nem kell archiválnia az üzeneteket. Bár a blobtároló viszonylag olcsó, hosszú távon némi pénzbe kerül, különösen akkor, ha sok adat áll rendelkezésre. Az üzenet törlését szinkron módon végezheti el az üzenetet fogadó és feldolgozó alkalmazás, vagy aszinkron módon, külön dedikált folyamattal. Az aszinkron megközelítés eltávolítja a régi adatokat, és nem befolyásolja a fogadó alkalmazás átviteli sebességét és üzenetfeldolgozási teljesítményét.

  • Az üzenet tárolása és beolvasása további többletterhelést és késést okoz. Érdemes lehet logikát implementálni a küldő alkalmazásban, hogy ezt a mintát csak akkor használja, ha az üzenet mérete meghaladja az üzenetbusz adatkorlátját. A minta kisebb üzenetek esetén ki lesz hagyva. Ez a megközelítés feltételes jogcím-ellenőrzési mintát eredményezne.

Mikor érdemes ezt a mintát használni?

Ez a minta akkor használható, ha egy üzenet nem fér el a kiválasztott üzenetbusz technológia támogatott üzenetkorlátjának megfelelően. A Service Bus például jelenleg 100 MB-os (prémium szintű) korláttal rendelkezik, míg az Event Grid legfeljebb 1 MB-os üzeneteket támogat.

A minta akkor is használható, ha a hasznos adatokat csak azok a szolgáltatások érhetik el, amelyek jogosultak a megtekintésére. A hasznos adatok külső erőforrásba való kiszervezésével szigorúbb hitelesítési és engedélyezési szabályokat lehet életbe léptetni annak biztosítása érdekében, hogy a rendszer kényszerítse a biztonságot a hasznos adatok bizalmas adatainak tárolásakor.

Számítási feladatok tervezése

Az építészeknek értékelniük kell, hogy a jogcím-ellenőrzési minta hogyan használható a számítási feladatok tervezésében az Azure Well-Architected Framework pilléreiben foglalt célok és alapelvek kezelése érdekében. Példa:

Pillér Hogyan támogatja ez a minta a pillércélokat?
A megbízhatósági tervezési döntések segítenek a számítási feladatnak ellenállóvá válni a hibás működéssel szemben, és biztosítani, hogy a hiba bekövetkezése után teljesen működőképes állapotba kerüljön. Az üzenetbuszok nem ugyanazt a megbízhatóságot és vészhelyreállítást biztosítják, mint amelyek gyakran a dedikált adattárakban találhatók, így az adatok elkülönítése az üzenettől nagyobb megbízhatóságot biztosíthat a mögöttes adatok számára. Ez az elkülönítés lehetővé teszi az üzenetsorok vészhelyreállítási megközelítését is.

- RE:03 Hibamód elemzése
- RE:09 Vészhelyreállítás
A biztonsági tervezési döntések segítenek biztosítani a számítási feladatok adatainak és rendszereinek titkosságát, integritását és rendelkezésre állását. Ez a minta támogatja, hogy a bizalmas adatok ne legyenek az üzenettörzsekben, hanem biztonságos adattárban legyenek kezelve. Ez a konfiguráció lehetővé teszi, hogy szigorúbb engedélyezést hozzon létre a bizalmas adatokhoz való hozzáférés támogatásához olyan szolgáltatásokból, amelyek várhatóan használják az adatokat, de eltávolítja a láthatóságot a kiegészítő szolgáltatásokból, például a várólista-figyelési megoldásokból.

- Standard kiadás:03 Adatbesorolás
- Standard kiadás:04 Szegmentálás
A költségoptimalizálás a számítási feladatok megtérülésének fenntartására és javítására összpontosít. Az üzenetkezelési rendszerek gyakran korlátozzák az üzenetek méretét, és a megnövekedett méretkorlátok gyakran prémium szintű funkciók. Az üzenettörzsek méretének csökkentésével olcsóbb üzenetkezelési megoldást használhat.

- CO:07 Összetevő költségei
- CO:09 Flow-költségek
A teljesítményhatékonyság a skálázás, az adatok és a kód optimalizálásával segíti a számítási feladatok hatékony kielégítését . Ez a minta javítja az üzenet közzétevőinek, előfizetőinek és magának az üzenetbusznak a hatékonyságát és teljesítményét, amikor a rendszer nagy adatmennyiségeket kezel. Úgy működik, hogy csökkenti az üzenetek méretét, és biztosítja, hogy a felhasználók csak szükség esetén és időszerű időben kérik le a hasznos adatokat.

- PE:05 Skálázás és particionálás
- PE:12 Folyamatos teljesítményoptimalizálás

Mint minden tervezési döntésnél, fontolja meg az ezzel a mintával bevezethető többi pillér céljaival szembeni kompromisszumokat.

Példák

Az Azure-ban ez a minta többféleképpen és különböző technológiákkal implementálható, de két fő kategória létezik. Mindkét esetben a fogadó felelőssége, hogy elolvassa a jogcím-ellenőrzést, és felhasználja a hasznos adatok lekéréséhez.

  • Automatikus jogcím-ellenőrzés létrehozása. Ez a módszer az Azure Event Grid használatával automatikusan létrehozza a jogcím-ellenőrzést, és leküldi az üzenetbuszba.

  • Manuális jogcím-ellenőrzés létrehozása. Ebben a megközelítésben a feladó felelős a hasznos adatok kezeléséért. A feladó a hasznos adatokat a megfelelő szolgáltatással tárolja, lekéri vagy létrehozza a jogcím-ellenőrzést, és elküldi a jogcím-ellenőrzést az üzenetbusznak.

Az Event Grid egy esemény-útválasztási szolgáltatás, amely konfigurálható időn belül, legfeljebb 24 órán belül próbál eseményeket kézbesíteni. Ezután a rendszer elveti az eseményeket, vagy a holt betűt. Ha archiválnia kell az esemény hasznos adatait, vagy vissza kell játszania az eseménystreamet, hozzáadhat egy Event Grid-előfizetést az Event Hubshoz vagy a Queue Storage-hoz, ahol az üzenetek hosszabb ideig megőrizhetők, és az üzenetek archiválása támogatott. Az Event Grid üzenetkézbesítésének és újrapróbálkozásának finomhangolásáról, valamint a kézbesítetlen levelek konfigurálásáról további információt a Holt betű és az újrapróbálkozás szabályzatai című témakörben talál.

Automatikus jogcím-ellenőrzési létrehozás a Blob Storage és az Event Grid használatával

Ebben a megközelítésben a feladó az üzenet hasznos adatait egy kijelölt Azure Blob Storage-tárolóba dobja. Az Event Grid automatikusan létrehoz egy címkét/hivatkozást, és elküldi azt egy támogatott üzenetbusznak, például az Azure Storage-üzenetsoroknak. A fogadó lekérdezheti az üzenetsort, lekérheti az üzenetet, majd a tárolt referenciaadatok használatával közvetlenül a Blob Storage-ból töltheti le a hasznos adatokat.

Ugyanazt az Event Grid-üzenetet közvetlenül használhatja az Azure Functions, anélkül, hogy át kellene mennie egy üzenetbuszon. Ez a megközelítés teljes mértékben kihasználja az Event Grid és a Functions kiszolgáló nélküli jellegét.

Ehhez a megközelítéshez itt talál példakódot.

Event Grid és Event Hubs

Az előző példához hasonlóan az Event Grid automatikusan létrehoz egy üzenetet, amikor egy hasznos adat egy Azure Blob-tárolóba van írva. Ebben a példában azonban az üzenetbusz az Event Hubs használatával van implementálva. Az ügyfél regisztrálhatja magát, hogy megkapja az üzenetek adatfolyamát, miközben azokat az eseményközpontba írják. Az eseményközpont úgy is konfigurálható, hogy archiválja az üzeneteket, és elérhetővé tegye őket Avro-fájlként, amely lekérdezhető olyan eszközökkel, mint az Apache Spark, az Apache Drill vagy bármely elérhető Avro-kódtár.

Ehhez a megközelítéshez itt talál példakódot.

Jogcím-ellenőrzés létrehozása a Service Bus használatával

Ez a megoldás egy adott Service Bus beépülő modul, a ServiceBus.AttachmentPlugin előnyeit használja, amely megkönnyíti a jogcím-ellenőrzési munkafolyamat implementálását. A beépülő modul az üzenetek törzsét mellékletté alakítja, amely az üzenet elküldésekor az Azure Blob Storage-ban lesz tárolva.

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

A Service Bus-üzenet értesítési üzenetsorként működik, amelyre az ügyfél előfizethet. Amikor a fogyasztó megkapja az üzenetet, a beépülő modul lehetővé teszi az üzenetadatok közvetlen olvasását a Blob Storage-ból. Ezután kiválaszthatja, hogyan dolgozza fel tovább az üzenetet. Ennek a megközelítésnek az az előnye, hogy elvonja a jogcím-ellenőrzési munkafolyamatot a feladótól és a fogadótól.

Ehhez a megközelítéshez itt talál példakódot.

Manuális jogcím-ellenőrzés létrehozása a Kafkával

Ebben a példában egy Kafka-ügyfél írja a hasznos adatokat az Azure Blob Storage-ba. Ezután egy értesítési üzenetet küld a Kafka-kompatibilis Event Hubs használatával. A fogyasztó megkapja az üzenetet, és hozzáférhet a hasznos adatokhoz a Blob Storage-ból. Ez a példa bemutatja, hogyan használható egy másik üzenetkezelési protokoll a jogcím-ellenőrzési minta azure-beli implementálásához. Előfordulhat például, hogy támogatnia kell a meglévő Kafka-ügyfeleket.

Ehhez a megközelítéshez itt talál példakódot.

Következő lépések