Partilhar via

Padrão de aplicativo Web confiável para Java

Este artigo fornece orientação para implementar o padrão Reliable Web App. Esse padrão descreve como reformular aplicativos Web para migração para a nuvem. Ele fornece arquitetura prescritiva, código e orientação de configuração que se alinha com os princípios do Azure Well-Architected Framework.

Por que usar o padrão Reliable Web App para Java?

O padrão Reliable Web App é um conjunto de princípios e técnicas de implementação que definem como reformular aplicativos Web quando você os migra para a nuvem. Ele enfatiza atualizações mínimas de código para garantir o sucesso na nuvem. Esta orientação usa uma implementação de referência como um exemplo consistente ao longo do documento. Ele segue a jornada de reestruturação da empresa fictícia Contoso Fiber para fornecer contexto de negócios para a sua própria migração. Antes de implementar o padrão Reliable Web App para Java, a Contoso Fiber opera um Sistema de Gerenciamento de Conta do Cliente (CAMS) monolítico e local criado com a estrutura Spring Boot.

Sugestão

Logótipo do GitHub. A implementação de referência (exemplo) do padrão Reliable Web App representa o estado final de uma implementação concluída. Este aplicativo Web de nível de produção inclui todas as atualizações de código, arquitetura e configuração descritas neste artigo. Implante e use a implementação de referência para ajudar a orientar sua própria implementação do padrão Reliable Web App.

Como implementar o padrão Reliable Web App

Encontre as orientações específicas de que necessita nas seguintes secções deste artigo:

  • Contexto de negócios: alinhe essa orientação com o contexto do seu negócio e aprenda a definir metas imediatas e de longo prazo que impulsionam as decisões de replataforma.

  • Orientação de arquitetura: selecione os serviços de nuvem certos e projete uma arquitetura que atenda aos seus requisitos de negócios.

  • Orientação de código: implemente os padrões de projeto Retry, Circuit Breaker e Cache-Aside para melhorar a confiabilidade e a eficiência de desempenho do seu aplicativo Web na nuvem.

  • Orientação de configuração: Configure autenticação e autorização, identidades gerenciadas, ambientes com direitos, infraestrutura como código (IaC) e monitoramento.

Contexto empresarial

O primeiro passo na replataforma de um aplicativo Web é definir seus objetivos de negócios. Defina metas imediatas, como objetivos de nível de serviço (SLOs) e metas de otimização de custos, juntamente com metas futuras para seu aplicativo Web. Estes objetivos influenciam a sua escolha de serviços na nuvem e a arquitetura da sua aplicação na nuvem. Defina um SLO de alvo para a sua aplicação web, como 99,9% de disponibilidade. Calcule o contrato de nível de serviço composto (SLA) para todos os serviços que afetam a disponibilidade do seu aplicativo Web.

A Contoso Fiber quer expandir seu aplicativo Web CAMS local para alcançar outras regiões. Para atender ao aumento da demanda no aplicativo web, a empresa estabelece as seguintes metas:

  • Aplique alterações de código de baixo custo e alto valor.
  • Alcance um SLO (Objetivo de Nível de Serviço) de 99,9%.
  • Adote práticas de DevOps.
  • Crie ambientes otimizados em termos de custos.
  • Melhore a fiabilidade e a segurança.

A Contoso Fiber determina que sua infraestrutura local não é uma solução econômica para dimensionar o aplicativo. A empresa decide que migrar a aplicação Web CAMS para o Azure é a forma mais económica de atingir os seus objetivos imediatos e futuros.

Orientações para a arquitetura

O padrão Reliable Web App tem alguns elementos arquitetônicos essenciais. Você precisa do DNS (Sistema de Nomes de Domínio) para gerenciar a resolução de pontos finais, um firewall de aplicativo da Web para bloquear tráfego HTTP mal-intencionado e um balanceador de carga para rotear e ajudar a proteger as solicitações dos usuários de entrada. A plataforma de aplicações hospeda o código da aplicação web e chama os serviços de back-end através de endpoints privados numa rede virtual. Uma ferramenta de monitoramento de desempenho de aplicativo captura métricas e logs para ajudá-lo a entender seu aplicativo Web.

Diagrama que mostra os elementos arquitetônicos essenciais do padrão Reliable Web App.

Projete a arquitetura

Projete sua infraestrutura para dar suporte às métricas de recuperação, como o RTO (Recovery Time Objetive, objetivo de tempo de recuperação) e o RPO (Recovery Point Objetive, objetivo de ponto de recuperação). O RTO afeta a disponibilidade e deve suportar o seu SLO. Determine um RPO e configure a redundância de dados para atender ao RPO.

Selecione os serviços do Azure certos

Ao mover um aplicativo Web para a nuvem, escolha serviços do Azure que atendam aos seus requisitos de negócios e se alinhem com os recursos do aplicativo Web local. Esse alinhamento ajuda a minimizar o esforço de reestruturação de plataforma. Por exemplo, use serviços que permitem manter o mesmo mecanismo de banco de dados e oferecer suporte a middleware e estruturas existentes.

Antes da migração, o aplicativo Web CAMS da Contoso Fiber é um aplicativo Java local e monolítico. É um aplicativo Spring Boot com um banco de dados PostgreSQL. O aplicativo Web é um aplicativo de suporte de linha de negócios (LOB) para funcionários. Eles o usam para gerenciar casos de suporte ao cliente. O aplicativo enfrenta desafios comuns com escalabilidade e implantação de recursos. Esse ponto de partida, juntamente com os objetivos de negócios e SLOs, influencia suas escolhas de serviço.

A lista a seguir fornece orientação para selecionar os serviços do Azure certos para seu aplicativo Web e descreve por que a Contoso Fiber seleciona serviços específicos:

  • Plataforma de aplicação: Use o Serviço de Aplicativo do Azure como sua plataforma de aplicativo. A Contoso Fiber usa o Serviço de Aplicativo pelos seguintes motivos:

    • Progressão natural: A Contoso Fiber implanta um arquivo JAR do Spring Boot em seu servidor local e deseja minimizar a quantidade de rearquitetura para esse modelo de implantação. O Serviço de Aplicativo fornece suporte robusto para executar aplicativos Spring Boot, o que o torna uma opção adequada. Os Aplicativos de Contêiner do Azure também são uma opção adequada para esse aplicativo. Para obter mais informações, consulte Visão geral de aplicativos de contêiner e Visão geral de Java em aplicativos de contêiner.

    • SLA alto: O Serviço de Aplicativo fornece um SLA alto que atende aos requisitos de produção.

    • Redução das despesas gerais de gerenciamento: O Serviço de Aplicativo é uma solução de hospedagem gerenciada.

    • Capacidade de contentorização: O Serviço de Aplicativo integra-se a registros de imagem de contêiner privado, como o Registro de Contêiner do Azure. A Contoso Fiber pode usar esses registros para colocar o aplicativo Web em contêineres no futuro.

    • Dimensionamento automático: A aplicação web pode escalar rapidamente para cima, para baixo, para dentro e para fora, com base no tráfego de utilizadores.

  • Gestão de identidades: Use o Microsoft Entra ID como sua solução de gerenciamento de identidade e acesso. A Contoso Fiber usa o Microsoft Entra ID pelos seguintes motivos:

    • Autenticação e autorização: O aplicativo precisa autenticar e autorizar funcionários de call center.

    • Escalabilidade: O Microsoft Entra ID é dimensionado para oferecer suporte a cenários maiores.

    • Controle de identidade do usuário: Os funcionários do call center podem usar suas identidades corporativas existentes.

    • Suporte ao protocolo de autorização: O Microsoft Entra ID suporta OAuth 2.0 para identidades gerenciadas.

  • Base de dados: Use um serviço que permita manter o mesmo mecanismo de banco de dados. Use a árvore de decisão do armazenamento de dados para orientar sua seleção. A Contoso Fiber usa o modelo de implantação de servidor flexível do Banco de Dados do Azure para PostgreSQL pelos seguintes motivos:

    • Fiabilidade: O modelo de implantação de servidor flexível oferece suporte à alta disponibilidade com redundância de zona em várias zonas de disponibilidade. Esta configuração mantém um servidor em standby quente numa zona de disponibilidade diferente dentro da mesma região do Azure. A configuração replica dados de forma síncrona para o servidor em espera.

    • Replicação entre regiões: O Banco de Dados do Azure para PostgreSQL fornece um recurso de réplica de leitura para replicar dados de forma assíncrona para um banco de dados de réplica somente leitura em outra região.

    • Desempenho: O Banco de Dados do Azure para PostgreSQL fornece desempenho previsível e ajuste inteligente que melhora o desempenho do banco de dados usando dados de uso real.

    • Redução das despesas gerais de gerenciamento: Este serviço gerenciado do Azure reduz as obrigações de gerenciamento.

    • Apoio à migração: Ele suporta a migração de banco de dados de bancos de dados PostgreSQL de servidor único local. A Contoso Fiber pode usar a ferramenta de migração para simplificar o processo de migração.

    • Consistência com configurações locais: Ele suporta diferentes versões da comunidade do PostgreSQL, incluindo a versão que a Contoso Fiber usa atualmente.

    • Recuperabilidade: A implementação flexível do servidor cria automaticamente backups do servidor e armazena-os em armazenamento redundante por zona (ZRS) dentro da mesma região. A Contoso Fiber pode restaurar o banco de dados para qualquer momento específico dentro do período de retenção do backup. O recurso de backup e restauração cria um RPO melhor em comparação com ambientes locais.

  • Monitoramento de desempenho de aplicativos: Use o Application Insights para analisar a telemetria em seu aplicativo. A Contoso Fiber usa o Application Insights pelos seguintes motivos:

    • Integração com o Azure Monitor: Ele fornece a melhor integração com o Azure Monitor.

    • Deteção de anomalias: Deteta automaticamente anomalias de desempenho.

    • Resolução de problemas: Ele ajuda a diagnosticar problemas no aplicativo em execução.

    • Monitorização: Ele coleta dados de uso para o aplicativo e rastreia eventos personalizados.

    • Lacuna de visibilidade: A solução local não tem uma solução de monitoramento de desempenho de aplicativos. O Application Insights oferece fácil integração com a plataforma e o código do aplicativo.

  • Cache: Escolha se deseja adicionar um cache à arquitetura do seu aplicativo Web. O Azure Managed Redis é a principal solução de cache do Azure. É um armazenamento de dados gerenciado na memória baseado no software Redis. A Contoso Fiber adiciona o Azure Managed Redis pelos seguintes motivos:

    • Velocidade e volume: Ele fornece alta taxa de transferência de dados e leituras de baixa latência para dados acessados com frequência e de mudança lenta.

    • Capacidade de suporte diversificada: É um local de cache unificado que todas as instâncias do aplicativo Web podem usar.

    • Armazenamento de dados externos: Os servidores de aplicativos locais usam cache local de VM. Essa configuração não descarrega dados acessados com frequência e não pode invalidar dados obsoletos.

    • Sessões antiaderentes: O cache permite que o aplicativo Web externalize o estado da sessão e use sessões antiaderentes. A maioria dos aplicativos Web Java que são executados no local dependem do cache do lado do cliente na memória. Esta abordagem não é bem escalável e aumenta o uso de memória no host. O Azure Managed Redis fornece um serviço de cache gerenciado e escalável para melhorar a escalabilidade e o desempenho dos aplicativos. A Contoso Fiber usou o Spring Cache como sua estrutura de abstração de cache e precisou apenas de alterações mínimas de configuração para alternar de um provedor Ehcache para o provedor Redis.

  • Balanceador de carga: Os aplicativos Web que usam soluções de plataforma como serviço (PaaS) devem usar o Azure Front Door, o Azure Application Gateway ou ambos, dependendo da arquitetura e dos requisitos do aplicativo Web. Use a árvore de decisão do balanceador de carga para selecionar o balanceador de carga correto. A Contoso Fiber precisa de um balanceador de carga de camada 7 que possa rotear o tráfego entre várias regiões e um aplicativo Web de várias regiões para atender ao SLO de 99,9%. A empresa usa o Azure Front Door pelos seguintes motivos:

    • Balanceamento de carga global: Este balanceador de carga de camada 7 pode rotear o tráfego em várias regiões.

    • Firewall de aplicação Web: Ele se integra nativamente ao Azure Web Application Firewall.

    • Flexibilidade de roteamento: Ele permite que a equipe do aplicativo configure as necessidades de entrada para suportar futuras alterações no aplicativo.

    • Aceleração do tráfego: Ele usa o roteamento anycast para chegar ao ponto de presença do Azure mais próximo e encontrar a rota mais rápida para o aplicativo Web.

    • Domínios personalizados: Ele suporta nomes de domínio personalizados com validação de domínio flexível.

    • Sondas de verificação de integridade: O aplicativo precisa de monitorização inteligente de sondas de verificação de integridade. O Azure Front Door usa respostas da sonda para determinar a melhor origem para rotear solicitações de clientes.

    • Apoio à monitorização: O Azure Front Door dá suporte a relatórios internos com um painel tudo-em-um para o Azure Front Door e padrões de segurança. Ele fornece alertas que se integram ao Azure Monitor. O Azure Front Door permite que o aplicativo registre cada solicitação e testes de integridade com falha.

    • Proteção distribuída contra negação de serviço (DDoS): Possui proteção contra DDoS integrada nas camadas 3 e 4.

    • Rede de distribuição de conteúdos: Ele posiciona a Contoso Fiber para usar uma rede de distribuição de conteúdo. A rede de entrega de conteúdo fornece aceleração do site.

  • Firewall de aplicação Web: Use o Firewall de Aplicativo Web do Azure para fornecer proteção centralizada contra vulnerabilidades e explorações da Web comuns. A Contoso Fiber usa o Firewall de Aplicativo Web do Azure pelos seguintes motivos:

    • Proteção global: Ele fornece proteção aprimorada de aplicativos Web globais, mantendo o desempenho.

    • Proteção contra botnets: A equipe pode monitorar e definir configurações para resolver problemas de segurança relacionados a botnets.

    • Paridade com o local: A solução local é executada atrás de um firewall de aplicativo Web gerenciado pela TI.

    • Facilidade de utilização: O Azure Web Application Firewall integra-se com o Azure Front Door.

  • Gestor de segredos: Use o Azure Key Vault se tiver segredos para gerenciar no Azure. A Contoso Fiber usa o Cofre da Chave pelos seguintes motivos:

    • Encriptação: Suporta encriptação em repouso e em trânsito.

    • Suporte de identidade gerida: Os serviços de aplicação podem usar identidades geridas para aceder ao cofre de segredos.

    • Monitorização e registo: O Key Vault facilita o acesso à auditoria e gera alertas quando os segredos armazenados são alterados.

    • Integração: O Key Vault fornece integração nativa com o repositório de configuração do Azure (Configuração de Aplicativo do Azure) e a plataforma de hospedagem na Web (Serviço de Aplicativo).

  • Segurança do ponto final: Use o Azure Private Link para acessar soluções PaaS em um ponto de extremidade privado em sua rede virtual. O tráfego entre a sua rede virtual e o serviço viaja através da rede de backbone da Microsoft. A Contoso Fiber usa o Private Link pelos seguintes motivos:

    • Comunicação de segurança reforçada: Ele permite que o aplicativo acesse serviços de forma privada na plataforma Azure e reduz a pegada de rede dos armazenamentos de dados para ajudar a proteger contra vazamento de dados.

    • Esforço mínimo: Os pontos de extremidade privados suportam a plataforma da aplicação web e a plataforma de base de dados que a aplicação web utiliza. Ambas as plataformas espelham as configurações locais existentes, portanto, é necessária uma alteração mínima.

  • Segurança da rede: Use o Firewall do Azure para controlar o tráfego de entrada e saída no nível da rede. Use o Azure Bastion para se conectar a VMs com segurança aprimorada, sem expor portas RDP/SSH (Remote Desktop Protocol/Secure Shell). A Contoso Fiber adota uma topologia de rede hub-and-spoke e coloca serviços de segurança de rede compartilhados no hub. O Azure Firewall inspeciona o tráfego de saída dos hubs para melhorar a segurança da rede. A empresa usa o Azure Bastion para implantações com segurança reforçada a partir de um host intermediário na sub-rede DevOps.

Orientações de codificação

Para mover com êxito uma aplicação web para a nuvem, é necessário atualizar o código da aplicação utilizando os padrões Retry, Circuit Breaker e Cache-Aside.

Diagrama que mostra as funções dos padrões de design no padrão Reliable Web App.

Os padrões de projeto a seguir fornecem benefícios de carga de trabalho que estão relacionados com um ou mais pilares do Well-Architected Framework.

  1. O padrão Retry lida com falhas transitórias repetindo operações que podem falhar intermitentemente. Implemente esse padrão em todas as chamadas de saída para outros serviços do Azure.

  2. O padrão Disjuntor impede que um aplicativo tente novamente operações que não são transitórias. Implemente esse padrão em todas as chamadas de saída para outros serviços do Azure.

  3. O padrão Cache-Aside carrega dados sob demanda em um cache de um armazenamento de dados. Implemente esse padrão em solicitações para o banco de dados.

Padrão de estruturação Fiabilidade (RE) Segurança (SE) Otimização de Custos (CO) Excelência Operacional (OE) Eficiência de desempenho (PE) Apoiar os princípios do WAF
Padrão de repetição ✔ RE:07
Padrão Circuit Breaker ✔ ✔ RE:03
RE:07
PE:07
PE:11
Padrão Cache-Aside ✔ ✔ RE:05
PE:08
PE:12

Implementar o padrão Retry

Adicione o padrão Repetir ao código do aplicativo para resolver interrupções temporárias do serviço. Essas interrupções são chamadas de falhas transitórias. Falhas transitórias geralmente se resolvem em segundos. Pode usar o padrão Retry para reenviar pedidos que falharam. Também permite configurar o atraso entre novas tentativas e o número de tentativas a serem realizadas antes de considerar falha.

Use o Resilience4j, uma biblioteca leve de tolerância a falhas, para implementar o padrão Retry em Java. Para adicionar o padrão Retry, a implementação de referência decora o método do controlador do serviço do plano listServicePlans com anotações Retry. O código tenta novamente a chamada para uma lista de planos de serviço do banco de dados se a chamada inicial falhar. A política de repetição para a implementação de referência inclui tentativas máximas, duração de espera e exceções para tentar novamente. Configure a política de repetição no arquivo application.properties.

    @GetMapping("/list")
    @PreAuthorize("hasAnyAuthority('APPROLE_AccountManager')")
    @CircuitBreaker(name = SERVICE_PLAN)
    @Retry(name = SERVICE_PLAN)
    public String listServicePlans(Model model) {
        List<serviceplandto> servicePlans = planService.getServicePlans();
        model.addAttribute("servicePlans", servicePlans);
        return "pages/plans/list";
    }

Implementar o Padrão Circuit Breaker

Utilize o padrão Disjuntor para lidar com interrupções de serviço que não sejam falhas transitórias. O padrão de disjuntor impede que um aplicativo tente acessar continuamente um serviço que não responde. Ele libera o aplicativo e ajuda a evitar o desperdício de ciclos da unidade central de processamento (CPU) para que o aplicativo mantenha sua integridade de desempenho para os usuários.

Use o Spring Cloud Circuit Breaker e o Resilience4j para implementar o padrão de Circuit Breaker. A implementação de referência aplica o padrão Circuit Breaker decorando métodos com o atributo Circuit Breaker.

Implementar o padrão Cache-Aside

Adicione o padrãoCache-Aside ao seu aplicativo Web para melhorar o gerenciamento de dados na memória. O padrão atribui ao aplicativo a responsabilidade de lidar com solicitações de dados e garantir a consistência entre o cache e o armazenamento persistente, como um banco de dados. Ele reduz os tempos de resposta, melhora a taxa de transferência e reduz a necessidade de mais escala. Ele também reduz a carga no armazenamento de dados primário, o que melhora a confiabilidade e a otimização de custos. Para implementar o padrão Cache-Aside, siga estas recomendações:

  • Configure o aplicativo para usar um cache. Para habilitar o cache, adicione o spring-boot-starter-cache pacote como uma dependência em seu pom.xml arquivo. Este pacote fornece configurações padrão para o cache Redis.

  • Armazene em cache dados de alta necessidade. Aplique o padrão Cache-Aside em dados de alta necessidade para melhorar sua eficácia. 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 uma SKU de banco de dados menor depois de aplicar o padrão Cache-Aside. Para armazenar em cache dados específicos em seu código, adicione a @Cacheable anotação. Esta anotação especifica ao Spring quais métodos devem ter seus resultados armazenados em cache.

  • Mantenha os dados de cache atualizados. Agende atualizações regulares de cache para sincronizar com as alterações mais recentes do banco de dados. Use a volatilidade dos dados e as necessidades do usuário para determinar a taxa de atualização ideal. Essa prática garante que o aplicativo use o padrão Cache-Aside para fornecer acesso rápido e informações atuais. As configurações de cache padrão podem não se adequar ao seu aplicativo Web. Você pode personalizar essas configurações no arquivo ou nas application.properties variáveis de ambiente. Por exemplo, você pode modificar o spring.cache.redis.time-to-live valor (expresso em milissegundos) para controlar quanto tempo os dados devem permanecer no cache antes de serem removidos.

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

Diretrizes de configuração

As seções a seguir fornecem orientação sobre como implementar as atualizações de configuração. Cada secção está alinhada com um ou mais pilares do Well-Architected Framework.

Configuração Fiabilidade (RE) Segurança (SE) Otimização de Custos (CO) Excelência Operacional (OE) Eficiência de desempenho (PE) Apoiar os princípios do WAF
Configurar autenticação e autorização de usuário ✔ ✔ SE:05
OE:10
Implementar identidades gerenciadas ✔ ✔ SE:05
OE:10
Otimização de ambientes ✔ CO:05
CO:06
Implementar dimensionamento automático ✔ ✔ ✔ RE:06
CO:12
PE:05
Automatizar a implantação de recursos ✔ OE:05
Implementar monitorização ✔ ✔ ✔ OE:07
PE:04

Configurar autenticação e autorização de usuário

Ao migrar aplicativos Web para o Azure, configure os mecanismos de autenticação e autorização do usuário. Siga estas recomendações:

  • Use uma plataforma de identidade. Use a plataforma de identidade da Microsoft para que os desenvolvedoresconfigurem a autenticação de aplicativos Web. Esta plataforma suporta aplicações que utilizam um único diretório Microsoft Entra, vários diretórios Microsoft Entra de diferentes organizações e identidades ou contas sociais da Microsoft.

    O [Spring Boot Starter for Microsoft Entra ID](/azure/developer/java/spring-framework/spring-boot-starter-for-entra-developer-guide usa o Spring Security e o Spring Boot para garantir fácil configuração e integração. Ele fornece vários fluxos de autenticação, gerenciamento automático de tokens, políticas de autorização personalizáveis e recursos de integração com componentes do Spring Cloud. Esta ferramenta permite a integração direta do Microsoft Entra ID e OAuth 2.0 em aplicativos Spring Boot sem biblioteca manual ou configuração de configurações.

    A implementação de referência usa a plataforma de identidade da Microsoft (Microsoft Entra ID) como o provedor de identidade para o aplicativo Web. Usa a concessão de código de autorização OAuth 2.0 para autenticar um utilizador que tem uma conta do Microsoft Entra. O trecho XML a seguir define as duas dependências necessárias do fluxo de concessão de código de autorização OAuth 2.0. A dependência com.azure.spring: spring-cloud-azure-starter-active-directory permite a autenticação e autorização do Microsoft Entra em um aplicativo Spring Boot. A dependência org.springframework.boot: spring-boot-starter-oauth2-client permite a autenticação e autorização do OAuth 2.0 em um aplicativo Spring Boot.

    <dependency>
    <groupid>com.azure.spring</groupid>
    <artifactid>spring-cloud-azure-starter-active-directory</artifactid>
</dependency>
<dependency>
    <groupid>org.springframework.boot</groupid>
    <artifactid>spring-boot-starter-oauth2-client</artifactid>
</dependency>

  • Crie um registro de aplicativo. O Microsoft Entra ID requer um registro de aplicativo no locatário principal. O registro do aplicativo ajuda a garantir que os usuários que obtêm acesso ao aplicativo Web tenham identidades no locatário principal. A implementação de referência usa o Terraform para criar um registro de aplicativo Microsoft Entra ID junto com uma função de Gerente de Conta específica do aplicativo:

    resource "azuread_application" "app_registration" {
  display_name     = "${azurecaf_name.app_service.result}-app"
  owners           = [data.azuread_client_config.current.object_id]
  sign_in_audience = "AzureADMyOrg"  # single tenant

  app_role {
    allowed_member_types = ["User"]
    description          = "Account Managers"
    display_name         = "Account Manager"
    enabled              = true
    id                   = random_uuid.account_manager_role_id.result
    value                = "AccountManager"
  }
}

  • Impor a autorização no aplicativo. Use o controle de acesso baseado em função (RBAC) para atribuir privilégios mínimos às funções do aplicativo. Defina funções específicas para diferentes ações do usuário para evitar sobreposições e garantir clareza. Mapeie os usuários para as funções apropriadas e garanta que eles tenham acesso apenas aos recursos e ações necessários. Configure o Spring Security para utilizar o Spring Boot Starter associado ao Microsoft Entra ID. Essa biblioteca permite a integração com o Microsoft Entra ID e ajuda a garantir que os usuários sejam autenticados com segurança. Configure e habilite a Biblioteca de Autenticação da Microsoft (MSAL) para obter acesso a mais recursos de segurança. Esses recursos incluem cache de token e atualização automática de token.

    A implementação de referência cria funções de aplicativo que refletem os tipos de funções de usuário no sistema de gerenciamento de contas da Contoso Fiber. As funções se traduzem em permissões durante a autorização. Exemplos de funções específicas do aplicativo no CAMS incluem Gerente de Conta, Representante de Suporte Nível Um (L1) e Representante de Serviço de Campo. A função Gestor de Conta tem permissões para adicionar novos utilizadores e clientes da aplicação. Um Representante de Serviço de Campo pode criar tickets de suporte. O PreAuthorize atributo restringe o acesso a funções específicas.

        @GetMapping("/new")
    @PreAuthorize("hasAnyAuthority('APPROLE_AccountManager')")
    public String newAccount(Model model) {
        if (model.getAttribute("account") == null) {
            List<ServicePlan> servicePlans = accountService.findAllServicePlans();
            ServicePlan defaultServicePlan = servicePlans.stream().filter(sp -> sp.getIsDefault() == true).findFirst().orElse(null);
            NewAccountRequest accountFormData = new NewAccountRequest();
            accountFormData.setSelectedServicePlanId(defaultServicePlan.getId());
            model.addAttribute("account", accountFormData);
            model.addAttribute("servicePlans", servicePlans);
        }
        model.addAttribute("servicePlans", accountService.findAllServicePlans());
        return "pages/account/new";
    }
    ...

    Para integrar com o Microsoft Entra ID, a implementação de referência utiliza o fluxo de concessão de código do OAuth 2.0. Esse fluxo permite que um usuário entre usando uma conta da Microsoft. O trecho de código a seguir mostra como configurar o SecurityFilterChain para usar o Microsoft Entra ID para autenticação e autorização.

    @Configuration(proxyBeanMethods = false)
@EnableWebSecurity
@EnableMethodSecurity
public class AadOAuth2LoginSecurityConfig {
    @Bean
    SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http.apply(AadWebApplicationHttpSecurityConfigurer.aadWebApplication())
            .and()
                .authorizeHttpRequests()
            .requestMatchers(EndpointRequest.to("health")).permitAll()
            .anyRequest().authenticated()
            .and()
                .logout(logout -> logout
                            .deleteCookies("JSESSIONID", "XSRF-TOKEN")
                            .clearAuthentication(true)
                            .invalidateHttpSession(true));
        return http.build();
    }
}
...

  • Prefira o acesso temporário ao armazenamento. Use permissões temporárias para se proteger contra acesso não autorizado e violações. Por exemplo, você pode usar assinaturas de acesso compartilhado (SAS) para limitar o acesso a um período de tempo. Use a delegação de usuários SAS para maximizar a segurança ao conceder acesso temporário. É o único SAS que usa credenciais do Microsoft Entra ID e não requer uma chave de conta de armazenamento permanente.

  • Impor autorização no Azure. Use o Azure RBAC) para atribuir privilégios mínimos às identidades do usuário. O RBAC do Azure define os recursos do Azure que as identidades podem acessar, o que podem fazer com esses recursos e as áreas às quais têm acesso.

  • Evite permissões permanentes elevadas. Use o Microsoft Entra Privileged Identity Management (PIM) para conceder acesso just-in-time (JIT) para operações privilegiadas. Por exemplo, os desenvolvedores geralmente precisam de acesso em nível de administrador para criar e excluir bancos de dados, modificar esquemas de tabela e alterar permissões de usuário. Quando você usa o acesso JIT, as identidades de usuário recebem permissões temporárias para executar tarefas privilegiadas.

Implementar identidades gerenciadas

Use identidades gerenciadas para todos os serviços do Azure que oferecem suporte a elas. Uma identidade gerenciada permite que os recursos do Azure, especificamente identidades de carga de trabalho, se autentiquem e interajam com outros serviços do Azure sem exigir que você gerencie credenciais. Para simplificar a migração, você pode continuar a usar soluções de autenticação local para sistemas híbridos e legados, mas deve fazer a transição para identidades gerenciadas o mais rápido possível. Para implementar identidades gerenciadas, siga estas recomendações:

  • Selecione o tipo certo de identidade gerenciada. Prefira identidades gerenciadas atribuídas pelo usuário quando você tiver dois ou mais recursos do Azure que precisam do mesmo conjunto de permissões. Essa abordagem é mais eficiente do que criar identidades gerenciadas atribuídas ao sistema para cada um desses recursos e atribuir as mesmas permissões a todos eles. Caso contrário, use identidades gerenciadas atribuídas ao sistema.

  • Configure privilégios mínimos. Use o RBAC do Azure para conceder apenas permissões que são críticas para operações, como criar, ler, atualizar e excluir ações (CRUD) em bancos de dados ou acessar segredos. As permissões de identidade de carga de trabalho são persistentes, portanto, você não pode fornecer permissões JIT ou de curto prazo para identidades de carga de trabalho. Se o RBAC do Azure não cobrir um cenário específico, complemente o RBAC do Azure com políticas de acesso de nível de serviço do Azure.

  • Forneça segurança para os segredos restantes. Armazene todos os segredos restantes no Cofre da Chave. Carregue segredos do Cofre da Chave na inicialização do aplicativo em vez de durante cada solicitação HTTP. O acesso de alta frequência em solicitações HTTP pode exceder os limites de transação do Cofre da Chave. Armazene as configurações do aplicativo em Configuração do aplicativo.

Otimização de ambientes

Use camadas de desempenho (SKUs) dos serviços do Azure que atendam às necessidades de cada ambiente sem excedê-las. Para dimensionar corretamente seus ambientes, execute as seguintes ações:

  • Estimativa de custos. Use a calculadora de preços do Azure para estimar o custo de cada ambiente.

  • Otimize os ambientes de produção. Os ambientes de produção precisam de SKUs que atendam ao SLA, aos recursos e à escala necessários para a produção. Monitore continuamente o uso de recursos e ajuste as SKUs para alinhá-las com as necessidades reais de desempenho.

  • Otimize os ambientes de pré-produção.Os ambientes de pré-produção devem usar recursos de baixo custo e aproveitar descontos como o plano do Azure para preços de desenvolvimento/teste. Nesses ambientes, desative os serviços que não são necessários. Assegure-se também de que os ambientes de pré-produção sejam suficientemente semelhantes aos ambientes de produção para evitar a introdução de riscos. Mantenha esse equilíbrio para garantir que os testes permaneçam eficazes sem incorrer em custos desnecessários.

  • Use o IaC para definir SKUs. Implemente o IaC para selecionar e implantar dinamicamente as SKUs corretas com base no ambiente. Essa abordagem aumenta a consistência e simplifica o gerenciamento.

Por exemplo, a implementação de referência tem um parâmetro opcional que especifica a SKU a ser implantada. Um parâmetro de ambiente especifica que o template do Terraform deverá implantar SKUs de desenvolvimento:

azd env set APP_ENVIRONMENT prod

Implementar dimensionamento automático

O dimensionamento automático ajuda a garantir que um aplicativo Web permaneça resiliente, responsivo e capaz de lidar com cargas de trabalho dinâmicas de forma eficiente. Para implementar o dimensionamento automático, siga estas recomendações:

  • Automatize o dimensionamento. Use o dimensionamento automático do Azure para automatizar o dimensionamento horizontal em ambientes de produção. Configure regras de dimensionamento automático para expandir com base nas principais métricas de desempenho para que seu aplicativo possa lidar com cargas variáveis.

  • Refine os gatilhos de dimensionamento. Use a utilização da CPU como seu gatilho de dimensionamento inicial se você não estiver familiarizado com os requisitos de dimensionamento do seu aplicativo. Refine seus gatilhos de dimensionamento para incluir outras métricas, como RAM, taxa de transferência de rede e entrada/saída (E/S) de disco. O objetivo é corresponder ao comportamento do seu aplicativo Web para um melhor desempenho.

  • Forneça um buffer de expansão. Defina seus limites de dimensionamento para iniciar o dimensionamento antes que a capacidade máxima seja atingida. Por exemplo, configure o dimensionamento para ocorrer a 85% de utilização da CPU em vez de esperar até atingir 100%. Essa abordagem proativa ajuda a manter o desempenho e a evitar possíveis gargalos.

Automatizar a implantação de recursos

Use a automação para implantar e atualizar recursos e código do Azure em todos os ambientes. Siga estas recomendações:

  • Utilize o IaC. Implemente o IaC usando pipelines de integração contínua e entrega contínua (CI/CD). O Azure fornece modelos Bicep pré-criados, modelos do Azure Resource Manager (modelos ARM), JSON e modelos Terraform para cada recurso do Azure.

  • Use um pipeline de CI/CD. Use um pipeline de CI/CD para implantar o código do controle do código-fonte em seus vários ambientes, como teste, preparo e produção. Use o Azure Pipelines se você trabalhar com o Azure DevOps. Utilize as GitHub Actions para projetos GitHub.

  • Integre testes de unidade. Priorize a execução e a validação de todos os testes de unidade em seu pipeline antes da implantação no Serviço de Aplicativo. Incorpore ferramentas de qualidade e cobertura de código como o SonarQube para obter uma cobertura de teste abrangente.

  • Adote estruturas simuladas. Para testes que envolvem pontos de extremidade externos, use estruturas simuladas. Essas estruturas permitem que você crie pontos de extremidade simulados. Eles eliminam a necessidade de configurar pontos de extremidade externos reais e garantem condições de teste uniformes em todos os ambientes.

  • Execute verificações de segurança. Use o teste de segurança de aplicativo estático (SAST) para encontrar falhas de segurança e erros de codificação em seu código-fonte. Conduza a análise de composição de software (SCA) para examinar bibliotecas e componentes que não sejam da Microsoft quanto a riscos de segurança. Integre ferramentas para essas análises no GitHub e no Azure DevOps.

Configurar a monitorização

Implemente o monitoramento de aplicativos e plataformas para melhorar a excelência operacional e a eficiência de desempenho de seu aplicativo Web. Para implementar o monitoramento, siga estas recomendações:

  • Colete telemetria de aplicações. Utilize autoinstrumentação no Application Insights para recolher telemetria de aplicações, como taxa de transferência de solicitações, duração média de solicitações, erros e monitorização de dependências. Você não precisa alterar nenhum código para usar essa telemetria. O Spring Boot registra várias métricas principais no Application Insights, como Java virtual machine (JVM), CPU e Tomcat. Application Insights coleta automaticamente de frameworks de logging como Log4j e Logback.

    A implementação de referência ativa o Application Insights via Terraform na configuração do serviço de aplicação app_settings.

    app_settings = {
    APPLICATIONINSIGHTS_CONNECTION_STRING = var.app_insights_connection_string
    ApplicationInsightsAgent_EXTENSION_VERSION = "~3"
    ...
}

    Para obter mais informações, consulte os seguintes artigos:

  • Crie métricas de aplicativos personalizadas. Implemente instrumentação baseada em código para capturar telemetria de aplicativo personalizada adicionando o SDK do Application Insights e usando sua API.

  • Monitore a plataforma. Habilite o diagnóstico para todos os serviços suportados. Envie diagnósticos para o mesmo destino que os registos da aplicação para assegurar a correlação. Os serviços do Azure criam logs de plataforma automaticamente, mas só os armazenam quando você habilita o diagnóstico. Habilite as configurações de diagnóstico para cada serviço que ofereça suporte a diagnósticos.

    A implementação de referência usa o Terraform para habilitar o diagnóstico do Azure em serviços com suporte. O código Terraform a seguir define as configurações de diagnóstico para o serviço de aplicativo:

    # Configure diagnostic settings for app service
resource "azurerm_monitor_diagnostic_setting" "app_service_diagnostic" {
  name                           = "app-service-diagnostic-settings"
  target_resource_id             = azurerm_linux_web_app.application.id
  log_analytics_workspace_id     = var.log_analytics_workspace_id
  #log_analytics_destination_type = "AzureDiagnostics"

  enabled_log {
    category_group = "allLogs"

  }

  metric {
    category = "AllMetrics"
    enabled  = true
  }
}

Implantar a implementação de referência

A implementação de referência orienta você pela migração simulada da Contoso Fiber de um aplicativo Java local para o Azure. Destaca igualmente as alterações necessárias durante a fase inicial de adoção.

A arquitetura a seguir representa o estado final da implementação do padrão Aplicativo Web Confiável da Contoso Fiber com base em suas metas.

Diagrama que mostra a arquitetura da implementação de referência.

Descarregue um ficheiro Visio desta arquitetura.

Próximo passo

  • Last updated on