Estilos de arquitetura

Um estilo de arquitetura é uma família de arquiteturas que compartilham determinadas características. Por exemplo, N camadas é um estilo de arquitetura comum. Mais recentemente, as arquiteturas de microsserviço começaram a ganhar favores. Os estilos de arquitetura não exigem o uso de tecnologias específicas, mas algumas tecnologias são adequadas para determinadas arquiteturas. Por exemplo, os contêineres são naturalmente 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:

• 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 usando serviços relevantes do Azure.

Um tour rápido pelos estilos

Esta seção fornece um tour rápido pelos estilos de arquitetura que identificamos, juntamente com algumas considerações de alto nível para seu uso. Observe que a lista não é exaustiva. Leia mais detalhes nos tópicos vinculados.

N-camadas de serviço

N camadas é uma arquitetura tradicional para aplicativos empresariais. As dependências são gerenciadas dividindo o aplicativo em camadas que executam funções lógicas, como apresentação, lógica de negócios e acesso a dados. Uma camada só pode fazer chamadas para as camadas que estão abaixo dela. No entanto, essa camada horizontal pode representar um risco. Pode ser difícil introduzir alterações em uma parte do aplicativo sem tocar no restante do aplicativo. Isso torna as atualizações frequentes um desafio, limitando a rapidez com que novos recursos podem ser adicionados.

N camadas é uma opção natural para migrar os aplicativos existentes que já usam uma arquitetura em camadas. Por esse motivo, a camada N geralmente é vista em soluções iaaS (infraestrutura como serviço) ou aplicativo que usa uma combinação de IaaS e serviços gerenciados.

Trabalhador de fila da Web

Para uma solução puramente PaaS, considere uma arquitetura Web-Queue-Worker . Nesse estilo, o aplicativo tem um front-end da Web que lida com solicitações HTTP e um trabalho de back-end que executa tarefas com uso intensivo de CPU ou operações de execução longa. O front-end se comunica com o trabalhador por meio de uma fila de mensagens assíncrona.

O Web-queue-worker é adequado para domínios relativamente simples com algumas tarefas com uso intensivo de recursos. Assim como a arquitetura de N-camadas, essa arquitetura é fácil de entender. O uso de serviços gerenciados simplifica a implantação e as operações. Mas com domínios complexos, pode ser difícil gerenciar dependências. O front-end e o trabalhador podem facilmente se tornar componentes grandes e monolíticos difíceis de manter e atualizar. Assim como acontece com n camadas, isso pode reduzir a frequência de atualizações e limitar a inovação.

Microsserviços

Se seu aplicativo tiver um domínio mais complexo, considere mover para uma arquitetura de Microsserviços . Um aplicativo de microsserviços é composto por muitos serviços pequenos e independentes. Cada serviço implementa uma única funcionalidade de negócios. Os serviços são flexívelmente acoplados, comunicando-se por meio de contratos de API.

Cada serviço pode ser criado por uma equipe de desenvolvimento pequena e focada. Serviços individuais podem ser implantados sem muita coordenação entre as equipes, o que incentiva atualizações frequentes. Uma arquitetura de microsserviço é mais complexa de criar e gerenciar que as de N camadas ou de trabalhador de fila da Web. Requer um desenvolvimento maduro e uma cultura de DevOps. Mas feito corretamente, esse estilo pode levar a uma maior velocidade de lançamento, inovação mais rápida e uma arquitetura mais resiliente.

Arquitetura baseada em evento

Event-Driven Arquiteturas usam um modelo de publicação-assinatura (pub-sub), em que os produtores publicam eventos e os consumidores os assinam. Os produtores são independentes dos consumidores e os consumidores são independentes uns dos outros.

Considere uma arquitetura orientada a eventos para aplicativos que ingerem e processam um grande volume de dados com latência muito baixa, como soluções de IoT. O estilo também é útil quando subsistemas diferentes devem executar diferentes tipos de processamento nos mesmos dados de evento.

Big Data, Grande Computação

