Ao projetar um aplicativo da Web baseado em uma arquitetura de microsserviços, você decide como dividir os recursos do seu aplicativo em microsserviços e como chamá-los do seu aplicativo. Para serviços de longa duração, convém usar chamadas de serviço assíncronas. Nesta arquitetura de referência, mostramos como implantar um aplicativo conteinerizado que invoca processos de longa duração de forma assíncrona.
Este documento de arquitetura de referência é destinado a desenvolvedores e arquitetos que querem implementar microsserviços de maneira assíncrona usando tecnologias modernas, incluindo o Google Kubernetes Engine (GKE) e Pub/Sub. O documento pressupõe que você esteja familiarizado com microsserviços em geral e com o Pub/Sub e o GKE no Google Cloud.
Arquitetura
O diagrama a seguir ilustra um cenário de exemplo em que um aplicativo gera imagens em miniatura. Gerar imagens em miniatura pode ser uma tarefa que consome muitos recursos e, portanto, pode levar algum tempo.
Figura 1. Arquitetura original para o processamento de imagens baseada no uso de VMs.
No diagrama anterior, o aplicativo recebe arquivos de imagem dos clientes e, em seguida, gera miniaturas. Nesta arquitetura, o aplicativo é implementado usando instâncias de máquina virtual (VM, na sigla em inglês) no Compute Engine e usando o armazenamento de arquivos de back-end no Cloud Storage. O aplicativo armazena metadados usando o Cloud Storage. O Cloud Load Balancing distribui solicitações para várias VMs.
Para reduzir a sobrecarga operacional e manter as VMs, migre esse sistema para uma nova arquitetura que não use VMs.
O diagrama a seguir mostra como esse fluxo pode ser implementado usando serviços gerenciados que usam notificações e microsserviços para implementar chamadas assíncronas entre componentes do sistema.
Figura 2. Nova arquitetura para processamento de imagens baseada no uso de contêineres e mensagens assíncronas.
Na nova arquitetura, o cliente envia uma imagem ao aplicativo e o aplicativo a envia para o Cloud Storage. Em seguida, as notificações do Pub/Sub colocam uma mensagem na fila de mensagens do Pub/Sub. A mensagem chama um microsserviço executado no GKE. O microsserviço recupera a imagem do Cloud Storage, gera uma miniatura e faz o upload dela para o Cloud Storage.
Considerações sobre o design
As diretrizes a seguir podem ajudar você a desenvolver uma arquitetura que atenda aos requisitos da sua organização para segurança, custo e desempenho.
Eficiência operacional
Essa nova arquitetura tem as seguintes vantagens:
Escalonabilidade independente: na arquitetura original, o aplicativo executado no Compute Engine aborda duas tarefas principais. Uma tarefa é receber arquivos e a outra é gerar uma miniatura da imagem original. Receber arquivos enviados consome largura de banda de rede, enquanto a geração de miniaturas é uma tarefa que consome muita CPU. As instâncias do Compute Engine podem ficar sem recursos de CPU para gerar imagens e ainda ter recursos de rede suficientes para receber arquivos. Na nova arquitetura, essas tarefas são compartilhadas pelo Cloud Storage e pelo GKE, tornando-as escalonáveis de maneira independente.
Fácil de adicionar novas funcionalidades: na arquitetura original, se você quiser adicionar funcionalidades, precisará implantá-las nas mesmas instâncias do Compute Engine. Na nova arquitetura, é possível desenvolver um aplicativo e adicioná-lo de forma independente. Por exemplo, é possível adicionar um aplicativo de remetente de e-mail para enviar uma notificação quando uma nova miniatura for gerada. O Pub/Sub pode se conectar ao aplicativo de geração de miniaturas e ao aplicativo de envio de e-mails de maneira assíncrona sem modificar o código original que é executado no GKE.
Acoplamento reduzido: na arquitetura antiga, um problema comum é o acoplamento temporal. Se um servidor de redirecionamento de e-mail não estiver disponível, quando o aplicativo tentar enviar uma notificação, ela falhará. Esses processos possuem um acoplamento rígido e um cliente pode não receber uma resposta bem-sucedida do aplicativo. Na nova arquitetura, o cliente recebe uma resposta bem-sucedida porque a geração de uma miniatura e o envio de uma notificação são acoplados com flexibilidade
Essa nova arquitetura tem as seguintes desvantagens:
Esforço adicional para modernizar o aplicativo: colocar um aplicativo em um contêiner exige tempo e esforço. A nova arquitetura usa mais serviços e requer uma abordagem diferente de observação, que inclui alterações no monitoramento do aplicativo, no processo de implantação e no gerenciamento de recursos.
Requisito para lidar com a duplicação no lado do aplicativo: o Pub/Sub garante pelo menos uma entrega da mensagem, o que significa que mensagens duplicadas podem ser enviadas. Seu aplicativo precisa lidar com essa possibilidade.
Desempenho
A nova arquitetura pode oferecer o uso eficiente de recursos. Na arquitetura original, escalonar horizontalmente as instâncias do Compute Engine consome mais recursos para executar sistemas operacionais. Com o GKE, você pode usar de forma eficiente os recursos do servidor que executam vários contêineres em apenas alguns servidores (empacotamento). Faça o escalonamento horizontal e vertical de contêineres para que a nova arquitetura possa lidar com bursts breves de carga alta e escalonar rapidamente quando as tarefas forem concluídas.
Implantação
Para implantar um aplicativo de exemplo que implementa essa arquitetura, consulte Implantar microsserviços que usam o Pub/Sub e o GKE.
A seguir
- Leia sobre o DevOps e saiba mais sobre o recurso de arquitetura relacionado a essa arquitetura de referência.
- Faça a verificação rápida de DevOps para entender sua posição em relação ao restante do setor.
- Para mais arquiteturas de referência, diagramas e práticas recomendadas, confira a Central de arquitetura do Cloud.