Il presente articolo è stato tradotto automaticamente.

Microsoft Azure

Diffusione dei sistemi orientati ai flussi di eventi

Christopher Bennage

Si tratta di dati in questi giorni. Dati ci aiuta a prendere decisioni informate. Dati Big ci aiuta a prendere decisioni informate e penetranti. Grandi flussi di dati ci aiutano a prendere decisioni informate, penetranti e tempestive. Questi scorre continuamente flussi di dati sono spesso chiamati flussi di eventi. È sempre più comune per costruire sistemi di software con lo scopo principale è quello di elaborare flussi di eventi.

Anche attraverso diverse industrie e domini, c'è un modello architettonico comune percepibile attorno a questi sistemi orientati al flusso di eventi. Questo pattern per sistemi orientati al flusso moderno evento svolge lo stesso ruolo fondamentale che l'architettura classica livelli tenuto per sistemi aziendali tradizionali locali. Potrai iniziare esplorando uno schizzo delle miniature di questo modello nascente.

Identificare il modello

In primo luogo, io dovrei chiarire cosa si intende per l'evento di termine. Qui, significa semplicemente un po' di dati che significa che qualcosa è successo in un sistema. Gli eventi tendono ad essere di piccole dimensioni, nell'intervallo di byte o kilobyte. Sentirete anche termini come messaggio, telemetria o anche soli dati al posto dell'evento.

Successivamente, ci sono produttori di evento. Questi produttori potrebbero essere quasi nulla — collegato automobili, termostati intelligenti, console di gioco, dispositivi di fitness personale o anche un sistema di software che generano self -­eventi diagnostici. È importante riconoscere, però, che nella maggior parte di questi sistemi, hai a che fare con numerosi produttori di evento.

Molti sistemi di anticipano i numeri dei produttori di eventi in decine di migliaia e che vanno in decine di milioni o più. Ciò significa che questi sistemi tendono ad avere sia ad alto volume e ad alta velocità. Alto volume significa che c'è un sacco di dati complessivo e ad alta velocità significa che i dati vengono generati frequentemente.

Ci sono anche i consumatori evento. I consumatori sono il vero cuore di questi tipi di sistemi. Sono responsabili per analizzare, interpretare e rispondere agli eventi. Il numero dei consumatori in un tipico sistema potrebbe variare da un paio di un paio di dozzine. Gli eventi non sono indirizzati ai consumatori specifici. Ogni consumatore è guardando lo stesso insieme di eventi. Nel contesto della Microsoft Azure, i consumatori sono più probabili servizi cloud.

Si consideri questo esempio. C'è un flusso di eventi che rappresentano le operazioni finanziarie. I produttori di evento in questo scenario sono sistemi POS nei negozi al dettaglio. Un consumatore possiede la responsabilità di analizzare il flusso per attività fraudolente e generare avvisi. Un altro consumatore analizza il flusso stesso per rendere le ottimizzazioni di catena di fornitura just-in-time. Infine, un terzo dei consumatori sono responsabili per tradurre gli eventi in frigoconservazione a lungo termine per analitica successiva.

Quando combinato con la realtà dell'alto volume e ad alta -­eventi di velocità, questo modello di produttori e consumatori presenta alcuni interessanti problemi:

• Come evitare picchi di produzione evento da consumatori schiaccianti? Ovvero, come dovrebbe il sistema risponde quando il tasso di produzione evento inizia a superare il tasso di consumo?
• Perché evento velocità è alta, come si può scalare un consumer di eventi individuali?

La chiave del problema è utilizzare un broker di evento (vedere Figura 1). Questo è precisamente il ruolo interpretato dalla mozzi evento Azure rilasciato di recente.

Figura 1 architettura Hub evento azzurro

Così come, esattamente, operazione usando un broker come evento mozzi risolve i problemi che ho descritto finora?

Capire l'evento mozzi

Mozzi evento fornisce l'elasticità necessaria per assorbire e persistono eventi finché possono raggiungere consumatori a valle. Evento mozzi possono efficacemente livello fuori variabilità nel caso il tasso di flusso quindi i consumatori non devono preoccupare. Senza questo livellamento, un consumatore ricevente potrebbe diventare sopraffatto e cominciano a fallire.

