Federace více lokalit a více oblastíMulti-site and multi-region federation

Mnoho propracovaných řešení vyžaduje, aby byly stejné datové proudy událostí k dispozici pro použití ve více umístěních, nebo vyžaduje, aby datové proudy událostí byly shromažďovány ve více umístěních a poté konsolidovány do konkrétního umístění pro spotřebu.Many sophisticated solutions require the same event streams to be made available for consumption in multiple locations, or they require event streams to be collected in multiple locations and then consolidated into a specific location for consumption. Často je potřeba rozšířit nebo snížit datové proudy událostí nebo provádět převody formátu událostí, a to i v rámci jedné oblasti a řešení.There's also often the need to enrich or reduce event streams or do event format conversions, also for within a single region and solution.

Prakticky to znamená, že vaše řešení bude uchovávat více Event Hubs, často v různých oblastech a Event Hubsch oborech názvů, a pak mezi nimi replikovat události.Practically, that means your solution will maintain multiple Event Hubs, often in different regions and Event Hubs namespaces, and then replicate events between them. Můžete také vyměňovat události se zdroji a cíli, jako je Azure Service Bus, Azure IoT Hubnebo Apache Kafka.You might also exchange events with sources and targets like Azure Service Bus, Azure IoT Hub, or Apache Kafka.

Udržování více aktivních Event Hubs v různých oblastech taky umožňuje klientům vybírat a přepínat mezi nimi, pokud se jejich obsah slučuje. díky tomu je celkový odolný systém proti problémům s regionální dostupností.Maintaining multiple active Event Hubs in different regions also allows clients to choose and switch between them if their contents are being merged, which makes the overall system more resilient against regional availability issues.

Tato "federace" kapitola vysvětluje vzory federace a způsob, jak tyto vzory realizovat pomocí Azure Stream Analytics bez serveru, nebo Azure Functions modulu runtime, s možností mít v cestě toku událostí vlastní transformaci nebo kód pro obohacení.This "Federation" chapter explains federation patterns and how to realize these patterns using the serverless Azure Stream Analytics or the Azure Functions runtimes, with the option of having your own transformation or enrichment code right in the event flow path.

Vzory federaceFederation Patterns

K dispozici je celá řada možných motivů, proč můžete chtít přesunout události mezi různými Event Hubs nebo jinými zdroji a cíli a vytvořit výčet nejdůležitějších vzorů v této části a také vytvořit odkaz na podrobnější pokyny k příslušnému vzoru.There are many potential motivations for why you may want to move events between different Event Hubs or other sources and targets, and we enumerate the most important patterns in this section and also link to more detailed guidance for the respective pattern.

Odolnost proti událostem regionální dostupnostiResiliency against regional availability events

Dostupnost podle oblastí

I když jsou maximální dostupnost a spolehlivost nejdůležitějšími provozními prioritami Event Hubs, existuje mnoho způsobů, jak může producent nebo spotřebitel zabránit v komunikaci s přiřazeným "primárním" centrem událostí kvůli potížím se sítí nebo překladem IP adres nebo v případě, kdy může centrum událostí skutečně dočasně nereagovat nebo vracet chyby.While maximum availability and reliability are the top operational priorities for Event Hubs, there are nevertheless many ways in which a producer or consumer might be prevented from talking to its assigned "primary" Event Hub because of networking or name resolution issues, or where an Event Hub might indeed be temporarily unresponsive or returning errors.

Tyto podmínky nejsou "katastrofální důsledky", takže budete chtít opustit regionální nasazení úplně, jak můžete dělat při zotavení po havárii , ale obchodní scénář některých aplikací už může mít vliv na události dostupnosti, které posledních nepřesahují více než několik minut nebo dokonce i sekund.Such conditions aren't "disastrous" such that you'll want to abandon the regional deployment altogether as you might do in a disaster recovery situation, but the business scenario of some applications might already be impacted by availability events that last not more than a few minutes or even seconds.

