🚚 👨🏿‍✈️ 🤹🏽 Guia do aplicativo de arquitetura em nuvem 👩🏽‍🎤 💍 🚱

Este guia estruturou diretrizes de design para aplicativos em nuvem escaláveis, resilientes e altamente acessíveis. Ele foi desenvolvido para ajudá-lo a tomar decisões sobre sua arquitetura, independentemente da plataforma em nuvem usada.

O manual é organizado como uma sequência de etapas - escolha de uma arquitetura → escolha de tecnologias para computação e armazenamento de dados → criação de um aplicativo do Azure → escolha de modelos → verificação de arquitetura. Para cada um deles, existem recomendações que ajudarão você a desenvolver a arquitetura do aplicativo.

Hoje publicamos parte do primeiro capítulo deste livro. Você pode baixar a versão completa gratuitamente aqui .

Sumário

A escolha da arquitetura - 1;
A escolha de tecnologias para computação e armazenamento de dados - 35;
Criando um aplicativo do Azure: princípios de design - 60;
Criando um aplicativo do Azure: indicadores de qualidade - 95;
Criando um aplicativo do Azure: padrões de design - 103;
Diretório de modelos - 110;
Listas de verificação de validação de arquitetura - 263;
Conclusão - 291;
Arquiteturas de Referência do Azure - 292;

Escolha da arquitetura

A primeira decisão que você precisa tomar ao projetar um aplicativo em nuvem é escolher uma arquitetura. A escolha da arquitetura depende da complexidade do aplicativo, do escopo, do seu tipo (IaaS ou PaaS) e das tarefas a que se destina. Também é importante considerar as habilidades da equipe de desenvolvimento e dos gerentes de projeto, bem como a disponibilidade de uma arquitetura pronta para o aplicativo.

A escolha da arquitetura impõe certas restrições à estrutura do aplicativo, limitando a escolha de tecnologias e outros elementos do aplicativo. Essas limitações estão associadas a vantagens e desvantagens da arquitetura selecionada.

As informações nesta seção ajudarão você a encontrar um equilíbrio entre elas ao implementar uma arquitetura específica. Esta seção lista dez princípios de design a serem lembrados. Seguir esses princípios o ajudará a criar um aplicativo mais escalável, resiliente e gerenciável.

Identificamos um conjunto de opções de arquitetura que são comumente usadas em aplicativos em nuvem. A seção dedicada a cada um deles contém:

descrição e lógica da arquitetura;
recomendações sobre o escopo dessa arquitetura;
vantagens, desvantagens e recomendações de uso;
Opção de implantação recomendada usando os serviços apropriados do Azure.

Visão geral da arquitetura

Esta seção fornece uma breve visão geral das opções de arquitetura que identificamos, bem como recomendações gerais para seu uso. Você pode encontrar informações mais detalhadas nas seções relevantes disponíveis através dos links.

Nível N

A arquitetura de camada N é mais comumente usada em aplicativos corporativos. Para gerenciar dependências, o aplicativo é dividido em camadas, cada uma das quais é responsável por uma determinada função lógica, por exemplo, pela apresentação de dados, lógica de negócios ou acesso a dados. Uma camada pode chamar outras camadas abaixo. No entanto, essa divisão em camadas horizontais pode causar dificuldades adicionais. Por exemplo, pode ser difícil fazer alterações em uma parte do aplicativo sem afetar seus outros elementos. Portanto, atualizar esse aplicativo geralmente não é fácil, e os desenvolvedores terão que adicionar novos recursos com menos frequência.

A arquitetura de camada N é uma opção natural ao transferir aplicativos já usados criados com base na arquitetura em camadas. Portanto, essa arquitetura é usada com mais frequência em soluções de IaaS (infraestrutura como serviço) ou em aplicativos que combinam IaaS com serviços gerenciados.

Interface da Web - Fila - Função do Trabalhador

Para soluções PaaS, a arquitetura da interface da web-fila-de-trabalho é adequada. Com essa arquitetura, o aplicativo possui uma interface da web que processa solicitações HTTP e uma função de trabalho de servidor responsável por operações que demoram muito tempo ou exigem recursos de computação. Uma fila de mensagens assíncrona é usada para se comunicar entre a interface e a função de trabalho do servidor.

A arquitetura "interface da web - fila - função de trabalho" é adequada para tarefas relativamente simples que requerem recursos de computação. Como a arquitetura de camada N, esse modelo é fácil de entender. O uso de serviços gerenciados simplifica a implantação e a operação. Porém, ao criar aplicativos para áreas de assunto complexas, pode ser difícil controlar dependências. A interface da Web e a função de trabalho podem ser facilmente expandidas para grandes componentes monolíticos difíceis de manter e atualizar. Assim como na arquitetura de camada N, esse modelo é caracterizado por uma menor taxa de atualização e oportunidades limitadas de aprimoramento.

Microsserviços

Se o aplicativo for projetado para resolver problemas mais complexos, tente implementá-lo com base na arquitetura de microsserviços. Esse aplicativo consiste em muitos pequenos serviços independentes. Cada serviço é responsável por uma função comercial separada. Os serviços são fracamente acoplados e usam contratos de API para interagir.

Uma pequena equipe de desenvolvedores pode trabalhar na criação de um serviço separado. Os serviços podem ser implantados sem uma coordenação complexa entre desenvolvedores, facilitando a atualização regular deles. A arquitetura do microsserviço é mais difícil de implementar e gerenciar do que as duas abordagens anteriores. Requer uma cultura madura de gerenciamento de desenvolvimento. Mas se tudo estiver organizado corretamente, essa abordagem ajudará a aumentar a frequência de lançamento de novas versões, acelerar a implementação de inovações e tornar a arquitetura mais tolerante a falhas.

Cqrs

A arquitetura do CQRS (Segregação de responsabilidade por comandos e consultas, a distribuição de responsabilidades entre equipes e consultas) permite separar operações de leitura e gravação entre modelos individuais. Como resultado, partes do sistema responsáveis pela alteração de dados são isoladas das partes responsáveis pela leitura dos dados. Além disso, as operações de leitura podem ser executadas em uma visão materializada fisicamente separada do banco de dados no qual está sendo gravado. Isso permite escalar independentemente os processos de leitura e gravação e otimizar a apresentação materializada para execução da consulta.

O modelo CQRS é melhor usado para um subsistema de uma arquitetura maior. Em geral, ele não deve ser aplicado a todo o aplicativo, pois isso complica desnecessariamente sua arquitetura. Funciona bem em sistemas de colaboração, onde um grande número de usuários trabalha simultaneamente com os mesmos dados.

Arquitetura Baseada em Eventos

Uma arquitetura baseada em eventos usa um modelo de publicação-assinatura no qual os fornecedores publicam eventos e os consumidores assinam. Os fornecedores são independentes dos consumidores e os consumidores são independentes um do outro.

Uma arquitetura baseada em eventos é adequada para aplicativos que precisam receber e processar rapidamente grandes quantidades de dados com baixa latência, como a Internet das Coisas. Além disso, essa arquitetura funciona bem nos casos em que diferentes subsistemas devem processar os mesmos dados de evento de maneira diferente.

Big data, grande computação

Big data e big computing são opções especiais de arquitetura usadas para resolver problemas especiais. Ao usar a arquitetura de big data, grandes conjuntos de dados são divididos em fragmentos, que são processados em paralelo para fins de análise e relatório. A computação grande também é chamada de computação de alto desempenho (HPC). Essa tecnologia permite distribuir a computação entre vários (milhares) de núcleos de processador. Essas arquiteturas podem ser usadas para simulação, renderização em 3D e outras tarefas semelhantes.

Opções de arquitetura como limitações

A arquitetura atua como uma restrição ao projetar uma solução, em particular, determina quais elementos podem ser usados e quais conexões entre eles são possíveis. As restrições definem a "forma" da arquitetura e permitem que você escolha entre um conjunto mais restrito de opções. Se as restrições da arquitetura selecionada forem atendidas, a solução terá propriedades características dessa arquitetura.

Por exemplo, os microsserviços são caracterizados pelas seguintes restrições:

cada serviço é responsável por uma função separada;
os serviços são independentes um do outro;
Os dados estão disponíveis apenas para o serviço responsável por eles. Os serviços não trocam dados.

Seguir essas restrições leva à criação de um sistema no qual os serviços podem ser implantados independentemente um do outro, falhas são isoladas, atualizações frequentes são possíveis e novas tecnologias são facilmente adicionadas ao aplicativo.

Antes de escolher uma arquitetura, certifique-se de entender bem os princípios subjacentes e as limitações relacionadas. Caso contrário, você pode obter uma solução que corresponda externamente ao modelo de arquitetura selecionado, mas não revela totalmente o potencial desse modelo. O senso comum também é importante. Às vezes, é mais prudente renunciar a uma ou outra restrição do que buscar uma arquitetura limpa.

A tabela a seguir mostra como o gerenciamento de dependências é implementado em cada uma de suas arquiteturas e para quais tarefas essa ou aquela arquitetura é mais adequada.

Análise das vantagens e desvantagens

As limitações criam dificuldades adicionais; portanto, é importante entender o que você deve sacrificar ao escolher uma ou outra opção de arquitetura e poder responder à pergunta se as vantagens da opção escolhida superam suas desvantagens para uma tarefa específica em um contexto específico.

Listadas abaixo estão algumas das desvantagens a serem consideradas ao escolher uma arquitetura:

Complexidade O uso de arquitetura complexa é justificado para sua tarefa? E vice-versa, é uma arquitetura muito simples escolhida para uma tarefa complexa? Nesse caso, você corre o risco de obter um sistema sem uma estrutura clara, pois a arquitetura usada não permite gerenciar corretamente as dependências.
Mensagens assíncronas e, finalmente, consistência. As mensagens assíncronas ajudam a separar os serviços e melhoram a confiabilidade (graças à capacidade de reenviar mensagens) e a escalabilidade. No entanto, cria certas dificuldades, como a semântica de apenas uma única transmissão e o problema de coerência a longo prazo.
Interação entre serviços. Se você dividir o aplicativo em serviços separados, existe o risco de que a troca de dados entre os serviços leve muito tempo ou leve ao congestionamento da rede (por exemplo, ao usar microsserviços).
Gerenciabilidade. Quão difícil será gerenciar o aplicativo, monitorar seu trabalho, implantar atualizações e executar outras tarefas?

Arquitetura de camada N

Na arquitetura de camada N, um aplicativo é dividido em camadas lógicas e físicas.

Camadas são um mecanismo para compartilhar responsabilidades e gerenciar dependências. Cada camada tem sua própria área de responsabilidade. Camadas de nível superior usam os serviços de camadas de nível inferior, mas não vice-versa.

Os níveis são fisicamente separados e funcionam em computadores diferentes. Um nível pode acessar o outro diretamente ou usando mensagens assíncronas (filas de mensagens). Embora cada camada deva ser colocada em seu próprio nível, isso não é necessário. Você pode colocar várias camadas em um nível. A separação física de níveis torna a solução não apenas mais escalável e tolerante a falhas, mas também mais lenta, pois a rede é frequentemente usada para interação. Um aplicativo tradicional de três camadas consiste em uma camada de apresentação, uma intermediária e uma de banco de dados. Um nível intermediário é opcional. Aplicativos mais complexos podem consistir em mais de três níveis. O diagrama acima mostra uma aplicação com dois níveis intermediários responsáveis por várias áreas funcionais.

Um aplicativo de camada N pode ter uma arquitetura de camada fechada ou uma arquitetura de camada aberta.

Em uma arquitetura fechada, uma camada arbitrária pode acessar apenas a camada inferior mais próxima.
Em uma arquitetura aberta, uma camada arbitrária pode se referir a quaisquer camadas inferiores.

A arquitetura da camada fechada limita as dependências entre as camadas. No entanto, seu uso pode aumentar excessivamente o tráfego de rede se uma camada específica simplesmente encaminhar solicitações para a próxima camada.

Aplicações de arquitetura

A arquitetura de camada N é normalmente usada em aplicativos IaaS, em que cada camada é executada em um conjunto separado de máquinas virtuais. No entanto, um aplicativo de camada N não precisa ser um aplicativo IaaS puro. Muitas vezes, é conveniente usar serviços gerenciados para alguns componentes de uma solução, especialmente para armazenamento em cache, sistema de mensagens e armazenamento de dados.

A arquitetura de camada N é recomendada para uso nos seguintes casos:

aplicações web simples;
Portando um aplicativo local para o Azure com refatoração mínima
implantação consistente de aplicativos locais e na nuvem.

A arquitetura de camada N é comum entre aplicativos locais comuns, portanto, é adequada para transportar aplicativos existentes para o Azure.

Os benefícios

A capacidade de transferir aplicativos entre a implantação local e a nuvem, bem como entre plataformas na nuvem.
Menos treinamento para a maioria dos desenvolvedores.
Uma extensão natural do modelo de aplicativo tradicional.
Suporte para ambientes heterogêneos (Windows / Linux).

Desvantagens

É fácil obter um aplicativo no qual a camada intermediária execute apenas operações CRUD no banco de dados, aumentando o tempo de processamento das solicitações e não trazendo nenhum benefício.
A arquitetura monolítica não permitirá o desenvolvimento de componentes individuais por equipes de desenvolvimento independentes.
O gerenciamento de um aplicativo IaaS consome mais tempo do que um aplicativo gerenciado apenas de serviço.
Pode ser difícil gerenciar a segurança da rede em sistemas grandes.

Recomendações