Usando un broker consente di isolare l'evento produttori e consumatori di evento da altro. Questo isolamento è particolarmente importante nelle versioni più sofisticate del modello architettonico dove intermediari supplementari sono necessari tra i produttori e i consumatori. Mozzi di evento è un punto di composizione, una cucitura o un limite nell'architettura. Tutti i componenti che interagiscono attraverso un Hub di evento non richiedono conoscenze specifiche di ogni altro.

A questo punto, potrebbe essere facile confondere l'evento mozzi con tradizioni­zionale enterprise messaging services che offrono lo stesso tipo di isolamento. Tuttavia, evento mozzi è diversa in molti modi chiave che lo rendono ideale per questo modello architettonico.

Consumatori indipendenti

Evento Hub utilizza una pubblicazione e sottoscrizione modello; Tuttavia, ogni consumatore ha una visione indipendente del flusso stesso evento. In alcuni sistemi di messaggistica tradizionali con più utenti, i messaggi vengono copiati per ogni consumatore interessato. Questo può essere inefficiente in termini di velocità e spazio, ma il vantaggio è che ogni consumatore ha il proprio "inbox". Come un consumatore elabora i messaggi, li rimuove dalla sua casella di posta. Non non c'è alcun effetto su altri consumatori perché hanno le proprie copie nelle proprie caselle di posta.

Con mozzi evento, c'è un insieme di eventi immutabili e, perche ' sono immutabili, ci deve solo essere una copia di ogni evento. Allo stesso modo, i consumatori mai rimuovere eventi dal sistema. Tutti i consumatori stanno guardando la stessa serie di eventi. Per questo motivo, i consumatori proprio la responsabilità di tenere traccia di dove sono nell'evento streaming. Lo fanno di loro offset nel flusso di eventi di rilevamento. C'è effettivamente un'API per questo integrato nel SDK.

Basato sul tempo ritenzione

Nei sistemi di messaggistica tradizionali, il consumatore è responsabile per raccontare il sistema quando è fatto con il messaggio. Il sistema quindi può sbarazzarsi del messaggio. Perché un consumatore evento mozzi è responsabile per la propria posizione all'interno del flusso di eventi di rilevamento, come un Hub di evento sa quando il consumatore è fatto con gli eventi? In breve, non è così. Con mozzi di evento, si configura un periodo di conservazione e gli eventi vengono memorizzati per quel lasso di tempo. Questo significa eventi scadano il proprio, indipendente da qualsiasi azione dei consumatori.

L'implicazione di basati sul tempo di ritenzione è che il consumatore deve esaminare ed elaborare gli eventi prima che scadano. Con conservazione basate sul tempo, ogni consumatore ha pressione per tenere il passo. Fortunatamente, il disegno sottostante dell'evento mozzi lascia scala singoli consumatori come necessario.

Evento hub supporta questa da è partizionamento fisicamente il flusso di eventi. Impostare il numero di partizioni quando un Hub eventi di provisioning. Vedere la documentazione ufficiale presso bit.ly/11QAxOY per maggiori dettagli.

Come eventi vengono pubblicati in un Hub di evento, hanno sei disposto in partizioni. Un dato evento risiede in un'unica partizione. Gli eventi sono distribuiti uniformemente per impostazione predefinita in partizioni in modo round robin. Ci sono meccanismi per fornire l'affinità della partizione. I più comuni ti consente di impostare una proprietà chiave di partizione su un evento, e tutti gli eventi con la stessa chiave saranno consegnati alla partizione stessa.

Come un flusso di eventi partizionata aiuta i consumatori con conservazione basate sul tempo? Nel contesto dell'evento mozzi, il termine corretto è in realtà il gruppo dei consumatori. La ragione di chiamarlo un gruppo è che davvero ogni consumatore è costituito da più istanze. Ogni gruppo ha un'istanza per ogni partizione. Da questo punto, gruppo di consumatori si riferisce al consumatore nel suo complesso e istanza consumer il membro del gruppo interessato ad una particolare partizione.

