Editar

Share via


Padrão de aplicativo Web confiável para .NET: aplique o padrão

Serviço de aplicativo do Azure
Porta da frente do Azure
Cache do Azure para Redis
.NET

Este artigo mostra como aplicar o padrão de aplicativo Web confiável. O padrão de aplicativo Web confiável é um conjunto de princípios e técnicas de implementação que definem como você deve modificar aplicativos Web (replataforma) ao migrar para a nuvem. Ele se concentra nas atualizações mínimas de código que você precisa fazer para ter sucesso na nuvem.

Para facilitar a aplicação dessa diretriz, há uma implementação de referência do padrão de aplicativo Web confiável que você pode implantar.

O diagrama mostra a arquitetura da implementação de referênciaArquitetura da implementação de referência. Baixe um Arquivo Visio dessa arquitetura.

A orientação a seguir usa a implementação de referência como um exemplo em todo o processo. Para aplicar o padrão de aplicativo Web confiável, siga estas recomendações alinhadas aos pilares do Well-Architected Framework:

Confiabilidade

A confiabilidade garante que seu aplicativo possa cumprir os compromissos que você assume com seus clientes. Para obter mais informações, consulte a Lista de verificação de revisão de design para confiabilidade. O padrão de aplicativo Web confiável introduz dois padrões de design principais no nível do código para aumentar a confiabilidade: o padrão de repetição e o padrão de interruptor.

Use o padrão de repetição

O padrão de repetição aborda interrupções temporárias de serviço, denominadas falhas transitórias, que geralmente são resolvidas em segundos. Essas falhas geralmente resultam de limitações de serviço, distribuição dinâmica de carga e problemas de rede em ambientes de nuvem. A implementação do padrão Repetir envolve o reenvio de solicitações com falha, permitindo atrasos e tentativas configuráveis antes de conceder falhas.

Os aplicativos que usam o padrão Repetir devem integrar os SDKs (kits de desenvolvimento de software) cliente do Azure e os mecanismos de repetição específicos do serviço para melhorar a eficiência. Os aplicativos que não possuem esse padrão devem adotá-lo seguindo estas orientações.

Experimente primeiro os SDKs de serviço e cliente do Azure

A maioria dos SDKs de serviço e cliente do Azure têm um mecanismo interno de repetição. Você deve usar o mecanismo interno de repetição dos serviços do Azure para agilizar a implementação.

Exemplo: a implementação de referência usa a resiliência de conexão no Entity Framework Core para aplicar o padrão de repetição em solicitações ao Banco de Dados SQL do Azure (consulte o código a seguir).

services.AddDbContextPool<ConcertDataContext>(options => options.UseSqlServer(sqlDatabaseConnectionString,
    sqlServerOptionsAction: sqlOptions =>
    {
        sqlOptions.EnableRetryOnFailure(
        maxRetryCount: 5,
        maxRetryDelay: TimeSpan.FromSeconds(3),
        errorNumbersToAdd: null);
    }));

Use a biblioteca Polly quando a biblioteca cliente não oferecer suporte a repetições

Talvez seja necessário fazer chamadas para uma dependência que não seja um serviço do Azure ou que não ofereça suporte ao padrão de repetição de maneira nativa. Nesse caso, você deve usar a biblioteca Polly para implementar o padrão de repetição. Polly é uma resiliência do .NET e uma biblioteca de tratamento de falhas transitórias. Com ele, você pode usar APIs fluentes para descrever o comportamento em um local central do aplicativo.

Exemplo: a implementação de referência usa o Polly para configurar a injeção de dependência do ASP.NET Core. O Polly impõe o padrão de repetição toda vez que o código constrói um objeto que chama o objeto IConcertSearchService. Na estrutura do Polly, esse comportamento é conhecido como uma política. O código extrai essa política no método GetRetryPolicy, e o método GetRetryPolicy aplica o padrão de repetição sempre que o aplicativo Web front-end chama serviços de pesquisa de concerto da API Web (veja o código a seguir).

private void AddConcertSearchService(IServiceCollection services)
{
    var baseUri = Configuration["App:RelecloudApi:BaseUri"];
    if (string.IsNullOrWhiteSpace(baseUri))
    {
        services.AddScoped<IConcertSearchService, MockConcertSearchService>();
    }
    else
    {
        services.AddHttpClient<IConcertSearchService, RelecloudApiConcertSearchService>(httpClient =>
        {
            httpClient.BaseAddress = new Uri(baseUri);
            httpClient.DefaultRequestHeaders.Add(HeaderNames.Accept, "application/json");
            httpClient.DefaultRequestHeaders.Add(HeaderNames.UserAgent, "Relecloud.Web");
        })
        .AddPolicyHandler(GetRetryPolicy())
        .AddPolicyHandler(GetCircuitBreakerPolicy());
    }
}

