Arquitetura: cargas de trabalho de comércio escalonáveis usando microsserviços

Last reviewed 2017-12-11 UTC

Neste artigo, descrevemos uma série de abordagens arquitetônicas que podem ser usadas para criar plataformas de comércio escalonáveis que usam microsserviços no Google Cloud.

Requisitos de comércio varejista e microsserviços

As cargas de trabalho do comércio varejista exigem uma série de recursos nativos da nuvem para atender à demanda de um número cada vez maior de dispositivos e plataformas de consumo:

  • Normalmente, essas implantações precisam ser multirregionais para atender a uma base de clientes global.
  • Elas precisam ser compatíveis com algum grau de escalonamento automático ou programado, aumentando a escala para atender à demanda durante as temporadas de pico e a diminuindo para reduzir os custos de infraestrutura quando a demanda é menor.
  • As implantações do comércio varejista precisam fornecer recursos e funcionalidades aos clientes com rapidez e eficiência para atender às demandas do mercado em constante mudança.
  • As implantações do comércio varejista também precisam aproveitar a infraestrutura gerenciada para que os desenvolvedores se concentrem em funcionalidades voltadas para o cliente.
  • Por fim, essas implantações precisam ser protegidas e gerenciadas centralmente.

Os microsserviços são adequados para todos esses requisitos. Os microsserviços individuais podem ser implantados e escalonados de maneira independente uns dos outros, o que permite que você forneça rapidamente novos recursos e funcionalidades. Os serviços podem ser pequenos, modulares, ligeiramente acoplados e organizados em torno das capacidades e necessidades específicas de seus negócios. Os microsserviços utilizam a descoberta de serviços e usam mecanismos simples (como HTTP) para facilitar a conectividade de uma grande variedade de dispositivos.

Arquitetura de back-end

Para as cargas de trabalho do comércio varejista, você organiza microsserviços nas funções discretas que são necessárias para criar a experiência do usuário voltada para o cliente. Por exemplo, é possível ter um serviço de metadados de produto que recupera e, se você quiser, armazena em cache os metadados de um produto específico. Você também pode ter um serviço de preços de produtos que recupera o preço de um produto de um determinado cliente.

Seus microsserviços são expostos aos clientes por meio de REST APIs. Os aplicativos do seu cliente usam um gateway de API para se comunicar com as REST APIs.

No diagrama a seguir, mostramos um exemplo de arquitetura de microsserviços de back-end orientada a comércio.

Diagrama da arquitetura de microsserviços de back-end

Arquitetura de front-end

Para cargas de trabalho de comércio varejista, a experiência do usuário voltada ao cliente costuma incluir aplicativos da Web responsivos (geralmente fornecidos como aplicativos da Web progressivos) e, de modo opcional, aplicativos nativos para dispositivos móveis. Em combinação com a arquitetura de back-end mostrada anteriormente, você cria seus aplicativos montando vários componentes do front-end que correspondem e se comunicam com as APIs e serviços do back-end.

No diagrama a seguir, mostramos um exemplo de front-end de aplicativo da Web orientado para comércio.

Diagrama da arquitetura que mostra o front-end do aplicativo da Web orientado para comércio

Armazenamento de dados

As cargas de trabalho do comércio varejista precisam manter várias categorias de dados. As categorias incluem o seguinte:

  • catálogo de produtos: atributos do produto, como nome, descrição, cor e tamanho
  • perfil do comprador: dados do cliente como nome, idade, preferências e endereços de faturamento e envio
  • transações do comprador: informações sobre compras do cliente, como itens adquiridos e data de compra
  • dados da sequência de cliques: informações que acompanham a jornada do comprador pelo site
  • imagens e vídeos do produto: mídia relacionada a um produto específico, incluindo conteúdo próprio e fornecido pelo cliente
  • classificações e avaliações: opiniões e feedback de clientes sobre um produto
  • inventário de produtos: dados sobre a disponibilidade de um item no estoque e a chegada esperada de estoque novo

Cada categoria de dados pode ser mapeada para um mecanismo de armazenamento do Google Cloud, conforme mostrado na tabela a seguir.

Objeto Não relacional Relacional Armazém
Cloud Storage Cloud Datastore Cloud Bigtable Cloud SQL Cloud Spanner BigQuery
Imagens
Vídeos
Catálogo
Perfis
Faturas
Sequência de cliques
Preço
Transações
Inventário
Classificações
Transações
Inventário
Classificações
Análises
Armazenamento

Catálogo de produtos

Os produtos têm um conjunto de atributos nos catálogos: nome, descrição e assim por diante. Mas, à medida que aumenta a diversidade do catálogo de produtos, o número de atributos distintos também aumenta. Cada nova categoria de produtos tem um conjunto próprio de atributos que podem ser usados para pesquisar ou filtrar, como tamanhos, cores, tipo e modelo de itens.

Portanto, para os catálogos de produtos, a opção de armazenamento mais apropriada é um banco de dados NoSQL orientado a documentos. Ele tem um esquema flexível e pode armazenar atributos por categoria ou objeto. O Datastore é um banco de dados NoSQL totalmente gerenciado e compatível com este caso de uso. No Datastore, você armazena objetos como entidades, e cada entidade aceita pares de chave-valor aninhados, semelhantes à estrutura do JSON. O Datastore está disponível em várias regiões do Google Cloud e é executado como um serviço sempre ativado.

