Arquitetura de microsserviços no Google App Engine

Os microsserviços compõem um estilo arquitetônico para o desenvolvimento de aplicativos. Eles permitem que um aplicativo grande seja decomposto em partes constituintes independentes, cada parte com a própria responsabilidade. Para atender a um único usuário ou solicitação de API, um aplicativo baseado em microsserviços pode chamar muitos microsserviços internos para compor a resposta.

Um aplicativo baseado em microsserviços devidamente implantado pode atingir os seguintes objetivos:

  • Definir contratos relevantes entre os vários microsserviços
  • Permitir ciclos de implantação independentes, incluindo reversão
  • Facilitar testes simultâneos de versão A/B em subsistemas
  • Minimizar a automação de teste e a sobrecarga de controle de qualidade
  • Melhorar a clareza do registro e monitoramento
  • Fornecer uma contabilidade de custos minuciosa
  • Aumentar a escalonabilidade geral e a confiabilidade do aplicativo

O Google App Engine tem vários recursos adequados para um aplicativo baseado em microsserviços. Esta página descreve as práticas recomendadas a serem usadas ao implantar seu aplicativo como baseado em microsserviços no Google App Engine.

Serviços do App Engine como microsserviços

Em um projeto do App Engine, é possível implantar vários microsserviços como serviços separados, anteriormente conhecidos como módulos no App Engine. Esses serviços têm o código totalmente isolado. A única maneira de executar o código neles é por meio de uma invocação HTTP, como uma solicitação de usuário ou uma chamada de API RESTful. O código em um serviço não pode chamar diretamente o código em outro serviço. O código pode ser implantado em serviços de maneira independente, e diferentes serviços podem ser gravados em diferentes linguagens, como Python, Java, Go e PHP. O escalonamento automático, o balanceamento de carga e os tipos de instâncias da máquina são gerenciados de maneira independente para serviços.

Um projeto do App Engine atinge a separação usando os serviços.

Versões dentro dos serviços

Além disso, cada serviço pode ter diversas versões implantadas simultaneamente. Para cada serviço, uma delas é a versão de veiculação padrão. No entanto, é possível acessar diretamente qualquer versão implementada de um serviço, já que cada uma delas tem um endereço próprio. Esta estrutura abre inúmeras possibilidades, incluindo o teste preliminar de uma nova versão, teste A/B entre diferentes versões e operações simplificadas de roll-forward e rollback. A estrutura do App Engine fornece mecanismos para auxiliar na maioria desses itens. Vamos abordar esses mecanismos com mais detalhes nas próximas seções.

Um projeto do App Engine pode ter serviços e versões.

Isolamento do serviço

Embora na maior parte seja isolado, os serviços compartilham alguns recursos do App Engine. Por exemplo, Cloud Datastore, Memcache e Task Queues são recursos compartilhados entre serviços em um projeto do App Engine. Ainda que este compartilhamento tenha algumas vantagens, é importante que um aplicativo baseado em microsserviços mantenha o isolamento de códigos e dados entre microsserviços. Existem padrões de arquitetura que ajudam a diminuir o compartilhamento indesejado. Esses padrões serão descritos mais adiante neste artigo.

Os projetos do App Engine compartilham serviços.

Isolamento do projeto

Se você não quiser confiar nesses padrões para alcançar o isolamento e quiser uma restrição mais formal da separação, é possível usar vários projetos do App Engine. Há vantagens e desvantagens no uso de projetos em vez de serviços e você precisa equilibrar as compensações de acordo com a situação. A menos que haja uma necessidade específica de uma das vantagens oferecidas pelo uso de vários projetos, é recomendável iniciar com o uso de vários serviços em um único projeto porque o desempenho será melhor e a sobrecarga administrativa será minimizada Também é possível escolher algum híbrido das duas abordagens.

Comparação do isolamento do serviço e do isolamento do projeto

A tabela a seguir apresenta uma comparação entre o uso de vários serviços e projetos em uma arquitetura de microsserviços:

Vários serviços Vários projetos
Isolamento do código O código de implantação é completamente independente entre serviços e versões. O código de implantação é completamente independente entre projetos e entre serviços e versões de cada projeto.
Isolamento de dados O Cloud Datastore e o Memcache são compartilhados entre serviços e versões. No entanto, namespaces podem ser usados como um padrão de desenvolvedor para isolar os dados. Para o isolamento de Fila de tarefas, uma convenção de desenvolvedor de nomes de fila pode ser empregada, como user-service-queue-1. O Cloud Datastore, o Memcache e as Filas de tarefas são completamente independentes entre os projetos.
Isolamento do registro Cada serviço (e versão) tem registros independentes, mas é possível vê-los em conjunto. Cada projeto (e serviço e versão de cada projeto) tem registros independentes, mas todos os registros de um determinado projeto podem ser vistos em conjunto. Não é possível ver em conjunto os registros de vários projetos.
Sobrecarga no desempenho Os serviços do mesmo projeto são implantados no mesmo data center, de modo que a latência ao chamar um serviço de outro usando o HTTP é muito baixa. Os projetos podem ser implantados em data centers diferentes. Portanto, as latências HTTP podem ser mais altas, embora ainda bastante baixas já que a rede do Google é de classe mundial.
Contabilidade de custos Os custos por instância-hora (CPU e memória para executar seu código) não estão separados por serviços. Todas as instâncias-horas para um projeto inteiro são agrupadas. Os custos de diferentes projetos são divididos, facilitando a visualização de custos de diferentes microsserviços.
Permissões do operador Um operador consegue implantar código, avançar e reverter as versões e visualizar os registros de todos os serviços de um projeto. Não há como limitar o acesso a serviços específicos. O acesso do operador pode ser controlado separadamente em projetos separados.
Rastreamento de solicitação Usando o Google Cloud Trace, é possível ver uma solicitação e as solicitações de microsserviço resultantes para serviços no mesmo projeto como um único trace composto. Esse recurso ajuda a facilitar o ajuste de desempenho. É possível visualizar o Cloud Trace em todos os projetos do GCP que estejam dentro da mesma organização.

Próximas etapas