Arquitetando aplicativos baseados em contêineres e microsserviços

Sugestão

Este conteúdo é um trecho do eBook, .NET Microservices Architecture for Containerized .NET Applications, disponível no do .NET Docs ou como um PDF para download gratuito que pode ser lido offline.

Descarregar PDF

Os microsserviços oferecem grandes benefícios, mas também levantam novos e enormes desafios. Os padrões de arquitetura de microsserviços são pilares fundamentais ao criar um aplicativo baseado em microsserviços.

No início deste guia, você aprendeu conceitos básicos sobre contêineres e Docker. Essas informações eram o mínimo que você precisava para começar a usar contêineres. Embora os contêineres sejam facilitadores e uma ótima opção para microsserviços, eles não são obrigatórios para uma arquitetura de microsserviços. Muitos conceitos de arquitetura nesta seção de arquitetura podem ser aplicados sem contêineres. No entanto, este guia centra-se na intersecção de ambos devido à importância já introduzida dos contentores.

Os aplicativos corporativos podem ser complexos e geralmente são compostos de vários serviços em vez de um único aplicativo baseado em serviço. Para esses casos, você precisa entender outras abordagens arquitetônicas, como os microsserviços e certos padrões de Domain-Driven Design (DDD), além de conceitos de orquestração de contêineres. Observe que este capítulo descreve não apenas microsserviços em contêineres, mas também qualquer aplicativo conteinerizado.

Princípios de design de contêineres

No modelo de contêiner, uma instância de imagem de contêiner representa um único processo. Ao definir uma imagem de contêiner como um limite de processo, você pode criar primitivas que podem ser usadas para dimensionar ou agrupar o processo.

Ao criar uma imagem de contêiner, você verá uma definição ENTRYPOINT no Dockerfile. Esta definição define o processo cujo tempo de vida controla o tempo de vida do contentor. Quando o processo é concluído, o ciclo de vida do contêiner termina. Os contêineres podem representar processos de longa execução, como servidores Web, mas também podem representar processos de curta duração, como trabalhos em lote, que anteriormente poderiam ter sido implementados como WebJobs do Azure.

Se o processo falhar, o contêiner termina e o orquestrador assume o controle. Se o orquestrador foi configurado para manter cinco instâncias em execução e uma falhar, o orquestrador criará outra instância de contêiner para substituir o processo com falha. Em um trabalho em lote, o processo é iniciado com parâmetros. Quando o processo é concluído, o trabalho está concluído. Esta orientação detalha os orquestradores, mais tarde.

Você pode encontrar um cenário em que deseja que vários processos sejam executados em um único contêiner. Para esse cenário, como pode haver apenas um ponto de entrada por contêiner, você pode executar um script dentro do contêiner que inicia quantos programas forem necessários. Por exemplo, você pode usar o Supervisor ou uma ferramenta semelhante para cuidar da execução de vários processos dentro de um único contêiner. No entanto, embora você possa encontrar arquiteturas que armazenam vários processos por contêiner, essa abordagem não é muito comum.

AnteriorPróximo