Applicazioni e attività di replica di messaggi

Come illustrato nell'articolo sulla replica dei messaggi e sulla federazione tra aree, la replica di sequenze di messaggi tra coppie di entità bus di servizio e tra bus di servizio e altre origini e destinazioni dei messaggi si appoggia in genere a Funzioni di Azure.

Funzioni di Azure è un ambiente di esecuzione scalabile e affidabile per la configurazione e l'esecuzione di applicazioni serverless, incluse le attività di replica dei messaggi e di federazione.

In questa panoramica verranno fornite informazioni sulle funzionalità predefinite di Funzioni di Azure per tali applicazioni, sui blocchi di codice che è possibile adattare e modificare per le attività di trasformazione e su come configurare un'applicazione Funzioni di Azure in modo che si integri idealmente con bus di servizio e altri servizi di messaggistica di Azure. Per molti dettagli, questo articolo farà riferimento alla documentazione di Funzioni di Azure.

Che cos'è un'attività di replica?

Un'attività di replica riceve gli eventi da un'origine e li inoltra a una destinazione. La maggior parte delle attività di replica inoltra gli eventi invariati e al massimo esegue il mapping tra le strutture di metadati se i protocolli di origine e di destinazione differiscono.

Le attività di replica sono in genere senza stato, ovvero non condividono lo stato o altri effetti collaterali tra esecuzioni sequenziali o parallele di un'attività. Ciò vale anche per l'invio in batch e il concatenamento, che possono essere implementati entrambi sullo stato esistente di un flusso.

Ciò rende le attività di replica diverse dalle attività di aggregazione, che sono in genere con stato e sono il dominio di framework di analisi e servizi come Analisi di flusso di Azure.

Applicazioni e attività di replica in Funzioni di Azure

In Funzioni di Azure, un'attività di replica viene implementata usando un trigger che acquisisce i messaggi di input da un'origine configurata e un'associazione di output che inoltra i messaggi copiati dall'origine a una destinazione configurata.

Le attività di replica vengono distribuite nell'applicazione di replica tramite gli stessi metodi di distribuzione di qualsiasi altra applicazione Funzioni di Azure. È possibile configurare più attività nella stessa applicazione.

Con Funzioni di Azure Premium, più applicazioni di replica possono condividere lo stesso pool di risorse sottostante, denominato piano di servizio app. Ciò significa che è possibile collocare facilmente le attività di replica scritte in .NET con attività di replica scritte in Java, ad esempio. Ciò è importante se si vuole sfruttare librerie specifiche, ad esempio Apache Camel, disponibili solo per Java e se queste sono l'opzione migliore per un percorso di integrazione specifico, anche se in genere si preferisce un linguaggio e un runtime diversi per le altre attività di replica.

Quando disponibile, è consigliabile preferire i trigger orientati al batch rispetto ai trigger che recapitano singoli eventi o messaggi ed è sempre necessario ottenere l'evento completo o la struttura dei messaggi anziché basarsi sulle espressioni di associazione di parametri della funzione di Azure.

Il nome della funzione deve riflettere la coppia di origine e destinazione che si sta connettendo ed è necessario anteporre riferimenti a stringa di connessione o altri elementi di configurazione nei file di configurazione dell'applicazione con tale nome.

Mapping di dati e metadati

Dopo aver deciso una coppia di trigger di input e binding di output, è necessario eseguire un mapping tra i diversi tipi di evento o messaggio, a meno che il tipo di trigger e l'output non siano uguali.

Per attività di replica semplici che copiano i messaggi tra Hub eventi e bus di servizio, non è necessario scrivere codice personalizzato, ma può essere basato su una libreria di utilità fornita con gli esempi di replica.

Criteri di ripetizione

Per evitare la perdita di dati durante l'evento di disponibilità su entrambi i lati di una funzione di replica, è necessario configurare i criteri di ripetizione dei tentativi in modo che siano affidabili. Fare riferimento alla documentazione Funzioni di Azure sui tentativi per configurare i criteri di ripetizione dei tentativi.

