Novembro de 2018
Volume 33 – Número 11
Barramento de Serviço do Azure — Processamento em segundo plano do Site da Web com Filas do Barramento de Serviço
Por Will Stott
Eu estava trabalhando no United Kingdom Collaborative Trial of Ovarian Cancer Screening (UKCTOCS), quando encontrei um problema. Encarregado da demonstração de um classificador de regressão logística que eu havia desenvolvido para um projeto de avaliação, eu comecei a criar um site simples e com baixo orçamento para dar suporte a ele. Mas eu precisava que o site desse suporte ao processamento em segundo plano de execução longa e à inicialização do servidor do classificador sob demanda.
Era um desafio com dois lados, mas que consegui resolver usando as principais tecnologias da Microsoft. Neste artigo, vou explorar como utilizei as filas do Azure Functions e do Barramento de Serviço para habilitar o processamento em segundo plano, enquanto em um artigo futuro me abordarei com mais detalhes o Serviço de Contêiner do Azure e como ele permitiu o provisionamento sob demanda dos recursos do servidor. Neste segundo artigo, mostrarei como iniciar e encerrar, programaticamente, um contêiner do Azure usando a API Azure.Management.Fluent.
O site subjacente e seu banco de dados estão hospedados no Azure como um aplicativo Web padrão baseado em ASP.Net Core 2.1 MVC, Entity Framework e SQL Server. Caso você não esteja familiarizado com essa tecnologia, eu disponibilizei um artigo complementar na Web que fornece instruções passo a passo para criar o aplicativo Web e seu banco de dados, bem como para provisionar os recursos do Azure associados. Você pode encontrá-lo em msdn.com/magazine/mt830372. No entanto, a maioria dos leitores deve ser capaz de construir o que é necessário a partir da visão geral do sistema mostrada na Figura1 e do modelo de OvaryVis mostrado na Figura 2. Na verdade, o projeto é apenas um formulário Web que captura os três números inteiros que representam medidas de um ovário, salva-os em um registro de banco de dados e exibe uma página de resultados que mostra se o classificador considera as dimensões consistentes com as de um ovário.
.png "Visão geral do sistema")
Figura 1 Visão geral do sistema
.png "A classe OvaryVis na pasta Modelos")
Figura 2 A classe OvaryVis na pasta Modelos
Recriar o projeto neste artigo não exige muito mais do que habilidades básicas de desenvolvimento Web. Suponho que você já tenha criado o aplicativo Web do ASP.NET Core 2.1 MVC e seu banco de dados do SQL Server, bem como os recursos do Azure associados (que são descritos no artigo complementar). Em termos de ferramentas, você precisará do Visual Studio 2017 v15.7 com o SDK do .NET Core 2.1 e a carga de trabalho de desenvolvimento Web. Você também precisará de uma assinatura do Azure, mas você pode obter o que você precisa gratuitamente se for um novo cliente. Todos os códigos-fonte e instruções para criar os recursos do Azure para a solução mostrada na Figura1 estão disponíveis no repositório do GitHub (bit.ly/2NSiIuh).
Visão geral
Um aplicativo Web, como o desenvolvido para este artigo, suporta vários usuários decidindo o que cada um deles deseja e, em seguida, retornando uma página HTML apropriada (Modo de Exibição) para cada navegador individual. O tempo necessário para o aplicativo Web retornar um modo de exibição determina a capacidade de resposta do seu site e o número de usuários simultâneos que ele suporta. Por esse motivo, há uma necessidade crítica de evitar um processo de execução longa ao obter os dados necessários para seus modos de exibição do site. Uma Fila do Barramento de Serviço é uma boa maneira de resolver esse tipo de problema, pois permite que seu aplicativo Web armazene mensagens que contêm os detalhes de processamento e, em seguida, fornece uma resposta imediata para o usuário, mesmo se for apenas um modo de exibição que diga para voltar mais tarde para obter o resultado. Outro componente de software opera em segundo plano para ler a fila e executar o processamento necessário para cada mensagem.
A vantagem do Barramento de Serviço é que quando vários usuários estão enviando dados para classificação, a fila simplesmente fica mais longa. Sim, isso significa que talvez seja necessário que as pessoas aguardem os resultados, mas garante que o site permaneça responsivo. Ele também desacopla seu sistema, separando o processamento do aplicativo Web em primeiro plano do componente que executa o processamento em segundo plano. Os serviços do Azure, como filas de Armazenamento, Hubs de Eventos e Grade de Eventos executam uma função semelhante, mas servem para outros tipos de uso. Você pode encontrar uma comparação útil entre as filas de Armazenamento do Azure e as filas do Barramento de Serviço em bit.ly/2QJVwNp, e uma comparação dos serviços de mensagens do Azure em bit.ly/2DoY1T5.
No caso do meu aplicativo, a fila do Barramento de Serviço é a opção ideal. Ele também é barato e muito fácil de usar, especialmente agora que há uma boa integração com o Azure Functions, o que é perfeito para fazer meu processamento em segundo plano.
Provisionar recursos do Azure
O Azure Cloud Shell é incorporado ao site do Portal do Azure e permite provisionar recursos do Azure usando uma série de comandos simples no Console do PowerShell, conforme descrito no artigo complementar online. Para criar a fila do Barramento de Serviço do Azure e o Aplicativo de funções você deve emitir comandos do Cloud Shell com valores apropriados para sua assinatura, grupo de recursos e local. Esses valores serão os mesmos que foram usados para provisionar seu aplicativo Web e o banco de dados. Você também precisará conceder a você mesmo um único namespace do Barramento de Serviço em vez de MSDNOvaryVisSBQ. Estes são os comandos que devem ser usados:
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
Você perceberá que eu optei pela camada de serviço mais baixa (--sku Basic), que me permite receber 1 milhão de mensagens de até 256KB cada por US$ 0,05 sem custo mensal. Além de criar uma fila do Barramento de Serviço você também precisa criar um Aplicativo de funções e uma nova conta de armazenamento para ele, conforme mostrado aqui:
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
O nome do serviço do Aplicativo de função é acessível publicamente, portanto, você precisará inserir seu próprio nome no lugar de MSDNOvaryVisFnApp. Observe também que criar sua primeira função do Azure resulta na criação de um plano de consumo, que é como você será cobrado pelo uso, embora para um projeto dessa natureza, o custo deve ser quase zero.
A intenção da Microsoft é que você crie o Azure Functions sem precisar provisionar explicitamente um servidor para executá-lo, essa é a chamada execução sem servidor. A Microsoft usa planos de consumo para cobrar os clientes com base apenas na frequência com que uma função é executada, no tempo que ela leva para ser executada e na quantidade de memória que ela usa. Sim, você pode obter uma conta com um preço fixo ao optar por executar o serviço de aplicativo do Azure Functions na mesma máquina virtual (VM) que o seu aplicativo Web, mas essa opção não está disponível para aplicativos Web que usam a infraestrutura compartilhada. Como resultado, para este projeto, era mais barato usar um plano de consumo do que atualizar meu plano do serviço do aplicativo Web.
Agora vamos aplicar as configurações do aplicativo ao novo Aplicativo de funções para concluir a etapa de provisionamento. Observe que você deve substituir o valor de conexão MMM pelo valor do seu Barramento de Serviço, copiando a cadeia de conexão primária RootManageSharedAccessKey da sua folha de Políticas de acesso compartilhado no Portal do Azure. Eis o código:
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'
É claro que, no código de produção, você criaria uma chave adicional na folha de Políticas de acesso compartilhado com privilégios de apenas enviar e, em seguida, usaria essa cadeia de conexão em vez da cadeia de conexão da chave da raiz. Você também deve estar ciente de que sua função do Azure é executada em um tempo de execução comum, que pode ser alterado se houver uma atualização, a menos que você defina uma versão específica usando a configuração de FUNCTIONS_EXTENSION_VERSION.
Eu descobri a necessidade de especificar meu tempo de execução da maneira mais difícil, pois a Microsoft atualizou o tempo de execução de pré-lançamento com o qual eu estava trabalhando logo depois que eu concluí o trabalho de desenvolvimento para este artigo, fazendo com que a minha função parasse de funcionar repentinamente. Felizmente, eu consegui forçar o Azure Functions a usar uma versão específica do tempo de execução para garantir que minha função pudesse ser executada apenas em um servidor com o mesmo usado tempo de execução que foi usado durante o desenvolvimento. Não espero que essas alterações que geram falha aconteçam agora que o tempo de execução entrou em suas versões beta, mas é algo que vale a pena saber. Você pode ver a versão do tempo de execução para suas próprias funções, visitando a folha de Configurações do Aplicativo de funções do Azure no Portal do Azure.
Implementar um Serviço de Aplicativo de funções do Azure
A função do Azure necessária para executar o processamento em segundo plano do seu site será desenvolvida a partir de um projeto de Aplicativo de funções do Azure do Visual Studio. O modelo necessário está instalado em seu computador como parte do SDK do .NET Core 2.1 e da carga de trabalho de desenvolvimento Web.
Criar um projeto de função do Azure leva menos de um minuto. Primeiro, abra a caixa de diálogo Novo projeto (Arquivo | Novo projeto), selecione o Azure Functions da pasta de Modelo de nuvem no Visual C# e forneça um nome adequado para seu projeto (OvaryVisFnApp), verificando se Adicionar a solução está selecionado. Na caixa de diálogo seguinte, forneça o tipo do projeto (neste caso, Vazio) e selecione a conta de armazenamento que você acabou de criar. O novo projeto OvaryVisFnApp será então exibido no Gerenciador de Soluções, junto com um conjunto inicial de arquivos.
Agora é um bom momento para verificar se você tem as versões mais recentes dos pacotes necessários para o projeto. Eles são exibidos na janela de Solução de NuGet quando você clica em Ferramentas | Gerenciador de pacotes NuGet | Gerencie pacotes NuGet para solução. Usei o seguinte para este artigo, mas você talvez queira experimentar as versões posteriores para seu próprio trabalho:
- NETStandard.Library v2.0.3
- Microsoft.NET.Sdk.Functions v1.0.19
Para implementar a função do Azure em si, você precisará adicionar uma nova classe ao seu projeto OvaryVisFnApp. Novamente, o Visual Studio fornece um bom suporte. Selecione o projeto, clique com o botão direito do mouse em Adicionar | Nova função do Azure e nomeie o arquivo OvaryVisSubmitProc.cs. Em seguida, selecione o Gatilho de Fila do Barramento de Serviço como o tipo de função do Azure para criar com AzureWebJobsServiceBus como a configuração da cadeia de conexão e dimsubmission como o nome da fila (consulte a Figura 3). Isso cria a classe necessária, que você deve atualizar fornecendo myQueueItem como o parâmetro log.Info, da seguinte maneira:
public static class OvaryVisSubmitProc
{
[FunctionName("OvaryVisSubmitProc")]
public static async Task Run([ServiceBusTrigger("dimsubmission",
Connection = "AzureWebJobsServiceBus")]string myQueueItem,
TraceWriter log)
{
log.Info(myQueueItem));
}
}
.png "Criar uma função do Azure para o Gatilho de Fila do Barramento de Serviço")
Figura 3 Criar uma função do Azure para o Gatilho de Fila do Barramento de Serviço
Lembre-se de que AzureWebJobsServiceBus é o nome da configuração do aplicativo aplicada ao seu aplicativo de funções do Azure anteriormente, enquanto dimsubmission é o nome real da sua fila do Barramento de Serviço.
Agora você pode publicar seu projeto do Azure Functions. Isso é feito em grande parte da mesma forma que o aplicativo Web, que eu descrevo no artigo complementar: selecione o projeto e clique com o botão direito do mouse em Publicar. Você precisa selecionar um Serviço de Aplicativo de funções do Azure existente (em vez de um novo) para que você possa publicar seu projeto para o recurso MSDNOvaryVisFnApp que você criou anteriormente. Felizmente, o MSDNOvaryVisFnApp aparece na pasta de Grupo de Recursos na caixa de diálogo seguinte. A única coisa com a qual você se deve preocupar é que o Serviço de Aplicativo do Azure é interrompido antes de publicar no Visual Studio, já que suas DLLs não podem ser substituídas enquanto estiverem sendo usadas por um processo em execução. Você pode conseguir isso emitindo o seguinte comando a partir do Cloud Shell:
az functionapp stop --name MSDNOvaryVisFnApp --resource-group resMSDNOvaryVis
Após publicar com êxito o seu projeto, você pode iniciar o serviço, emitindo um comando de início do Cloud Shell, ou clicando no botão Iniciar na folha de Visão geral, conforme mostrado na Figura 4.
.png "Folha de Visão Geral do Serviço de Aplicativo de funções do Azure")
Figura 4 Folha de Visão Geral do Serviço de Aplicativo de funções do Azure
Testar sua função no Portal do Azure é uma boa ideia neste ponto, especialmente se você já tiver aberto a folha de Visão Geral do Serviço de Aplicativo de funções do Azure. A função OvaryVisSubmitProc está listada no lado esquerdo da folha e selecioná-la exibe uma página que permite testá-la, embora você talvez precise clicar no item Teste no menu vertical à direita para exibir esta página totalmente.
A página de Teste não é particularmente bonita, como você pode ver na Figura 5, mas é útil. A primeira coisa que você precisa fazer é digitar uma mensagem apropriada na caixa do corpo da solicitação, por exemplo, “Olá, mundo”. Posteriormente, substituiremos essa cadeia de caracteres pela ID de registro de OvaryVis criada pelo método HomeController.Index (HttpPost) do aplicativo Web. No entanto, lembre-se de que essa mensagem pode ter um conteúdo muito maior e mais complexo, bem como metadados para descrever o conteúdo e as instruções de manipulação (para obter mais informações sobre isso, consulte o documento Mensagens de serviço do Azure, “Mensagens, conteúdo e serialização”, em bit.ly/2OCnIjX). Na verdade, dependendo da camada de serviço selecionada, você pode criar filas do Barramento de Serviço capazes de armazenar até 80 GB de mensagens com cada mensagem tendo até 1 MB de tamanho.
.png "Folha de Teste do Serviço de Aplicativo de funções do Azure")
Figura 5 Folha de Teste do Serviço de Aplicativo de funções do Azure
Depois de criar o texto do Corpo da solicitação na página de Teste, você precisa clicar em Executar para simular um evento que está sendo enviado para sua função de Execução. O processamento desse evento pode ser visto na janela de Log, mostrada na parte inferior da Figura 5. Você deve observar que o valor do campo de dados no log é o mesmo do corpo da solicitação. Quando a função retornar, ela exibirá uma mensagem Status 202 Aceito na página de Teste. Isso indica que sua função e o Serviço de Aplicativo de Funções do Azure estão funcionando corretamente.
Enviar mensagens à fila do Barramento de Serviço a partir de um aplicativo Web
Presume-se que você já compilou um aplicativo Web como o descrito no artigo online que acompanha este artigo. Ele só precisa ter dois métodos do Controlador que lidam com a criação de um modo de exibição com um formulário simples e o seu lançamento subsequente de volta para o aplicativo Web. Em nosso caso, é um HomeController com métodos de Índice para HttpGet e HttpPost.
Instalar o pacote Azure.ServiceBus em seu projeto de aplicativo Web permitirá que ele use o componente necessário para enviar uma mensagem de evento para sua fila do Barramento de Serviço. O console do gerenciador de pacotes NuGet do Visual Studio permite adicionar esses pacotes, conforme descrito no Microsoft Docs em bit.ly/2QIiOmZ. Você deve abrir o console no menu Ferramentas (Ferramentas | Gerenciador de Pacotes NuGet | Console do Gerenciador de Pacotes) e, em seguida, emitir o seguinte comando:
Install-Package Microsoft.Azure.ServiceBus -Version 3.1.0 -Project OvaryVisWebApp
Isso também instala dependências como WebJobs.Extensions.ServiceBus (3.0.0-beta8), portanto, agora você deve ter tudo o que precisa para enviar mensagens para a fila do Barramento de Serviço.
Agora é hora de configurar o cliente da fila do Barramento de Serviço. Isso exige que você passe a ele o nome da fila e sua conexão. Achei mais conveniente manter esses valores como parâmetros de configuração de aplicativo, então inicializei o cliente da fila do Barramento de Serviço no construtor de classe de inicialização do aplicativo Web, conforme mostrado na Figura 6. Em seguida, usei o Cloud Shell para fornecer os seguintes comandos, substituindo novamente MMM pela mesma cadeia de conexão do Barramento de Serviço usada anteriormente durante a configuração do aplicativo de funções do 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'
Você verá na Figura 6 que o cliente da fila é mantido em uma variável estática, que é inicialmente definida como null e, em seguida, inicializada pelo método SetupServiceBus. O uso de bloqueio torna esse método seguro contra threads, enquanto testar se esta _queueClient é nula evita que mais de um cliente seja construído. Esse é um exagero para um aplicativo Web, já que a classe de inicialização é inicializada apenas uma vez, mas permitirá que o método SetupServiceBus seja copiado para a Função do Azure que você criará no próximo artigo, onde essa proteção será necessária.
Figura 6 Configurar o cliente da fila do Barramento de Serviço na classe de inicialização do aplicativo 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"]);
}
}
Em seguida, eu precisei atualizar o método de índice HttpPost da classe HomeController, para que seu código ficasse como o mostrado na Figura 7. Isso permite que você envie uma mensagem de evento para a fila do Barramento de Serviço da mesma forma que você fez usando a página de Teste do Serviço de Aplicativo de funções do Azure. No entanto, você também precisa adicionar as seguintes instruções na parte superior do arquivo:
using Microsoft.Azure.ServiceBus;
using System.Net.Http;
Você verá na Figura 7 que depois de salvar inicialmente os dados de formulário como um registro na tabela OvaryVis, você cria um objeto Mensagem com o corpo definido como a cadeia de caracteres de ID do registro. Depois de compilar e executar o aplicativo Web localmente (Ctrl + F5), a página Resultados exibe Trabalho Criado na sua Mensagem de status após o envio do formulário da Página de índice. Além disso, você verá o valor da ID de registro exibido no log de função do Azure no Portal. Isso indica que você não apenas teve êxito ao salvar um registro no banco de dados, mas você também transmitiu sua ID para a função do Azure. Agora, tudo o que você precisa fazer é atualizar sua função do Azure para que ela use essa ID para ler o registro correspondente do banco de dados na Função do Azure.
Figura 7 Método de índice HomeController
[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 });
}
Adicionar o Entity Framework à função do Azure
O Entity Framework fornece uma maneira simples de recuperar o registro de OvaryVis do banco de dados usando o valor da ID passado na mensagem de evento do Barramento de Serviço. A implementação envolve adicionar o pacote do Entity Framework ao seu projeto de função do Azure, usando o mesmo console do gerenciador de pacotes que você usou para instalar o pacote do Barramento de Serviço, da seguinte forma:
Install-Package Microsoft.EntityFrameworkCore.SqlServer
-Project OvaryVisFnApp –version 2.1.2
Você também precisará fornecer uma cadeia de conexão para que sua função do Azure possa acessar o Banco de Dados SQL do Azure. Essa é a mesma cadeia de conexão usada pelo seu aplicativo Web e pode ser melhor configurada através das Configurações de Aplicativos da Função do Azure, que é acessível a partir de sua folha de Visão geral no Portal mostrado na Figura 4. Você precisará rolar para baixo até a seção Cadeias de Conexão e, em seguida, clicar em Adicionar nova cadeia de conexão com o nome DefaultConnection, digitar SQLAzure e o valor a seguir, mas com o nome do seu próprio servidor de banco de dados e seu nome de usuário e senha:
Server=tcp:msdnovaryvisdbsvr.database.windows.net,1433;Database=Msdn.OvaryVisDb;
User ID=XXX;Password=YYY;Encrypt=true;Connection Timeout=30;
Depois de adicionar a cadeia de caracteres, não se esqueça de rolar de volta para a parte superior e clicar em Salvar.
A última coisa que você precisa fazer para acessar seu banco de dados a partir da sua função do Azure é copiar essa classe DataContext e a classe do modelo OvaryVis do seu projeto de aplicativo Web para o projeto do aplicativo de Funções. Você precisará alterar o namespace de ambos os arquivos para OvaryVisFnApp, mas, fora isso, você deve ser capaz de recriar sua solução sem problemas (pressione F7). Por fim, você precisa implementar o método a seguir e, em seguida, chamá-lo a partir do método Executar da função OvaryVisSubmitProc. Eis o código:
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;
}
O parâmetro de configuração passado para FormSubmittedProc pelo método Executar da função do Azure é obtido usando ConfigurationBuilder e fornece acesso às suas configurações de aplicativo, incluindo a cadeia de conexão de banco de dados. Em seguida, ele é usado para criar o objeto ApplicationDbContext que forma o segundo parâmetro. Você pode encontrar os detalhes exatos de implementação no download do exemplo de código.
Você concluiu o trabalho de desenvolvimento para este artigo, então, agora é hora de recompilar sua solução do Visual Studio, publicar seu projeto de aplicativo de funções do Azure e fazer um teste rápido de aceitação do build. Se você abrir a folha de Teste de Serviço do Aplicativo de funções do Azure, que descrevi anteriormente (Figura 5), você deve ver a Id do registro de ovário exibida no log sempre que enviar um formulário de entrada do seu site Web, conforme mostrado na Figura 8 . Isso indica que a sua função do Azure encontrou com êxito o registro correspondente ao valor da ID contido na mensagem do Barramento de Serviço enviado do aplicativo Web, portanto, todas as partes do sistema mostradas na Figura 1 estão funcionando conforme o esperado.
.png "Formulário de entrada do site e página de Resultados")
Figura 8 Formulário de entrada do site e página de Resultados
Conclusão
Vale a pena refletir sobre como o Azure facilita o desenvolvimento de um mecanismo de processamento em segundo plano robusto para qualquer site. Com um site de produção, convém fornecer alguma forma de atualizar automaticamente a página de resultados, em vez de contar que o usuário pressione F4, mas isso não é muito difícil de ser feito usando SignalR ou um mecanismo semelhante. No entanto, o provisionamento de uma fila do Barramento de Serviço e do Serviço de Aplicativo de funções do Azure foi alcançado com apenas alguns comandos do Portal do Azure e a integração com o controlador inicial do seu aplicativo Web exigiu apenas algumas linhas de código.
Há um custo muito baixo associado a esse tipo de implementação além do pequeno encargo mensal para um servidor de banco de dados e o Plano do Serviço de Aplicativo. Se você estiver executando na camada gratuita do Plano do Serviço de Aplicativo, você deve ser capaz de hospedar um site de teste por um custo menor do que o preço de dois cafezinhos por mês. Isso torna essa solução verdadeiramente atraente.
No próximo artigo, explorarei como estender uma função do Azure enviando os valores de dimensão no registro para o classificador em execução em um servidor provisionado de uma imagem do Docker. Você também verá como iniciar esse servidor automaticamente quando o tráfego chega ao seu site e, em seguida, interrompê-lo depois que o tráfego é encerrado, implementando um servidor sob demanda que é cobrado apenas pelo tempo real usado.
Dr. Will Stotttem mais de 25 anos de experiência trabalhando como consultor/prestador de serviço para uma ampla gama de empresas no Reino Unido e Europa, inclusive IBM, Cap Gemini, Logica CMG e a Accenture. No entanto, nos últimos 10 anos, a maior parte do seu tempo foi dedicado a pesquisas na University College London (UCL) na área de Rastreamento para Câncer de Ovário. Dr. Stott já fez apresentações em muitas conferências no Reino Unido e internacionalmente. Ele também é autor de trabalhos publicados em vários jornais e revistas, bem como do livro “Visual Studio Team System: Better Software Development for Agile Teams” (Addison-Wesley Professional, 2007).
Agradecemos aos seguintes especialistas técnicos da Microsoft pela revisão deste artigo: David Barkol