private static IAsyncPolicy<HttpResponseMessage> GetRetryPolicy()
{
    var delay = Backoff.DecorrelatedJitterBackoffV2(TimeSpan.FromMilliseconds(500), retryCount: 3);
    return HttpPolicyExtensions
      .HandleTransientHttpError()
      .OrResult(msg => msg.StatusCode == System.Net.HttpStatusCode.NotFound)
      .WaitAndRetryAsync(delay);
}

O manipulador de políticas da instância RelecloudApiConcertSearchService aplica o padrão de repetição em todas as solicitações à API. Ele usa a lógica HandleTransientHttpError para detectar solicitações HTTP que pode repetir com segurança e, em seguida, repetir a solicitação com base na configuração. Ele inclui alguma aleatoriedade para simplificar possíveis intermitências no tráfego para a API, se ocorrer um erro.

Usar o padrão de disjuntor

Emparelhar os padrões de repetição e interruptor expande a capacidade de um aplicativo para lidar com interrupções de serviço que não estão relacionadas a falhas transitórias. O padrão de interruptor impede que um aplicativo tente acessar continuamente um serviço que não responde. O padrão de interruptor libera o aplicativo e evita o desperdício de ciclos de CPU para que o aplicativo mantenha sua integridade de desempenho para os usuários finais.

Exemplo: a implementação de referência adiciona o padrão de interruptor no método GetCircuitBreakerPolicy (consulte o código a seguir).

private static IAsyncPolicy<HttpResponseMessage> GetCircuitBreakerPolicy()
{
    return HttpPolicyExtensions
        .HandleTransientHttpError()
        .OrResult(msg => msg.StatusCode == System.Net.HttpStatusCode.NotFound)
        .CircuitBreakerAsync(5, TimeSpan.FromSeconds(30));
}

No código, o manipulador de políticas da instância RelecloudApiConcertSearchService aplica o padrão de interruptor em todas as solicitações à API. Ele usa a lógica HandleTransientHttpError para detectar solicitações HTTP que ele pode repetir com segurança, mas limita o número de falhas agregadas durante um período de tempo especificado.

Segurança

A segurança fornece garantias contra ataques deliberados e o abuso de seus dados e sistemas valiosos. Para obter mais informações, consulte Lista de verificação de revisão de design para segurança. O padrão de aplicativo Web confiável usa identidades gerenciadas para implementar a segurança centrada em identidade. Pontos de extremidade privados, firewall do aplicativo Web e acesso restrito ao aplicativo Web fornecem uma entrada segura.

Aplique privilégios mínimos

Para garantir a segurança e a eficiência, conceda aos usuários (identidades de usuário) e aos serviços do Azure (identidades de carga de trabalho) apenas as permissões necessárias.

Atribua permissões a identidades de usuários

Avalie as necessidades do seu aplicativo para definir um conjunto de funções que abrangem todas as ações do usuário sem sobreposição. Mapeie cada usuário para a função mais apropriada. Conceda a eles somente o acesso necessário para desempenhar suas funções.

Atribua permissões a identidades de carga de trabalho

Conceda apenas as permissões críticas para as operações, como ações CRUD em bancos de dados ou acesso a segredos. As permissões de identidade de carga de trabalho são persistentes, portanto, você não pode fornecer permissões just-in-time ou de curto prazo para identidades de carga de trabalho.

  • Prefira o controle de acesso baseado em função (RBAC). Sempre comece com o RBAC do Azure para atribuir permissões. Ele oferece controle preciso, garantindo que o acesso seja auditável e granular. Use o RBAC do Azure para conceder apenas as permissões necessárias para que o serviço execute suas funções pretendidas.

  • Complemente com controles de acesso de nível de serviço do Azure. Se o RBAC do Azure não cobrir um cenário específico, complemente com políticas de acesso de nível de serviço do Azure.

Configure a autenticação e a autorização do usuário

A autenticação e a autorização são aspectos críticos da segurança de aplicativos Web. Autenticação é o processo de verificação da identidade do usuário de forma confiável. Autorização especifica as ações que um usuário tem permissão para executar no aplicativo. O objetivo é implementar autenticação e autorização sem enfraquecer sua postura de segurança. Para atingir essa meta, você precisa usar os recursos da plataforma de aplicativos do Azure (Serviço de Aplicativo do Azure) e do provedor de identidade (Microsoft Entra ID).