Existují dva základní způsoby řešení těchto scénářů:There are two foundational patterns to address such scenarios:

  • Vzor replikace má za následek replikaci obsahu primárního centra událostí do sekundárního centra událostí, přičemž primární centrum událostí je obecně používané aplikací pro vytváření i využívání událostí a sekundární slouží jako záložní možnost pro případ, že primární centrum událostí nebude k dispozici.The replication pattern is about replicating the contents of a primary Event Hub to a secondary Event Hub, whereby the primary Event Hub is generally used by the application for both producing and consuming events and the secondary serves as a fallback option in case the primary Event Hub is becoming unavailable. Vzhledem k tomu, že replikace je jednosměrná od primární k sekundárnímu, přepnutí obou výrobců i příjemců z nedostupného primárního na sekundární způsobí, že původní primární událost už nebude dostávat nové události, a nebude už tak aktuální.Since replication is unidirectional, from the primary to the secondary, a switchover of both producers and consumers from an unavailable primary to the secondary will cause the old primary to no longer receive new events and it will therefore be no longer current. Čistě replikace je proto vhodná jenom pro jednosměrné scénáře převzetí služeb při selhání.Pure replication is therefore only suitable for one-way failover scenarios. Po provedení převzetí služeb při selhání se stará primární primární událost opuštěna a nové sekundární centrum událostí se musí vytvořit v jiné cílové oblasti.Once the failover has been performed, the old primary is abandoned and a new secondary Event Hub needs to be created in a different target region.
  • Vzor sloučení rozšiřuje model replikace tím, že provádí průběžné sloučení obsahu dvou nebo více Event Hubs.The merge pattern extends the replication pattern by performing a continuous merge of the contents of two or more Event Hubs. Každá událost, která byla původně předložena do jednoho z Event Hubs zahrnutých ve schématu, se replikuje do druhé Event Hubs.Each event originally produced into one of the Event Hubs included in the scheme is replicated to the other Event Hubs. Události se při replikaci přidávají do poznámek tak, že je následně ignoruje proces replikace cíle replikace.As events are replicated, they are annotated such that they are subsequently ignored by the replication process of the replication target. Výsledky použití vzoru sloučení jsou dva nebo více Event Hubs, které budou obsahovat stejnou sadu událostí v rámci trvalého konzistentního způsobem.The results of using the merge pattern are two or more Event Hubs that will contain the same set of events in an eventually consistent fashion.

V obou případech nebude obsah Event Hubs identický.In either case, the contents of the Event Hubs will not be identical. Události od libovolného producenta seskupené podle stejného klíče oddílu se zobrazí ve stejném relativním pořadí jako původně odeslané, ale absolutní pořadí událostí se může lišit.Events from any one producer and grouped by the same partition key will appear in the same relative order as originally submitted, but the absolute order of events may differ. To platí zejména pro situace, kdy se liší počet oddílů zdroje a cíle Event Hubs, což je žádoucí pro některé z rozšířených vzorů, které jsou zde popsané.This is especially true for scenarios where the partition count of source and target Event Hubs differ, which is desirable for several of the extended patterns described here. Rozdělovač nebo směrovač může získat řez mnohem většího centra událostí se stovkami oddílů a trychtýřem do menšího centra událostí s pouze několik oddíly, které jsou vhodnější pro zpracování podmnožiny s omezenými prostředky zpracování.A splitter or router may obtain a slice of a much larger Event Hub with hundreds of partitions and funnel into a smaller Event Hub with just a handful of partitions, more suitable for handling the subset with limited processing resources. V opačném případě může konsolidace odfiltrovat data z několika menších Event Hubs do jediného a většího centra událostí s větším množstvím oddílů, aby se vypořádat s konsolidovanou propustností a požadavky na zpracování.Conversely, a consolidation may funnel data from several smaller Event Hubs into a single, larger Event Hub with more partitions to cope with the consolidated throughput and processing needs.

