Novembre 2018

Volume 33 Numero 11

Bus di servizio di Azure - elaborazione con le code del Bus di servizio in background in siti Web

Dal Will Stott

Ho lavorato al Regno Unito Collaborative versione di valutazione di ovarico Cancer Screening (UKCTOCS), quando è verificato un problema. L'incarico di dimostrare una classificazione di regressione logistica che ho avevo sviluppato per un progetto di valutazione, ho iniziato a creare un sito Web semplice e budget ridotto per supportarlo. Ma ho dovuto il sito per supportare l'elaborazione in background a esecuzione prolungata sia avviate il classificatore server on demand.

Era una sfida duale e uno che sono stato in grado di affrontare con tecnologie Microsoft principali. In questo articolo verrà esaminato come sfruttare le code di funzioni di Azure e Bus di servizio per abilitare l'elaborazione in background, mentre in un dato future verrà approfondito il servizio contenitore di Azure e come abilitata su richiesta di provisioning delle risorse del server. In questo secondo articolo vi mostrerò come avviare e terminare un contenitore di Azure usando l'API Azure.Management.Fluent a livello di codice.

Come per il sito Web sottostante e il relativo database, che siano ospitate in Azure come App Web basate su ASP.Net Core 2.1 MVC, Entity Framework e SQL Server standard. Nel caso si ha familiarità con questa tecnologia, ho fornito un articolo complementare sul Web che fornisce istruzioni dettagliate per la creazione di App Web e il relativo database, nonché il provisioning delle risorse di Azure associate. È possibile trovarlo nella msdn.com/magazine/mt830372. Tuttavia, la maggior parte dei lettori devono essere in grado di costruire i requisiti di panoramica sistema illustrata nella figura 1 e il modello OvaryVis illustrato nella Figura2. Veramente, il progetto è semplicemente un modulo Web per l'acquisizione di tre interi che rappresenta le misurazioni effettuate di un ovaie, li salva in un record di database e viene visualizzata una pagina di risultati che mostra se la funzione di classificazione ritiene le dimensioni siano coerenti con quelli di un ovaie.

Figura 1 Panoramica sistema

Figura 2 la classe OvaryVis nella cartella Models

Ricreare il progetto in questo articolo non richiede molto più di competenze di sviluppo Web elementare. Presuppone di avere già creato l'App Web MVC di ASP.NET Core 2.1 e il database SQL Server, nonché le risorse di Azure associate (come descritto nell'articolo complementare). In termini di strumenti, è necessario Visual Studio 2017 v15.7 con .NET Core 2.1 SDK e il carico di lavoro di sviluppo Web. È necessario anche una sottoscrizione di Azure, ma è possibile ottenere le informazioni necessarie gratuitamente se non ha un nuovo cliente. Tutto il codice sorgente e istruzioni per la creazione delle risorse di Azure per la soluzione illustrata nel figura 1 sono disponibili nel repository di GitHub (bit.ly/2NSiIuh).

Panoramica

Un'App Web, come quella sviluppata in questo articolo supporta più utenti stabilendo quali ognuno di essi esperto e restituendo quindi una pagina HTML appropriata (visualizzazione) per ogni browser singoli. Il tempo impiegato per l'App Web restituire una vista determina la velocità di risposta del sito Web e il numero di utenti simultanei che può supportare. Per questo motivo è necessario premere per evitare di processo a esecuzione prolungata quando si ottengono i dati necessari per le visualizzazioni del sito Web. Una coda del Bus di servizio è un buon metodo per risolvere questo tipo di problema, in quanto consente all'App Web di archiviare i messaggi che contiene i dettagli di elaborazione e quindi fornisce una risposta immediata all'utente, anche se è semplicemente una vista con la dicitura tornare a questa pagina in seguito per il risultato. Un altro componente software opera in background per leggere la coda ed eseguire l'elaborazione necessaria per ogni messaggio.