Configurar autenticação do usuário

Proteja seu aplicativo Web habilitando a autenticação do usuário por meio dos recursos da sua plataforma. O Serviço de Aplicativo do Azure dá suporte à autenticação com provedores de identidade, como o Microsoft Entra ID, descarregando a carga de trabalho de autenticação do seu código.

Configure a autenticação e a autorização de serviço

Configure a autenticação e autorização de serviço para que os serviços em seu ambiente tenham as permissões para realizar as funções necessárias. Use identidades gerenciadas no Microsoft Entra ID para automatizar a criação e o gerenciamento de identidades de serviço, eliminando o gerenciamento manual de credenciais. Uma identidade gerenciada permite que seu aplicativo Web acesse com segurança os serviços do Azure, como o Azure Key Vault e bancos de dados. Ele também facilita as integrações de pipeline de CI/CD para implantações no Serviço de Aplicativo do Azure. No entanto, em cenários como implantações híbridas ou com sistemas herdados, continue usando suas soluções de autenticação local para simplificar a migração. Faça a transição para identidades gerenciadas quando seu sistema estiver pronto para uma abordagem moderna de gerenciamento de identidades. Para obter mais informações, confira Monitorar identidades gerenciadas.

Use DefaultAzureCredential para configurar o código

Use DefaultAzureCredential para fornecer credenciais para desenvolvimento local e identidades gerenciadas na nuvem. DefaultAzureCredential gera um aquisição de TokenCredential para token OAuth. Ele gerencia a maioria dos cenários do SDK do Azure e bibliotecas de cliente da Microsoft. Ele detecta o ambiente do aplicativo para usar a identidade correta e solicita tokens de acesso conforme necessário. DefaultAzureCredential simplifica a autenticação de aplicativos implantados no Azure Para obter mais informações, consulte DefaultAzureCredential.

Exemplo: a implementação de referência usa a classe DefaultAzureCredential durante a inicialização para habilitar o uso de identidade gerenciada entre a API Web e o Key Vault (consulte o código a seguir).

builder.Configuration.AddAzureAppConfiguration(options =>
{
     options
        .Connect(new Uri(builder.Configuration["Api:AppConfig:Uri"]), new DefaultAzureCredential())
        .ConfigureKeyVault(kv =>
        {
            // Some of the values coming from Azure App Configuration are stored Key Vault. Use
            // the managed identity of this host for the authentication.
            kv.SetCredential(new DefaultAzureCredential());
        });
});

Use a infraestrutura como código para criar identidades gerenciadas

Você deve usar modelos do Bicep para criar e configurar a infraestrutura do Azure e dar suporte a identidades gerenciadas. As identidades gerenciadas não usam segredos ou senhas, portanto, você não precisa do Key Vault nem de uma estratégia de rotação secreta para garantir a integridade. Você pode compartilhar as strings de conexão no serviço de Configuração de Aplicativos.

Exemplo: a implementação de referência usa modelos Bicep para (1) criar a identidade gerenciada, (2) associar a identidade ao aplicativo Web e (3) conceder à identidade permissão para acessar o banco de dados SQL. O argumento Authentication na cadeia de conexão instrui a biblioteca de cliente da Microsoft a se conectar com uma identidade gerenciada (consulte o código a seguir).

    Server=tcp:my-sql-server.database.windows.net,1433;Initial Catalog=my-sql-database;Authentication=Active Directory Default

Para obter mais informações, consulte Conectar-se ao banco de dados SQL do Serviço de Aplicativo .NET.

Usar um repositório central de segredos para gerenciar segredos

Ao mover seu aplicativo para a nuvem, use o Azure Key Vault para armazenar com segurança todos esses segredos. Esse repositório centralizado oferece armazenamento seguro, rotação de chaves, auditoria de acesso e monitoramento de serviços que não oferecem suporte a identidades gerenciadas. Para configurações de aplicativo, a Configuração de Aplicativos do Azure é recomendada.

Exemplo: a implementação de referência armazena os seguintes segredos no Key Vault: (1) nome de usuário e senha do banco de dados PostgreSQL, (2) senha do Cache Redis e (3) o segredo do cliente do Microsoft Entra ID associado à implementação da Microsoft Authentication Library (MSAL).

Não coloque o Cofre de Chaves no fluxo de solicitação HTTP