Kritérium pro zachování událostí společně je klíč oddílu a nikoli původní ID oddílu.The criterion for keeping events together is the partition key and not the original partition ID. Další informace o relativním pořadí a o tom, jak provést převzetí služeb při selhání z jednoho centra událostí do dalšího, aniž by se museli spoléhat na stejný rozsah posunů streamu, najdete v popisu vzoru replikace .Further considerations about relative order and how to perform a failover from one Event Hub to the next without relying on the same scope of stream offsets is discussed in replication pattern description.

SměrnéGuidance:

Optimalizace latenceLatency optimization

Optimalizace latence

Datové proudy událostí jsou jednou výrobci zapisovány, ale mohou být čteny libovolným počtem pokusů od uživatelů událostí.Event streams are written once by producers, but may be read any number of times by event consumers. V případě scénářů, kdy je datový proud událostí v oblasti sdílen více uživateli a je zapotřebí k němu opakovaně přicházet během zpracování analýz nacházející se v jiné oblasti nebo v rámci všech požadavků, které by omezují souběžným spotřebitelům, může být užitečné umístit kopii streamu událostí poblíž analytického procesoru, aby se snížila latence zpětného volání.For scenarios where an event stream in a region is shared by multiple consumers, and needs to be accessed repeatedly during analytics processing residing in a different region, or with throughout demands that would starve out concurrent consumers, it may be beneficial to place a copy of the event stream near the analytics processor to reduce the roundtrip latency.

Dobrými příklady, jak by se replikace měla upřednostnit při vzdáleném zpracování událostí z různých oblastí, jsou obzvláště ta, kde jsou tyto oblasti extrémně navzájem od sebe, a v případě, že se jedná o skoro antipodesou, může být zeměpisná latence a jejich latence pro každou dobu odezvy snadno vyšší než 250 ms.Good examples for when replication should be preferred over consuming events remotely from across regions are especially those where the regions are extremely far apart, for instance Europe and Australia being nearly antipodes, geographically and network latencies can easily exceed 250 ms for any round trip. Rychlost světla nemůžete zrychlit, ale můžete snížit počet cyklů vysoké latence pro interakci s daty.You can't accelerate the speed of light, but you can reduce the number of high-latency round trips to interact with data.

SměrnéGuidance:

Ověřování, snižování a obohaceníValidation, reduction, and enrichment

Ověřování, zmenšení, obohacení

Datové proudy událostí mohou být odesílány do centra událostí od klientů mimo vaše vlastní řešení.Event streams may be submitted into an Event Hub by clients external to your own solution. Tyto datové proudy událostí můžou vyžadovat, aby se pro externě odeslané události kontrolovala kompatibilita s daným schématem a aby se nevyhovující události vynechaly.Such event streams may require for externally submitted events to be checked for compliance with a given schema, and for non-compliant events to be dropped.

Ve scénářích, kdy je u klientů extrémně šířka pásma omezená, protože se jedná o mnoho scénářů "Internet věcí" s měřením šířky pásma nebo kdy se události původně odesílají přes jiné sítě než IP s omezenými velikostmi paketů, můžou být události vyladěny s referenčními daty, aby bylo možné přidat další kontext, který je možné použít pro procesory navazujících událostí.In scenarios where clients are extremely bandwidth constrained as it is the case in many "Internet of Things" scenarios with metered bandwidth, or where events are originally sent over non-IP networks with constrained packet sizes, the events may have to be enriched with reference data to add further context for being usable by downstream event processors.

V jiných případech, zejména při konsolidaci datových proudů, se může stát, že se data události sníží ve složitosti nebo v Sheer velikosti tím, že se vynechají nějaké podrobnosti.In other cases, especially when streams are being consolidated, the event data may have to be reduced in complexity or sheer size by omitting some detail.

