Estilos de arquitetura

Um estilo de arquitetura é uma família de arquiteturas que partilham determinadas características. Por exemplo, N camadas é um estilo de arquitetura comum. Mais recentemente, as arquiteturas de microsserviços começaram a destacar-se. Os estilos de arquitetura não requerem a utilização de tecnologias específicas, mas algumas tecnologias são ideais para determinadas arquiteturas. Por exemplo, os contentores são uma escolha natural para microsserviços.

Identificámos um conjunto de estilos de arquitetura que se encontram normalmente em aplicações de cloud. O artigo para cada estilo inclui:

• Uma descrição e um diagrama lógico do estilo.
• Recomendações para quando escolher este estilo.
• Vantagens, desafios e melhores práticas.
• Uma implementação recomendada que utiliza os serviços do Azure relevantes.

Uma rápida apresentação dos estilos

Esta secção fornece uma rápida apresentação dos estilos de arquitetura que identificámos, juntamente com algumas considerações de alto nível para a sua utilização. Note-se que a lista não é exaustiva. Leia mais detalhes nos tópicos ligados.

N camadas

N camadas é uma arquitetura tradicional para aplicações empresariais. As dependências são geridas ao dividir a aplicação em camadas que executam funções lógicas, como apresentação, lógica de negócio e acesso a dados. Uma camada apenas pode chamar em camadas que estejam abaixo de si mesma. No entanto, esta disposição em camadas horizontal pode ser uma desvantagem. Pode ser difícil introduzir alterações numa parte da aplicação sem afetar o resto da aplicação. Isso torna as atualizações frequentes um desafio, ao limitar a rapidez com que as novas funcionalidades podem ser adicionadas.

N camadas é uma opção natural para migrar as aplicações existentes que já utilizam uma arquitetura em camadas. Por esse motivo, a opção N camadas é muitas vezes utilizada em soluções de infraestrutura como serviço (IaaS) ou em aplicações que utilizam uma combinação de IaaS e serviços geridos.

Web-Queue-Worker

Para uma solução puramente PaaS, considere uma arquitetura Web-Queue-Worker. Neste estilo, a aplicação tem um front-end da Web que processa os pedidos HTTP e uma função de trabalho back-end que efetua tarefas com utilização intensiva da CPU ou operações de longa execução. O front-end comunica com a função de trabalho através de uma fila de mensagens assíncronas.

O Web-queue-worker é adequado para domínios relativamente simples com algumas tarefas com muitos recursos. Tal como a opção N camadas, a arquitetura é fácil de compreender. A utilização de serviços geridos simplifica a implementação e as operações. No entanto, com domínios complexos, pode ser difícil gerir dependências. O front-end e a função de trabalho podem tornar-se facilmente componentes grandes e monolíticos difíceis de manter e atualizar. Tal como a opção N camadas, é possível reduzir a frequência de atualizações e limitar a inovação.

Microsserviços

Se a sua aplicação tiver um domínio mais complexo, considere movê-la para uma arquitetura de Microsserviços. Uma aplicação de microsserviços é composta por vários serviços pequenos independentes. Cada serviço implementa uma única capacidade empresarial. Os serviços estão acoplados e comunicam através de contratos de API.

Cada serviço pode ser criado por uma pequena equipa de desenvolvimento focada. Os serviços individuais podem ser implementados sem muita coordenação entre equipas, o que encoraja atualizações frequentes. Uma arquitetura de microsserviços é mais complexa de criar e gerir do que a de N camadas ou web-queue-worker. Requer um desenvolvimento maduro e cultura DevOps. No entanto, se for implementado corretamente, este estilo pode originar uma maior velocidade de lançamento, uma inovação mais rápida e uma arquitetura mais resiliente.

Arquitetura condicionada por eventos

As Arquiteturas Condicionadas por Eventos utilizam um modelo de publicação-subscrição (pub-sub), em que os produtores publicam eventos e os consumidores os subscrevem. Os produtores são independentes dos consumidores e estes são independentes entre si.

Considere uma arquitetura condicionada por eventos para as aplicações que ingerem e processam um elevado volume de dados com latência muito baixa, como soluções de IoT. O estilo também é útil quando diferentes subsistemas têm de efetuar diferentes tipos de processamento nos mesmos dados de evento.

Macrodados, Macrocomputação

Os estilos de arquitetura especializados Macrodados e Macrocomputação destinam-se a cargas de trabalho que se enquadram em determinados perfis específicos. Os Macrodados dividem um grande conjunto de dados em segmentos e efetuam o processamento paralelo em todo o conjunto, para análise e relatórios. A Macrocomputação, também denominada computação de alto desempenho (HPC), cria cálculos paralelos num grande número (milhares) de núcleos. Os domínios incluem simulações, modelação e composição 3D.