Questo significa che un gruppo di consumatori in grado di elaborare gli eventi di flusso in parallelo. Ogni istanza di consumatore nel gruppo può elaborare una partizione indipendente da altre istanze. Queste istanze del consumatore possono risiedere in una sola macchina, con ogni istanza di consumatore in esecuzione in isolamento uno da altro. Essi potrebbero tutti essere distribuiti su più computer, anche al punto di ogni istanza di consumatore in esecuzione su una casella dedicata. In questo modo, evento mozzi aggira alcuni dei tipici problemi connessi con il modello classico di consumatori concorrenti.

L'isolamento è un concetto chiave qui. In primo luogo, stai isolando evento produttori e consumatori di eventi da altro, permettendo così la composizione architettura flessibile, così come caricare il livellamento. In secondo luogo, gruppi di consumatori sono isolati gli uni dagli altri, riducendo la possibilità per i fallimenti CSS attraverso gruppi di consumatori. In terzo luogo, le istanze dei consumatori in un gruppo di consumatori determinato sono isolate gli uni dagli altri per consentire il ridimensionamento orizzontale per gruppi di consumatori individuali.

Utilizzare l'evento mozzi

Ci sono diversi buoni tutorial per iniziare con mozzi di evento. Consultare la documentazione ufficiale presso bit.ly/11QAxOY e seguire il tutorial che utilizza la piattaforma di vostra scelta.

Sarà necessario eseguire il provisioning di un Hub di evento prima. Il processo è semplice. È facilmente possibile provare con un account trial azzurro. Nel portale di gestione Azure, passare alla sezione servizio Bus. Sarà necessario creare uno spazio dei nomi del servizio autobus, se non avete già uno. Dopo di che, vedrai una scheda denominata evento mozzi che ha le istruzioni per la creazione di un Hub di evento (vedere Figura 2).

Figura 2 creare un Hub di evento

È inoltre necessario configurare un criterio di accesso condiviso per l'Hub di evento prima di iniziare. Queste politiche gestire la sicurezza per un evento Hub. Nel portale, passare all'Hub evento appena creato e selezionare la scheda Configura.

Scegliere Gestisci per le autorizzazioni e dare alla politica un nome come "super" o "-non-uso-in-produzione." Dopo di che, tornare alla scheda Dashboard e cliccare il pulsante informazioni di connessione nella parte inferiore. Ti consigliamo di prendere nota della stringa di connessione, come pure il nome che hai dato il tuo Hub di evento.

Produrre eventi

Il codice che vi mostrerò qui utilizza .NET SDK, ma è possibile utilizzare qualsiasi piattaforma che supporti HTTP o AMQP. Sarà necessario fare riferimento al pacchetto Microsoft Azure Service Bus NuGet. Le classi che necessarie sono nel namespace Microsoft.ServiceBus.Messaging. Tutto quello che dovete fare è creare un client, creare un evento e inviare:

var client = EventHubClient.CreateFromConnectionString (
  connectionString,
  eventHubName);
var body = Encoding.UTF8.GetBytes("My first event");
var eventData = new EventData (body);
await client.SendAsync (eventData);

Nonostante la semplicità, ci sono alcuni interessanti elementi da sottolineare. Il corpo dell'evento è una matrice di byte. I gruppi di consumatori questo evento di elaborazione dovrà saper interpretare questi byte. È probabile che i gruppi di consumatori saranno necessario una sorta di suggerimento per determinare come deserializzare il corpo. Prima che l'evento viene inviato, i metadati possono essere fissati:

eventData.Properties.Add ("event-type", "utf8string");

Questo significa che utilizzando le chiavi e i valori che sono ben noti da gruppi di consumatori e produttori. Se si desidera garantire che una serie di eventi viene consegnata alla stessa partizione, è possibile impostare una chiave di partizione:

eventData.PartitionKey = "something-meaningful-to-your-domain";