Tato operace může nastat jako součást toků replikace, konsolidace nebo sloučení.Any of these operations may occur as part of replication, consolidation, or merge flows.

SměrnéGuidance:

Integrace se službou Analytics ServicesIntegration with analytics services

Integrace se službou Analytics Services

Několik cloudových služeb Azure, jako je například Azure Stream Analytics nebo Azure synapse, nejlépe funguje s datovými proudy nebo předzpracovanými daty z Azure Event Hubs a Azure Event Hubs také umožňuje integraci s několika Open-Source analytickými balíčky, jako je Apache Samza, Apache Flink, Apache Spark a Apache Storm.Several of Azure's cloud-native analytics services like Azure Stream Analytics or Azure Synapse work best with streamed or pre-batched data served up from Azure Event Hubs, and Azure Event Hubs also enables integration with several open-source analytics packages such as Apache Samza, Apache Flink, Apache Spark, and Apache Storm.

Pokud vaše řešení primárně používá Service Bus nebo Event Grid, můžete tyto události snadno zpřístupnit pro tyto analytické systémy a také pro archivaci Event Hubs zachytávání, pokud je rozřadíte do centra událostí.If your solution primarily uses Service Bus or Event Grid, you can make these events easily accessible to such analytics systems and also for archival with Event Hubs Capture if you funnel them into Event Hub. Event Grid se to dá nativně s integrací centra událostí, Service Bus postupovat podle pokynů pro Service Bus replikace.Event Grid can do so natively with its Event Hub integration, for Service Bus you follow the Service Bus replication guidance.

Azure Stream Analytics se integruje přímo s Event Hubs.Azure Stream Analytics integrates with Event Hubs directly.

SměrnéGuidance:

Konsolidace a normalizace datových proudů událostíConsolidation and normalization of event streams

Konsolidace a normalizace datových proudů událostí

Globální řešení se často skládají z oblastí, které jsou z velké části nezávislé, včetně toho, že mají vlastní analytické možnosti, ale Supra-oblastní a globální analytické perspektivy budou vyžadovat integrovanou perspektivu a to je důvod, proč se v příslušných regionálních oblastech pro místní perspektivu vyhodnocuje střední konsolidace stejných proudů událostí.Global solutions are often composed of regional footprints that are largely independent including having their own analytics capabilities, but supra-regional and global analytics perspectives will require an integrated perspective and that's why a central consolidation of the same event streams that are evaluated in the respective regional footprints for the local perspective.

Normalizace je charakter scénáře konsolidace, kdy dva nebo více příchozích datových proudů událostí má stejný druh událostí, ale s různými strukturami nebo různými kódováními a události, které jsou překódovány nebo transformovány předtím, než mohou být spotřebovány.Normalization is a flavor of the consolidation scenario, whereby two or more incoming event streams carry the same kind of events, but with different structures or different encodings, and the events most be transcoded or transformed before they can be consumed.

Normalizace může zahrnovat také kryptografickou práci, jako je dešifrování kompletních šifrovaných datových částí a jejich opětovné šifrování s různými klíči a algoritmy pro cílovou skupinu uživatelů pro příjem dat.Normalization may also include cryptographic work such as decrypting end-to-end encrypted payloads and re-encrypting it with different keys and algorithms for the downstream consumer audience.

SměrnéGuidance:

Rozdělení a směrování datových proudů událostíSplitting and routing of event streams

Rozdělení a směrování datových proudů událostí

Azure Event Hubs se občas používá ve scénářích pro publikování a předplacení, kdy příchozí torrentované události daleko překročily kapacitu Azure Service Bus nebo Azure Event Grid. obě tyto funkce mají nativní možnosti filtrování a distribuce pro publikování a jejich upřednostnění pro tento model.Azure Event Hubs is occasionally used in "publish-subscribe" style scenarios where an incoming torrent of ingested events far exceeds the capacity of Azure Service Bus or Azure Event Grid, both of which have native publish-subscribe filtering and distribution capabilities and are preferred for this pattern.

