Upravit

Zpracování událostí bez serveru

Azure Cosmos DB
Azure Functions
Azure Monitor
Azure Pipelines
Azure Storage

Tato referenční architektura ukazuje bezserverovou architekturu řízenou událostmi, která ingestuje datový proud, zpracovává data a zapisuje výsledky do back-endové databáze.

Architektura

Diagram znázorňující referenční architekturu pro zpracování bezserverových událostí pomocí Azure Functions

Workflow

  • Události přicházejí do služby Azure Event Hubs.
  • Aplikace funkcí se aktivuje pro zpracování události.
  • Událost je uložená v databázi Azure Cosmos DB.
  • Pokud se aplikaci funkcí nepodaří úspěšně uložit událost, uloží se událost do fronty úložiště, která se zpracuje později.

Komponenty

  • Event Hubs ingestuje datový proud. Služba Event Hubs je navržená pro scénáře streamování dat s vysokou propustností.

    Poznámka:

    Pro scénáře Internetu věcí (IoT) doporučujeme Azure IoT Hub. IoT Hub má integrovaný koncový bod, který je kompatibilní s rozhraním API služby Azure Event Hubs, takže v této architektuře můžete použít některou službu bez velkých změn v back-endovém zpracování. Další informace najdete v tématu Připojení připojení zařízení IoT do Azure: IoT Hub a Event Hubs.

  • Aplikace funkcí Azure Functions je bezserverová výpočetní možnost. Používá model řízený událostmi, kde aktivační událost vyvolá část kódu ( funkce). V této architektuře při příchodu událostí do služby Event Hubs aktivují funkci, která zpracovává události a zapisuje výsledky do úložiště.

    Aplikace funkcí jsou vhodné pro zpracování jednotlivých záznamů ze služby Event Hubs. V případě složitějších scénářů zpracování datových proudů zvažte Použití Apache Sparku pomocí Azure Databricks nebo Azure Stream Analytics.

  • Azure Cosmos DB. Azure Cosmos DB je vícemodelová databázová služba, která je dostupná v bezserverovém režimu založeném na spotřebě. V tomto scénáři ukládá funkce zpracování událostí záznamy JSON pomocí služby Azure Cosmos DB for NoSQL.

  • Queue Storage. Queue Storage se používá pro zprávy s nedoručenou zprávou. Pokud při zpracování události dojde k chybě, uloží funkce data události do fronty nedoručených zpráv pro pozdější zpracování. Další informace naleznete v části Odolnost dále v tomto článku.

  • Azure Monitor Monitor shromažďuje metriky výkonu o službách Azure nasazených v řešení. Vizualizací těchto prvků na řídicím panelu můžete získat přehled o stavu řešení.

  • Azure Pipelines. Pipelines je služba kontinuální integrace (CI) a průběžného doručování (CD), která sestavuje, testuje a nasazuje aplikaci.

Důležité informace

Tyto aspekty implementují pilíře dobře architektuře Azure, což je sada hlavních principů, které je možné použít ke zlepšení kvality úlohy. Další informace naleznete v tématu Microsoft Azure Well-Architected Framework.

Dostupnost

Toto nasazení se nachází v jedné oblasti Azure. Pokud chcete odolnější přístup k zotavení po havárii, využijte funkce geografické distribuce v různých službách:

  • Event Hubs. Vytvořte dva obory názvů služby Event Hubs, primární (aktivní) obor názvů a sekundární (pasivní) obor názvů. Zprávy se automaticky směrují do aktivního oboru názvů, pokud nepřejdete do sekundárního oboru názvů. Další informace najdete v tématu Geografické zotavení po havárii služby Azure Event Hubs.
  • Aplikace funkcí Nasaďte druhou aplikaci funkcí, která čeká na čtení ze sekundárního oboru názvů služby Event Hubs. Tato funkce zapisuje do sekundárního účtu úložiště pro frontu nedoručených zpráv.
  • Azure Cosmos DB. Azure Cosmos DB podporuje více oblastí zápisu, což umožňuje zápisy do libovolné oblasti, kterou přidáte do účtu služby Azure Cosmos DB. Pokud nepovolíte více zápisů, můžete převzít služby při selhání primární oblasti zápisu. Klientské sady SDK služby Azure Cosmos DB a vazby funkce Azure Functions automaticky zpracovávají převzetí služeb při selhání, takže nemusíte aktualizovat žádná nastavení konfigurace aplikace.
  • Azure Storage Pro frontu nedoručených zpráv použijte úložiště RA-GRS. Tím se vytvoří replika jen pro čtení v jiné oblasti. Pokud primární oblast přestane být dostupná, můžete číst položky, které jsou aktuálně ve frontě. Kromě toho zřiďte další účet úložiště v sekundární oblasti, do které může funkce zapisovat po převzetí služeb při selhání.