Use a escala automática com carga variável. Consulte Práticas recomendadas para dimensionamento automático.
Use mensagens assíncronas para separar os níveis um do outro.
Cache de dados semi-estáticos. Consulte Considerações sobre armazenamento em cache.
Garanta alta disponibilidade no nível do banco de dados com uma solução como Grupos de Disponibilidade AlwaysOn no SQL Server.
Instale um firewall de aplicativo da web (WAF) entre a interface e a Internet.
Coloque cada nível em sua própria sub-rede; use sub-redes como limites de segurança.
Limite o acesso à camada de dados, permitindo apenas consultas de camadas intermediárias.

Arquitetura de máquina virtual de camada N

Esta seção fornece diretrizes para a construção de uma arquitetura de camada N usando máquinas virtuais.

Esta seção fornece diretrizes para a construção de uma arquitetura de camada N usando máquinas virtuais. Cada camada consiste em duas ou mais máquinas virtuais hospedadas em um conjunto de disponibilidade ou em um conjunto escalável de máquinas virtuais. O uso de várias máquinas virtuais fornece tolerância a falhas em caso de falha de uma delas. Para distribuir solicitações entre máquinas virtuais do mesmo nível, são utilizados subsistemas de balanceamento de carga. O nível pode ser dimensionado horizontalmente, adicionando novas máquinas virtuais ao pool.

Cada nível também é colocado dentro de sua própria sub-rede. Isso significa que seus endereços IP internos estão no mesmo intervalo. Isso facilita a aplicação de regras do grupo de segurança de rede (NSG) e tabelas de roteamento em camadas individuais.

O estado da camada da web e da empresa não é monitorado. Qualquer máquina virtual pode lidar com qualquer solicitação para esses níveis. A camada de dados deve consistir em um banco de dados replicado. Para Windows, recomendamos o uso do SQL Server com grupos de disponibilidade AlwaysOn para alta disponibilidade. Para Linux, você deve escolher um banco de dados que suporte replicação, como o Apache Cassandra.

O acesso a cada nível é limitado por grupos de segurança de rede (NSGs). Por exemplo, o acesso à camada de banco de dados é permitido apenas para a camada de negócios

Recursos adicionais

A arquitetura de camada N não precisa consistir em três camadas. Aplicativos mais complexos tendem a usar mais níveis. Nesse caso, use o roteamento através da camada 7 para redirecionar solicitações para um nível específico.
Os níveis limitam a decisão sobre escalabilidade, confiabilidade e segurança. É recomendável usar níveis diferentes para serviços com requisitos diferentes para essas características.
Use o dimensionamento automático usando conjuntos escaláveis de máquinas virtuais.
Encontre elementos em sua arquitetura que você pode implementar com serviços gerenciados sem grande refatoração. Em particular, preste atenção ao armazenamento em cache, mensagens, armazenamento e bancos de dados.
Para aumentar a segurança, coloque o aplicativo atrás da rede de perímetro. A rede de perímetro inclui componentes de rede virtual que fornecem segurança, como firewalls e inspetores de pacotes. Para obter mais informações, consulte Arquitetura de rede de referência de perímetro.
Para alta disponibilidade, coloque dois ou mais componentes de rede virtual no conjunto de disponibilidade e adicione um balanceador de carga para distribuir solicitações da Internet entre eles. Para obter mais informações, consulte Implantando componentes de rede virtual para alta disponibilidade.
Não permita o acesso direto a máquinas virtuais executando o código do aplicativo nos protocolos RDP e SSH. Em vez disso, os operadores devem inserir o nó do bastião. Essa é uma máquina virtual localizada em rede usada pelos administradores para conectar-se a outras máquinas virtuais. No host bastião, as regras NSG são configuradas para permitir o acesso via RDP e SSH somente a partir de endereços IP públicos aprovados.
Você pode expandir a rede virtual do Azure para uma rede local usando um tipo de rede virtual (VPN) de rede para rede ou o Azure ExpressRoute. Para mais informações, consulte Arquitetura de referência de rede híbrida.
Se sua organização usa o Active Directory para gerenciamento de identidades, você pode estender seu ambiente do Active Directory para a rede virtual do Azure. Para obter mais informações, consulte Arquitetura de referência de gerenciamento de identidade.
Se um nível de disponibilidade mais alto for necessário que o exigido pelo Contrato de Nível de Serviço da Máquina Virtual do Azure, replique o aplicativo entre as duas regiões e configure o Gerenciador de Tráfego do Azure para failover. Para obter mais informações, consulte Iniciando máquinas virtuais Windows em várias regiões e Iniciando máquinas virtuais Linux em várias regiões.

Você pode baixar a versão completa do livro gratuitamente e estudá-lo no link abaixo.

→ Baixar

Guia do aplicativo de arquitetura em nuvem