I když je skutečná schopnost "publikování a odběr" ponechává předplatitelům, aby si vybrali požadované události, dělicí vzorek má za to, že se události mapují na oddíly předem určeným distribučním modelem a určení spotřebitelé pak bude exkluzivně vyčítat z "jejich" oddílu.While a true "publish-subscribe" capability leaves it to subscribers to pick the events they want, the splitting pattern has the producer map events to partitions by a predetermined distribution model and designated consumers then exclusively pull from "their" partition. Když centrum událostí ukládá celkový provoz do vyrovnávací paměti, může se pak obsah konkrétního oddílu, který představuje zlomek původního objemu propustnosti, replikovat do fronty pro spolehlivou a transakční a konkurenční spotřebu zákazníků.With the Event Hub buffering the overall traffic, the content of a particular partition, representing a fraction of the original throughput volume, may then be replicated into a queue for reliable, transactional, competing consumer consumption.

Řada scénářů, ve kterých se Event Hubs primárně používá pro přesun událostí v rámci aplikace v rámci oblasti, má některé případy, kdy je možné vybrat události, které se dají použít jenom v jednom oddílu, ale taky je potřeba je zpřístupnit jinde.Many scenarios where Event Hubs is primarily used for moving events within an application within a region have some cases where select events, maybe just from a single partition, also have to be made available elsewhere. Tento scénář je podobný rozdělení scénáře, ale může používat škálovatelný směrovač, který bere v úvahu všechny zprávy přicházející v centru událostí a výběry určitých položek, a to jenom pár pro další směrování a může odlišit cíle směrování pomocí metadat a obsahu událostí.This scenario is similar to the splitting scenario, but might use a scalable router that considers all the messages arriving in an Event Hub and cherry-picks just a few for onward routing and might differentiate routing targets by event metadata or content.

SměrnéGuidance:

Projekce protokoluLog projections

Projekce protokolu

V některých scénářích budete chtít mít přístup k nejnovější hodnotě odeslané z libovolného podproudu události a běžně rozlišující klíč oddílu.In some scenarios, you will want to have access to the latest value sent for any substream of an event, and commonly distinguished by the partition key. V Apache Kafka to často dosahuje povolením "komprimace protokolů" v tématu, které zahodí všechny nejnovější události označené jedinečným klíčem.In Apache Kafka, this is often achieved by enabling "log compaction" on a topic, which discards all but the latest event labeled with any unique key. Přístup k komprimaci protokolů má tři složené nevýhody:The log compaction approach has three compounding disadvantages:

  • Komprimace vyžaduje nepřetržitou reorganizaci protokolu, což je velmi náročná operace pro zprostředkovatele optimalizovaného pro úlohy, které jsou jenom pro připojení.The compaction requires a continuous reorganization of the log, which is an excessively expensive operation for a broker that is optimized for append-only workloads.
  • Komprimace je destruktivní a neumožňuje pro komprimaci a nezhuštěnou perspektivu stejného datového proudu.Compaction is destructive and does not allow for a compacted and non-compacted perspective of the same stream.
  • Komprimovaný datový proud má stále sekvenční model přístupu, což znamená, že vyhledávání požadované hodnoty v protokolu vyžaduje čtení celého protokolu v nejhorším případě, což obvykle vede k optimalizaci, které implementují přesný vzor, který je uveden zde: projektování obsahu protokolu do databáze nebo do mezipaměti.A compacted stream still has a sequential access model, meaning that finding the desired value in the log requires reading the entire log in the worst case, which typically leads to optimizations that implement the exact pattern presented here: projecting the log contents into a database or cache.