Škálovatelnost

Event Hubs

Kapacita propustnosti služby Event Hubs se měří v jednotkách propustnosti. Centrum událostí můžete automaticky škálovat tak, že povolíte automatické nafouknutí, které automaticky škáluje jednotky propustnosti na základě provozu až na nakonfigurované maximum.

Trigger Event Hubs v aplikaci funkcí se škáluje podle počtu oddílů v centru událostí. Každému oddílu je přiřazena jedna instance funkce najednou. Pokud chcete maximalizovat propustnost, získejte události v dávce místo jednoho po druhém.

Azure Cosmos DB

Azure Cosmos DB je k dispozici ve dvou různých režimech kapacity:

  • Bezserverové úlohy s přerušovaným nebo nepředvídatelným provozem a poměrem provozu s nízkým průměrem a špičkou.
  • Zřízená propustnost pro úlohy s trvalým provozem vyžadujícím předvídatelný výkon.

Abyste měli jistotu, že je vaše úloha škálovatelná, je důležité při vytváření kontejnerů Azure Cosmos DB zvolit odpovídající klíč oddílu. Tady jsou některé charakteristiky dobrého klíče oddílu:

  • Prostor hodnot klíče je velký.
  • Bude existovat rovnoměrné rozdělení čtení a zápisů na hodnotu klíče, aby nedocházelo k horkým klávesám.
  • Maximální data uložená pro libovolnou hodnotu jednoho klíče nepřekročí maximální velikost fyzického oddílu (20 GB).
  • Klíč oddílu dokumentu se nezmění. Klíč oddílu v existujícím dokumentu nejde aktualizovat.

Ve scénáři pro tuto referenční architekturu ukládá funkce přesně jeden dokument na zařízení, které odesílá data. Funkce průběžně aktualizuje dokumenty o nejnovější stav zařízení pomocí operace upsertu. ID zařízení je vhodný klíč oddílu pro tento scénář, protože zápisy se rovnoměrně rozdělí mezi klíče a velikost každého oddílu bude přísně svázaná, protože pro každou hodnotu klíče je jeden dokument. Další informace o klíčích oddílů najdete v tématu Dělení a škálování ve službě Azure Cosmos DB.

Odolnost

Při použití triggeru služby Event Hubs se službou Functions zachyťte výjimky ve smyčce zpracování. Pokud dojde k neošetřené výjimce, modul runtime Služby Functions nezopakuje zprávy. Pokud zprávu nelze zpracovat, vložte zprávu do fronty nedoručených zpráv. Pomocí vzdáleného procesu můžete zkoumat zprávy a určit nápravnou akci.