Carregue segredos do Key Vault na inicialização do aplicativo, e não durante cada solicitação HTTP. O Key Vault destina-se a armazenar e recuperar dados confidenciais com segurança durante a implantação. O acesso de alta frequência em solicitações HTTP pode exceder os recursos de taxa de transferência do Key Vault, levando a limitações de solicitação e erros de código de status HTTP 429. Para obter mais informações, consulte Limites de transação do Key Vault.

Use um método para acessar segredos no Key Vault

Ao configurar um aplicativo Web para acessar segredos no Key Vault, você tem duas opções principais:

  • Configuração do Serviço de Aplicativo: use uma configuração de aplicativo no Serviço de Aplicativo para injetar o segredo diretamente como uma variável de ambiente.

  • Referência de segredo direto: faça referência direta ao segredo dentro do código do aplicativo. Adicione uma referência específica no arquivo de propriedades do seu aplicativo, como application.properties para aplicativos Java, para que seu aplicativo se comunique com o Key Vault.

É importante escolher um desses métodos e mantê-lo para simplicidade e para evitar complexidade desnecessária.

Prefira métodos de acesso temporário

Use permissões temporárias para se proteger contra acesso não autorizado e violações. Use assinaturas de acesso compartilhado (SASs) para acesso temporário. Use o SAS de delegação de usuário para maximizar a segurança ao conceder acesso temporário. Ele é o único SAS que usa credenciais do Microsoft Entra e não requer uma chave de conta de armazenamento.

Usar pontos de extremidade privados

Use pontos de extremidade privados em todos os ambientes de produção para todos os serviços do Azure com suporte. Os pontos de extremidade privados fornecem conexões privadas entre recursos em uma rede virtual do Azure e os serviços do Azure. Por padrão, a comunicação com a maioria dos serviços do Azure passa pela Internet pública. Os pontos de extremidade privados não exigem alterações de código, configurações de aplicativos ou strings de conexão. Para obter mais informações, consulte Como criar um ponto de extremidade privado e Práticas recomendadas para segurança de ponto de extremidade.

Exemplo: a Configuração de Aplicativos do Azure, o Banco de Dados SQL do Azure, o Cache do Azure para Redis, o Armazenamento do Azure, o Serviço de Aplicativo do Azure e o Key Vault usam um ponto de extremidade privado.

Use o firewall do aplicativo Web e restrinja o tráfego de entrada da Internet

Todo o tráfego de entrada da Internet para o aplicativo Web deve passar por um firewall de aplicativo Web para proteger contra explorações comuns na Web. Force todo o tráfego de entrada da Internet a passar pelo balanceador de carga público, se você tiver um, e pelo firewall de aplicativo Web.

Exemplo: a implementação de referência força todo o tráfego de entrada da Internet por meio do Front Door e do Firewall de Aplicativo Web do Azure. Na produção, preserve o nome do host HTTP original.

Configurar segurança de banco de dados

O acesso de nível de administrador ao banco de dados concede permissões para executar operações privilegiadas. As operações privilegiadas incluem criar e excluir bancos de dados, modificar esquemas de tabela ou alterar permissões de usuários. Os desenvolvedores frequentemente precisam de acesso no nível de administrador para manter o banco de dados ou solucionar problemas.

  • Evite permissões elevadas permanentes. Você só deve conceder aos desenvolvedores acesso just-in-time para realizar operações privilegiadas. Com o acesso just-in-time, os usuários recebem permissões temporárias para realizar tarefas privilegiadas

  • Não dê permissões elevadas ao aplicativo. Você não deve conceder acesso de nível de administrador à identidade do aplicativo. Você deve configurar o acesso com privilégios mínimos para o aplicativo ao banco de dados. Ele limita o raio de alcance de bugs e violações de segurança.

Otimização de custo

A otimização de custos é a análise de maneiras de reduzir as despesas desnecessárias e a sobrecarga de gerenciamento. Para obter mais informações, consulte a Lista de verificação de revisão de design para otimização de custos. O padrão de aplicativo Web confiável implementa técnicas de correção de tamanho, dimensionamento automático e uso eficiente de recursos para um aplicativo Web mais otimizado em termos de custo.

Recursos de correção de tamanho para cada ambiente

Compreenda as diferentes níveis de desempenho dos serviços do Azure e use apenas a SKU apropriada para as necessidades de cada ambiente. Os ambientes de produção precisam de SKUs que atendam aos SLAs (Contratos de Nível de Serviço), aos recursos e à escala necessários para a produção. Ambientes de não produção normalmente não precisam dos mesmos recursos. Para obter economias extras, considere as opções de preços de Desenvolvimento/Teste do Azure, Reservas do Azure e planos de economia do Azure para computação.