Komprimovaný protokol je nakonec úložištěm klíč-hodnota a jako takový je to nejhorší možná možnost implementace takového úložiště.Ultimately, a compacted log is a key-value store and as such, it is the worst possible implementation option for such a store. Je mnohem efektivnější pro vyhledávání a dotazy k vytvoření a použití trvalé projekce protokolu do správného úložiště hodnot klíčů nebo jiné databáze.It is far more efficient for lookups and for queries to create and use a permanent projection of the log onto a proper key-value store or some other database.

Vzhledem k tomu, že události jsou neměnné a pořadí je vždy zachované v protokolu, jakákoli projekce protokolu do úložiště hodnot klíčů bude vždy identická pro stejnou škálu událostí, což znamená, že projekce, kterou si aktualizujete, vždy poskytne autoritativní zobrazení a nikdy není dobrý důvod k jejich opětovnému sestavení z obsahu protokolu po sestavení.Since events are immutable and the order is always preserved in a log, any projection of a log into a key-value store will always be identical for the same range of events, meaning that a projection you keep updated always provides an authoritative view and there is never any good reason to rebuild it from the log contents once built.

SměrnéGuidance:

Technologie replikačních aplikacíReplication application technologies

Implementace výše uvedených vzorů vyžaduje škálovatelné a spolehlivé spouštěcí prostředí pro úlohy replikace, které chcete nakonfigurovat a spustit.Implementing the patterns above requires a scalable and reliable execution environment for the replication tasks that you want to configure and run. V Azure jsou běhová prostředí, která jsou nejvhodnější pro tyto úlohy, nestavové úlohy, Azure Stream Analytics úlohy replikace stavového streamu a Azure Functions pro nestavové úlohy replikace.On Azure, the runtime environments that are best suited for such tasks are stateless tasks are Azure Stream Analytics for stateful stream replication tasks and Azure Functions for stateless replication tasks.

Aplikace stavové replikace v Azure Stream AnalyticsStateful replication applications in Azure Stream Analytics

U aplikací pro stavovou replikaci, které potřebují zvážit vztahy mezi událostmi, vytvářet složené události, rozšiřovat události nebo snižovat události, vytvářet agregace dat a transformovat datové části událostí, Azure Stream Analytics je nejlepší možností implementace.For stateful replication applications that need to consider relationships between events, create composite events, enrich events or reduce events, create data aggregations, and transform event payloads, Azure Stream Analytics is the best implementation option.

V Azure Stream Analytics vytváříte úlohy , které integrují vstupy a výstupy a integrují data ze vstupů prostřednictvím dotazů , které poskytují výsledek, který je pak k dispozici na výstupech.In Azure Stream Analytics, you create jobs that integrate inputs and outputs and integrate the data from the inputs through queries that yield a result that is then made available on the outputs.

Dotazy jsou založené na jazyce SQL Query a dají se použít k snadnému filtrování, řazení, agregaci a připojení streamování dat v časovém intervalu.Queries are based on the SQL query language and can be used to easily filter, sort, aggregate, and join streaming data over a period of time. Tento jazyk SQL můžete také roztáhnout pomocí uživatelem definovaných funkcí jazyka JavaScript a jazyka C# (UDF).You can also extend this SQL language with JavaScript and C# user-defined functions (UDFs). Můžete snadno upravit možnosti řazení událostí a dobu trvání časových oken při provádění agregačních operací prostřednictvím jednoduchých jazykových konstrukcí nebo konfigurací.You can easily adjust the event ordering options and duration of time windows when performing aggregation operations through simple language constructs and/or configurations.