Následující kód ukazuje, jak funkce příjmu dat zachytává výjimky a vkládá nezpracované zprávy do fronty nedoručených zpráv.

 [Function(nameof(RawTelemetryFunction))]
 public async Task RunAsync([EventHubTrigger("%EventHubName%", Connection = "EventHubConnection")] EventData[] messages,
     FunctionContext context)
 {
     _telemetryClient.GetMetric("EventHubMessageBatchSize").TrackValue(messages.Length);
     DeviceState? deviceState = null;
     // Create a new CosmosClient
     var cosmosClient = new CosmosClient(Environment.GetEnvironmentVariable("COSMOSDB_CONNECTION_STRING"));

     // Get a reference to the database and the container
     var database = cosmosClient.GetDatabase(Environment.GetEnvironmentVariable("COSMOSDB_DATABASE_NAME"));
     var container = database.GetContainer(Environment.GetEnvironmentVariable("COSMOSDB_DATABASE_COL"));

     // Create a new QueueClient
     var queueClient = new QueueClient(Environment.GetEnvironmentVariable("DeadLetterStorage"), "deadletterqueue");
     await queueClient.CreateIfNotExistsAsync();

     foreach (var message in messages)
     {
         try
         {
             deviceState = _telemetryProcessor.Deserialize(message.Body.ToArray(), _logger);
             try
             {
                 // Add the device state to Cosmos DB
                 await container.UpsertItemAsync(deviceState, new PartitionKey(deviceState.DeviceId));
             }
             catch (Exception ex)
             {
                  _logger.LogError(ex, "Error saving on database", message.PartitionKey, message.SequenceNumber);
                 var deadLetterMessage = new DeadLetterMessage { Issue = ex.Message, MessageBody = message.Body.ToArray(), DeviceState = deviceState };
                 // Convert the dead letter message to a string
                 var deadLetterMessageString = JsonConvert.SerializeObject(deadLetterMessage);

                 // Send the message to the queue
                 await queueClient.SendMessageAsync(deadLetterMessageString);
             }

         }
         catch (Exception ex)
         {
             _logger.LogError(ex, "Error deserializing message", message.PartitionKey, message.SequenceNumber);
             var deadLetterMessage = new DeadLetterMessage { Issue = ex.Message, MessageBody = message.Body.ToArray(), DeviceState = deviceState };
             // Convert the dead letter message to a string
             var deadLetterMessageString = JsonConvert.SerializeObject(deadLetterMessage);

             // Send the message to the queue
             await queueClient.SendMessageAsync(deadLetterMessageString);
         }
     }
 }

Zobrazený kód také protokoluje výjimky Přehledy aplikace. Klíč oddílu a pořadové číslo můžete použít ke korelaci nedoručených zpráv s výjimkami v protokolech.

Zprávy ve frontě nedoručených zpráv by měly mít dostatek informací, abyste pochopili kontext chyby. V tomto příkladu DeadLetterMessage třída obsahuje zprávu výjimky, původní data těla události a deserializovanou zprávu události (pokud je k dispozici).

    public class DeadLetterMessage
    {
        public string? Issue { get; set; }
        public byte[]? MessageBody { get; set; }
        public DeviceState? DeviceState { get; set; }
    }

K monitorování centra událostí použijte Azure Monitor . Pokud se zobrazí vstup, ale žádný výstup, znamená to, že se nezpracovávají zprávy. V takovém případě přejděte do Log Analytics a vyhledejte výjimky nebo jiné chyby.

DevOps

Pokud je to možné, použijte infrastrukturu jako kód (IaC). IaC spravuje infrastrukturu, aplikace a prostředky úložiště pomocí deklarativního přístupu, jako je Azure Resource Manager. To vám pomůže při automatizaci nasazení pomocí DevOps jako řešení kontinuální integrace a průběžného doručování (CI/CD). Šablony by měly být verze a zahrnuty jako součást kanálu verze.

Při vytváření šablon seskupujte prostředky jako způsob, jak je uspořádat a izolovat podle úloh. Běžným způsobem, jak přemýšlet o úloze, je jedna bezserverová aplikace nebo virtuální síť. Cílem izolace úloh je přidružit prostředky k týmu, aby tým DevOps mohl nezávisle spravovat všechny aspekty těchto prostředků a provádět CI/CD.

Při nasazování služeb je budete muset monitorovat. Zvažte použití Přehledy aplikací, abyste vývojářům umožnili monitorovat výkon a zjišťovat problémy.

Další informace najdete v kontrolním seznamu DevOps.

Zotavení po havárii