Exemplo: a implementação de referência usa parâmetros Bicep para disparar configurações de implantação de recursos. Um desses parâmetros indica as camadas de recursos (SKUs) a serem implantadas. O aplicativo Web usa as SKUs mais eficientes e caras para os ambientes de produção e as SKUs mais baratas para o ambiente de não produção (consulte o código a seguir).

var redisCacheSkuName = isProd ? 'Standard' : 'Basic'
var redisCacheFamilyName = isProd ? 'C' : 'C'
var redisCacheCapacity = isProd ? 1 : 0

Usar escala automática

A escala automática automatiza o dimensionamento horizontal para ambientes de produção. Escala automática baseada em métricas de desempenho. Os gatilhos de desempenho de utilização da CPU são um bom ponto de partida se você não entender os critérios de dimensionamento do seu aplicativo. Você precisa configurar e adaptar os gatilhos de dimensionamento (CPU, RAM, rede e disco) para corresponder ao comportamento do seu aplicativo Web. Não dimensione verticalmente para atender a mudanças frequentes na demanda. Isso gera menos economia. Para obter mais informações, consulte Dimensionamento no Serviço de Aplicativo do Azure e Escala automática no Microsoft Azure.

Exemplo: a implementação de referência usa a seguinte configuração no modelo Bicep. Ela cria uma regra de escala automática para o Serviço de Aplicativo do Azure. A regra é dimensionada para até 10 instâncias, e o padrão é uma instância. Ela se baseia no uso da CPU como gatilho para escalar para dentro e para fora. A plataforma de hospedagem de aplicativos Web dimensiona horizontalmente para 85% de uso da CPU e verticalmente para 60%. A configuração de expansão de 85%, em vez de uma porcentagem mais próxima de 100%, fornece um buffer de proteção contra o tráfego acumulado de usuários causado por sessões adesivas. Ela também protege contra altas intermitências de tráfego, dimensionando com antecedência para evitar o uso máximo da CPU. Essas regras de escala automática não são universais (consulte o código a seguir).

resource autoScaleRule 'Microsoft.Insights/autoscalesettings@2022-10-01' = if (autoScaleSettings != null) { 
  name: '${name}-autoscale' 
  location: location 
  tags: tags 
  properties: { 
    targetResourceUri: appServicePlan.id 
    enabled: true 
    profiles: [ 
      { 
        name: 'Auto created scale condition' 
        capacity: { 
          minimum: string(zoneRedundant ? 3 : autoScaleSettings!.minCapacity) 
          maximum: string(autoScaleSettings!.maxCapacity) 
          default: string(zoneRedundant ? 3 : autoScaleSettings!.minCapacity) 
        } 
        rules: [ 
          ... 
        ] 
      } 
    ] 
  } 
}

Use recursos com eficiência

  • Use serviços compartilhados. Centralizar e compartilhar determinados recursos proporciona otimização de custos e menor sobrecarga de gerenciamento. Coloque recursos de rede compartilhados na rede virtual de hub.

    Exemplo: a implementação de referência coloca o Firewall do Azure, o Azure Bastion e o Key Vault na rede virtual de hub.

  • Exclua ambientes não utilizados. Exclua ambientes de não produção após o expediente ou durante feriados para otimizar os custos. Você pode usar a infraestrutura como código para excluir recursos do Azure e ambientes inteiros. Remova a declaração do recurso que você deseja excluir do modelo Bicep. Use a operação de teste de hipóteses para visualizar as alterações antes que elas entrem em vigor. Faça backup dos dados necessários mais tarde. Entenda as dependências do recurso que você está excluindo. Se houver dependências, talvez seja necessário atualizar ou remover esses recursos também. Para obter mais informações, consulte Operação de teste de hipóteses de implantação do Bicep.

  • Coloque a funcionalidade. Onde houver capacidade ociosa, coloque recursos e funcionalidades do aplicativo em um único recurso do Azure. Por exemplo, vários aplicativos Web podem usar um único servidor (Plano do Serviço de Aplicativo) ou um único cache pode oferecer suporte a vários tipos de dados.

    Exemplo: a implementação de referência usa uma única instância do Cache do Azure para Redis para gerenciamento de sessão em aplicativos Web front-end (armazenando carrinho e tokens MSAL) e back-end (mantendo dados do Upcoming Concerts). Ela opta pelo menor SKU do Redis, oferecendo mais do que a capacidade necessária, eficientemente utilizada empregando vários tipos de dados para controlar custos.

Excelência operacional