Le impostazioni dei criteri scelte per i progetti di esempio nel repository di esempio configurano una strategia di backoff esponenziale con intervalli di ripetizione da 5 secondi a 15 minuti con tentativi infiniti per evitare la perdita di dati.

La versione disponibile a livello generale dei criteri di ripetizione dei tentativi per Funzioni di Azure supporta solo hub eventi e trigger timer. Il supporto dell'anteprima per tutti gli altri trigger è stato rimosso.

Configurazione di un host dell'applicazione di replica

Un'applicazione di replica è un host di esecuzione per una o più attività di replica.

Si tratta di un'applicazione Funzioni di Azure configurata per l'esecuzione nel piano a consumo o (scelta consigliata) in un piano Funzioni di Azure Premium. Tutte le applicazioni di replica devono essere eseguite con un'identità gestita assegnata dal sistema o assegnata dall'utente.

I modelli di Azure Resource Manager (ARM) collegati creano e configurano un'applicazione di replica con:

• Un account Archiviazione di Azure per tenere traccia dello stato di avanzamento della replica e dei log.
• Identità gestita assegnata dal sistema.
• Monitoraggio di Azure e integrazione di Application Insights per il monitoraggio.

Le applicazioni di replica che devono accedere a Hub eventi associate a una rete virtuale di Azure devono usare il piano Funzioni di Azure Premium e essere configurate per connettersi alla stessa rete virtuale, che è anche una delle opzioni disponibili.

	Distribuzione	Visualizzare
Piano a consumo di Funzioni di Azure
piano Funzioni di Azure Premium
Funzioni di Azure piano Premium con rete virtuale

Esempi

Il repository di esempi contiene diversi esempi di attività di replica che copiano eventi tra Hub eventi e/o tra entità bus di servizio.

Per copiare i dati degli eventi tra hub eventi, usare un trigger di Hub eventi con un'associazione di output di Hub eventi:

[FunctionName("telemetry")]
[ExponentialBackoffRetry(-1, "00:00:05", "00:05:00")]
public static Task Telemetry(
    [EventHubTrigger("telemetry", ConsumerGroup = "$USER_FUNCTIONS_APP_NAME.telemetry", Connection = "telemetry-source-connection")] EventData[] input,
    [EventHub("telemetry-copy", Connection = "telemetry-target-connection")] EventHubClient outputClient,
    ILogger log)
{
    return EventHubReplicationTasks.ForwardToEventHub(input, outputClient, log);
}

Per copiare i messaggi tra bus di servizio entità, usare il trigger di bus di servizio e l'associazione di output:

[FunctionName("jobs-transfer")]
[ExponentialBackoffRetry(-1, "00:00:05", "00:05:00")]
public static Task JobsTransfer(
    [ServiceBusTrigger("jobs-transfer", Connection = "jobs-transfer-source-connection")] Message[] input,
    [ServiceBus("jobs", Connection = "jobs-target-connection")] IAsyncCollector<Message> output,
    ILogger log)
{
    return ServiceBusReplicationTasks.ForwardToServiceBus(input, output, log);
}

I metodi helper possono semplificare la replica tra Hub eventi e bus di servizio:

Monitoraggio

Per informazioni su come monitorare l'app di replica, vedere la sezione relativa al monitoraggio della documentazione di Funzioni di Azure.

Uno strumento visivo particolarmente utile per il monitoraggio delle attività di replica è la mappa delle applicazioni di Application Insights, generata automaticamente dalle informazioni di monitoraggio acquisite e consente di esplorare l'affidabilità e le prestazioni dell'origine dell'attività di replica e i trasferimenti di destinazione.

Per informazioni dettagliate di diagnostica immediate, è possibile usare lo strumento del portale delle metriche attive, che offre una visualizzazione a bassa latenza dei dettagli del log.

Passaggi successivi

• distribuzioni Funzioni di Azure
• Diagnostica di Funzioni di Azure
• Opzioni di rete Funzioni di Azure
• Azure Application Insights