Mídia de produtos

Todos os produtos em um catálogo podem ter imagens ou vídeos próprios, e também podem ter imagens ou vídeos fornecidos pelo cliente. Esse tipo de recurso pode ser armazenado em um sistema de armazenamento de objeto escalável, capaz de veiculá-los diretamente para aplicativos da Web ou para dispositivos móveis. O Cloud Storage é um serviço de armazenamento de objetos gerenciado que pode veicular dados entre várias regiões. Ele oferece níveis diferentes de acesso e disponibilidade de dados de acordo com suas necessidades. Para o alto desempenho, o Cloud CDN aproveita os pontos de presença globalmente distribuídos do Google para agilizar a entrega de conteúdo veiculado do Cloud Storage. Isso garante que os recursos estáticos estejam localizados o mais próximo possível dos usuários finais para minimizar a latência do download.

Perfil do comprador

Os perfis dos compradores têm um conjunto consistente de atributos e muitas vezes são multidimensionais. Por exemplo, alguns dos clientes podem ter vários endereços para envio ou vários métodos de pagamento, cada um com um endereço de faturamento próprio.

Você pode armazenar perfis de compradores em bancos de dados relacionais usando várias tabelas. No entanto, para isso você também pode usar bancos de dados NoSQL orientados a documentos. Isso permite que os perfis de compradores sejam armazenados como objetos únicos e avançados contendo todos os dados de um determinado cliente. O Datastore é um banco de dados NoSQL totalmente gerenciado que pode fornecer suporte para esse caso de uso.

Classificações e avaliações

As classificações e avaliações de produtos deixadas pelos clientes consistem em conjuntos de dados relativamente simples. Essas informações podem ser mantidas por meio de diferentes mecanismos de armazenamento. É comum usar esquemas relacionais que contenham campos como ID do produto, ID do cliente, valor de avaliação e texto de revisão. É possível armazenar esses dados usando o Cloud SQL ou o Spanner. Na maioria dos casos de uso, o Cloud SQL é o sistema mais adequado para armazenar dados de classificações e avaliações. Caso os aplicativos que você usa exijam maior capacidade transacional e escalonabilidade horizontal, o Spanner é a escolha certa. Para mais informações sobre o serviço de banco de dados a ser usado, consulte Como escolher uma opção de armazenamento.

Transações e faturas

Assim como acontece com as classificações e avaliações, é possível manter as transações e faturas do comprador ou detalhes do pedido usando diferentes mecanismos de armazenamento. As transações precisam ser armazenadas em sistemas de banco de dados compatíveis com a semântica ACID, especificamente a capacidade de confirmar as gravações atomicamente. O Datastore, o Cloud SQL e o Spanner são compatíveis com operações atômicas. Para a maioria dos casos de uso, os sistemas relacionais são uma boa opção para as transações, porque os dados são estruturados de maneira consistente de uma gravação para a próxima. A escolha do sistema de armazenamento depende em grande parte da sua familiaridade com os sistemas SQL ou NoSQL e da capacidade de personalizar aplicativos no banco de dados escolhido.

As faturas também podem ser armazenadas usando o NoSQL ou bancos de dados relacionais, mas os casos de uso downstream precisam acionar o sistema escolhido. Em cargas de trabalho comerciais modernas, bancos de dados NoSQL orientados a documentos, como o Datastore, costumam ser usados para manter faturas ou detalhes do pedido, porque todo o estado da fatura pode ser armazenado como um único objeto avançado. Para cargas de trabalho de comércio mais tradicional, o Cloud SQL ou o Spanner também podem ser escolhas apropriadas.

Para mais informações sobre o serviço de banco de dados a ser usado para transações e faturas, consulte Como escolher uma opção de armazenamento.

Se o ambiente estiver totalmente baseado em nuvem, os dados de transação e de faturamento residirão inteiramente na infraestrutura da nuvem. Por outro lado, se você trabalha com um ambiente híbrido, é necessário sincronizar os dados entre o ambiente da nuvem e o ambiente local. No cenário híbrido, os dados de transação e de fatura geralmente residem na infraestrutura local. Nesse caso, é possível sincronizar sistemas de back-end com a infraestrutura de dados em nuvem usando uma combinação de aplicativos personalizados, Pub/Sub ou replicação de banco de dados.

Dados da sequência de cliques

Os dados sobre o tráfego do cliente geralmente são capturados por meio de pacotes de análise, como o Google Analytics. No entanto, você pode reunir esses dados de navegação (dados da sequência de cliques) em tempo real.

Há vários métodos de captura de dados de sequência de cliques. Um deles é usar o rastreamento de pixels sem servidor usando o Google Cloud. Os conjuntos de dados produzidos para o rastreamento de sequência de cliques tendem a ser muito grandes e são frequentemente usados como fontes para aprendizagem de máquinas ou análises preditivas. Esse tipo de dados geralmente é armazenado em sistemas NoSQL de coluna larga, como o Bigtable. O Bigtable é compatível com conjuntos de dados em larga escala (até centenas de petabytes). Ele fornece baixa latência e alto rendimento, o que é útil para este caso de uso.