A excelência operacional abrange os processos de operações que implantam um aplicativo e o mantêm em execução na produção. Para obter mais informações, consulte a Lista de verificação de revisão de design para Excelência Operacional. O padrão de aplicativo Web confiável implementa a infraestrutura como código para implantações de infraestrutura e monitoramento para observabilidade.

Automatizar a implantação

Use um pipeline de CI/CD para implantar alterações do controle do código-fonte para a produção. Se você estiver usando o Azure DevOps, utilize o Azure Pipelines. Se você estiver usando o GitHub, use as ações do GitHub. O Azure dá suporte a modelos ARM (JSON), Bicep e Terraform e tem modelos para cada recurso do Azure Para obter mais informações, consulte Modelo Bicep, Azure Resource Manager e Terraform e Infraestrutura repetível.

Exemplo: a implementação de referência usa a CLI de Desenvolvimento do Azure e a infraestrutura como código (modelos Bicep) para criar recursos do Azure, definir a configuração e implantar os recursos necessários.

Configurar monitoramento

Para monitorar seu aplicativo Web, colete e analise métricas e logs do código do aplicativo, da infraestrutura (tempo de execução) e da plataforma (recursos do Azure). Adicione uma configuração de diagnóstico para cada recurso do Azure na sua arquitetura. Cada serviço do Azure tem um conjunto diferente de logs e métricas que você pode capturar. Para obter mais informações, consulte Monitorar a plataforma e Monitorar o Serviço de Aplicativo.

Monitore métricas de linha de base

Use o Azure Application Insights para controlar métricas de linha de base, como taxa de transferência de solicitação, duração média da solicitação, erros e monitoramento de dependência. Use AddApplicationInsightsTelemetry a partir do pacote NuGet Microsoft.ApplicationInsights.AspNetCore para habilitar a coleta de telemetria. Para obter mais informações, consulte Habilitar telemetria do Application Insights e Injeção de dependência no .NET.

Exemplo: a implementação de referência usa o código para configurar métricas de linha de base no Application Insights (consulte o código a seguir).

public void ConfigureServices(IServiceCollection services)
{
   ...
   services.AddApplicationInsightsTelemetry(Configuration["App:Api:ApplicationInsights:ConnectionString"]);
   ...
}

Crie telemetria personalizada conforme necessário

Use o Application Insights para coletar telemetria personalizada e entender melhor os usuários do aplicativo Web. Crie uma instância da classe TelemetryClient e use os métodos TelemetryClient para criar a métrica correta. Transforme a consulta em um widget do Painel do Azure.

Exemplo: a implementação de referência adiciona métricas que ajudam a equipe de operações a identificar se o aplicativo Web está concluindo transações com êxito. Ela valida que o aplicativo Web está online monitorando se os clientes podem fazer pedidos, não medindo o número de solicitações ou o uso da CPU. A implementação de referência usa TelemetryClient via injeção de dependência e o método TrackEvent para coletar telemetria em eventos relacionados à atividade do carrinho. A telemetria controla os ingressos que os usuários adicionam, removem e compram (consulte o código a seguir).

  • AddToCart conta quantas vezes os usuários adicionam um determinado ingresso (ConcertID) ao carrinho.
  • RemoveFromCart registra os ingressos que os usuários removem do carrinho.
  • CheckoutCart registra um evento toda vez que um usuário compra um ingresso.

this.telemetryClient.TrackEvent conta os ingressos adicionados ao carrinho. Ela fornece o nome do evento (AddToCart) e especifica um dicionário que tem o concertId e o count (consulte o código a seguir).

this.telemetryClient.TrackEvent("AddToCart", new Dictionary<string, string> {
    { "ConcertId", concertId.ToString() },
    { "Count", count.ToString() }
});

Para saber mais, veja:

Colete métricas baseadas em log

Rastreie métricas baseadas em log para obter mais visibilidade sobre a integridade e as métricas essenciais do aplicativo. Você pode usar consultas KQL (Linguagem de Consulta Kusto) no Application Insights para localizar e organizar dados. Para obter mais informações, consulte Métricas baseadas em log do Azure Application Insights e Métricas pré-agregadas e baseadas em log no Application Insights.

Habilite diagnósticos de plataforma