Toto nasazení se nachází v jedné oblasti Azure. Pokud chcete odolnější přístup k zotavení po havárii, využijte funkce geografické distribuce v různých službách:

  • Event Hubs. Vytvořte dva obory názvů služby Event Hubs, primární (aktivní) obor názvů a sekundární (pasivní) obor názvů. Zprávy se automaticky směrují do aktivního oboru názvů, pokud nepřejdete do sekundárního oboru názvů. Další informace najdete v tématu Geografické zotavení po havárii služby Azure Event Hubs.

  • Aplikace funkcí Nasaďte druhou aplikaci funkcí, která čeká na čtení ze sekundárního oboru názvů služby Event Hubs. Tato funkce zapisuje do sekundárního účtu úložiště pro frontu nedoručených zpráv.

  • Azure Cosmos DB. Azure Cosmos DB podporuje více oblastí zápisu, což umožňuje zápisy do libovolné oblasti, kterou přidáte do účtu služby Azure Cosmos DB. Pokud nepovolíte více zápisů, můžete převzít služby při selhání primární oblasti zápisu. Klientské sady SDK služby Azure Cosmos DB a vazby funkce Azure Functions automaticky zpracovávají převzetí služeb při selhání, takže nemusíte aktualizovat žádná nastavení konfigurace aplikace.

  • Azure Storage Pro frontu nedoručených zpráv použijte úložiště RA-GRS . Tím se vytvoří replika jen pro čtení v jiné oblasti. Pokud primární oblast přestane být dostupná, můžete číst položky, které jsou aktuálně ve frontě. Kromě toho zřiďte další účet úložiště v sekundární oblasti, do které může funkce zapisovat po převzetí služeb při selhání.

Optimalizace nákladů

Optimalizace nákladů se zabývá způsoby, jak snížit zbytečné výdaje a zlepšit efektivitu provozu. Další informace najdete v tématu Přehled pilíře optimalizace nákladů.

K odhadu nákladů použijte cenovou kalkulačku Azure. Tady jsou některé další aspekty služby Azure Functions a Azure Cosmos DB.

Azure Functions

Azure Functions podporuje dva modely hostování:

  • Plán Consumption Výpočetní výkon se automaticky přidělí, když je váš kód spuštěný.
  • Plán služby App Service. Pro váš kód se přidělí sada virtuálních počítačů. Plán služby App Service definuje počet virtuálních počítačů a velikost virtuálního počítače.

V této architektuře každá událost, která dorazí do služby Event Hubs, aktivuje funkci, která tuto událost zpracuje. Z hlediska nákladů doporučujeme použít plán Consumption, protože platíte jenom za výpočetní prostředky, které používáte.

Azure Cosmos DB

V případě služby Azure Cosmos DB platíte za operace s databází a za úložiště využité vašimi daty.

  • Databázové operace. Způsob, jakým se vám budou účtovat poplatky za databázové operace, závisí na typu účtu služby Azure Cosmos DB, který používáte.
    • V bezserverovém režimu nemusíte při vytváření prostředků v účtu služby Azure Cosmos DB zřizovat žádnou propustnost. Na konci fakturačního období se vám účtuje množství jednotek žádostí spotřebovaných databázovými operacemi.
    • V režimu zřízené propustnosti zadáte propustnost, kterou potřebujete, v jednotkách žádostí za sekundu (RU/s) a fakturuje se po hodinách maximální zřízená propustnost za danou hodinu. Poznámka: Vzhledem k tomu, že model zřízené propustnosti vyhrazuje prostředky kontejneru nebo databázi, bude se vám účtovat propustnost, kterou jste zřídili, i když nespustíte žádné úlohy.
  • Úložiště: Účtuje se vám paušální sazba za celkovou velikost úložiště (v GB) spotřebovaná vašimi daty a indexy za danou hodinu.

V této referenční architektuře ukládá funkce přesně jeden dokument na zařízení, které odesílá data. Funkce průběžně aktualizuje dokumenty o nejnovější stav zařízení pomocí operace upsertu, která je nákladově efektivní z hlediska spotřebovaného úložiště. Další informace najdete v cenovém modelu služby Azure Cosmos DB.

Pomocí kalkulačky kapacity Služby Azure Cosmos DB získáte rychlý odhad nákladů na úlohy.

Nasazení tohoto scénáře

Logo GitHubu Referenční implementace pro tuto architekturu je k dispozici na GitHubu.

Další kroky