Cómo implementar sistemas basados en secuencias de eventos con Cloud Spanner

Con un patrón de arquitectura como ejemplo, en este artículo se explica cómo usar Cloud Spanner como un sistema de transferencia de eventos y Cloud Pub/Sub como un registro de eventos para crear un sistema que pueda realizar las tareas siguientes:

  • Escribir a una fuente de evento que tenga alta disponibilidad.
  • Publicar estas operaciones de escrituras como eventos para el uso por parte de otros sistemas.
  • Archivar eventos para su reproducción.
  • Cargar eventos en un sistema para elaborar estadísticas.
  • Filtrar eventos en un sistema para realizar consultas rápidas.

Este artículo está destinado a ingenieros de software que estén interesados en aprender acerca de los usos, las compensaciones y los componentes de un sistema basado en secuencias de eventos. Aprende a crear una gran cantidad de aplicaciones y servicios mediante Cloud Functions para respaldar tu arquitectura basada en secuencias de eventos.

Casos prácticos y criterios de diseño

Puedes usar este patrón de arquitectura cada vez que necesites realizar una acción relacionada con la escritura de datos nuevos en una fuente de datos, en este caso, Cloud Spanner.

Casos prácticos

Este patrón resulta útil para administrar las siguientes situaciones:

  • Carritos de compra de comercio electrónico.
  • Administración de pedidos y cadena de suministro.
  • Billeteras, pagos y resoluciones de cargos.

El siguiente diagrama ilustra el flujo de un sistema de carrito de compras de comercio electrónico.

El flujo de eventos en un carrito de compras de comercio electrónico.

En sistemas complejos, como el comercio electrónico y los pagos, resulta útil realizar un seguimiento de las transacciones mediante las arquitecturas basadas en eventos. Por ejemplo, cuando un cliente agrega un artículo a su carrito de compras o procesa una tarjeta de crédito a la hora de realizar un pago, es posible que desees activar varios procesos descendentes para verificar que haya existencias del artículo y que la cuenta del cliente tenga fondos. Es importante asegurarse de que los clientes puedan realizar pedidos en todo momento, ya que tu negocio depende de ello.

Criterios de diseño

A continuación, se presentan algunos ejemplos de criterios de diseño que sugieren la utilización de un sistema de arquitectura basado en secuencias de eventos:

  • Debe administrar la escritura de pedidos y pagos al sistema con alta disponibilidad.
  • Debe verificar que sus clientes reciban los artículos que pidieron (y solamente estos artículos) y que se les cobre el monto de dinero correcto por la compra.
  • Debe tener modos de falla deterministas (es decir, debes estar seguro de que tu escritura falló o tuvo éxito).
  • Debe incluir un mecanismo para notificar a los servicios dependientes que se realizó una operación de escritura que era de su interés.

En este artículo, se describe un sistema que puede satisfacer todos estos requisitos y proporcionar flexibilidad para agregar funcionalidades más adelante.

Arquitectura del sistema

En primer lugar, necesitas un servicio que pueda aceptar operaciones de escritura con alta disponibilidad. Ese sistema también debe proporcionar modos de falla deterministas. El sistema debe saber cuándo una escritura falla, de modo que el escritor pueda reintentar la escritura sin miedo de duplicarla entera o parcialmente.

La aplicación canónica de esta situación es una base de datos que admita transacciones con atomicidad, coherencia, aislamiento y durabilidad (ACID), pero lograr que las bases de datos tengan alta disponibilidad, sobre todo para las operaciones de escritura, es difícil. La replicación puede provocar incoherencias en los datos y puede incrementar el costo y la complejidad de tu arquitectura. Empeorar la complejidad es uno de los mayores riesgos de diseño cuando la alta disponibilidad es una prioridad.

Además, las configuraciones de bases de datos de alta disponibilidad no pueden lidiar con fallas en distintas zonas de disponibilidad sin incurrir en demoras de replicación. A medida que aumentan esas demoras, también aumenta la probabilidad de que las fallas adicionales provoquen la pérdida de todas las operaciones de escritura que estén en tránsito a ese nodo de réplica en otra zona de disponibilidad. Estas fallas adicionales significan que las operaciones de escritura no se escriben completamente en la réplica antes de la falla en esa zona.

Diagrama de arquitectura

En el diagrama siguiente, se ilustra una arquitectura basada en secuencias de eventos con Cloud Spanner y diseñada para resolver los problemas de complejidad y costo asociados con las bases de datos con alta disponibilidad tradicionales.