Il vantaggio del Bus di servizio è che quando un numero elevato di utenti venga inviati i dati per la classificazione, la coda è sufficiente diventi più lunga. Sì, questo significa che potrebbe essere necessario attendere i risultati più persone, ma garantisce che il sito Web rimanga reattivo. Associa anche a deprovisioning del sistema separando l'elaborazione di App Web di primo piano del componente che esegue l'elaborazione in background. Servizi di Azure, quali le code di archiviazione, hub eventi ed EventGrid eseguono una funzione simile, ma altri tipi di utilizzo di destinazione. È possibile trovare un utile confronto tra le code di archiviazione di Azure e code del Bus di servizio bit.ly/2QJVwNp, e un confronto tra Azure messaggistica services all'indirizzo bit.ly/2DoY1T5.

Nel caso l'applicazione, coda del Bus di servizio è ideale. È anche economica e molto facile da usare, in particolare dopo che è una buona integrazione con funzioni di Azure, che sono ideali per l'elaborazione in background.

Il provisioning delle risorse di Azure

Azure Cloud Shell è incorporata nel sito Web del portale Azure e consente di eseguire il provisioning delle risorse di Azure usando una serie di semplici comandi dalla Console di PowerShell, come descritto nell'articolo complementare online. Per creare la coda del Bus di servizio di Azure e App per le funzioni, è necessario eseguire i comandi da Cloud Shell, con valori appropriati per la sottoscrizione, gruppo di risorse e località. Questi valori saranno gli stessi utilizzati per eseguire il provisioning dell'app Web e database. È anche necessario assegnare a se stessi un'univoco lo spazio dei nomi del Bus di servizio anziché MSDNOvaryVisSBQ. Ecco i comandi da usare:

az account set --subscription MsdnOvaryVis
az servicebus namespace create  --name MSDNOvaryVisSBQ --location "WestEurope"
  --resource-group resMSDNOvaryVis --sku Basic
az servicebus queue create --name dimsubmission --namespace-name MSDNOvaryVisSBQ
  --resource-group resMSDNOvaryVis --max-size 1024

Si noterà che si è optato per il livello di servizio più basso (-sku Basic), che mi consente di ricevere 1 milione di messaggi fino a 256KB ogni dimensione per 0,05 dollari senza costi mensili. Oltre a creare una coda del Bus di servizio è anche necessario creare un'app per le funzioni e un nuovo account di archiviazione, come illustrato di seguito:

az storage account create -name msdnovaryvisstorageac
  --resource-group resMSDNOvaryVis
  --location "WestEurope" --sku Standard_LRS
az functionapp create --name MSDNOvaryVisFnApp --resource-group resMSDNOvaryVis
  --storage-account msdnovaryvisstorageac --consumption-plan-location westeurope

Il nome del servizio app di funzione è accessibile pubblicamente, pertanto sarà necessario immettere il proprio nome anziché MSDNOvaryVisFnApp. Si noti anche che crea i primi risultati di funzioni di Azure per la creazione di un piano a consumo, ovvero come l'addebito di utilizzo, anche se per un progetto di questa natura il costo deve essere quasi nulla.

Intenzione di Microsoft è creare funzioni di Azure senza la necessità di eseguire in modo esplicito il provisioning di un server per l'esecuzione, noti come l'esecuzione senza server. Microsoft utilizza i piani di consumo per la fatturazione ai clienti basati solo su frequenza viene eseguita una funzione, il tempo impiegato per l'esecuzione e la quantità di memoria utilizzata. Sì, è possibile ottenere una fattura a prezzo fisso designando eseguire il servizio app di funzioni di Azure nella stessa macchina virtuale (VM) dell'App Web, ma questa opzione non è disponibile per le app Web che usano infrastruttura condivisa. Di conseguenza per questo progetto, è più conveniente usare un piano a consumo rispetto a aggiornare il piano di servizio app Web.

A questo punto è possibile applicare le impostazioni dell'applicazione per la nuova app per le funzioni per completare la fase di provisioning. Si noti che con quella per il Bus di servizio, è necessario sostituire il valore della connessione MMM copiando la stringa di connessione primaria RootManageSharedAccessKey dal relativo pannello criteri di accesso condiviso nel portale di Azure. Il codice è il seguente:

az functionapp config appsettings set --name MSDNOvaryVisFnApp
  --resource-group resMSDNOvaryVis --settings 'AzureServiceBusQueueName=dimsubmission'
az functionapp config appsettings set --name MSDNOvaryVisFnApp
  --resource-group resMSDNOvaryVis --settings 'AzureWebJobsServiceBus=MMM’
az functionapp config appsettings set --name MSDNOvaryVisFnApp
  --resource-group resMSDNOvaryVis
  --settings 'FUNCTIONS_EXTENSION_VERSION=2.0.12050.0'

Naturalmente, nell'ambiente di produzione codice si creerebbe una chiave aggiuntiva nel Pannello di criteri di accesso condiviso con sufficiente inviare i privilegi e quindi usare la stringa di connessione invece di quello dalla chiave radice. È anche necessario essere consapevoli che la funzione di Azure viene eseguita in un runtime comune, che possa cambiare se si tratta di un aggiornamento a meno che non si definisce una versione specifica usando l'impostazione FUNCTIONS_EXTENSION_VERSION.

Ho scoperto la necessità di specificare il runtime come il disco rigido, come Microsoft ha aggiornato il runtime di versioni non definitive che lavoravo con subito dopo è stata completata l'attività di sviluppo per questo articolo, causando la funzione improvvisamente smettere di funzionare. Fortunatamente, ero in grado di forzare funzioni di Azure per usare una versione specifica del runtime per assicurarsi che la funzione potrebbe essere eseguita solo su un server con lo stesso runtime usato durante lo sviluppo. È difficile immaginare che tali modifiche di rilievo ad accadere dopo che il runtime è stata attivata alle versioni beta, ma si tratta di qualcosa di utile esserne a conoscenza. È possibile visualizzare la versione di runtime per funzioni personalizzate, visitare il pannello impostazioni dell'app funzioni di Azure nel portale di Azure.

Implementazione di un servizio App di funzioni di Azure

La funzione di Azure necessarie per eseguire un sito Web l'elaborazione in background verrà sviluppata da un progetto di app di funzione di Azure Visual Studio. Il modello necessario viene installato nel PC come parte di .NET Core 2.1 SDK e il carico di lavoro di sviluppo Web.

Creazione di un progetto funzioni di Azure richiede meno di un minuto. Prima di tutto aprire la finestra di dialogo Nuovo progetto (File | Nuovo progetto), selezionare le funzioni di Azure dalla cartella dei modelli Cloud nell'oggetto visivo C# e specificare un nome adatto per il progetto (OvaryVisFnApp), rendendo che Aggiungi a soluzione è selezionato. Nella finestra di dialogo successiva specificare il tipo di progetto (in questo caso, vuoto) e selezionare l'account di archiviazione appena creato. Il nuovo progetto OvaryVisFnApp verrà quindi visualizzata in Esplora soluzioni con un set iniziale di file.

Questo è un buon momento per assicurarsi di avere le versioni più recenti dei pacchetti necessari per il progetto. Questi sono visualizzati nella finestra della soluzione di NuGet quando si fa clic su strumenti | Gestione pacchetti NuGet | Gestisci pacchetti NuGet per la soluzione. Ho utilizzato le operazioni seguenti per questo articolo, ma è possibile provare le versioni successive per il proprio lavoro:

• V2.0.3 netstandard. Library
• Microsoft.NET.Sdk.Functions v1.0.19

Per implementare la funzione di Azure stesso, è necessario aggiungere una nuova classe al progetto OvaryVisFnApp. Nuovo Visual Studio offre supporto ottimale. Selezionare il progetto, fare doppio clic su Aggiungi | Nuova funzione di Azure e nome del file OvaryVisSubmitProc.cs. Selezionare quindi i Trigger della coda del Bus di servizio come tipo di funzione di Azure per creare con AzureWebJobsServiceBus dimsubmission come il nome della coda e impostazione della stringa di connessione (vedere figura 3). In questo modo viene creata la classe necessaria, che è necessario aggiornare fornendo myQueueItem del log. Parametro Info, come indicato di seguito:

public static class OvaryVisSubmitProc
{
  [FunctionName("OvaryVisSubmitProc")]
  public static async Task Run([ServiceBusTrigger("dimsubmission", 
    Connection = "AzureWebJobsServiceBus")]string myQueueItem,
    TraceWriter log)
  {
    log.Info(myQueueItem));
  }
}

Figura 3 Creazione di una funzione di Azure per il servizio del Bus di Trigger della coda

È importante ricordare che AzureWebJobsServiceBus è il nome dell'impostazione dell'applicazione che è applicata per l'app per le funzioni di Azure in precedenza, mentre dimsubmission è il nome effettivo della coda del Bus di servizio.

A questo punto è possibile pubblicare il progetto funzioni di Azure. Questa operazione viene eseguita in gran parte identico a quello dell'app Web, che ho descritto nell'articolo complementare: selezionare il progetto e fare doppio clic su pubblica. È necessario selezionare un servizio App di funzione di Azure esistente (invece di nuovo) in modo che è possibile pubblicare il progetto alla risorsa MSDNOvaryVisFnApp creato in precedenza. Modo suggerito, MSDNOvaryVisFnApp cartella verrà visualizzato il gruppo di risorse nella finestra di dialogo successiva. L'unica cosa da preoccuparsi è che il servizio App di Azure è stata interrotta prima della pubblicazione da Visual Studio, perché le DLL non possono essere sovrascritto quando è in uso da un processo in esecuzione. È possibile ottenere questo risultato eseguendo il comando seguente da Cloud Shell:

az functionapp stop --name MSDNOvaryVisFnApp --resource-group resMSDNOvaryVis

Dopo aver pubblicato il progetto, è possibile avviare il servizio, entrambi emettendo un comando di avvio da Cloud Shell oppure fare clic sul pulsante start nel Pannello di panoramica, come illustrato nella figura 4.

Figura 4 pannello della panoramica del servizio App funzioni di Azure

Test della funzione nel portale di Azure è una buona idea a questo punto, in particolare se è già stata aperta nel Pannello di panoramica del servizio App di funzione di Azure. La funzione OvaryVisSubmitProc è elencata a sinistra del pannello e selezione di questa viene visualizzata una pagina che consente di eseguire la verifica, anche se potrebbe essere necessario fare clic sull'elemento di Test nel menu a destra verticale per visualizzare questa pagina completamente.

La pagina di Test non è particolarmente vera e propria, come si può notare nel figura 5, ma è utile. La prima cosa devi fare è digitare un messaggio appropriato nella finestra di corpo della richiesta, ad esempio, "hello world". Questa stringa in un secondo momento verrà sostituito dall'ID record OvaryVis create dall'app Web metodo HomeController.Index (HttpPost). Tuttavia, tenere presente questo messaggio può avere contenuto molto più grande e complesso, nonché i metadati per descrivere payload e la gestione delle istruzioni (per altre informazioni su esso, vedere il documento messaggistica servizio di Azure, "Messaggi, payload e serializzazione" in bit.ly/2OCnIjX). In effetti, a seconda del livello di servizio selezionati, è possibile creare le code del Bus di servizio in grado di contenere fino a 80 GB di messaggi con ogni messaggio in fase di dimensioni fino a 1 MB.

Pannello di Test nella figura 5 funzioni di Azure App Service

Dopo aver creato il testo del corpo di richiesta nella pagina di Test, è necessario fare clic su Esegui per simulare un evento viene inviato a funzioni di esecuzione. L'elaborazione dell'evento sono consultabili nella finestra del Log mostrato nella parte inferiore della figura 5. Si noti che il valore del campo dati nel log è uguale a quello nel corpo della richiesta. Quando la funzione viene restituito, si verificherà un messaggio di stato 202-accettato da visualizzare nella pagina di Test. Ciò indica che la funzione e il servizio App di funzione di Azure funzioni correttamente.

