Microsserviços refere-se a um estilo arquitetónico para o desenvolvimento de aplicações. Os microsserviços permitem decompor uma aplicação grande em partes constituintes independentes, com cada parte a ter o seu próprio âmbito de responsabilidade. Para publicar um único pedido de utilizador ou API, uma aplicação baseada em microsserviços pode chamar muitos microsserviços internos para compor a respetiva resposta.
Uma aplicação baseada em microsserviços implementada corretamente pode atingir os seguintes objetivos:
- Definir contratos fortes entre os vários microsserviços.
- Permitir ciclos de implementação independentes, incluindo reversão.
- Facilitar os testes de lançamento A/B simultâneos em subsistemas.
- Minimize a automatização de testes e os custos gerais de garantia de qualidade.
- Melhorar a clareza do registo e da monitorização.
- Fornecer contabilidade de custos detalhada.
- Aumentar a escalabilidade e a fiabilidade gerais da aplicação.
O Google App Engine tem várias funcionalidades adequadas para uma aplicação baseada em microsserviços. Esta página descreve as práticas recomendadas a usar quando implementar a sua aplicação como uma aplicação baseada em microsserviços no Google App Engine.
Serviços do App Engine como microsserviços
Num projeto do App Engine, pode implementar vários microsserviços como serviços separados, anteriormente conhecidos como módulos no App Engine. Estes serviços têm isolamento total do código. A única forma de executar código nestes serviços é através de uma invocação HTTP, como um pedido do utilizador ou uma chamada de API RESTful. O código num serviço não pode chamar diretamente o código noutro serviço. O código pode ser implementado nos serviços de forma independente e os diferentes serviços podem ser escritos em diferentes linguagens, como Python, Java, Go e PHP. A escala automática, o balanceamento de carga e os tipos de instâncias de máquinas são todos geridos de forma independente para os serviços.
Versões nos serviços
Além disso, cada serviço pode ter várias versões implementadas em simultâneo. Para cada serviço, uma destas versões é a versão de publicação predefinida, embora seja possível aceder diretamente a qualquer versão implementada de um serviço, uma vez que cada versão de cada serviço tem o seu próprio endereço. Esta estrutura abre inúmeras possibilidades, incluindo testes rápidos de uma nova versão, testes A/B entre diferentes versões e operações de reversão e implementação simplificadas. A framework App Engine oferece mecanismos para ajudar com a maioria destes itens. Vamos abordar estes mecanismos mais detalhadamente nas secções seguintes.
Isolamento de serviços
Embora estejam maioritariamente isolados, os serviços partilham alguns recursos do App Engine. Por exemplo, o Cloud Datastore, a cache de memória e as filas de tarefas são todos recursos partilhados entre serviços num projeto do App Engine. Embora esta partilha tenha algumas vantagens, é importante que uma aplicação baseada em microsserviços mantenha o isolamento de código e dados entre os microsserviços. Existem padrões de arquitetura que ajudam a mitigar a partilha indesejada. Vamos descrever estes padrões mais adiante neste artigo.
Isolamento de projetos
Se não quiser depender destes padrões para alcançar o isolamento e quiser uma aplicação mais formal da separação, pode usar vários projetos do App Engine. Existem vantagens e desvantagens na utilização de projetos em vez de serviços, e tem de equilibrar as concessões consoante a sua situação. A menos que tenha uma necessidade específica de uma das vantagens oferecidas pela utilização de vários projetos, é melhor começar por usar vários serviços num único projeto, porque o desempenho será melhor e a sobrecarga administrativa será minimizada. Claro que também pode escolher uma combinação das duas abordagens.
Comparação entre o isolamento de serviços e o isolamento de projetos
A tabela seguinte apresenta uma comparação entre a utilização de vários serviços e vários projetos numa arquitetura de microsserviços:
| Vários serviços | Vários projetos | |
|---|---|---|
| Isolamento de código | O código implementado é completamente independente entre serviços e versões. | O código implementado é 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 partilhados entre serviços e versões. No entanto, os
namespaces
podem ser usados como um padrão de programador para isolar os dados.
Para o isolamento da fila de tarefas, pode usar uma convenção de nomenclatura de filas de programador, como user-service-queue-1.
|
O Cloud Datastore, o Memcache e as filas de tarefas são completamente independentes entre projetos. |
| Isolamento de registos | Cada serviço (e versão) tem registos independentes, embora possam ser vistos em conjunto. | Cada projeto (e serviço e versão de cada projeto) tem registos independentes, embora todos os registos de um determinado projeto possam ser vistos em conjunto. Não é possível ver os registos de vários projetos em conjunto. |
| Sobrecarga de desempenho | Os serviços do mesmo projeto são implementados no mesmo centro de dados, pelo que a latência na chamada de um serviço a partir de outro através de HTTP é muito baixa. | Os projetos podem ser implementados em diferentes centros de dados, pelo que as latências HTTP podem ser mais elevadas, embora ainda sejam bastante baixas, uma vez que a rede da Google é de classe mundial. |
| Contabilidade de custos | Os custos das horas de instância (a CPU e a memória para executar o seu código) não estão separados para os serviços. Todas as horas de instância de um projeto inteiro estão agrupadas. | Os custos de diferentes projetos são divididos, o que facilita muito a visualização do custo de diferentes microsserviços. |
| Autorizações do operador | Um operador tem a capacidade de implementar código, implementar versões futuras e reverter versões, bem como ver os registos de todos os serviços de um projeto. Não é possível limitar o acesso a serviços específicos. | O acesso do operador pode ser controlado separadamente em projetos separados. |
| Pedir rastreio | Com o Google Cloud Trace, pode ver um pedido e os pedidos de microsserviços resultantes para serviços no mesmo projeto como um único rastreio composto. Esta funcionalidade pode ajudar a facilitar o ajuste do desempenho. | As chamadas do Cloud Trace podem ser visualizadas em projetos do GCP se estiverem na mesma organização. |
O que se segue?
- Compreenda como criar e atribuir nomes a ambientes de desenvolvimento, teste, controlo de qualidade, preparação e produção com microsserviços no App Engine.
- Conheça as práticas recomendadas para criar APIs que comuniquem entre microsserviços.
- Saiba mais sobre as práticas recomendadas para o desempenho dos microsserviços.
- Saiba como migrar uma aplicação monolítica existente para uma com microserviços.
- Compreenda se os microsserviços são ideais para a sua situação. No seu blogue pessoal, o arquiteto de soluções da Google, Preston Holmes, publicou uma publicação sobre algumas das desvantagens que vê nos microsserviços.