Diagrama arquitectónico basado en secuencias de eventos con Cloud Spanner.

Esta arquitectura basada en secuencias de eventos se apoya en los siguientes componentes, que puedes crear con Cloud Functions. Estos componentes consisten en aplicaciones y Cloud Functions.

  • Aplicación de sondeo: sondea Cloud Spanner, convierte el formato de registro en Avro y publica en Cloud Pub/Sub.
  • archiver: obtiene los eventos activados por los mensajes publicados en un tema de Cloud Pub/Sub y escribe esos registros en un archivo global en Cloud Storage.
  • bqloader: se activa cuando se escriben los registros en Cloud Storage y carga esos registros en una tabla de BigQuery correspondiente.
  • janitor: lee todas las entradas escritas en el archivo global con un ritmo determinado y, luego, los comprime para su almacenamiento a largo plazo.
  • replayer: lee los registros en orden desde el almacenamiento a largo plazo, los descomprime y los carga en un flujo de Cloud Pub/Sub nuevo.
  • Aplicación de materialización: filtra los registros escritos en Cloud Pub/Sub y, luego, los carga en la base de datos de Redis correspondiente (vista materializada) para un fácil acceso de consulta.

Cómo crear un servicio de sondeo

Una vez que hayas establecido un sistema que acepte operaciones de escritura, debe notificarse a tus servicios descendentes cada vez que se escribe algo en el sistema.

Las bases de datos tradicionales realizan esta tarea de distintas maneras, pero generalmente escuchan al registro de escritura por adelantado (WAL) o al flujo de captura de datos de cambio (CDC) de una base de datos. Estas soluciones no se encuentran en un formato útil para la legibilidad. El formato se diseñó para representar y transmitir los cambios realizados al registro. No se diseñó para informar a un sistema descendente sobre eventos y pasar el contexto relevante de esos eventos. Contar con una representación binaria solo de los cambios, y no un registro completo, no resulta útil en la mayoría de los casos. Otra desventaja de ese formato es que no es legible por humanos, lo que dificulta en gran medida la depuración y la auditoría del flujo.

En su lugar, puedes crear una solución que sondea la base de datos para obtener todas las nuevas entradas y las pasa al sistema descendente. Los servicios de sondeo son una manera común de procesar nuevos registros escritos en una base de datos y presentan las siguientes ventajas:

  • Son fáciles de comprender y escribir.
  • Presentan bajas sobrecargas cuando se escriben de forma correcta.
  • Son independientes y estables.
  • Toleran los errores, tanto para consultas como para el análisis de los registros.
  • Resultan flexibles en cuanto a la forma de filtrarse y representar los cambios.

Entre las compensaciones por escribir un servicio de sondeo en lugar de usar un WAL o una CDC convencionales, se incluyen las siguientes cuestiones:

  • Sondear una base de datos de a intervalos cortos (menos de un segundo) puede agregar cargas a tu base de datos.
  • Según el diseño de tu tabla, la consulta que usas para sondear y cuántas otras aplicaciones estén sondeando tu base de datos actualmente, un servicio de sondeo podría crear una contención de recursos (bloqueos) con otras aplicaciones.
  • El sondeo puede requerir que uses máquinas de bases de datos de mayor tamaño y almacenamiento más costoso (como SSD) para administrar la carga adicional y la contención de recursos.

Si deseas ayudar a mitigar algunas de estas compensaciones en Cloud Spanner, usa transacciones de solo lectura para tus lecturas de sondeo y asegúrate de aplicar las prácticas recomendadas de SQL a fin de realizar consultas eficientes y eficaces.

Para encontrar todos los nuevos registros de un período determinado, puedes usar la característica de marca de tiempo de confirmación en Cloud Spanner. La marca de tiempo de confirmación se basa en la tecnología TrueTime y proporciona a Cloud Spanner una representación coherente a nivel global del momento en que se confirmó una escritura a la base de datos. Cloud Spanner puede aceptar operaciones de escritura en numerosas regiones en todo el mundo y tu aplicación de sondeo puede crear un registro que contiene una representación exacta de los eventos en orden.

Cómo usar Cloud Functions para representar tareas

