Arquitectura: Cargas de trabajo de comercio escalables mediante microservicios

Last reviewed 2017-12-11 UTC

En este artículo, se describe una serie de enfoques arquitectónicos que puedes usar para compilar plataformas de comercio escalables mediante microservicios en Google Cloud.

Requisitos de venta minorista y microservicios

Las cargas de trabajo de comercio minorista requieren una serie de características nativas de la nube para satisfacer la demanda de un número cada vez mayor de dispositivos y plataformas de consumidores:

  • Por lo general, estas implementaciones deben ser multirregionales para entregar a una base de clientes global.
  • Deben admitir cierto grado de ajuste de escala automático o escalado programado que aumente la escala para satisfacer la demanda máxima durante las temporadas altas y la reduzca a fin de disminuir los costos de infraestructura cuando la demanda es menor.
  • Las implementaciones en comercios minoristas deben ofrecer funciones a los clientes con rapidez y eficiencia para satisfacer las demandas cambiantes del mercado.
  • Las implementaciones de comercio minorista también deben aprovechar la infraestructura administrada para permitir que los desarrolladores se enfoquen en la funcionalidad orientada al cliente.
  • Por último, estas implementaciones deben ser protegidas y administradas de forma central.

Los microservicios son una buena opción para todos estos requisitos. Los microservicios individuales se pueden implementar y escalar de forma independiente entre sí, lo que te permite entregar con rapidez características y funcionalidades nuevas. Los servicios pueden ser pequeños, modulares, acoplados de forma flexible y organizados en función de tus capacidades y necesidades empresariales específicas. Los microservicios pueden aprovechar el descubrimiento de servicios y usar mecanismos simples (como HTTP) para una fácil conectividad desde una amplia variedad de dispositivos.

Arquitectura de backend

Para las cargas de trabajo de comercio minorista, debes organizar los microservicios en las funciones discretas que se necesitan para compilar la experiencia del usuario del cliente. Por ejemplo, puedes tener un servicio de metadatos del producto que recupera los metadatos de un producto en particular (y, de forma opcional, los almacena en caché). También puedes tener un servicio de precios de productos que recupera el precio de un producto para un cliente determinado.

Tus microservicios se exponen a los clientes a través de las API de REST, y tus aplicaciones cliente se comunican con las API de REST a través de una puerta de enlace API.

En el diagrama siguiente, se muestra un ejemplo de la arquitectura de microservicios de backend orientada al comercio.

Diagrama de arquitectura que muestra las arquitectura de los microservicios de backend

Arquitectura de frontend

La experiencia de usuario de los clientes en tus cargas de trabajo de comercio minorista, por lo general, incluye aplicaciones web responsivas (que a menudo se entregan como apps web progresivas) y, de forma opcional, como aplicaciones nativas para dispositivos móviles. En combinación con la arquitectura de backend mostrada antes, tus aplicaciones se construyen mediante el ensamble de múltiples componentes de frontend que corresponden y se comunican con las API y servicios de backend.

En el siguiente diagrama, se muestra un ejemplo de frontend de una aplicación web orientada al comercio.

Diagrama de arquitectura que muestra el frontend de una aplicación web orientada al comercio

Almacenamiento de datos

Las cargas de trabajo de comercio minorista deben conservar varias categorías de datos, como las siguientes:

  • Catálogo de productos: atributos de producto, como nombre, descripción, color y tamaño
  • Perfiles de compradores: datos de cliente, como nombre, edad, preferencias y direcciones de facturación y envío.
  • Transacciones de compradores: información sobre las compras de los clientes, como los artículos comprados y la fecha de compra.
  • Datos de flujo de clics: información que rastrea la ruta del comprador a través del sitio web.
  • Imágenes y videos de productos: contenido audiovisual relacionado con un producto en particular, lo que incluye contenido de origen y proporcionado por el cliente.
  • Calificaciones y reseñas: opiniones y comentarios de clientes sobre un producto.
  • Inventario de productos: datos sobre si un artículo está en stock y la llegada prevista de mercancía nueva

Cada categoría de datos se puede asignar a un mecanismo de almacenamiento de Google Cloud, como se muestra en la siguiente tabla.

Objeto No relacional Relacional Almacenamiento
Cloud Storage Cloud Datastore Cloud Bigtable Cloud SQL Cloud Spanner BigQuery
Imágenes
Videos
Catálogo
Perfiles
Facturas
Flujo de clics
Precios
Transacciones
Inventario
Calificaciones
Transacciones
Inventario
Calificaciones
Estadísticas
Almacenamiento

Catálogo de productos

En los catálogos, los productos tienen un conjunto de atributos, como nombre, descripción, etcétera. Sin embargo, a medida que crece la diversidad de tu catálogo de productos, también crece la cantidad de atributos distintos. Cada categoría de productos nueva tiene su propio conjunto de atributos que se pueden usar para buscar o filtrar, como los tamaños y colores de los artículos, o su tipo y modelo.

Para los catálogos de productos, la opción de almacenamiento más adecuada es, por lo tanto, una base de datos NoSQL orientada a documentos, que tiene un esquema flexible y puede almacenar atributos por categoría o por objeto. Datastore es una base de datos NoSQL orientada a documentos completamente administrada, que brinda asistencia para este caso práctico. En Datastore, los objetos se almacenan como entidades, y cada una admite pares clave-valor anidados, similar a la estructura de JSON. Datastore está disponible en varias regiones de Google Cloud y se ejecuta como un servicio siempre activo.

Contenido audiovisual de productos

Cada producto en un catálogo puede tener imágenes o videos de origen, y también puede tener imágenes o videos proporcionados por clientes. Puedes almacenar este tipo de elementos en un sistema de almacenamiento de objetos escalable, capaz de entregarlos de forma directa a aplicaciones web o aplicaciones para dispositivos móviles. Cloud Storage es un servicio de almacenamiento de objetos administrado que puede entregar datos en varias regiones. Cloud Storage ofrece diferentes niveles de acceso y disponibilidad de datos en función de tus necesidades. Para obtener un rendimiento alto, Cloud CDN aprovecha las ubicaciones perimetrales de Google distribuidas de manera global a fin de acelerar la entrega de contenido desde Cloud Storage. Esto garantiza que los elementos estáticos se ubiquen lo más cerca posible de los usuarios finales para minimizar la latencia de descarga.

Perfiles de compradores

Los perfiles de compradores tienen un conjunto de atributos coherente y son a menudo multidimensionales. Por ejemplo, algunos de tus clientes pueden tener múltiples direcciones de envío o formas de pago, cada una con su propia dirección de facturación.

Puedes almacenar perfiles de compradores en bases de datos relacionales con tablas múltiples. Sin embargo, también puedes usar bases de datos NoSQL orientadas a documentos para almacenar perfiles de clientes. Esto permite que los perfiles de tus compradores se almacenen como objetos únicos enriquecidos que contienen todos los datos de un cliente determinado. Datastore es una base de datos NoSQL orientada a documentos completamente administrada que puede brindar asistencia para este caso práctico.

Calificaciones y reseñas

Las calificaciones y reseñas de productos que dejan los clientes consisten en conjuntos de datos bastante simples, y puedes conservar esta información con diferentes mecanismos de almacenamiento. Es común usar esquemas relacionales que contienen campos como ID del producto, ID de cliente, valor de calificación y texto de reseña. Puedes almacenar estos datos mediante Cloud SQL o Spanner. En la mayoría de los casos prácticos, Cloud SQL es el sistema más adecuado para almacenar datos de calificaciones y reseñas. Si las aplicaciones requieren mayor capacidad de procesamiento transaccional y escalabilidad horizontal, Spanner es la mejor opción. Para obtener más información sobre qué servicio de base de datos usar, consulta Elige una opción de almacenamiento.