Otterrai prestazioni migliori se gli eventi non hanno affinità con le partizioni. In alcuni casi, però, ti consigliamo una serie di eventi correlati, indirizzato a un'istanza del singolo consumatore per l'elaborazione. Eventi in una determinata partizione sono garantiti per essere in ordine in che cui sono stati ricevuti. Analogamente, non non c'è alcun modo semplice per garantire l'ordine degli eventi in diverse partizioni in un Hub di evento. Questa è spesso la motivazione per eventi di volere avere affinità per una particolare partizione.

Ad esempio, se si stanno abilitando automobili intelligenti, si desidera che tutti gli eventi per una determinata macchina per essere nella stessa partizione. È possibile scegliere il numero di identificazione veicolo (VIN) per la chiave di partizione. O sistema potrebbe concentrarsi su edifici intelligenti, con centinaia di dispositivi in ogni edificio di produzione di eventi. In tal caso, è possibile utilizzare l'identità dell'edificio stesso come partizione chiave così tutti gli eventi da tutti i dispositivi nella stessa terra edificio nella stessa partizione.

Nel complesso, affinità di partizione è una pratica pericolosa e dovrebbe solo usarlo con cautela. Una scelta povera di chiave di partizione può comportare una distribuzione irregolare di evento attraverso partizioni. Questo potrebbe significare, infine, gruppi di consumatori avrebbe problemi di ridimensionamento. La buona notizia è che molte volte è possibile cambiare il design di sistema per evitare la necessità di affinità di partizione.

Utilizzare gli eventi

Può essere preoccupati per come potrai gestire tutto questo. Vostro consumatore gruppi bisogno di tenere traccia delle loro offset streaming dell'evento. Ogni gruppo ha bisogno di un'istanza per ogni partizione. Fortunatamente, c'è un'API per questo.

Il pacchetto di NuGet Microsoft Azure Service Bus evento Hub-evento di riferimento­ProcessorHost. Le classi che necessarie sono nel namespace Microsoft.ServiceBus.Messaging. Iniziare è semplice come implementa una singola interfaccia: IEventProcessor.

Una volta che tu hai implementato elaboratore di evento, si creerà un'istanza di EventProcessorHost per registrare il tuo processore evento. L'host gestirà tutto il lavoro sporco per voi. Quando avvia, esaminerà proprio Hub di evento per vedere quante partizioni ha. Creerà quindi una sola istanza del vostro processore di evento per ogni partizione disponibile.

Ci sono tre metodi da implementare. I primi due sono OpenAsync e CloseAsync. L'host chiama OpenAsync quando l'istanza del processore di evento è prima concesso un contratto di locazione di partizione. Questo significa che l'istanza dell'evento processore ha accesso esclusivo alla partizione per il gruppo di consumatore in questione. Allo stesso modo, l'host chiama CloseAsync quando si perde la sua locazione o quando sta spegnendo. Mentre sta per iniziare, è possibile utilizzare un'implementazione molto semplice:

public Task OpenAsync(PartitionContext context)
{
  return Task.FromResult(true);
}
public Task CloseAsync(PartitionContext context, CloseReason reason)
{
  return Task.FromResult(true);
}

Entrambi i metodi ricevono un argomento PartitionContext. Il metodo rimanente, riceve pure. Se si desidera visualizzare informazioni dettagliate sulla specifica partizione affittato al processore evento, è possibile esaminare questo argomento. Il metodo finale è dove si ricevono gli eventi (Vedi Figura 3).

Figura 3 il metodo finale che recapita gli eventi

public async Task ProcessEventsAsync (PartitionContext context, 
  IEnumerable<EventData> messages)
{
  foreach (var message in messages)
  {
    var eventType = message.Properties["event-type"];
    var bytes = message.GetBytes();
    if (eventType.ToString() == "utf8string") {
      var body = System.Text.Encoding.UTF8.GetString (bytes);
      // Do something interesting with the body
    } else {
      // Record that you don't know what to do with this event
    }
  }
  await context.CheckpointAsync();
  // This is not production-ready code
}

Come potete vedere, l'operazione è semplice. Ricevete un insieme enumerabile di eventi è possibile scorrere e fare qualsiasi lavoro è necessario. Hai anche questa invocazione del contesto.CheckpointAsync alla fine del metodo. Questo spiega l'host si hai elaborata correttamente questa serie di eventi e si desidera registrare un checkpoint. Il checkpoint è l'offset dell'ultimo evento nel batch.

