Arquitetar aplicativos baseados em contêiner e microsserviço

Dica

Esse conteúdo é um trecho do eBook, arquitetura de microsserviços do .NET para aplicativos .NET em contêineres, disponível em do .NET Docs ou como um PDF para download gratuito que pode ser lido offline.

Baixar PDF

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

Anteriormente neste guia, você aprendeu conceitos básicos sobre contêineres e Docker. Essa informação era o mínimo que você precisava para começar a usar contêineres. Embora os contêineres sejam habilitadores e um ótimo ajuste para microsserviços, eles não são obrigatórios para uma arquitetura de microsserviço. Muitos conceitos de arquitetura nesta seção de arquitetura podem ser aplicados sem contêineres. No entanto, este guia se concentra na interseção de ambos devido à importância já introduzida dos contêineres.

Os aplicativos empresariais podem ser complexos e geralmente são compostos por 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 determinados padrões de design de Domain-Driven (DDD), além de conceitos de orquestração de contêiner. Observe que este capítulo descreve não apenas microsserviços em contêineres, mas também qualquer aplicativo em contêineres.

Princípios de design de contêiner

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 colocar em lote o processo.

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

Se o processo falhar, o contêiner terminará e o orquestrador assumirá o controle. Se o orquestrador tiver sido 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 lotes, o processo é iniciado com parâmetros. Quando o processo for concluído, o trabalho será concluído. Esta orientação detalha os orquestradores, posteriormente.

Você pode encontrar um cenário em que deseja vários processos em execução 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 inicialização de vários processos dentro de um único contêiner. No entanto, embora você possa encontrar arquiteturas que contêm vários processos por contêiner, essa abordagem não é muito comum.

AnteriorPróximo