Uma configuração de diagnóstico no Azure permite especificar os logs e as métricas de plataforma que você deseja coletar e onde armazená-los. Os logs de plataforma são logs internos que fornecem informações de diagnóstico e auditoria. Você pode habilitar o diagnóstico de plataforma para a maioria dos serviços do Azure, mas cada serviço define suas próprias categorias de log. Diversos serviços do Azure têm categorias de log para escolher.

  • Habilite o diagnóstico para todos os serviços compatíveis. Os serviços do Azure criam logs de plataforma automaticamente, mas o serviço não os armazena automaticamente. Você deve habilitar a configuração de diagnóstico para cada serviço e habilitá-la para cada serviço do Azure que ofereça suporte a diagnósticos.

  • Envie diagnósticos para o mesmo destino que os logs do aplicativo. Ao habilitar o diagnóstico, você escolhe os logs que deseja coletar e para onde enviá-los. Você deve enviar os logs da plataforma para o mesmo destino que os logs do aplicativo para que possa correlacionar os dois conjuntos de dados.

Eficiência de desempenho

A eficiência do desempenho é a capacidade de dimensionar a carga de trabalho para atender às demandas exigidas pelos usuários de maneira eficiente. Para obter mais informações, consulte a Lista de verificação de revisão de design para eficiência de desempenho. O padrão de aplicativo Web confiável usa o padrão Cache-Aside para minimizar a latência de dados altamente solicitados.

Use o padrão Cache-Aside

O padrão Cache-Aside é uma estratégia de armazenamento em cache que melhora o gerenciamento de dados na memória. O padrão atribui ao aplicativo a responsabilidade de manipular solicitações de dados e garantir a consistência entre o cache e um armazenamento persistente, como um banco de dados. Quando o aplicativo Web recebe uma solicitação de dados, ele primeiro pesquisa o cache. Se os dados estiverem ausentes, ele os recuperará do banco de dados, responderá à solicitação e atualizará o cache. Essa abordagem reduz os tempos de resposta, aumenta a taxa de transferência e reduz a necessidade de mais dimensionamento. Ela também reforça a disponibilidade do serviço, reduzindo a carga no armazenamento de dados principal e minimizando os riscos de paralisação.

Exemplo: a implementação de referência melhora a eficiência do aplicativo armazenando em cache dados críticos, como informações dos próximos shows que são cruciais para a venda de ingressos. Ela usa o cache de memória distribuída do ASP.NET Core para armazenamento de itens na memória. O aplicativo usa automaticamente o Cache do Azure para Redis quando encontra uma cadeia de conexão específica. Ele também oferece suporte a ambientes de desenvolvimento local sem Redis para simplificar a configuração e reduzir custos e complexidade. O método (AddAzureCacheForRedis) configura o aplicativo para usar o Cache do Azure para Redis (consulte o código a seguir).

private void AddAzureCacheForRedis(IServiceCollection services)
{
    if (!string.IsNullOrWhiteSpace(Configuration["App:RedisCache:ConnectionString"]))
    {
        services.AddStackExchangeRedisCache(options =>
        {
            options.Configuration = Configuration["App:RedisCache:ConnectionString"];
        });
    }
    else
    {
        services.AddDistributedMemoryCache();
    }
}

Para obter mais informações, veja Cache distribuído no ASP.NET Core e Método AddDistributedMemoryCache.

Armazene em cache dados de alta necessidade

Priorize o armazenamento em cache para os dados acessados com mais frequência. Identifique os principais pontos de dados que impulsionam a participação do usuário e o desempenho do sistema. Implemente estratégias de armazenamento em cache especificamente para essas áreas para otimizar a eficácia do padrão Cache-Aside reduzindo significativamente a latência e a carga do banco de dados. Use o Azure Monitor para controlar a CPU, a memória e o armazenamento do banco de dados. Essas métricas ajudam a determinar se você pode usar um SKU de banco de dados menor.

Exemplo: a implementação de referência armazena em cache os dados que dão suporte à página Próximos shows. A página Próximos shows cria a maioria das consultas ao Banco de Dados SQL e produz uma saída consistente para cada visita. O padrão Cache-Aside armazena em cache os dados após a primeira solicitação dessa página para reduzir a carga no banco de dados. O código a seguir usa o método GetUpcomingConcertsAsync para extrair dados para o Cache Redis do Banco de Dados SQL. O método preenche o cache com os shows mais recentes. O método filtra por tempo, classifica os dados e retorna os dados ao controlador para exibir os resultados (consulte o código a seguir).