Transacciones y facturas

Al igual que con las calificaciones y reseñas, puedes conservar las transacciones y facturas de los compradores o los detalles de los pedidos con diferentes mecanismos de almacenamiento. Las transacciones deben almacenarse en sistemas de bases de datos que admitan la semántica de ACID, en particular, la capacidad de confirmar escrituras de forma atómica. Datastore, Cloud SQL y Spanner admiten operaciones atómicas. En la mayoría de los casos prácticos, los sistemas relacionales son una buena opción para las transacciones, ya que los datos se estructuran de manera coherente de una escritura a la siguiente. La elección del sistema de almacenamiento depende en gran medida de qué sistema encuentras más cómodo, SQL o NoSQL, y de si las aplicaciones se pueden personalizar para la base de datos elegida.

Las facturas también se pueden almacenar con bases de datos relacionales o NoSQL; tu elección debe basarse en los casos prácticos posteriores. En las cargas de trabajo modernas de comercios, las bases de datos NoSQL orientadas a documentos, como Datastore, a menudo se usan para conservar facturas o detalles de pedidos, ya que el estado completo de la factura se puede almacenar como un único objeto enriquecido. Para las cargas de trabajo de comercios más tradicionales, Cloud SQL o Spanner también pueden ser opciones adecuadas.

Si deseas obtener más información sobre qué servicio de base de datos usar para transacciones y facturas, consulta Elige una opción de almacenamiento.

Si tu entorno está basado por completo en la nube, los datos de transacciones y facturas residen por completo en la infraestructura de nube. Por otro lado, si trabajas con un entorno híbrido, debes sincronizar los datos entre el entorno de nube y tu entorno local. En el entorno híbrido, los datos de transacciones y facturas, por lo general, residen en la infraestructura local. En ese caso, puedes sincronizar sistemas de backend con la infraestructura de datos en la nube mediante una combinación de aplicaciones personalizadas, Pub/Sub o la replicación de bases de datos.

Datos de flujo de clics

Los datos sobre el tráfico de clientes a menudo se capturan a través de paquetes de estadísticas como Google Analytics. Sin embargo, es posible que desees recopilar estos datos de navegación (datos de flujo de clics) en tiempo real.

Hay muchos métodos para capturar datos de flujo de clics, como el uso del seguimiento de píxeles sin servidores mediante Google Cloud. Los conjuntos de datos producidos en el seguimiento del flujo de clics suelen ser muy grandes y, a menudo, se usan como fuentes para el aprendizaje automático o las estadísticas predictivas. Por lo general, este tipo de datos se almacena en sistemas NoSQL de columna ancha, como Bigtable. Bigtable admite conjuntos de datos a gran escala (hasta cientos de petabytes) y proporciona una latencia baja y una capacidad de procesamiento alta, lo que es útil para este caso de uso.

Inventario de productos

Los datos sobre la disponibilidad de un producto son de vital importancia para la experiencia general del cliente. Los datos de inventario a menudo consisten en conjuntos de datos que contienen SKU de productos, inventario actual y fecha prevista del inventario adicional. Sin embargo, dada la forma en que estos datos se usan a menudo en las aplicaciones, el mecanismo de almacenamiento debe admitir transacciones y operaciones atómicas para reflejar con precisión los niveles de inventario. Datastore, Cloud SQL y Spanner admiten operaciones atómicas. En la mayoría de los casos prácticos, los sistemas relacionales son una buena opción para los datos de inventario porque los datos se estructuran de manera coherente. Para obtener más información sobre qué servicio de base de datos usar, consulta Elige una opción de almacenamiento.

Al igual que con los datos de transacción, si tu entorno está basado por completo en la nube, los datos de inventario residen en la infraestructura de datos en la nube. Si trabajas con un entorno híbrido, debes sincronizar los datos entre el entorno de nube y tu entorno local. En el entorno híbrido, los datos de inventario, por lo general, residen en la infraestructura local. En ese caso, puedes sincronizar sistemas de backend con la infraestructura de datos en la nube mediante una combinación de aplicaciones personalizadas, Pub/Sub o la replicación de bases de datos.