Každá úloha obsahuje jeden nebo několik výstupů pro transformovaná data a můžete řídit, co se stane v reakci na informace, které jste analyzovali.Each job has one or several outputs for the transformed data, and you can control what happens in response to the information you've analyzed. Můžete například:For example, you can:

  • Odesílání dat do služeb, jako jsou Azure Functions, Service Bus témat nebo front pro aktivaci komunikace nebo vlastních pracovních postupů.Send data to services such as Azure Functions, Service Bus Topics or Queues to trigger communications or custom workflows downstream.
  • Odešlete data na řídicí panel Power BI pro řídicí panel v reálném čase.Send data to a Power BI dashboard for real-time dashboarding.
  • Ukládejte data do jiných služeb úložiště Azure (například Azure Data Lake, Azure synapse Analytics atd.), abyste mohli provádět dávkové analýzy, nebo naučit modely strojového učení na základě velmi rozsáhlých indexovaných fondů historických dat.Store data in other Azure storage services (for example, Azure Data Lake, Azure Synapse Analytics, etc.) to perform batch analytics or train machine learning models based on very large, indexed pools of historical data.
  • V databázích (SQL Database, Cosmos DB ) se ukládají projekce (označované také jako "materializovaná zobrazení").Store projections (also called "materialized views") in databases (SQL Database, Cosmos DB ).

Bezstavové replikační aplikace v Azure FunctionsStateless replication applications in Azure Functions

Pro nestavové úlohy replikace, kde chcete předávané události bez ohledu na jejich datovou část nebo procesy zpracovávat jednotlivě, aniž byste museli brát v úvahu relace událostí (s výjimkou jejich relativního pořadí), můžete použít Azure Functions, což poskytuje značnou flexibilitu.For stateless replication tasks where you want to forward events without considering their payloads or processes them singly without having to consider the relationships of events (except their relative order), you can use Azure Functions, which provides enormous flexibility.

Azure Functions má předem připravené, škálovatelné triggery a výstupní vazby pro azure Event Hubs, azure IoT Hub, Azure Service Bus, Azure Event Grida azure Queue Storagea také vlastní rozšíření pro RabbitMQa Apache Kafka.Azure Functions has prebuilt, scalable triggers and output bindings for Azure Event Hubs, Azure IoT Hub, Azure Service Bus, Azure Event Grid, and Azure Queue Storage, as well as custom extensions for RabbitMQ, and Apache Kafka. Většina aktivačních událostí se dynamicky přizpůsobí požadavkům propustnosti tím, že se počet souběžně prováděných instancí nahoru a dolů na základě dokumentovaných metrik.Most triggers will dynamically adapt to the throughput needs by scaling the number of concurrently executing instances up and down based on documented metrics.

Pro sestavování projekce protokolu Azure Functions podporuje výstupní vazby pro Cosmos DB a Azure Table Storage.For building log projections, Azure Functions supports output bindings for Cosmos DB and Azure Table Storage.

Azure Functions může běžet pod spravovanou identitou Azure a v takovém případě může uchovávat konfigurační hodnoty pro přihlašovací údaje v přísném úložišti řízeném přístupem v rámci Azure Key Vault.Azure Functions can run under a Azure managed identity and with that, it can hold the configuration values for credentials in tightly access-controlled storage inside of Azure Key Vault.

Azure Functions navíc umožňuje úlohám replikace přímo integraci se službami Azure Virtual Networks a koncovými body služby pro všechny služby zasílání zpráv Azure a je snadno integrovaná do Azure monitor.Azure Functions furthermore allows the replication tasks to directly integrate with Azure virtual networks and service endpoints for all Azure messaging services, and it is readily integrated with Azure Monitor.

S plánem Azure Functions spotřeby se předem připravené triggery můžou rovnoměrně škálovat na nulu, zatímco nejsou k dispozici žádné zprávy pro replikaci, což znamená, že se vám neúčtují žádné náklady, aby byla konfigurace připravená na zálohování. klíčovým nevýhodouem použití plánu spotřeby je, že latence pro úlohy replikace "vychází z tohoto stavu" je výrazně vyšší než u plánů hostování, ve kterých je infrastruktura udržována v provozu.With the Azure Functions consumption plan, the prebuilt triggers can even scale down to zero while no messages are available for replication, which means you incur no costs for keeping the configuration ready to scale back up; the key downside of using the consumption plan is that the latency for replication tasks "waking up" from this state is significantly higher than with the hosting plans where the infrastructure is kept running.