Inventário de produtos

Saber os dados sobre a disponibilidade de um produto é fundamental para a experiência geral do cliente. Os dados de inventário geralmente consistem em conjuntos de dados que contêm as SKUs de produtos, o inventário atual e a data prevista de inventário adicional. Mas dada a maneira como esses dados são frequentemente usados em aplicativos, o mecanismo de armazenamento precisa ser compatível com as transações e operações atômicas para refletir com precisão os níveis de estoque. O Datastore, o Cloud SQL e o Spanner são compatíveis com operações atômicas. Para a maioria dos casos de uso, os sistemas relacionais são uma boa opção para os dados de inventário, porque eles são estruturados de maneira consistente. Para mais informações sobre o serviço de banco de dados a ser usado, consulte Como escolher uma opção de armazenamento.

Assim como com os dados de transação, se o ambiente estiver totalmente baseado em nuvem, os dados de inventário residirão na infraestrutura dos dados da nuvem. Se você trabalha com um ambiente híbrido, precisará sincronizar dados em todo o ambiente da nuvem e seu ambiente local. No cenário híbrido, os dados de inventário geralmente residem na infraestrutura local. Nesse caso, é possível sincronizar sistemas de back-end com a infraestrutura de dados em nuvem usando uma combinação de aplicativos personalizados, Pub/Sub ou replicação de banco de dados.

Arquiteturas de implantação

Ao usar o Google Cloud, você geralmente implanta microsserviços usando o Cloud Run ou o Google Kubernetes Engine. O Cloud Run é uma plataforma de computação gerenciada que permite executar contêineres sem estado invocáveis por solicitações da Web ou eventos do Pub/Sub. O GKE foi desenvolvido com base no Kubernetes, uma orquestração de contêineres de código aberto e um mecanismo de gerenciamento de cluster. A escolha da plataforma para implantação depende do nível de flexibilidade que você precisa e da complexidade da sua infraestrutura de aplicativos.

Para mais informações, consulte Como escolher uma opção de computação. Neste guia, apresentamos as duas opções de implantação.

Como usar o Cloud Run

O diagrama a seguir mostra um exemplo de implantação com microsserviços usando o Cloud Run.

Diagrama mostrando a implantação com microsserviços usando o Cloud Run.

O Cloud Run automaticamente escalona verticalmente e reduz a escala vertical o número de instâncias que executam os aplicativos com base no tráfego recebido. Quando você implanta o aplicativo em uma arquitetura de microsserviços usando o Cloud Run, o aplicativo é empacotado como um contêiner e implantado como um Serviço. Os serviços podem ser executados em várias instâncias de contêineres e escalonados de maneira independente um do outro. O Cloud Run provisiona automaticamente recursos de balanceamento de carga e fornece recursos para gerenciar revisões de microsserviços individuais e dividir o tráfego entre as versões.

O Cloud Run é criado no Knative e permite que você execute contêineres totalmente gerenciados no Cloud Run, no cluster do Google Kubernetes Engine ou no local com o Cloud Run para Anthos. Os serviços do Cloud Run são implantados em uma única região ou namespace de cluster do GKE e são replicados automaticamente em várias zonas na região em que estão para redundância e failover. Um determinado projeto do Google Cloud pode executar muitos serviços em diferentes regiões ou clusters do GKE.

É possível provisionar e operar a infraestrutura de armazenamento de dados separadamente do Cloud Run. Por exemplo, o aplicativo no Cloud Run pode se conectar a um banco de dados PostgreSQL gerenciado pelo Cloud SQL para armazenamento de dados relacionais.

O diagrama a seguir mostra um exemplo de arquitetura para uma implantação multirregional do Cloud Run.

Diagrama mostrando a implantação que usa um Cloud Run multirregional.

Como usar o GKE

O diagrama a seguir mostra um exemplo de implantação com microsserviços usando o GKE.

Diagrama da implantação com microsserviços usando o GKE

Quando você usa o GKE, cada microsserviço tem um ciclo de vida de desenvolvimento e implantação separado. Cada microsserviço é empacotado como um contêiner do Docker. Você implanta esses contêineres como um pod e serviço do Kubernetes usando um destes métodos:

O GKE é compatível com pods de escalonamento automático, dependendo do uso da CPU, com o escalonador automático de pods horizontal (em inglês). Além disso, os clusters do GKE também são compatíveis com o escalonamento automático usando o escalonador automático de clusters do GKE, que redimensiona os clusters automaticamente, com base em recursos saturados ou subutilizados.

Os clusters do GKE são recursos regionais. Para implantações que exigem alta disponibilidade, crie implantações em várias zonas. Para mais informações, consulte Visão geral de clusters de várias zonas do GKE.

Para implantações que atendem a uma base de clientes global, implante vários clusters do GKE em um único projeto, um por região. O armazenamento de dados para cada microsserviço é provisionado e operado do mesmo projeto que os clusters do GKE.

A seguir