public async Task<ICollection<Concert>> GetUpcomingConcertsAsync(int count)
{
    IList<Concert>? concerts;
    var concertsJson = await this.cache.GetStringAsync(CacheKeys.UpcomingConcerts);
    if (concertsJson != null)
    {
        // There is cached data. Deserialize the JSON data.
        concerts = JsonSerializer.Deserialize<IList<Concert>>(concertsJson);
    }
    else
    {
        // There's nothing in the cache. Retrieve data from the repository and cache it for one hour.
        concerts = await this.database.Concerts.AsNoTracking()
            .Where(c => c.StartTime > DateTimeOffset.UtcNow && c.IsVisible)
            .OrderBy(c => c.StartTime)
            .Take(count)
            .ToListAsync();
        concertsJson = JsonSerializer.Serialize(concerts);
        var cacheOptions = new DistributedCacheEntryOptions {
            AbsoluteExpirationRelativeToNow = TimeSpan.FromHours(1)
        };
        await this.cache.SetStringAsync(CacheKeys.UpcomingConcerts, concertsJson, cacheOptions);
    }
    return concerts ?? new List<Concert>();
}

Mantenha os dados do cache atualizados

Agende atualizações regulares de cache para sincronizar com as alterações mais recentes do banco de dados. Determine a taxa de atualização ideal com base na volatilidade dos dados e nas necessidades do usuário. Essa prática garante que o aplicativo use o padrão Cache-Aside para fornecer acesso rápido e informações atuais.

Exemplo: a implementação de referência armazena dados em cache apenas por uma hora. Ele tem um processo para limpar a chave do cache quando os dados são alterados. O método CreateConcertAsync limpa a chave do cache (consulte o código a seguir).

public async Task<CreateResult> CreateConcertAsync(Concert newConcert)
{
    database.Add(newConcert);
    await this.database.SaveChangesAsync();
    this.cache.Remove(CacheKeys.UpcomingConcerts);
    return CreateResult.SuccessResult(newConcert.Id);
}

Garanta a consistência dos dados

Implemente mecanismos para atualizar o cache imediatamente após qualquer operação de gravação no banco de dados. Use atualizações orientadas a eventos ou classes de gerenciamento de dados dedicadas para garantir a coerência do cache. A sincronização consistente do cache com modificações no banco de dados é fundamental para o padrão Cache-Aside.

Exemplo: a implementação de referência usa o método UpdateConcertAsync para manter os dados no cache consistentes (consulte o código a seguir).

public async Task<UpdateResult> UpdateConcertAsync(Concert existingConcert), 
{
   database.Update(existingConcert);
   await database.SaveChangesAsync();
   this.cache.Remove(CacheKeys.UpcomingConcerts);
   return UpdateResult.SuccessResult();
}

Desempenho do banco de dados de teste

O desempenho do banco de dados pode afetar o desempenho e a escalabilidade de um aplicativo. É importante testar o desempenho do banco de dados para garantir que ele seja otimizado. Algumas considerações importantes incluem a escolha da região de nuvem, pool de conexões, padrão de cache-aside e otimização de consultas certos.

  • Teste saltos de rede. Migrar um aplicativo para a nuvem pode introduzir saltos de rede e latência extras no seu banco de dados. Você deve testar os saltos extras que o novo ambiente de nuvem introduz.

  • Estabelecer uma linha de base do desempenho. Você deve usar métricas de desempenho locais como a linha de base inicial para comparar o desempenho do aplicativo na nuvem.

Próximas etapas

Faça a implementação de referência seguindo as instruções no repositório do GitHub. Use os recursos a seguir para saber mais sobre aplicativos .NET, aplicativos Web, práticas recomendadas de nuvem e migração.

Atualizar aplicativos .NET Framework

A implementação de referência é implantada em um Serviço de Aplicativo que executa o Windows, mas pode ser executado no Linux. A plataforma de Serviço de Aplicativo do Windows permite migrar aplicativos Web do .NET Framework para o Azure sem atualizar para versões mais recentes da estrutura. Para obter informações sobre Plano do Serviço de Aplicativo Linux ou novos recursos e melhorias de desempenho adicionados às versões mais recentes do .NET, consulte as diretrizes a seguir.

Introdução aos aplicativos Web no Azure

Para obter uma introdução prática aos aplicativos Web .NET no Azure, consulte esta orientação para implantar um aplicativo Web .NET básico.

Práticas recomendadas da nuvem

Para obter diretrizes de arquitetura e adoção do Azure, consulte:

  • Cloud Adoption Framework. Pode ajudar sua organização a preparar e executar uma estratégia para criar soluções no Azure.
  • Well-Architected Framework. Um conjunto de princípios de orientação que podem ser usados para melhorar a qualidade de uma carga de trabalho.

Para aplicativos que exigem um SLO mais alto do que o padrão de aplicativo Web Confiável, consulte cargas de trabalho de missão crítica.

Diretrizes de migração

As ferramentas e recursos a seguir podem ajudar você a migrar recursos locais para o Azure.