Arquitecturas de implementación

Cuando usas Google Cloud, por lo general, implementas microservicios mediante Cloud Run o Google Kubernetes Engine. Cloud Run es una plataforma de procesamiento administrada que te permite ejecutar contenedores sin estado que se pueden invocar a través de solicitudes web o eventos de Pub/Sub. GKE se basa en Kubernetes, un mecanismo de organización de contenedores y administración de clústeres de código abierto. La elección de la plataforma para tu implementación depende del nivel de flexibilidad que necesitas y de la complejidad de la infraestructura de tu aplicación.

Para obtener más información, consulta Elige una opción de procesamiento. En esta guía, presentamos ambas opciones de implementación.

Usa Cloud Run

En el siguiente diagrama, se muestra un ejemplo de implementación con microservicios mediante Cloud Run.

Diagrama que muestra la implementación con microservicios mediante Cloud Run.

Cloud Run aumenta y disminuye automáticamente la escala de instancias que ejecutan las aplicaciones según el tráfico entrante. Cuando implementas tu aplicación en una arquitectura de microservicios mediante Cloud Run, tu aplicación se empaqueta como un contenedor y se implementa como un servicio. Los servicios pueden ejecutarse en varias instancias de contenedor y escalar de forma independiente entre sí. Cloud Run aprovisiona automáticamente los recursos de balanceo de cargas y proporciona capacidades para administrar revisiones de microservicios individuales y dividir el tráfico entre las versiones.

Cloud Run está compilado a partir de Knative, que te permite ejecutar contenedores completamente administrados en Cloud Run, en tu clúster de Google Kubernetes Engine o en un entorno local con Cloud Run for Anthos. Los servicios de Cloud Run se implementan dentro de una sola región o un espacio de nombres de clúster de GKE, y se replican de forma automática en varias zonas de la región en la que se encuentran para obtener redundancia y conmutación por error. Un solo proyecto de Google Cloud puede ejecutar muchos servicios en diferentes regiones o clústeres de GKE.

Debes aprovisionar y operar la infraestructura de almacenamiento de datos por separado de Cloud Run. Por ejemplo, tu aplicación en Cloud Run puede conectarse a una base de datos de PostgreSQL administrada por Cloud SQL para el almacenamiento de datos relacionales.

En el siguiente diagrama, se muestra un ejemplo de la arquitectura para una implementación multirregional de Cloud Run.

Diagrama que muestra la implementación mediante una instancia multirregional de Cloud Run.

Usa GKE

En el diagrama siguiente, se muestra un ejemplo de implementación con microservicios mediante GKE.

Diagrama de la implementación con microservicios mediante GKE

Cuando usas GKE, cada microservicio tiene un ciclo de vida de implementación y desarrollo separado. Cada microservicio se empaqueta como un contenedor de Docker. Debes implementar estos contenedores como un pod y servicio de Kubernetes de una de las maneras siguientes:

GKE admite los pods con ajuste de escala automático, según el uso de CPU, con el escalador automático horizontal de pods. Además, los clústeres de GKE también admiten el ajuste de escala automático mediante el escalador automático de clústeres de GKE, que cambia el tamaño de los clústeres de forma automática según los recursos saturados o con poco uso.

Los clústeres de GKE son recursos regionales y, para implementaciones que requieren alta disponibilidad, debes crear implementaciones en zonas múltiples. Para obtener más información, consulta Descripción general de los clústeres de GKE multizonales.

Para las implementaciones que deben realizar entregas a una base de clientes global, implementa varios clústeres de GKE en un solo proyecto, uno por región. El almacenamiento de datos para cada microservicio se aprovisiona y opera desde el mismo proyecto que los clústeres de GKE.

¿Qué sigue?