Estilos de arquitetura como restrições

Um estilo de arquitetura coloca restrições na conceção, incluindo o conjunto de elementos que pode ser apresentado e as relações permitidas entre esses elementos. As restrições guiam a "forma" de uma arquitetura ao limitar o universo de opções. Quando uma arquitetura está em conformidade com as restrições de um determinado estilo, surgem algumas propriedades desejadas.

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

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

Ao cumprir estas restrições, o que surge é um sistema em que os serviços podem ser implementados de forma independente, as falhas são isoladas, é possível ter atualizações frequentes e é fácil introduzir novas tecnologias na aplicação.

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 subjacentes e as restrições desse estilo. Caso contrário, pode acabar com uma conceção que está em conformidade com o estilo a um nível superficial, mas que não alcança todo o potencial desse estilo. Você precisa prestar mais atenção ao motivo pelo qual você está escolhendo um determinado estilo arquitetônico do que a como implementá-lo. É igualmente importante ser pragmático. Por vezes, é melhor reduzir uma restrição, em vez de insistir na pureza da arquitetura.

A escolha de um estilo arquitetónico adequado deve ser feita, idealmente, com um consenso de partes interessadas informadas sobre a carga de trabalho. A equipa de carga de trabalho deve, em primeiro lugar, identificar a natureza do problema que está a tentar resolver. Em seguida, eles devem identificar os drivers de negócios e as características de arquitetura correspondentes (também conhecidas como requisitos não funcionais) e, em seguida, priorizá-los. Por exemplo, se eles precisarem de menos tempo de comercialização, eles podem priorizar a capacidade de manutenção, estabilidade e confiabilidade por meio de recursos de implantação rápida. Ou, se a equipe de carga de trabalho tiver orçamento limitado, eles podem 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, portanto, mais esforço inicial pode ser justificado para a eficiência da equipe a longo prazo e a mitigação de riscos.

A tabela seguinte resume a forma como cada estilo gere as dependências e os tipos de domínio mais adequados a cada um.

Estilo de arquitetura	Gestão de dependências	Tipo de domínio
N-níveis	Camadas horizontais divididas por sub-rede	Domínio empresarial tradicional. A frequência de atualizações é baixa.
Trabalhador em fila da Web	Tarefas de front-end e back-end, desacopladas por mensagens assíncronas.	Domínio relativamente simples com algumas tarefas com muitos recursos.
Microsserviços	Serviços decompostos verticalmente (funcionalmente) que se chamam entre si através de APIs.	Domínio complicado. Atualizações frequentes.
Arquitetura orientada a eventos	Produtor/consumidor. Vista independente por sub-sistema.	IoT e sistemas em tempo real.
Grandes volumes de dados	Divide um grande conjunto de dados em pequenos segmentos. Processamento paralelo em conjuntos de dados locais.	Análise de dados em lote e em tempo real. Análise preditiva através de ML.
Grande computação	Alocação de dados em milhares de núcleos.	Domínios com computação intensiva, como simulação.

Desafios e vantagens

As restrições também criam desafios, pelo que é importante compreender os compromissos ao adotar qualquer um destes estilos. As vantagens do estilo de arquitetura prevalecem sobre os desafios, para este subdomínio e contexto vinculado.

Seguem-se alguns dos tipos de desafios que deve considerar ao selecionar um estilo de arquitetura:

• Complexidade. A complexidade da arquitetura é justificada para o seu domínio? Por outro lado, o estilo é demasiado simplista para o seu domínio? Nesse caso, arrisca acabar com uma "grande bola de lama", uma vez que a arquitetura não o ajuda a gerir corretamente as dependências.

• Mensagens assíncronas e consistência eventual. Podem ser utilizadas mensagens assíncronas para desacoplar serviços e aumentar a fiabilidade (as mensagens podem ser repetidas) e a escalabilidade. No entanto, isso também cria desafios no processamento da consistência eventual, bem como a possibilidade de mensagens duplicadas.

• Comunicação entre serviços. À medida que decompõe uma aplicação em serviços separados, existe o risco de a comunicação entre serviços causar uma latência inaceitável ou criar congestionamento de rede (por exemplo, numa arquitetura de microsserviços).

• Capacidade de gestão. É difícil gerir a aplicação, monitorizar, implementar atualizações, etc.?

Recursos relacionados

• Dez princípios de design para aplicativos do Azure
• Crie aplicativos na nuvem da Microsoft
• Melhores práticas em aplicações na nuvem
• Padrões de design de nuvem
• Testes de desempenho e antipadrões para aplicativos em nuvem
• Arquitete soluções multilocatárias no Azure
• Arquitetura de carga de trabalho de missão crítica no Azure
• Arquitetura para startups