Cloud Functions es una plataforma de procesamiento sin servidores controlada por eventos en GCP. Estas funciones son fragmentos de código sin estado que se ejecutan en respuesta a un activador, como una solicitud HTTP o un activador de evento. En el caso de los sistemas basados en secuencias de eventos, Cloud Functions representa generalmente las tareas individuales asociadas con un evento que se publica. Debido a que se trata de funciones sin servidores, se escalan con tu volumen de solicitudes y no requieren la intervención de operaciones adicionales.

A continuación, se enumeran algunas compensaciones de Cloud Functions:

  • Los tiempos de respuesta pueden ser incoherentes.
  • El registro y el seguimiento pueden ser más difíciles debido a la naturaleza efímera del inicio y la ejecución.
  • Deben ser funciones sin estado y también idempotentes, ya que el reintento en caso de falla es generalmente automático.
  • Puede ser difícil depurar y reproducir errores de manera local, según el estado de tu entorno de registro.

Cómo usar Cloud Pub/Sub como un registro

Este registro es de solo anexar y registra los eventos publicados en un bus de eventos o una cola de mensajes de algún tipo. Para suscribirte o detectar un evento, puedes suscribirte a un bus de eventos en particular o a un tema de cola de mensajes, o filtrar la colección de todos los mensajes por el sustantivo, el verbo o los metadatos en particular que te interesen.

En este patrón, el registro es un único tema de Cloud Pub/Sub. Puedes usar el sistema de eventos para activar Cloud Functions cada vez que se escribe un registro en el flujo.

Asegúrate de que tus suscriptores no reconozcan el mensaje, de modo que permanezca disponible para otras funciones interesadas. Además, existe una ventana de retención de mensajes en la cola limitada, por lo que debes crear una Cloud Function que realice una copia de seguridad de estos mensajes en un archivo. Cuando desees consultar mensajes archivados, puedes usar una Cloud Function con el objetivo de leer los mensajes archivados y publicarlos en un nuevo tema de Cloud Pub/Sub para su consumo.

Cómo usar una aplicación de sondeo para consultar la base de datos

El trabajo de la aplicación de sondeo es consultar la base de datos a intervalos fijos y pedir todos los registros que ocurran después de un momento en el tiempo en particular, ordenados según las marcas de tiempo de confirmación y en orden descendente (el registro más antiguo en primer lugar).

Requisitos de la aplicación de sondeo

Este diseño implica que debes realizar un seguimiento de la última marca de tiempo que vio la aplicación de sondeo y que debes ejecutar un bootstrap del sistema para la primera ejecución. Para realizar un seguimiento de esta marca de tiempo, puedes almacenarla en el estado de aplicación, escribirla en otra base de datos o pedirle al registro su entrada más reciente y analizar la marca de tiempo a partir de ella.

Almacenar el registro en otra base de datos puede agregar complejidad adicional, ya que crea una dependencia en otro sistema que agrega otro punto de falla. Es mejor mantener la marca de tiempo del último proceso en el almacenamiento local de la aplicación y solo recurrir a la consulta del registro si la aplicación falla o se reinicia por algún motivo y se pierde el estado interno.

Los requisitos de la aplicación de sondeo son los siguientes:

  • El intervalo de sondeo debe ser fijo y coherente.
  • El intervalo de sondeo debe ser menor de 1 segundo.
  • Ejecuta un bootstrap del sistema la primera vez que se ejecuta.
  • Consulta todos los registros que ocurren después de la marca de tiempo registrada previamente.
  • Serializa cada registro en un registro individual de Avro.
  • Publica cada registro de Avro en un registro de eventos basado en Cloud Pub/Sub.
  • Se suspende hasta que haya transcurrido el intervalo de sondeo.
  • Si se produce una falla, lo reintenta automáticamente dentro de su intervalo fijo.
  • Si se produce una falla, cuando se reinicia la aplicación de sondeo, consulta el flujo de Cloud Pub/Sub para obtener la última marca de tiempo registrada. Si este proceso falla, puedes iniciar la aplicación de sondeo con una marca de tiempo configurada de manera manual. También puedes obtener la marca de tiempo de los archivos de Cloud Storage.

Cómo diseñar la aplicación de sondeo

A continuación, debes diseñar la aplicación de sondeo. Existen al menos tres maneras diferentes de diseñarla, cada una con sus compensaciones.

Puedes usar Cloud Scheduler para programar una Cloud Function que sondee la base de datos, puedes iniciar tu aplicación de sondeo en un clúster de Kubernetes como un trabajo cron y programarla según el intervalo que prefieras, o bien puedes tener un servicio que se ejecute continuamente en un pod de Kubernetes y que sondee la base de datos de a intervalos fijos, para conservar y actualizar la última marca de tiempo procesada en la memoria.

Sabiendo que debes consultar la base de datos a un intervalo fijo, puedes considerar usar Cloud Scheduler para programar una Cloud Function que sondee la base de datos y, luego, enviar los nuevos registros a un flujo de Cloud Pub/Sub.

Este enfoque funciona, pero conlleva dos compensaciones. En primer lugar, debes idear una manera de preservar el estado de la aplicación debido a que las Cloud Functions no tienen estado, por definición. Preservar el estado de la aplicación implica ingresar una base de datos adicional y agregar incoherencias en la latencia entre los eventos que se escriben y los eventos que se agregan al registro. A veces, las Cloud Functions pueden tardar más de lo esperado en generarse y ejecutarse. Esta demora se incrementa a medida que se reduce el intervalo de sondeo.

Si todos tus consumidores descendentes previsibles pueden tolerar una latencia variable que podría ser mayor que un segundo ocasionalmente, una Cloud Function programada podría ser la mejor opción para el diseño de tu sistema. En ese caso, tu Cloud Function realiza un seguimiento de la última marca de tiempo procesada mediante una consulta al flujo de Cloud Pub/Sub o almacena el estado en Cloud Storage. Si bien se reduce la complejidad de administrar sistemas como Kubernetes, otra compensación que se debe considerar en el caso de Cloud Functions es que esas consultas adicionales agregan latencia debido a la llamada adicional para obtener la marca de tiempo, por lo que se puede agregar otro punto de falla en tu sistema de sondeo. Si puedes tolerar la latencia de esa llamada adicional, puedes usar una Cloud Function en este caso.

También tienes la opción de iniciar tu aplicación de sondeo en un clúster de Kubernetes como un trabajo cron y programarla según el intervalo que prefieras. Lamentablemente, este enfoque tiene compensaciones semejantes a las de Cloud Scheduler, con la complejidad adicional de agregar Kubernetes. Sin embargo, puedes iniciar el trabajo como un servicio en Kubernetes y mantenerlo en suspensión durante un intervalo establecido, que puedes controlar en el bucle de eventos principales de la aplicación. Puedes mantener el estado y tener un control completo de la latencia de sondeo y la semántica de reintento. Si bien esta opción agrega la complejidad de Kubernetes, que puedes mitigar gracias a Google Kubernetes Engine (GKE), te proporciona control total sobre los siguientes aspectos:

  • El estado entre sondeos (la última marca de tiempo).
  • La latencia entre sondeos.
  • La semántica de reintento y la duración si falla la operación de lectura de Cloud Spanner o la operación de escritura de Cloud Pub/Sub.
  • Reinicio automático del servicio de sondeo si se cierra o finaliza inesperadamente.

Cómo ejecutar un bootstrap de la aplicación de sondeo

La primera vez que ejecutes la aplicación de sondeo, esta configura todos los componentes requeridos para ejecutar el sistema basado en secuencias de eventos. Esto incluye el flujo de Cloud Pub/Sub con el nombre correcto (idealmente, el nombre de la tabla) y el depósito de Cloud Storage en el que debe publicar el archiver. Una vez configurados todos los componentes del sistema, el proceso de bootstrap del sistema de sondeo realiza un escaneo de tabla inicial y procesa todos los datos existentes. Cuando la aplicación de sondeo ha finalizado, se mueve al intervalo de sondeo fijo y pasa la última marca de tiempo de confirmación procesada para que el sistema de sondeo la utilice en su primera ejecución de procesamiento.

Cómo usar un registro para interpretar datos

Una vez que tengas la aplicación de sondeo programada y que esté recopilando los últimos datos, necesitarás representar esos datos en el registro. Debido a que esta es una solución generalizada (es decir, puedes reutilizar esta aplicación de sondeo para varias tablas distintas con distintos esquemas), escribir aplicaciones de sondeo y registros de consumidores específicos de una tabla no resulta una solución escalable. También deberás tener la posibilidad de agregar distintos consumidores al registro sin que estos conozcan las variaciones del esquema con versión de antemano.

Estos son algunos casos prácticos potenciales:

  • Archivo a largo plazo de todas las transacciones.
  • Carga de las transacciones en un almacén de datos para elaborar estadísticas.
  • Carga de las transacciones en una base de datos NoSQL para alimentar modelos de aprendizaje automático y potencialmente almacenar en caché las respuestas a las preguntas frecuentes más cerca del usuario.

En estos casos prácticos, considera usar un formato de serialización, como Avro, JSON o Protobuf. BigQuery, la solución de almacenamiento de datos de Google, es compatible con la transferencia de datos directamente a partir de archivos Avro. Avro es el formato preferido para cargar datos en BigQuery. Cargar archivos Avro en vez de JSON presenta las siguientes ventajas:

  • Carga más rápida. Los datos se pueden leer en paralelo, incluso si los bloques de datos están comprimidos.
  • No requiere escritura o serialización.
  • Es más fácil analizar los archivos porque no existen los problemas de codificación inherentes que a veces se encuentran en otros formatos.

Cuando cargas los archivos de Avro en BigQuery, el esquema de la tabla se infiere de forma automática desde los datos de origen de descripción automática.

Protobuf representa una alternativa a Avro, pero en este caso práctico Avro presenta dos ventajas destacadas:

  • Es compatible con la transferencia directa en BigQuery.
  • El esquema está contenido en el objeto de datos.

La última ventaja permite que los consumidores del registro obtengan datos y los inspeccionen. No es necesario que deserialicen JSON y esperen que el formato no cambie, o que obtengan una versión de un registro de esquema para una versión determinada de ese objeto.

Por estos motivos, serializa tus tablas desde Cloud Spanner en un objeto Avro para cada transacción antes de ubicarlas en el registro. Para obtener más información, consulta cómo transformar una tabla de Cloud Spanner en un registro de Avro.

Cómo escribir la aplicación de sondeo

Una vez que tomes una decisión sobre el modelo de implementación y el formato de serialización, reflexiona sobre tus opciones de lenguaje para escribir la aplicación de sondeo. Dado que el objetivo es leer datos de Cloud Spanner y escribirlos en Cloud Pub/Sub, solo puedes usar los lenguajes admitidos por las API de Google Cloud. Estos lenguajes son C#, Go, Java, Node.js, PHP, Python y Ruby.

De los lenguajes admitidos actualmente en Cloud Spanner, Avro admite de manera oficial C#, Java, Python, PHP y Ruby. Debido a que es recomendable que tengas el mayor control posible sobre la latencia de tu aplicación y que proceses las tablas consultadas en varios subprocesos, Java es una buena opción.

Cómo usar el flujo de eventos

La aplicación de sondeo es la aplicación principal del servicio, pero también existen otros consumidores del flujo.La primera aplicación que necesitas es una que se suscriba al flujo y archive cada mensaje en Cloud Storage para referencia histórica. Este sistema almacena cada registro como un archivo separado en un depósito con el mismo nombre que la tabla.

Cada hora (o según tu frecuencia de transacción), habrá otro servicio que tome esos registros de transacciones individuales y los comprima en un archivo mayor. Según la frecuencia de tus transacciones y el tamaño de tus registros de transacciones, tal vez quieras considerar comprimir también los archivos Avro de cada transacción individual.

Una vez que hayas archivado todas tus transacciones históricas en Cloud Storage, puedes hacer lo siguiente:

  • Propagar BigQuery directamente con datos de transacciones para elaborar estadísticas
  • Reproducir registros históricos para entrenar o probar otros sistemas
  • Volver a compilar el contenido del sistema de registro (en este caso, la base de datos de Cloud Spanner) si se pierde o se daña
  • Crear una réplica histórica de solo lectura con fines de informes o auditoría
  • Crear una versión de la base de datos para entornos de etapas de pruebas

Cómo crear una Cloud Function de archiver

Crea una Cloud Function llamada archiver que se active cada vez que se agregue una transacción al flujo. Debes crear una nueva función y un activador por tema (una tabla en Cloud Spanner). Cada vez que se agrega una transacción al tema de Cloud Pub/Sub configurado, la Cloud Function archiver toma el registro Avro y lo escribe en un depósito de Cloud Storage con el mismo nombre que la tabla. La Cloud Function nombra el archivo con el nombre de la tabla, captura la fecha y hora en milisegundos, más 4 cifras al azar. Este esquema de nombramiento crea un ID similar al identificador único universal (UUID).

Cómo crear la Cloud Function bqloader

Ahora puedes crear una nueva Cloud Function llamada bqloader para cargar ese archivo Avro directamente en BigQuery. La función se activa cuando archiver sube el archivo a Cloud Storage. Cada vez que una transacción se carga en Cloud Storage, esta Cloud Function anexa la entrada de transacción en la tabla de BigQuery correspondiente. Si deseas reducir aún más la latencia para tareas como la elaboración de estadísticas o la alimentación de modelos de aprendizaje automático, puedes transmitir tus datos a BigQuery, de a un registro por vez, mediante el método tabledata.insertAll. Este enfoque permite consultar datos sin la demora de ejecutar un trabajo de carga. Ten en cuenta las cuotas de BigQuery para cargar registros.

Cómo crear una Cloud Function janitor

La Cloud Function archiver escribe el archivo Avro en un depósito de Cloud Storage. A continuación, tendrás que crear otra Cloud Function llamada janitor a fin de comprimir todas las transacciones individuales en un solo archivo comprimido para el almacenamiento a largo plazo. janitor nombra este archivo que se acaba de crear usando el nombre de la tabla, la fecha y el lapso temporal incluido en los archivos. Por ejemplo, si janitor está programado para ejecutarse cada hora, el nombre del archivo podría ser table1-jan_1_2019_1200-1300.tar.gz. La Cloud Function janitor no es un requisito, pero contribuye a reducir los costos de almacenamiento y a mantener los depósitos de Cloud Storage organizados.

Cómo crear la función de Cloud Function replayer

Si deseas reproducir los archivos Avro almacenados en Cloud Storage, necesitas otra función de Cloud Function, llamada replayer, que es activada por HTTP. La función replayer de Cloud Function toma los archivos almacenados correspondientes al período que solicitaste para la reproducción, los expande y los publica, en orden, en un nuevo flujo de Cloud Pub/Sub.

Esta función de Cloud Function se activa mediante una solicitud HTTP POST que proporciona el período que deseas reproducir. La función de Cloud Function responde con el nombre del flujo de Cloud Pub/Sub después de terminado, o con el código de error y la descripción si no se pudieron cargar de manera correcta todos los datos archivados en el nuevo flujo.

Si tus archivos almacenados se vuelven demasiado grandes para reproducirlos de manera coherente o si la reproducción se vuelve demasiado lenta para tu caso práctico, esta aplicación podría requerir algo más sofisticado. Puedes dividir tus archivos en secciones más pequeñas o crear una selección de lenguaje distinta para tu Cloud Function replayer.

Otra opción consiste en un trabajo de Cloud Dataflow para dividir el trabajo en tareas más pequeñas y ejecutarlo en paralelo. La implementación de un sistema como este excede el alcance de este documento, pero hay excelentes ejemplos disponibles en el repositorio de GitHub de GCP y en la documentación de Cloud Dataflow.

Cómo crear la aplicación de materialización

Con estos eventos en el registro y cada uno representando una sola transacción, puedes integrar distintas clases de servicios en el sistema de manera fluida sin necesidad de escribir código adicional y sin tener que coordinar entre los equipos de distintas aplicaciones.

Por ejemplo, esta aplicación detecta todos los mensajes relacionados con un tema determinado, filtra por nombre de cliente y crea una vista materializada de los datos relevantes de ese cliente. Idealmente, puedes usar esta aplicación cuando necesites consultar información acerca de un usuario y necesites acceder a ella con muy baja latencia.

Si puedes analizar los datos de manera temprana, colocarlos en un almacenamiento rápido y mostrar una respuesta detallada, puedes mejorar el rendimiento de las consultas que ejecutas con frecuencia.

Esta aplicación de materialización puede consistir en una sola Cloud Function que se activa mediante un tema de Cloud Pub/Sub, filtra la información por ID de cliente y, si el ID de cliente coincide con un ID de su interés, la Cloud Function escribe los datos relevantes en Cloud Memorystore.

Conclusión

Compilar una arquitectura de sistema basado en secuencias de archivos permite crear nuevas funcionalidades y agregar flexibilidad a cualquier sistema que necesite reaccionar ante eventos o comprender la relación entre ellos. Cuando el ordenamiento determinista o la capacidad de procesamiento de alta transferencia son importantes, usar Cloud Spanner como sistema de transferencia de archivos y Cloud Pub/Sub como registro de eventos puede llevar a compilar una base sólida y confiable para tu arquitectura basada en secuencias de eventos. Después de configurar la base de un sistema basado en secuencias de eventos, puedes descubrir las numerosas maneras en que los problemas que alguna vez fueron difíciles de resolver pueden convertirse en Cloud Functions simples o en soluciones suscritas a Cloud Pub/Sub.

Pasos siguientes

¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...