Na rozdíl od všech z Apache Kafka nich většina běžných replikačních modulů pro zasílání zpráv a událostí, jako je například nástroje MirrorMaker , vyžaduje, abyste poskytovali hostitelské prostředí a mohli škálovat replikační modul sami.In contrast to all of this, most common replication engines for messaging and eventing, such as Apache Kafka's MirrorMaker require you to provide a hosting environment and scale the replication engine yourself. Který zahrnuje konfiguraci a integraci funkcí zabezpečení a sítě a usnadnění toku dat monitorování, a pak ještě nemáte příležitost k vložení vlastních úloh replikace do toku.That includes configuring and integrating the security and networking features and facilitating the flow of monitoring data, and then you still don't have an opportunity to inject custom replication tasks into the flow.

Výběr mezi Azure Functions a Azure Stream AnalyticsChoosing between Azure Functions and Azure Stream Analytics

Azure Stream Analytics (ASA) je nejlepší volbou, kdykoli potřebujete zpracovat datovou část událostí při jejich replikaci.Azure Stream Analytics (ASA) is the best option whenever you need to process the payload of your events while replicating them. ASA může kopírovat události jednu po jedné nebo může vytvořit agregované hodnoty, které odhustí informace datových proudů událostí před jejich předáním.ASA can copy events one by one or it can create aggregates that condense the information of event streams before forwarding it. Může se snadno vyplynulě doplňovat referenční data uložená v Azure Blob Storage nebo Azure SQL Database bez nutnosti importovat taková data do datového proudu.It can readily lean on complementing reference data held in Azure Blob Storage or Azure SQL Database without having to import such data into a stream.

Pomocí programu ASA můžete snadno vytvářet trvalá a materializovaná zobrazení datových proudů v databázích ve velkém měřítku.With ASA, you can easily create persistent, materialized views of streams in hyper-scale databases. Je to zcela nadřízený přístup k modelu Apache Kafka "komprimace" protokolu clunky a stálým projektům Kafka datových proudů na straně klienta.It's a far superior approach to the clunky "log compaction" model of Apache Kafka and the volatile, client-side table projections of Kafka Streams.

ASA může snadno zpracovávat události s datovými částmi kódovanými ve formátech CSV, JSON a Apache Avro a vlastní deserializace můžete připojit pro jakýkoliv jiný formát.ASA can readily process events having payloads encoded in the CSV, JSON, and Apache Avro formats and you can plug in custom deserializers for any other format.

Pro všechny úlohy replikace, do kterých chcete zkopírovat datové proudy událostí "tak, jak jsou", bez zásahu do datových částí, nebo pokud potřebujete implementovat směrovač, proveďte kryptografickou práci, změňte kódování datových částí nebo pokud potřebujete úplnou kontrolu nad obsahem datového proudu, Azure Functions je nejlepší možností.For all replication tasks where you want to copy event streams "as-is" and without touching the payloads, or if you need to implement a router, perform cryptographic work, change the encoding of payloads, or if otherwise need full control over the data stream contents, Azure Functions is the best option.

Další krokyNext Steps

V tomto článku jsme prozkoumali řadu vzorů federace a v Azure jsme vysvětlili roli Azure Functions jako modul runtime replikace událostí a zasílání zpráv.In this article, we explored a range of federation patterns and explained the role of Azure Functions as the event and messaging replication runtime in Azure.

Dále si můžete přečíst, jak nastavit aplikaci replikátoru pomocí Azure Stream Analytics nebo Azure Functions a pak jak replikovat toky událostí mezi Event Hubs a různými jinými systémy pro zpracování událostí a zpráv:Next, you might want to read up how to set up a replicator application with Azure Stream Analytics or Azure Functions and then how to replicate event flows between Event Hubs and various other eventing and messaging systems: