Estilos de arquitetura

Um estilo de arquitetura é uma família de arquiteturas que compartilham características específicas. Por exemplo, N camadas é um estilo de arquitetura comum. Mais recentemente, as arquiteturas de microsserviço estão começando a ganhar favores. Os estilos de arquitetura não exigem o uso de tecnologias específicas, mas algumas tecnologias são mais adequadas para determinadas arquiteturas. Por exemplo, os contêineres são adequados para microsserviços.

Identificamos um conjunto de estilos de arquitetura que geralmente são encontrados em aplicativos de nuvem. O artigo para cada estilo inclui os seguintes componentes:

• Uma descrição e um diagrama lógico do estilo
• Recomendações para quando escolher esse estilo
• Benefícios, desafios e práticas recomendadas
• Uma implantação recomendada que usa serviços relevantes do Azure

Um tour rápido pelos estilos

Esta seção fornece um tour rápido dos estilos de arquitetura que identificamos, juntamente com algumas considerações de alto nível para seu uso. Essa lista não é completa. Leia mais detalhes nos artigos vinculados.

N-camadas de serviço

N-tier é uma arquitetura tradicional para aplicativos empresariais que divide um aplicativo em camadas lógicas e níveis físicos. Cada camada tem uma responsabilidade específica, e as camadas gerenciam dependências ao chamarem só as camadas abaixo delas. As camadas típicas incluem apresentação, lógica de negócios e acesso a dados.

As arquiteturas de N camadas são adequadas para migrar aplicativos existentes que já usam uma arquitetura em camadas. Essa abordagem requer alterações mínimas quando você se move para o Azure e dá suporte a ambientes mistos com componentes locais e de nuvem. Mas as camadas horizontais podem dificultar a introdução de alterações sem afetar várias partes do aplicativo, o que limita a agilidade para atualizações frequentes.

Trabalhador de fila da Web

Web-Queue-Worker é uma arquitetura que consiste em um front-end da Web, uma fila de mensagens e um trabalho de back-end. O front-end da Web lida com solicitações HTTP e interações do usuário, enquanto o worker executa tarefas que exigem muitos recursos, fluxos de trabalho de longa duração ou operações em lote. A comunicação entre o frontend e o trabalhador ocorre por meio de uma fila de mensagens assíncronas.

Essa arquitetura é ideal para aplicativos com domínios relativamente simples que têm alguns requisitos de processamento com uso intensivo de recursos. É fácil entender e implantar com serviços gerenciados do Azure, como o Serviço de Aplicativo e o Azure Functions. Você pode dimensionar o front-end e o trabalho de forma independente para fornecer flexibilidade na alocação de recursos. Mas sem um design cuidadoso, ambos os componentes podem se tornar grandes e monolíticos.

Microsserviços

A arquitetura de microsserviços decompõe aplicativos em uma coleção de serviços pequenos e autônomos. Cada serviço implementa uma única capacidade de negócios dentro de um contexto delimitado e é auto-suficiente com seu próprio armazenamento de dados. Os serviços se comunicam por meio de APIs bem definidas e podem ser desenvolvidos, implantados e dimensionados de forma independente.

Os microsserviços permitem que as equipes trabalhem de forma autônoma e ofereçam suporte a atualizações frequentes com maior velocidade de lançamento. Essa arquitetura é adequada para domínios complexos que exigem alterações frequentes e inovação. Mas ele introduz uma complexidade significativa em áreas como descoberta de serviço, consistência de dados e gerenciamento de sistema distribuído. O sucesso requer o desenvolvimento maduro e as práticas de DevOps, o que o torna mais adequado para organizações que têm funcionalidades técnicas avançadas.

Arquitetura baseada em evento

As arquiteturas orientadas a eventos usam um modelo de publicação/assinatura em que os produtores de eventos geram fluxos de eventos e os consumidores de eventos respondem a esses eventos quase em tempo real. Produtores e consumidores são separados uns dos outros, com a comunicação acontecendo por meio de canais de eventos ou agentes. Essa arquitetura dá suporte ao processamento de eventos simples e à análise de padrões de eventos complexos.

As arquiteturas orientadas a eventos se destacam em cenários que exigem processamento em tempo real com latência mínima. Alguns exemplos são soluções de IoT, sistemas de negociação financeira ou aplicativos que precisam processar grandes volumes de dados de streaming. As arquiteturas controladas por eventos fornecem excelente escalabilidade e isolamento de falhas, mas introduzem desafios em relação à entrega garantida, à ordenação de eventos e à consistência eventual entre componentes distribuídos.

Big Data

As arquiteturas de Big Data lidam com a ingestão, o processamento e a análise de dados muito grandes ou complexos para sistemas de banco de dados tradicionais. Essas arquiteturas normalmente incluem componentes para armazenamento de dados (como data lakes), processamento em lote para análise histórica, processamento de fluxo para insights em tempo real e armazenamentos de dados analíticos para relatórios e visualização.

As arquiteturas de Big Data são essenciais para organizações que precisam extrair insights de conjuntos de dados maciços, dar suporte à análise preditiva usando aprendizado de máquina ou processar dados de streaming em tempo real de dispositivos IoT. Implementações modernas geralmente usam serviços gerenciados como o Microsoft Fabric para simplificar a complexidade da criação e manutenção de soluções de Big Data.

Computação em grande escala

As arquiteturas de computação grande dão suporte a cargas de trabalho em larga escala que exigem centenas ou milhares de núcleos para operações computacionalmente intensivas. O trabalho pode ser dividido em tarefas discretas que são executadas em vários núcleos simultaneamente, com cada tarefa recebendo entrada, processando-a e produzindo saída. As tarefas podem ser independentes (embaraçosamente paralelas) ou firmemente acopladas, exigindo comunicação de alta velocidade.

A computação grande é essencial para simulações, modelagem de risco financeiro, computação científica, análise de estresse de engenharia e renderização 3D. O Azure fornece opções como o Azure Batch para cargas de trabalho de computação de grande porte gerenciadas ou o HPC Pack para gerenciamento de cluster mais tradicional. Essas arquiteturas podem aumentar a capacidade conforme a demanda e escalar para milhares de núcleos quando necessário.

Estilos de arquitetura como restrições

Um estilo de arquitetura coloca restrições no design, incluindo o conjunto de elementos que podem aparecer e as relações permitidas entre esses elementos. As restrições orientam a "forma" de uma arquitetura restringindo o universo de opções. Quando uma arquitetura está em conformidade com as restrições de um estilo específico, determinadas propriedades desejáveis surgem.

Por exemplo, as restrições em microsserviços incluem:

• Um serviço representa uma única responsabilidade.
• Cada serviço é independente dos outros.
• Os dados são privados para o serviço que o possui. Os serviços não compartilham dados.

Ao aderir a essas restrições, você obtém um sistema que permite executar as seguintes ações:

• Implantar serviços de forma independente.
• Isolar falhas.
• Envie mais atualizações frequentes.
• Introduza novas tecnologias no aplicativo com mais facilidade.

Cada estilo de arquitetura tem suas próprias compensações. Antes de escolher um estilo arquitetônico, é essencial entender os princípios e restrições subjacentes. Sem esse entendimento, você corre o risco de criar um design que esteja superficialmente em conformidade com o estilo sem perceber seus benefícios completos. Concentre-se mais no motivo pelo qual você está selecionando um estilo específico do que em como implementá-lo. Seja prático. Às vezes é melhor relaxar uma restrição do que perseguir a puridade arquitetônica.

Idealmente, a escolha do estilo arquitetônico deve ser feita com a contribuição de partes interessadas informadas sobre a carga de trabalho. A equipe de carga de trabalho deve começar identificando a natureza do problema que está resolvendo. Em seguida, eles devem definir os principais drivers de negócios e as características de arquitetura correspondentes, também conhecidos como requisitos não funcionais, e priorizá-los. Por exemplo, se o tempo de comercialização for crítico, a equipe poderá priorizar a manutenção, a testabilidade e a confiabilidade para habilitar a implantação rápida. Se a equipe tiver restrições de orçamento apertadas, a viabilidade e a simplicidade poderão ter precedência. Selecionar e manter um estilo de arquitetura não é uma tarefa única. Requer medida contínua, validação e refinamento. Como a mudança da direção arquitetônica mais tarde pode ser dispendiosa, muitas vezes vale a pena investir mais esforços antecipadamente para dar suporte à eficiência de longo prazo e reduzir os riscos.

A tabela a seguir resume como cada estilo gerencia dependências e os tipos de domínio mais adequados para cada estilo.

Considere desafios e benefícios

As restrições também criam desafios, portanto, é importante entender as compensações quando você adota qualquer um desses estilos. Determine se os benefícios do estilo de arquitetura superam os desafios para esse subdomínio e contexto limitado.

Considere os seguintes tipos de desafios ao selecionar um estilo de arquitetura:

• Complexidade: A complexidade da arquitetura deve corresponder ao domínio. Se for muito simplista, pode resultar em uma grande bola de lama, onde as dependências não são bem gerenciadas e a estrutura quebra.

• Mensagens assíncronas e consistência eventual: As mensagens assíncronas são usadas para desacoplar serviços e melhorar a confiabilidade porque as mensagens podem ser repetidas. Ele também aprimora a escalabilidade. No entanto, o sistema de mensagens assíncrona também cria desafios para lidar com a consistência eventual e a possibilidade de mensagens duplicadas.

• Comunicação entre serviços: Decompor um aplicativo em serviços separados pode aumentar a sobrecarga de comunicação. Em arquiteturas de microsserviços, essa sobrecarga geralmente resulta em problemas de latência ou congestionamento de rede.

• Gerenciamento: O gerenciamento do aplicativo inclui tarefas como monitoramento, implantação de atualizações e manutenção da integridade operacional.

Recursos relacionados

• Dez princípios de design para aplicativos do Azure

Próximas etapas

• Criar aplicativos no Microsoft Cloud
• Práticas recomendadas em aplicativos de nuvem
• Padrões de design de nuvem
• Testes de desempenho e antipadrões para aplicativos de nuvem
• Arquitetar soluções multitenant no Azure
• Arquitetura de carga de trabalho crítica no Azure
• Arquitetura para inicializações