Editar

Compartilhar via


Arquitetura com linha de base do Aplicativos Spring do Azure

Gateway de Aplicativo do Azure
Cofre de Chave do Azure
Azure Spring Apps
Banco de Dados do Azure para MySQL

Essa arquitetura de referência descreve como executar as cargas de trabalho do Java Spring Boot no Aplicativos Spring do Azure. O design usa redundância de zona para obter alta disponibilidade. Implemente esse design para evitar que um aplicativo falhe se houver uma interrupção de serviços em todos os datacenters em uma zona.

Essa arquitetura ajuda você a:

  • Aumentar a disponibilidade do seu aplicativo em uma implantação de zona única.
  • Aumentar a resiliência geral e o Objetivo a Nível de Serviço (SLO) para seu aplicativo.

Essa solução apresenta uma estratégia com linha de base para a implantação do Aplicativos Spring do Azure. Para obter outras soluções que são compiladas nessa arquitetura, consulte Implantar o Aplicativos Spring do Azure em várias regiões e Aplicativos Spring do Azure integrados com zonas de destino.

Dica

Logotipo do GitHub Veja uma implementação de exemplo que ilustra algumas das opções de design dessa arquitetura. Considere essa implementação como sua primeira etapa em direção à produção.

Arquitetura

O seguinte diagrama mostra a arquitetura para esta abordagem:

Diagrama que mostra uma arquitetura de referência do Azure Spring Apps de várias regiões.Baixe um Arquivo Visio dessa arquitetura.

Workflow

Esse fluxo de trabalho corresponde ao diagrama anterior:

  1. O usuário acessa o aplicativo usando o nome do host HTTP do aplicativo, como www.contoso.com. O DNS do Azure é usado para resolver a solicitação desse nome de host para o ponto de extremidade público do Gateway de Aplicativo do Azure.

  2. O Gateway de Aplicativo é usado para inspecionar a solicitação. Ele também é usado para encaminhar o tráfego permitido para o endereço IP do balanceador de carga que está na instância provisionada do Aplicativos Spring do Azure. O Gateway de Aplicativo é integrado com Firewall de Aplicativo Web.

  3. O balanceador de carga interno é usado para rotear o tráfego para os serviços de back-end.

  4. Enquanto a solicitação está sendo processada, o aplicativo se comunica com outros serviços do Azure dentro da rede virtual. Por exemplo, o aplicativo pode receber segredos do Azure Key Vault ou do estado de armazenamento do banco de dados.

Componentes

Os seguintes serviços do Azure são os componentes dessa arquitetura:

  • A versão Standard do Aplicativos Spring do Azure é usada para hospedar um aplicativo de Java Spring Boot de amostra que é implementado como microsserviços.

  • A versão Standard v2 do Gateway de Aplicativo é usada para gerenciar o tráfego para os aplicativos. Ele atua como um proxy reverso local na região em que seu aplicativo é executado.

    Essa SKU tem Firewall do Aplicativo Web integrado para ajudar a proteger seus aplicativos Web contra abusos e vulnerabilidades. O Firewall do Aplicativo Web no Gateway de Aplicativo rastreia abusos no Open Web Application Security Project (OWASP).

  • O DNS do Azure é usado para resolver solicitações que são enviadas para o nome do host do aplicativo. Ele resolve essas solicitações para o ponto de extremidade público do Gateway de Aplicativo. As Zonas privadas de DNS do Azure são usadas para resolver solicitações para os pontos de extremidade privados que acessam os recursos nomeados no Link Privado do Azure.

  • O Banco de Dados do Azure para MySQL é usado para armazenar o estado em um banco de dados back-end relacional.

  • O Key Vault é usado para armazenar segredos e certificados do aplicativo. Os microsserviços que são executados no Aplicativos Spring do Azure usam os segredos do aplicativo. O Aplicativos Spring do Azure e o Gateway de Aplicativo usam os certificados para preservação do nome do host.

Alternativas

O Banco de Dados do Azure para MySQL não é a única opção para um banco de dados. Também é possível usar:

Redundância

Compilar redundância em sua carga de trabalho para minimizar os pontos únicos de falha. Nessa arquitetura, você replica componentes entre zonas dentro de uma região. Em sua arquitetura, certifique-se de usar zonas de disponibilidade para todos os componentes em sua configuração.

Os serviços do Azure não têm suporte em todas as regiões e nem todas as regiões dão suporte a zonas. Antes de você selecionar uma região, verifique o seu suporte regional e o suporte de zona.

Os serviços com redundância de zona automaticamente replicam ou distribuem recursos entre zonas. Os serviços sempre disponíveis estão sempre disponíveis em todas as regiões geográficas do Azure e são resilientes a interrupções em toda a zona e em toda a região.

A seguinte tabela mostra os tipos de resiliência para os serviços nesta arquitetura:

Serviço Resiliência
DNS do Azure Sempre disponível
Gateway de Aplicativo Redundância de zona
Aplicativos Spring do Azure Redundância de zona
Banco de Dados do Azure para MySQL Redundância de zona
Key Vault Redundância de zona
Rede Virtual do Azure Redundância de zona
Pontos de extremidade privados do Azure Redundância de zona

O Aplicativos Spring do Azure oferece suporte a redundância de zona. Com a redundância de zona, toda a infraestrutura subjacente do serviço é distribuída entre várias zonas de disponibilidade, o que fornece maior disponibilidade para o aplicativo. Os aplicativos são dimensionados horizontalmente sem nenhuma alteração de código. Uma rede de alto desempenho conecta as zonas de disponibilidade do Azure. A conexão tem uma latência de ida e volta inferior a 2 milissegundos (ms). Você não precisa de depender da replicação assíncrona para cargas de trabalho de dados, o que geralmente apresenta desafios de design.

Várias zonas de disponibilidade são configuradas para o Gateway de Aplicativo, incluindo o endereço IP público que o Gateway de Aplicativo usa. Endereços IP públicos com um suporte de SKU padrão para zonas de disponibilidade.

Essa arquitetura usa o Banco de Dados do Azure para MySQL com a opção de implantação de Servidor Flexível para dar suporte à alta disponibilidade com failover automático. Dependendo de seus requisitos de latência, escolha alta disponibilidade de redundância de zona ou alta disponibilidade na mesma zona. Com uma configuração de alta disponibilidade, a opção Servidor Flexível provisiona e gerencia automaticamente uma réplica em espera. Se houver uma interrupção de serviços, os dados comprometidos não se perdem.

O Key Vault é automaticamente redundante por zona em qualquer região em que existam zonas de disponibilidade disponíveis. A instância do Key Vault usada nessa arquitetura é implantada para armazenar segredos para serviços de back-end.

Escalabilidade

A escalabilidade indica a capacidade da carga de trabalho de atender com eficiência as exigências que os usuários lhe colocam. A abordagem de várias zonas é melhor para escalabilidade do que uma implantação de zona única porque ela espalha a carga entre zonas de disponibilidade.

Essa arquitetura tem vários componentes que podem dimensionar automaticamente com base em métricas:

Dependendo da configuração do seu banco de dados, pode incorrer latência extra quando precisar de sincronizar dados entre zonas.

Segurança de rede

Proteja seu aplicativo contra acesso não autorizado da Internet, sistemas em redes privadas, outros serviços do Azure e dependências fortemente acopladas.

A Rede Virtual é o bloco de compilação fundamental para uma rede privada no Azure. Essa arquitetura usa uma rede virtual para a região da implantação. Coloque componentes em sub-redes para criar isolamento adicional. O Aplicativos Spring do Azure requer uma sub-rede dedicada para o runtime do serviço e uma sub-rede separada para aplicativos de Java Spring Boot.

Proteja suas redes virtuais com Proteção contra DDoS do Azure. Combinar proteção contra ataque de negação de serviço distribuído (DDoS) com as melhores práticas de design de aplicativos para oferece mitigações aprimoradas para proteger contra ataques de DDoS.

O design de arquitetura incorpora várias soluções de plataforma como serviço (PaaS) que ajudam a processar uma solicitação de usuário. Coloque controles de rede rigorosos nesses serviços para garantir que o aplicativo não seja afetado.

Conectividade privada

Use pontos de extremidade privados ou integração de rede para fornecer comunicação do Aplicativos Spring do Azure para serviços de suporte, como o Key Vault e o Banco de Dados do Azure para MySQL.

Use pontos de extremidade privados para controlar acesso. Os adaptadores de rede usam endereços IP privados para transferir os serviços para a rede virtual. Essa arquitetura usa os serviços do Azure que configuram automaticamente os pontos de extremidade privados.

Implantar o Aplicativos Spring do Azure na rede através do processo de injeção de rede virtual. O aplicativo é acessado através do endereço IP privado.

O banco de dados segue um modelo semelhante. O Modo de implantação de Servidor Flexível do Banco de Dados do Azure para MySQL dá suporte à integração de rede virtual por meio de uma sub-rede dedicada.

Outros serviços, como o Key Vault, são conectados à rede virtual através do Link Privado. Para o Link Privado, você precisa habilitar um ponto de extremidade privado para desabilitar o acesso à rede pública. Para obter mais informações, consulte Integrar Key Vault com Link Privado.

Pontos de extremidade privados não exigem uma sub-rede dedicada, mas é uma boa prática colocá-los em uma sub-rede separada. Os endereços IP privados para os pontos de extremidade privados são atribuídos a partir dessa sub-rede.

O ponto de extremidade privado e as conexões integradas à rede usam uma Zona privada DNS do Azure.

Controles no fluxo de tráfego

Com essa arquitetura, as solicitações de entrada são permitidas somente através do ponto de extremidade público exposto pelo Gateway de Aplicativo. O tráfego ainda precisa ser inspecionado para bloquear abusos e vulnerabilidades. O Firewall do Aplicativo Web no Gateway de Aplicativo rastreia vulnerabilidades no OWASP. O tráfego de entrada é inspecionado com base nas regras configuradas com uma ação a seguir.

A instância do Aplicativos Spring do Azure tem um balanceador de carga interno que roteia e distribui o tráfego para os serviços de back-end. O balanceador de carga é configurado para aceitar o tráfego somente através do Gateway de Aplicativo.

O aplicativo pode precisar de se conectar a outros pontos de extremidade através da Internet pública. Para restringir esse fluxo, considere colocar o Firewall do Azure no caminho de saída.

Configuração de proxy reverso

Essa solução usa o Gateway de Aplicativo como um proxy reverso. Mas você pode usar diferentes proxies reversos na frente do Aplicativos Spring do Azure. Você pode combinar o Gateway de Aplicativo com o Azure Front Door, ou usar o Azure Front Door em vez do Gateway de Aplicativo.

Para obter informações sobre cenários de proxy reverso, como configurá-los e suas considerações de segurança, consulte Expor o Aplicativos Spring do Azure através de um proxy reverso.

Gerenciamento de identidade e acesso

Para além de usar controles de rede, fortaleça a postura de segurança usando a identidade como perímetro.

O aplicativo deve se autenticar quando se conectar aos serviços de back-end, por exemplo, se o aplicativo recuperar segredos do Key Vault. No aplicativo, a abordagem recomendada é habilitar as Identidades gerenciadas para recursos do Azure através do Microsoft Entra ID. Esse método de configuração atribui uma identidade ao aplicativo para que ele possa obter tokens do Microsoft Entra ID, o que reduz a sobrecarga de gerenciamento de credenciais.

Essa arquitetura usa as identidades gerenciadas atribuídas pelo sistema para várias interações.

Os serviços de back-end devem permitir o acesso à entidade de serviço alocada à identidade gerenciada. O serviço deve definir políticas de acesso mínimas para determinadas ações. Nessa arquitetura, o Key Vault é usado para dar ao aplicativo acesso aos segredos, certificados e chaves.

Gerenciamento de segredos

Essa arquitetura armazena os segredos e certificados do aplicativo em um único cofre de chaves. Os segredos e certificados do aplicativo para preservação de nome de host são preocupações diferentes, portanto, talvez você queira armazenar esses itens em cofres de chaves separados. Essa abordagem alternativa adiciona outro cofre de chaves à sua arquitetura.

Monitoramento

O Azure Monitor é uma solução de monitoramento para coletar, analisar e responder à dados de monitoramento dos seus ambientes de nuvem e no local.

Adicione instrumentação ao seu aplicativo para emitir logs e métricas no nível do código. Considere habilitar o rastreamento distribuído para fornecer observabilidade entre os serviços na instância do Aplicativos Spring do Azure. Uma ferramenta de gerenciamento de desempenho de aplicativos (APM) é usada para coletar logs e métricas de dados. O agente Java do Application Insights para o Azure Monitor é uma boa escolha para a ferramenta APM.

Use o diagnóstico de plataforma para obter logs e métricas de todos os serviços do Azure, como o Banco de Dados do Azure para MySQL. Integre todos os dados no Logs do Azure Monitor para fornecer insights de ponta a ponta e serviços de plataforma ao seu aplicativo.

O Workspace do Azure Log Analytics é o coletor de dados de monitoramento que coleta logs e métricas dos recursos do Azure e do Application Insights. Essa solução de registro em log fornece visibilidade, o que ajuda os processos de automação a escalar componentes em tempo real. A análise de dados de log também pode revelar ineficiências no código do aplicativo que você pode abordar para melhorar os custos e o desempenho.

Para obter diretrizes de monitoramento específicas do Spring App, consulte Monitorar aplicativos de ponta a ponta e Monitor com o Dynatrace Java OneAgent.

Implantação automatizada

Automatize a implantação da infraestrutura e as implantações de código de aplicativo o máximo possível.

A automação das implantações de infraestrutura garante que a configuração da infraestrutura seja idêntica, o que ajuda a evitar o descompasso de configuração, possivelmente entre ambientes. Você também pode usar a automação de infraestrutura para testar operações de failover.

Você pode usar uma estratégia de implantação azul-verde ou canário para seus aplicativos.

Considerações

Estas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios de orientação que podem ser usados para aprimorar a qualidade de uma carga de trabalho. Para obter mais informações, confira Microsoft Azure Well-Architected Framework.

As considerações a seguir fornecem diretrizes para a implantação dos pilares da Estrutura Azure Well-Architected no contexto dessa arquitetura.

Confiabilidade

A confiabilidade garante que seu aplicativo possa cumprir os compromissos que você deve assumir com seus clientes. Para obter mais informações, confira Visão geral do pilar de confiabilidade.

Implemente as seguintes sugestões para criar um aplicativo mais confiável:

Segurança

A segurança fornece garantias contra ataques deliberados e o abuso de seus dados e sistemas valiosos. Para saber mais, confira Visão geral do pilar de segurança.

Implemente as seguintes sugestões para criar um aplicativo mais seguro:

Otimização de custo

A otimização de custos é a análise de maneiras de reduzir as despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, confira Visão geral do pilar de otimização de custo.

Para essa arquitetura, espere um custo mais alto porque você implementa componentes em várias zonas. Em vez de uma instância do Aplicativos Spring do Azure, você executa duas ou até três instâncias. Mas não há custo adicional para habilitar a redundância de zona no serviço. Para obter mais informações, consulte Preços do Aplicativos Spring do Azure.

Considere as seguintes opções de implementação para lidar com os custos:

  • Você pode implantar diferentes aplicativos e tipos de aplicativos em uma única instância do Aplicativos Spring do Azure. Quando você implanta vários aplicativos, o custo da infraestrutura subjacente é compartilhado entre os aplicativos.

  • O Aplicativos Spring do Azure oferece suporte ao dimensionamento automático de aplicativos acionado por métricas ou agendamentos, o que pode melhorar a utilização e a eficiência de custos.

  • Você também pode usar o Application Insights no Azure Monitor para reduzir o custo operacional. O monitoramento contínuo pode ajudar a resolver problemas mais rapidamente e melhorar os custos e o desempenho.

  • Escolha o melhor tipo de preço com base nos seus requisitos:

  • Use o dimensionamento automático de aplicativos para escalar verticalmente e horizontalmente com base na demanda.

Para obter uma estimativa do custo dos serviços para essa arquitetura, consulte a Calculadora de preços do Azure. Essa estimativa usa valores padrão razoáveis para um aplicativo de pequena escala. Você pode atualizar a estimativa com base nos valores de taxa de transferência esperados para seu aplicativo.

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, confira Visão geral do pilar de excelência operacional.

Além das diretrizes de monitoramento abordadas anteriormente, implemente as sugestões a seguir para ajudá-lo a implantar e monitorar seu aplicativo.

Eficiência de desempenho

A eficiência do desempenho é a capacidade de dimensionar sua carga de trabalho para atender às demandas colocadas por usuários de maneira eficiente. Para saber mais, confira Visão geral do pilar de eficiência de desempenho.

Implemente as seguintes sugestões para criar um aplicativo mais eficiente:

Implantar este cenário

Para implementar essa arquitetura, siga as instruções passo a passo em Arquitetura de referência de várias zonas do Aplicativos Spring do Azure. A implantação usa modelos do Terraform.

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Autor principal:

Para ver perfis não públicos do LinkedIn, entre no LinkedIn.

Próximas etapas