L'invio di messaggi alla coda del Bus di servizio da un'App Web

Si presume che è già stata creata un'app Web come quello descritto nell'articolo online associato. È sufficiente disporre di due metodi del Controller che gestiscono la creazione di una vista con un modulo semplice e la relativa registrazione successivi all'App Web. In questo caso che è una classe HomeController con metodi di indice per HttpGet e HttpPost.

Installazione del pacchetto nel progetto dell'app Web Azure.ServiceBus consentirà di utilizzare il componente necessario per l'invio di un messaggio di evento alla coda del Bus di servizio. La Console di gestione pacchetti NuGet di Visual Studio consente di aggiungere questi pacchetti, come descritto in Microsoft Docs in bit.ly/2QIiOmZ. È necessario aprire la console dal menu Strumenti (strumenti | Gestione pacchetti NuGet | Package Manager Console) e quindi eseguire il comando seguente:

Install-Package Microsoft.Azure.ServiceBus -Version 3.1.0 -Project OvaryVisWebApp

Le dipendenze come WebJobs.Extensions.ServiceBus (3.0.0-beta8), viene inoltre installato in modo che a questo punto è tutto ciò che occorre per inviare messaggi alla coda del Bus di servizio.

A questo punto è possibile configurare il client di coda del Bus di servizio. Ciò è necessario passare ad esso il nome della coda e la relativa connessione. Ho trovato più pratico mantenere questi valori come impostazioni di configurazione dell'applicazione, in modo che inizializzato il client di coda del Bus di servizio nel costruttore di classe di avvio dell'app Web, come illustrato nella figura 6. Ho quindi usato Cloud Shell per consentire i comandi seguenti, sostituendo nuovamente MMM con la stessa stringa di connessione del Bus di servizio utilizzata in precedenza durante l'impostazione di app per le funzioni di Azure:

az webapp config appsettings set --name MSDNOvaryVisWebApp
  --resource-group resMSDNOvaryVis --settings 'OvaryVisServiceBus:QueueName=dimsubmission'
az webapp config appsettings set --name MSDNOvaryVisWebApp
  --resource-group resMSDNOvaryVis --settings 'OvaryVisServiceBus:Connection=MMM'

Si vedrà nella figura 6 che il client di coda viene mantenuto in una variabile statica, che è inizialmente impostato come null e quindi inizializzata dal metodo SetupServiceBus. L'uso di blocco rende questo metodo prova di thread, mentre tale _queueClient il test è null evita più di un client che viene costruito. È eccessivo per un'app Web in quanto la classe di avvio viene inizializzata una sola volta, ma consente il metodo SetupServiceBus da copiare alla funzione di Azure si creerà nel prossimo articolo, in cui sarà necessario questo meccanismo di protezione.

Figura 6 configurare il Client di coda del Bus di servizio nella classe di avvio dell'App Web

public class Startup
{
  private static IQueueClient _queueClient = null;
  private static readonly object _accesslock = new object();
  private static void SetupServiceBus(string connection, string queueName)
  {
    lock (_accesslock)
    {
      if (_queueClient == null)
        _queueClient = new QueueClient(connection, queueName);
    }
  }
  public static IQueueClient GetQueueClient() { return _queueClient; }
  public Startup(IConfiguration configuration)
  {
    Configuration = configuration;
    SetupServiceBus(Configuration["OvaryVisServiceBus:Connection"],
      Configuration["OvaryVisServiceBus:QueueName"]);
  }
}

Successivamente, è necessario aggiornare il metodo HttpPost Index della classe HomeController in modo che il relativo codice è simile a quello illustrato figura 7. In questo modo è possibile inviare un messaggio di evento alla coda del Bus di servizio nello stesso modo che è stato fatto con la pagina di Test di servizio App di Azure (funzione). Tuttavia, è anche necessario aggiungere le seguenti istruzioni using all'inizio del file:

using Microsoft.Azure.ServiceBus;
using System.Net.Http;

Verrà visualizzato da figura 7 che dopo aver salvato inizialmente i dati del form come record nella tabella OvaryVis, si crea un oggetto di messaggio con il relativo corpo impostato come stringa dell'ID record. Dopo che si creerà ed eseguirà l'App Web in locale (CTRL+F5), la pagina dei risultati visualizzerà processo creato come relativo StatusMsg dopo l'invio del modulo della pagina di indice. Inoltre, noterete il valore di ID record visualizzato nel log di funzione di Azure del portale. Ciò indica che non solo riuscite durante il salvataggio di un record nel database, ma anche stato trasmesso il relativo ID per la funzione di Azure. Eseguire ora è sufficiente aggiornare la funzione di Azure in modo che usa questo ID per leggere il record corrispondente dal database nella funzione di Azure.

Figura 7 indice HomeController metodo

[HttpPost]
[ValidateAntiForgeryToken]
public async Task<IActionResult> Index([Bind("Id,D1mm,D2mm,D3mm")] OvaryVis form)
{
  OvaryVis record = new OvaryVis
  {
    D1mm = form.D1mm,  // First ovary dimension
    D2mm = form.D2mm,  // Second ovary dimension
    D3mm = form.D3mm,  // Third ovary dimension
    JobSubmitted = DateTime.UtcNow,
    ResultVis = -1,    // Result code: -1 = not yet processed 
    StatusMsg = String.Format("Job Created at {0}",
      DateTime.UtcNow.ToString("HH:mm:ss"))
  };
                       // Add record to database
  _context.Add(record);
  await _context.SaveChangesAsync();
                       // Send message with ID value to Service Bus Queue
  var message = new Message(Encoding.UTF8.GetBytes(record.Id));
  await Startup.GetQueueClient().SendAsync(message);
                       // Call Result method to return Result page
  return RedirectToAction("Result", new { id = record.Id });
}

Aggiunta di Entity Framework per la funzione di Azure

Entity Framework fornisce un modo semplice per il recupero del record OvaryVis dal database utilizzando il valore di ID passato nel messaggio dell'evento del Bus di servizio. Implementazione prevede l'aggiunta del pacchetto di Entity Framework per il progetto funzioni di Azure, usando la stessa Console di gestione pacchetti utilizzati per installare il pacchetto del Bus di servizio, come illustrato di seguito:

Install-Package Microsoft.EntityFrameworkCore.SqlServer
  -Project OvaryVisFnApp –version 2.1.2

È inoltre necessario fornire una stringa di connessione in modo che la funzione di Azure possono accedere ai Database SQL di Azure. Questa è la stessa stringa di connessione usata dall'app Web ed è migliore impostazione dalle impostazioni di applicazioni di funzioni di Azure, che è accessibile dal relativo pannello di panoramica del portale illustrato nella figura 4. È necessario scorrere fino alla sezione di stringhe di connessione e quindi fare clic su Aggiungi nuova stringa di connessione con il nome DefaultConnection, digitare SQLAzure e il valore seguente, anche se con il nome del proprio server di database e il nome utente e la password:

Server=tcp:msdnovaryvisdbsvr.database.windows.net,1433;Database=Msdn.OvaryVisDb;
  User  ID=XXX;Password=YYY;Encrypt=true;Connection Timeout=30;

Dopo aver aggiunto la stringa, non dimenticare di scorrere nuovamente verso l'alto e fare clic su Salva.

L'ultima operazione da eseguire per accedere al database da funzioni di Azure è la classe DataContext e la classe di modello OvaryVis dal progetto dell'app Web per il progetto dell'app funzioni. È necessario modificare lo spazio dei nomi di entrambi i file in OvaryVisFnApp, ma in caso contrario, dovrebbe essere possibile ricompilare la soluzione senza problemi (premere F7). Infine, è necessario implementare il metodo seguente e quindi chiamarlo dal metodo di esecuzione della funzione OvaryVisSubmitProc. Il codice è il seguente:

private static async Task<string> FormSubmittedProc(IConfigurationRoot config,
  ApplicationDbContext dbContext, string queueItem)
{
  string rc = "FormSubmittedProc: ";
  var record = await dbContext.OvaryVis.SingleOrDefaultAsync(a => a.Id == queueItem);
  if (record == null)
    rc += string.Format("record not found: Id={0}", msg.Id);
  else
    rc += string.Format("record Id={0} found, ", record.Id);
  return rc;
}

Il parametro di configurazione passato a FormSubmittedProc dal metodo per eseguire funzioni di Azure viene ottenuto usando ConfigurationBuilder e fornisce l'accesso per le impostazioni dell'applicazione, compresa la stringa di connessione di database. Ciò viene quindi usato per creare l'oggetto ApplicationDbContext che costituisce il secondo parametro. È possibile trovare i dettagli di implementazione esatta nel download del codice di esempio. 

Aver completato il lavoro di sviluppo di questo articolo, quindi è ora per ricompilare la soluzione di Visual Studio, pubblicare il progetto di app di funzioni di Azure e assegnargli un rapido test fumo. Se si apre Azure funzione pannello del servizio App Test che descritto in precedenza (figura5), si dovrebbe essere il record ovaie Id visualizzato nel log ogni volta che si invia un formato di input dal sito Web, come illustrato nel figura 8 . Ciò indica che la funzione di Azure ha rilevato il record corrispondente al valore dell'Id contenuto nel messaggio del Bus di servizio inviato dall'app Web, in modo che tutte le parti del sistema illustrato nella figura 1 funzionino come previsto.

Figura 8, il sito Web di Input per Form e pagina di risultati

Conclusioni

Vale la pena riflettenti Azure rende semplice per sviluppare un meccanismo per tutti i siti Web di elaborazione in background affidabile. Con un sito di produzione, si desidera fornire un modo per aggiornare la pagina dei risultati automaticamente, anziché affidarsi utente premendo F4, ma non è troppo difficile da ottenere tramite SignalR o un meccanismo simile. Tuttavia, il provisioning di una coda di servizio App di funzione di Azure e Bus di servizio è stato raggiunto con pochi comandi dal portale di Azure e l'integrazione con il Controller Home dell'app Web è necessaria solo poche righe di codice.

Dispone di una quantità estremamente ridotta associati costi per questo tipo di implementazione oltre all'addebito mensile piccolo per un server di database e piano di servizio App. Se si esegue il livello gratuito del piano di servizio App, è necessario essere in grado di ospitare un sito Web di test per inferiori ai costi dei criteri utente personalizzati di un paio di caffè mese. Questo rende una soluzione davvero interessante.

Nel prossimo articolo, illustrato come estendere una funzione di Azure inviando i valori delle dimensioni del record per la funzione di classificazione in esecuzione in un server di provisioning da un'immagine Docker. Si verrà inoltre informazioni su come avviare automaticamente il server quando il traffico arriva al sito Web e quindi arrestarlo dopo che termina il traffico, l'implementazione di un server on demand che viene addebitato solo il tempo effettivo utilizzato.

Dr. Will Stottha più di 25 anni di esperienza come appaltatore/consulente per un'ampia gamma di aziende nel Regno Unito ed Europa, tra cui IBM, Cap Gemini, Logica CMG e Accenture. Tuttavia, negli ultimi 10 anni la maggior parte del suo tempo impiegato per le ricerche alla University College London (LCS) sul cancro ovarico Screening. Dr. Stott è intervenuto a numerose conferenze a livello internazionale sia nel Regno Unito. È anche l'autore di documenti pubblicati in diverse riviste, nonché il libro "Visual Studio Team System: Migliorare lo sviluppo di Software per i team Agile"(Addison-Wesley Professional, 2007).

Grazie al seguente esperto tecnico Microsoft per la revisione dell'articolo: David Barkol

Discutere di questo articolo nel forum di MSDN Magazine