Big Data e Big Compute são estilos de arquitetura especializados para cargas de trabalho que se encaixam em determinados perfis específicos. O Big Data divide um conjunto de dados muito grande em partes, executando o processamento paralelo em todo o conjunto, para análise e relatórios. A computação grande, também chamada de HPC (computação de alto desempenho), faz cálculos paralelos em um grande número (milhares) de núcleos. Os domínios incluem simulações, modelagem e renderização 3D.

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, o que surge é um sistema em que os serviços podem ser implantados de forma independente, as falhas são isoladas, atualizações frequentes são possíveis e é fácil introduzir novas tecnologias no aplicativo.

Cada estilo de arquitetura tem suas próprias compensações. Portanto, antes de escolher qualquer estilo arquitetônico, certifique-se de entender os princípios e restrições subjacentes desse estilo. Caso contrário, você pode acabar com um design que está em conformidade com o estilo em um nível superficial, mas não alcança todo o potencial desse estilo. Você precisa prestar mais atenção ao motivo pelo qual está escolhendo um determinado estilo arquitetônico do que como implementá-lo. Também é importante ser pragmático. Às vezes é melhor relaxar uma restrição, em vez de insistir na puridade arquitetônica.

A escolha de um estilo de arquitetura apropriado deve ser feita, de preferência, com o consenso dos stakeholders informados sobre a carga de trabalho. A equipe de carga de trabalho deve primeiro identificar a natureza do problema que está tentando resolver. Em seguida, eles devem identificar os 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 precisarem de um tempo mais curto para o mercado, eles poderão priorizar a manutenção, a testabilidade e a confiabilidade por meio de recursos de implantação rápida. Ou se a equipe de carga de trabalho tiver orçamento restrito, ela poderá priorizar a viabilidade e a simplicidade. Escolher e manter um estilo arquitetônico não é uma atividade única, mas uma abordagem contínua: a arquitetura deve ser continuamente medida, validada e ajustada ao longo do tempo. Geralmente, há um custo significativo envolvido na mudança de estilo arquitetônico, de modo que mais esforço antecipadamente pode ser justificado para eficiência da equipe de longo prazo e mitigação de risco.

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

Estilo de arquitetura	Gerenciamento de dependências	Tipo de domínio
N camadas	Camadas horizontais divididas por sub-rede	Domínio comercial tradicional. A frequência de atualizações é baixa.
Web-fila-trabalho	Trabalhos de front-end e back-end, separados por mensagens assíncronas.	Domínio relativamente simples com algumas tarefas de uso intensivo de recursos.
Microsserviços	Serviços decompostos verticalmente (funcionalmente) que chamam uns aos outros por meio de APIs.	Domínio complicado. Atualizações frequentes.
Arquitetura orientada a eventos	Produtor/consumidor. Exibição independente por subsistema.	IoT e sistemas em tempo real.
Big Data	Divida um enorme conjunto de dados em pequenos blocos. Processamento paralelo em conjuntos de dados locais.	Análise de dados em lote e em tempo real. Análise preditiva usando ML.
Computação de grande porte	Alocação de dados para milhares de núcleos.	Domínios computacionais intensivos, como simulação.

Considere desafios e benefícios

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

Aqui estão alguns dos tipos de desafios a serem considerados ao selecionar um estilo de arquitetura:

• Complexidade. A complexidade da arquitetura é justificada para seu domínio? Por outro lado, o estilo é muito simplista para seu domínio? Nesse caso, você corre o risco de acabar com uma "grande bola de lama", porque a arquitetura não ajuda você a gerenciar as dependências de forma limpa.

• Sistema de mensagens assíncronas e consistência eventual. Mensagens assíncronas podem ser usadas para desacoplar serviços e aumentar a confiabilidade (porque as mensagens podem ser repetidas) e escalabilidade. No entanto, isso também cria desafios para lidar com a consistência eventual, bem como a possibilidade de mensagens duplicadas.

• Comunicação entre serviços. À medida que você decompõe um aplicativo em serviços separados, há o risco de que a comunicação entre serviços cause latência inaceitável ou crie congestionamento de rede (por exemplo, em uma arquitetura de microsserviços).

• Capacidade de gerenciamento. Quão difícil é gerenciar o aplicativo, monitorar, implantar atualizações e assim por diante?

Recursos relacionados

• Dez princípios de design para aplicativos do Azure
• 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 da missão no Azure
• Arquitetura para inicializações