Estilos de arquitetura

Um estilo de arquitetura é uma família de arquiteturas que compartilham certas características. Por exemplo, N-tier é um estilo de arquitetura comum. Mais recentemente, as arquiteturas de microsserviços começaram a ganhar força. 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 contentores são uma opção natural para microsserviços.

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

• Uma descrição e diagrama lógico do estilo.
• Recomendações para quando escolher este estilo.
• Benefícios, desafios e melhores práticas.
• Uma implantação recomendada usando serviços relevantes do Azure.

Um rápido passeio pelos estilos

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

N-níveis

N-tier é uma arquitetura tradicional para aplicativos corporativos. 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 chamar camadas que estão mais abaixo. No entanto, esta estruturação horizontal pode ser uma desvantagem. 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-tier é um ajuste natural para migrar aplicativos existentes que já usam uma arquitetura em camadas. Por esse motivo, a camada N é mais frequentemente vista em soluções de infraestrutura como serviço (IaaS), ou aplicativos que usam uma combinação de IaaS e serviços gerenciados.

Web-Queue-Worker

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 trabalhador back-end que executa tarefas intensivas de CPU ou operações de longa execução. O front-end se comunica com o trabalhador por meio de uma fila de mensagens assíncronas.

Web-queue-worker é adequado para domínios relativamente simples com algumas tarefas que consomem muitos recursos. Como N-tier, a 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 executor podem facilmente tornar-se componentes grandes e monolíticos que são difíceis de manter e atualizar. Tal como acontece com os níveis N, isto pode reduzir a frequência das atualizações e limitar a inovação.

Microsserviços

Se seu aplicativo tiver um domínio mais complexo, considere mudar para uma arquitetura de microsserviços . Um aplicativo de microsserviços é composto por muitos serviços pequenos e independentes. Cada serviço implementa um único recurso de negócios. Os serviços são acoplados de forma flexível, comunicando-se através de contratos API.

Cada serviço pode ser construído por uma pequena equipe de desenvolvimento focada. Serviços individuais podem ser implantados sem muita coordenação entre as equipes, o que incentiva atualizações frequentes. Uma arquitetura de microserviços é mais complexa de criar e gerir do que uma arquitetura N-tier ou uma arquitetura web-queue-worker. 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 condicionada por eventos

Event-Driven As arquiteturas usam um modelo publish-subscribe (pub-sub), onde os produtores publicam eventos e os consumidores subscrevem a eles. 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 diferentes subsistemas 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, realizando processamento paralelo em todo o conjunto, para análise e emissão de relatórios. A computação grande, também chamada de computação de alto desempenho (HPC), 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. Os constrangimentos guiam a "forma" de uma arquitetura restringindo o universo de escolhas. Quando uma arquitetura está de acordo com as restrições de um estilo particular, certas propriedades desejáveis surgem.

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

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

Ao aderir a essas restrições, o que emerge é um sistema onde 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 as suas próprias vantagens e desvantagens. 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, você pode acabar com um design que se ajusta ao estilo em um nível superficial, mas não atinge 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. Também é importante ser pragmático. Às vezes, é melhor relaxar uma restrição, em vez de insistir na pureza arquitetônica.

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, podem priorizar a capacidade de manutenção, testabilidade e confiabilidade através de capacidades 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 a seguir resume como cada estilo gerencia dependências e os tipos de domínio mais adequados para cada um.

Estilo da arquitetura	Gestão de dependências	Tipo de domínio
N-níveis	Níveis horizontais divididos por sub-rede	Domínio de negócio tradicional. A frequência das atualizações é baixa.
Processador de filas web	Trabalhos de front-end e back-end, dissociados por mensagens assíncronas.	Domínio relativamente simples com algumas tarefas intensivas em recursos.
Microsserviços	Serviços verticalmente (funcionalmente) decompostos que chamam uns aos outros por meio de APIs.	Domínio complicado. Atualizações frequentes.
Arquitetura orientada a eventos	Produtor/consumidor. Vista independente por subsistema.	IoT e sistemas em tempo real.
Grandes volumes de dados	Divida um enorme conjunto de dados em pequenos pedaços. Processamento paralelo em conjuntos de dados locais.	Análise de dados em lote e em tempo real. Análise preditiva utilizando ML.
Grande computação	Alocação de dados para milhares de núcleos.	Domínios de computação intensiva, como simulação.

Considere os desafios e benefícios

As restrições também criam desafios, por isso é importante entender as compensações ao adotar qualquer um desses estilos. Será que os benefícios do estilo de arquitetura superam os desafios, para este subdomínio e contexto delimitado?

Aqui estão alguns dos tipos de desafios a 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, corre-se o risco de acabar com uma "grande bola de lama", porque a arquitetura não o ajuda a gerir as dependências de forma limpa.

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

• Comunicação interserviços. Ao decompor um aplicativo em serviços separados, há um 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).

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

Recursos relacionados

• Dez princípios de conceção para aplicações 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
• Arquitetar soluções multilocatárias no Azure
• Arquitetura de carga de trabalho de missão crítica no Azure
• Arquitetura para startups