Ecco come il gruppo di consumatori può tenere traccia di quali eventi sono stati elaborati per ogni partizione. Una volta avviato un host, tenta di acquisire un contratto di locazione per qualsiasi partizione disponibile. Quando inizia l'elaborazione per una partizione, esaminerà le informazioni dei checkpoint per la partizione. Solo gli eventi più recenti rispetto all'ultimo checkpointed offset sono inviati ai loro rispettivi processori.

L'host fornisce anche carico automatico livellamento tra le macchine. Ad esempio, supponiamo che abbiate un evento Hub con 16 partizioni. Questo significa che ci saranno 16 istanze del vostro processore evento — uno per ogni partizione. Se si sta eseguendo l'host su una singola macchina, crea tutte le 16 istanze sulla stessa macchina. Se si avvia un altro host su una seconda macchina ed è parte dello stesso gruppo di consumatori, i due host inizierà a livello della distribuzione delle istanze processore evento attraverso le due macchine. Ci saranno alla fine otto eventi processore istanze per ogni macchina. Allo stesso modo, se si prende la seconda macchina, poi il primo host riprende indietro le partizioni orfane.

Assumere che un'implementazione di IEventProcessor è MyEventProcessor. Quindi un'istanza host può essere semplice come questo:

var host = new EventProcessorHost(
  hostName,
  eventHubName,
  consumerGroupName,
  eventHubConnectionString,
  checkpointConnectionString);
await host.RegisterEventProcessorAsync<MyEventProcessor>();

Il eventHubConnectionString ed eventHubName sono gli stessi valori utilizzati durante l'invio di eventi nell'esempio precedente. È meglio utilizzare le stringhe di connessione con le politiche di accesso condiviso che limitano l'utilizzo di solo ciò che è necessario.

Il nome host identifica l'istanza dell'EventProcessorHost. Quando si esegue l'host di un cluster (cioè più macchine), è consigliabile che è fornire un nome che riflette l'identità del computer su cui è in esecuzione.

L'argomento consumerGroupName identifica il gruppo di consumatore logico che rappresenta questo host. C'è un gruppo predefinito di consumatori è possibile fare riferimento mediante la costante EventHubConsumer­Group.DefaultGroupName. Qualsiasi altro nome si richiede prima disposizione il gruppo di consumatori. Fare questo creando un'istanza di Microsoft.ServiceBus.NamespaceManager e utilizzando metodi come CreateConsumerGroupAsync.

Infine, è necessario fornire una stringa di connessione a un account di Azure Storage mediante checkpointConnectionString. Questo account di archiviazione è dove l'host tracce tutti stato per quanto riguarda le partizioni e compensazioni di evento. Questo stato viene memorizzato in BLOB in testo normale, che è possibile esaminare prontamente.

Ci sono altri servizi Azure integrate con mozzi evento out-of-the-box. Azure Stream Analitica (attualmente in Preview) fornisce una sintassi simile a SQL dichiarativa per trasformare e analizzando i flussi di eventi originari evento mozzi. Similarmente, evento mozzi offre un beccuccio per la tempesta di Apache molto popolare, ora disponibile in anteprima su Azure attraverso HDInsight.

Il confezionamento

Il modello architettonico descritto qui è solo l'inizio. Quando si implementa un sistema reale, ci sono numerose altre preoccupazioni che sarà necessario prendere in considerazione. Queste preoccupazioni riguardano sicurezza avanzata, il provisioning e la gestione dell'evento produttori, traduzione di protocollo, comunicazione in uscita e più. Tuttavia, ora sei equipaggiato con i concetti fondamentali necessari per costruire un sistema che utilizza un broker di evento come evento mozzi.

Christopher Bennage è un membro dei modelli Microsoft &pratiche squadra.  Gli piace fare le cose con i computer.

Grazie ai seguenti esperti tecnici Microsoft per la revisione di questo articolo: Mostafa Elhemali e Dan Rosanova