Plataforma de procesamiento de eventos

Publicado por

Índice

  • Introducción
  • Arquitecturas Event-driven
  • Data Flow vs Data Store (eventos vs registros)

1. Introducción

En este artículo quiero hablar de cosas básicas en el diseño de arquitecturas basadas en eventos que sean capaces de servir los datos en tiempo real y evitar las duplicidades del dato.

En el año 2020 todavía se siguen utilizando en las grandes compañías el intercambio de ficheros en horario nocturno para la carga de datos en aplicaciones y tenerlos disponibles a primera hora de la mañana. Esta práctica viene heredada de sistemas legacy que no permiten intercambiar datos de forma más reactiva. Los casos de uso en los que el dato es relevante durante un breve periodo de tiempo, o para aquellos sistemas que necesiten los datos actualizados intradía tenemos que valorar el uso de las arquitecturas basadas en eventos.

Esta filosofía cambia el concepto de cómo diseñamos casos de uso, ya que estos se tienen que diseñar utilizando servicios básicos, desacoplados y reutilizables para ganar agilidad en la puesta en producción. En estos escenarios la transaccionalidad se pierde; más adelante veremos el porqué.

El sistema de almacenamiento escogido para los datos es importante para centralizar su consumo, dependiendo de la utilidad del dato podremos escoger sistemas más orientados a la transaccionalidad, o por el contrario más orientados al relacional. Tenemos que evitar la carga del mismo dato en diferentes sistemas para mejorar su trazabilidad y servir la misma versión a todas las aplicaciones. El consumo normalmente lo diseñamos utilizando una arquitectura de microservicios orientada a eventos, de esta manera dejaríamos en la capa de servicios la lógica de negocio necesaria para su consumo.

2. Arquitecturas event-driven

Las arquitecturas event-driven se basan en patrones de diseño de sistemas distribuidos y asíncronos; en la actualidad son muy populares porque permiten diseñar aplicaciones con una capacidad de escalado muy alta. Son arquitecturas bastante adaptables que se pueden utilizar tanto con aplicaciones complejas como con sencillas. Uno de los principios que guían el diseño es el de dividir el procesamiento y el acceso a otros sistemas en componentes sencillos y desacoplados que reciben y procesan eventos de forma asíncrona.

Los beneficios que podemos destacar son:

  • Escalabilidad elástica horizontal
  • Flexibilidad arquitectura
  • Microservicios event-driven
  • Ciclos de vida separados
  • Industrializar despliegues

Las arquitecturas basadas en eventos están divididas de dos topologías: la mediadora y la broker. La mediadora se suele utilizar cuando se necesita orquestar múltiples pasos para un mismo evento y la de broker cuando se encadenan eventos sin un mediador central. Debido a que las características de las arquitecturas y las estrategias de implementación difieren entre estas dos topologías, es importante comprender cada una para saber cuál es la más adecuada para su situación particular.

La topología de mediador es útil para el procesamiento de eventos que tienen múltiples pasos y requieren cierto nivel de orquestación para procesar el evento. Está formado principalmente por cuatro componentes:

  • colas de eventos
  • un mediador de eventos
  • canales de eventos
  • procesadores de eventos

La topología de broker difiere de la del mediador en que no existe un orquestador de eventos central; más bien, el flujo de mensajes se distribuye a través de los componentes del procesador de eventos en una cadena de forma secuencial. Los dos componentes principales son:

  • broker: colas, topic o una combinación de ambos
  • procesadores de eventos

Cuando trabajamos con arquitecturas guiadas por eventos, dado su caracter distribuido y asíncrono tenemos que entender que los patrones son complejos de implementar. Problemas típicos a los que nos tendremos que enfrentar son asegurar la disponibilidad de procesos remotos, timeouts, balanceos, reprocesos de datos, reconexiones del intermediador, etc.

Cuando diseñamos sistemas bajo este paradigma nos olvidamos de lo que eran las transacciones atómicas para un proceso de negocio. Esto se debe a que los componentes de procesamiento de eventos están bastante desacoplados y distribuidos y es muy difícil mantener una unidad de trabajo transaccional entre ellos.

Por esta razón, cuando diseñemos una aplicación teniendo en cuenta este patrón, habrá que pensar en que eventos pueden ejecutarse de forma independiente y cuales no; si existen eventos que no pueden dividir su procesamiento en dos unidades diferentes de procesamiento, quizás este no sea el patrón más adecuado para resolver el problema.

Uno de los aspectos más difíciles al utilizar este patrón es la de crear, mantener y gobernar los contratos de los componentes de procesamiento de eventos. Habría que resaltar la importancia de utilizar un formato de datos estándar y establecer una política de versiones de contratos desde el principio. Los contratos no se refieren a interfaces, sino a la entrada de los procesadores de eventos.

3. Dataflow vs datastore

Por la propia naturaleza de los datos, algunos de ellos o alguna acción derivada de ellos, solo es relevante durante un instante en el tiempo, y es ahí cuando debemos de capturarlo, procesarlo, aplicarle la lógica de negocio y desencadenar una acción. En las arquitecturas orientadas a eventos disponemos de las herramientas adecuadas para procesar los datos mientras se encuentran en movimiento. Algunos ejemplos:

  • Cancelar una transacción antes de que se produzca un fraude
  • Enviar una promoción cuando un cliente entre en una tienda
  • Mantenimiento predictivo, reemplazo de piezas antes de que se rompan
  • Información al cliente de transportes, retrasos, actualizaciones, cupones..

El evento que se encuentra en movimiento pueden interactuar con otros sistemas informacionales para enriquecerse y que vaya viajando por las distintas unidades de procesamiento. El viaje de un evento puede terminar en algún repositorio de datos y dependiendo de su naturaleza, será servido en una capa de consumo rápido o pasará a una capa de datos en reposo para consultas posteriores.

A continuación algunas de las características que debe de tener una plataforma de análisis de datos en streaming:

Para alimentar cualquier plataforma en streaming los datos tienen que ser suministrados en forma de eventos para su procesamiento en tiempo real, estos eventos también pueden ser producidos en batch. En el pasado todos los servicios estaban centralizados en sistemas de almacenamiento de datos en reposo lo que hacía imposible crear servicios ágiles y flexibles.

Un sistema central escalable y distribuido para dar un soporte al viaje de los eventos que se originan en distintas fuentes y se mueven a distintos destinos es fundamental. Una infraestructura distribuida, escalable, y construida sobre una arquitectura diseñada para que el que tiempo de inactividad sea 0, manejando los fallos de los distintos nodos y redes, y con la capacidad de mantener actualizado el software.

En la práctica los procesos de negocio pueden necesitar almacenar estados, a menudo esta necesidad se debe implementar con eventos y cambios de estado, no con llamadas a procedimientos remotos y patrones de petición/respuesta. Para ayudarnos podemos utilizar patrones como CQRS o Event Sourcing.

Después de todo lo escrito no hay que reinventar la rueda creando una plataforma de intercambio de mensajes utilizando algún sistema de mensajería tradicional, utiliza Kafka y tendrás gran parte del trabajo hecho.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s